Executive Summary: Serverless Architecture

Introduction

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:

Each microservice is independent and can run and be tested on its own. Once it does what it is supposed to do and the method and format of “talking” to it are documented, it is generally left alone. With a single code base there are often many dependencies between functions and changing one function can have unintended consequences in other areas of the solution.
The purpose of each microservice is clear, so it does not take long to track down issues or find specific functions that need a change.
If all your functions are in 1 code base then that entire code base needs access to all of your databases and any other services. With serverless, you can manage access per microservice. For example, you can have a microservice that is responsible for financial transactions or user profile data. Only that specific microservice will have write access to the relevant database and any other microservice must go through this one where access can be controlled, monitored and audited.
Often, the microservices will be fairly generic with a simple input and output value such as “image resize and crop”. These are microservices that can be used across many different solutions without even needing to copy and re-integrate them. Build-once, use many times saving development cost.

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.

Security

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:

The scope of your project will be on the code and service configuration, you do not need to plan time for procuring servers, setting up operating systems or software.
If you have to provide SLA’s to your clients then you may need to adapt them to match what your cloud provider offers. Also, keep in mind that not all services might have an enterprise level SLA yet.
You will need a cloud security specialist in your team, this is not an area where you want to cut corners. General, sweeping security policies are inadequate. Each team member and function in the solution should be assessed and provided only the access that they need at any given time. Consider, for example, creating a database. Initially, the team will need to have access permission allowing them to create a database, but once it is done they no longer need that permission so it can be removed.
All services can log activity, make sure to utilize these logs. Review them, trigger alerts and make them available for audit reports.

Budget

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:

Development cost will depend on your team’s experience but, time to learn and mistakes aside, it should be lower than a traditional architecture. Re-usability of microservices will greatly reduce development time on future solutions.
For the backend of serverless projects, the scope needs to be broken down into function-specific microservices which are easier and more accurate to provide cost estimates for.
General operational budget will be far lower due to no maintenance of operating system and software.
You can get a very accurate per-user cost estimate for servless solutions, this can help with the business model and with predicting the solution’s operational budget.
Keep the immense scalability of serverless in mind and use budget alerts.

People

A serverless team would typically look something like this:

A solution architect proficient in your cloud provider of choice. It is their responsibility to know the different services and how they can best work together to deliver the project's goals and within its limitations.
A security specialist (could be the same person as the solution architect). Deeply familiar with the security and access capabilities of your cloud provider. Manages user and function permissions and limitations, this requires active attention throughout the project lifetime.
Front-end and backend developer(s), ideally experienced in serverless but the solution architect should be able to support them either way
A DevOps specialist (one or more of the developers might be capable at this). Serverless lends itself very well to DevOps practices. The 2 most popular serverless frameworks have it built-in.
A NoSQL database specialist. For a truly serverless solution, you will need to use a "NoSQL" database instead of the more typical "SQL" databases. This can be a major challenge and sometimes one that cannot be resolved leading to hybrid solutions.
Testers and QA (of course!)

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.