Skip to main content
Serverless is a highly trending term in the world of software architecture, one can judge this from the many references of the term in journals, products, and open source frameworks, with even a webinar dedicated solely to the subject. Through this blog post, we shall learn about the basics of Serverless, why it is worth considering and the future. 

Origin of ‘Serverless’

First usages of the term seem to have appeared around 2012, including article by Ken Fromm. Also heard usage of the term around this time in regard to Continous Integration(CI) and source control systems being hosted as a service, rather than on a company’s own servers. However this usage was about development infrastructure rather than incorporation into products.
We start to see the term used more frequently in 2015, after AWS Lambda’s launch in 2014 and even more so after Amazon’s API Gateway launched in July 2015. Refer the talk at Amazon’s re:Invent conference titled “The Serverless Company using AWS Lambda”. Towards the end of 2015 the ‘Javascript Amazon Web Services (JAWS)’ open source project renamed themselves to the Serverless Framework.

What is serverless architecture?

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or "BaaS") or on custom code that's run in ephemeral containers (Function as a Service or "FaaS"). By using these ideas, and by moving much behavior to the front end, such architectures remove the need for the traditional 'always on' server system sitting behind an application. Depending on the circumstances, such systems can significantly reduce operational cost and complexity at a cost of vendor dependencies and (at the moment) immaturity of supporting services. The best known vendor host of which currently is AWS Lambda. 

The Future of Serverless

I’m going to discuss a few areas where I think the Serverless world may develop in the coming months and years.

Benefits of Serverless Architecture

Easier operational management
Faster innovation
Reduce operation cost


Architectural Complexity
Data Security


It is application system architecture, were relies to smaller extent services than usual on managing our own infrastructure. We do this through two techniques - Backend as a Service or "BaaS" OR ephemeral containers (Function as a Service or "FaaS"). 
Serverless is unlikely to be the correct approach for every problem, While there are benefits of scaling and saved deployment efforts. Those benefits shouldn't be quickly dismissed however since there are significant positive aspects to Serverless Architecture, including reduced operational and development costs, easier operational management, and reduced environmental impact.
The most important benefit to me though is the reduced feedback loop of creating new application components - I’m more towards agile/lean approaches, because I think there is a lot of value in getting technology in front of an end user as soon as possible to get early feedback, and the reduced time-to-market that comes with Serverless fits right in with this philosophy.


Popular posts from this blog

Individuals and interactions over processes and tools

Sprints, user stories, definitions of done, daily stand-ups, backlog grooming, sprint planning, retrospectives, burn-down charts, pair programming, technical spikes, continuous integration, test driven development, specification by example, refactoring…These words are now commonplace in our daily activities as IT professionals. We have lots of 'doing Agile' going on in projects. But, so what? As an industry we often get focused on the processes and the tools, and forget about the more important stuff, like people and business value. 'Doing Agile' is a waste of time if it doesn't help our organization be better by generating more value, or being more flexible or resilient to change, or creating great environments for people to work. In other words, 'doing Agile' is only really of value if it helps organization to achieve the state of 'being Agile'. Moving to 'being Agile'  The Agile manifesto warns us against focusing on '