Serverless Architecture is a way to build web applications on top of fully managed services from cloud service providers such as Amazon Web Services. The term “Serverless Architecture” was popularized by AWS, but it is now a fairly common name and the services needed for it can be found with most common cloud providers. IBM calls it “Service Oriented Architecture” and the term “Cloud Native” can also mean serverless.

The word “Serverless” is a bit of a misnomer, there are servers involved but they are fully managed by the cloud provider so you do not need to spend time procuring servers, installing an operating system or software, or maintaining and updating them. The cloud provider will also guarantee a certain level of redundancy and security for these services. Keep in mind that serverless is still relatively new so not all services have an enterprise level SLA yet.

Serverless Architecture will typically create a high degree of dependency on your cloud provider of choice. It’s possible, but not always easy, to move your solution to a different provider in the future. I believe that for most organisations, the benefits of cost, scalability and security far outweigh this risk, however.

Comparing the differences

Older software architectures tend to be monolithic. This means they are a single large chunk of code that contains all of the solution’s functions. With serverless, a single solution is split into many smaller parts also called “microservices”. Each of these will have a clearly defined and independent function or set of related functions.

From this structure we gain the following benefits:

The frontend (what users see) is also completely separate from the backend (the processing logic and functionality). This means that different front-ends (web, mobile, desktop) can all use the same back-end and access to data can be strictly controlled by the microservices.


A common advantage of moving to the cloud is that you can rely on their global, dedicated security team that are occupied 24/7 with monitoring and improving the security of the platform you are utilizing. With serverless, this is extended into the operating system and software which means your project and security scope is even smaller, more responsibility is being taken on by the cloud provider.

Many recent cloud security issues that have appeared in the news were due to misconfigurations in the services by the application developers. Serverless will use far more cloud services than a cloud-based app. This means that your team security specialist needs to be deeply familiar with the services and security configurations of your cloud provider of choice. For AWS this means very familiar with the IAM service with its roles and granular security policies. Familiarity with services such as CloudWatch, CloudTrail, GuardDuty and the Security Hub will also be useful for enterprise and large scale solutions. You have very granular control over access, including for the team members and it is good practice to provide “only needed access” to each individual user and function.

All activity by users and functions alike can and should be logged, for many services, this happens automatically but for some, it may need to be enabled. Advanced or more detailed logging can also be enabled. All of this log data does not need to be processed and reviewed for insights and alerts which can be done using a few serverless functions. This means you can trigger alerts or even actions should as locking a user account when certain conditions are met.

To summarize:


Development budget for serverless will depend on your team. If they are new to it then there is a bit of a learning curve. Utilizing and optimising the different cloud services takes some experience to get right and mistakes will be made getting there. An experienced team that has strong DevOps practices will get the most benefit and the lowest development cost from serverless. Re-usability of microservices over a number of solutions is where the real budget savings lie so this needs to be kept in mind when designing the microservices. For experienced developers, estimating microservices can be much easier and more accurate than estimating a monolithic code base.

Operational budget can be significantly lower with serverless compared to a server-based solution. The most obvious reason is that you do not have maintenance costs for the operating system and software as these are fully managed.

To get an idea of the operational costs of a server-based application you would probably do something called stress-testing. This will give you a rough idea of how many users your server can handle before it slows down. Assuming you know the monthly cost of a server this will give you a very rough approximation of “x users costs y$ per month”. For serverless, it is more complex to calculate this because there are many variables. But given the right input data, you can get a very accurate per-user cost. This per-user cost will also be fairly linear as your solution grows with far less of a curve compared to server applications. Any reduction in per-user cost over time will more likely be due to optimising the solution rather than simply “more users”. This makes budget planning for operations quite predictable and it means, if relevant, you can base your business model to users on the per-user cost instead of the more ambiguous per server cost.

Once the solution is running it is actually fairly straightforward to track the exact cost of each user as they utilize the system. This enables you to optimise the system over time to reduce those costs and to fine-tune your business model.

The biggest advantage of serverless when it comes to budget is far less wastage. With a server-based application, you will always need to margin your available server capacity to handle bursts. Even when using auto-scaling servers there will still be margin because it can take at least a minute to launch another server. With serverless you are only paying for exactly what you are using, there is next to no wastage. For example, you are paying for only the storage you are using, not the available space you would have in a server. You are paying per 100ms and memory each time a function is run and not 24/7 for a server to simply be online regardless of usage.

The budget risk in serverless is that it can scale to immense numbers. You can go from 100 to 100 million users in a matter of seconds. With a server-based application, this is more controlled through servers slowing down when they near capacity, boot time of 1-10 minutes and number of servers that are added when autoscaling and other factors. With serverlerless, there are no such blockers. So you can scale rapidly but you will also be paying for those 100 million users which may or may not be a problem depending on your business model. Also, keep in mind that mistakes can be costly. For example, if a bug in a function causes it to go rogue and start launching 1000’s of functions doing something like image resizing it's going to rack up expenses very quickly. Limitations and controls need to be built into functions and you can utilize cloud features such as budget monitoring to trigger alerts in such cases.

To summarize:


A serverless team would typically look something like this:

Microservices work really well with an Agile approach to the project. Individual independent functions can be developed and tested within each sprint. Front-end development can start as soon as the communication format has been documented for the backend and can run in parallel with the backend development.

An advantage of microservices combined with the fine-grained capabilities of the security services is that you can split your project into levels of security. Only the most senior of the developers would have access to crucial or sensitive microservices dealing with personal or financial data for example. And the more common microservices such as image resizing can be easily given to junior or third party developers. They can develop, deploy and test their functions themselves without your security being compromised. Their final delivery can then trigger your internal QA processes and integration testing before approving their work.