“Serverless” architecture is a hot topic in the IT world, especially after AWS released their Lambda service. But many people are confused with the term “serverless.” The term is paradoxical because applications running on the “serverless” architecture are still using services that are powered by servers on the back end. The term is meant to be catchy and provocative, but what it really means is that, as a developer or as a company providing an app or services, you don’t need to provision, monitor, patch and manage any server. You can focus on building and maintaining your application and leave the server administration tasks to the cloud provider. This also means that you don’t have to worry about capacity planning. With the vast resources available on the cloud, your application scales with usage. In addition, availability, fault-tolerance and infrastructure security are already built-in.

Whereas on the traditional “always on” server sitting behind an application, you have to pay for its 24/7 operations, on a serverless architecture, you only pay for the time your application is running and you never have to pay for server idle time.

In this model, your application is only invoked if there is a trigger, such as changes in data state, requests from end user, changes in resource state, etc. Your program (or function that is written in node.js, Python, Java or C# programming languages) will then perform the task, and provide the output or service.

The obvious benefits of this model are reduced cost and reduced complexity. However, there are also drawbacks such as vendor control, vendor lock-in, multi tenancy concerns, and security issues.

As the “serverless” architecture becomes mainstream, more and more companies and developers will use this model to provide services.