To discuss Serverless Architecture we need to understand how we got here. From using physical machines we moved to virtual machines (somewhere in between a few brave folks also used linux/solaris containers). The current trend is container technologies such as Docker or CoreOS RKT which allow even more efficient use of resources. Regardless of which you use, we are often required to plan our application infrastructure needs upfront and permanently keep the “servers” running.

And that planning will also include things like – provisioning runtime infrastructure, dealing with networking, worrying about scaling for average or peak volumes, often having to design for the peaks (which may happen once or twice a year, but you don’t want to be caught with pants down on that day so you provision anyways), etc. These are real concerns engineers have to deal with. Some of this can be improved on if you leverage cloud platforms such as AWS or Google Cloud. In the cloud you can use features such as auto scaling to stop provisioning for the once in a year peak volumes and let dynamic elasticity handle that for you.

Recently there has been chatter on a new style of application architecture that is referred to as the Serverless Architecture. IMO this style of architecture has tremendous potential. Imagine a scenario where you no longer provision servers. Yes I just said that. All you deploy (to some magical place) is the bits of loosely coupled independent code snippets that make your business functions. When a request for a particular business function comes in, the platform spins up a runtime process which executes your code and then stops running. No servers were permanently provisioned. The “runtime process/server” lived for all of the few milliseconds that it took to run the code.

The shortfall I think is in the way we design existing applications. In the traditional deployment model, you spin up a few always running application instances which are ready to serve user requests. If you do not have always running instances, then each incoming request will have to spin up a runtime from scratch. In this new style your service bootup time has to be measured in milliseconds.

We are used to building monolithic architectures and now often modular architectures. The latter is a huge improvement from the traditional monoliths. You break down into a few modules each implementing a group of business/technical functions and each deployed/scaled on its own. The Microservices architecture takes it further by breaking down into even smaller & more manageable pieces and combines that with a solid operational runtime platform, which includes elastic scaling and real time monitoring. As we move towards Microservices Architecture style (regardless of whether or not you use PaaS), we create smaller app components that should each boot up faster but will they be fast enough for the Serverless Architecture. In the Serverless Architecture the boot up time for the code has to be really small. If you are paying for only the time your code runs then your code better be fast to load up since there may not be a pool of resources being held. And then you do not want to keep your caller waiting (SLA’s or simply being sensitive to user responsiveness).

Existing application design patterns and tools need to be further optimized for the Serverless Architecture style. New frameworks will be born with this new style in mind from day#1.In the AWS world you can take the API Gateway + AWS Lambda to implement this model. An interesting and enabling framework called Serverless Application Framework has come to life which is something you should evaluate if you are using AWS. I am happy to see Spring Cloud Task under the Spring Cloud umbrella now focusing on short lived microservices using Spring Boot. Add this into CloudFoundry and you have a PaaS that can support the same Serverless Architecture model. Google just released (alpha as of this writing) Google Cloud Functions which is their version of this new architecture style.

Why am I so excited? At many places provisioning & planning for infrastructure can be a nightmare. Second, with Serverless Architecture style we truly get to the absolutely best pay for what you use and only when you use model with the most optimal use of available infrastructure. I am going to be keeping a close eye on this, and if you read this far – then you should too.