Why Do We Want Serverless?
The productivity of software development and product teams utilising Serverless is outperforming teams using a traditional Infrastructure as Code (IaC) approach. By utilising Serverless we can deliver more reliable software faster, reduce operational complexity and focus on our customer needs.
Why is the level of productivity between these approaches so fundamentally different?
A traditional IaC delivery requires a team to manage the entire technology stack. This includes tasks like installing and updating operating systems, deploying and updating software packages such as databases, application runtimes, patching and managing auto-scaling, load balancing, certificate management and many more. None of those activities are perceived by a customer as a ‘feature’ or customer experience improvement. They are rather taken for granted.
We do not need to perform any of these tasks when we use Serverless. AWS will manage all these responsibilities for us and probably much better than we would ever be able to.
By eliminating these tasks we can focus on the customer facing features.
Â
The following diagram illustrates the difference between a traditional IaS approach versus a Serverless approach.
Accelerate our Approach with AWS Native Services
AWS offers a variety of Serverless Technologies for different use cases.
Let’s have a look at a very common use case: a public facing web application. By using Serverless we can implement and operate the solution in a much more efficient way compared to traditional IaS solutions. The solution is typically hosted behind a Content Distribution Network (CDN) that caches static content closer to the user’s geographical location. Hence, a CDN can significantly reduce the latency. The AWS out-of-the-box CDN solution is called CloudFront.
We are now going through the common building blocks of our Serverless web application. We will also look at what we will need to consider for our deployment.
- Website Hosting:
The static content can be hosted in S3 (Simple Storage Service). S3 is an object storage that can also be used to host websites.
By using S3 we do not need to install and manage a web server. S3 is replicated multiple times across physical locations within one geographical region (e.g. Sydney). It is therefore not only extremely reliable, but also provides unlimited scalability. The price for S3 storage and hosting is impressively low and it differs per AWS region.
The main aspect we need to manage here is the security policy for the S3 bucket containing our website. For example: we could limit the public read-only access to CloudFront, our CDN solution in AWS. - Business Logic:
The business logic can be wrapped by utilising the AWS API-Gateway. The API-Gateway acts as a proxy and can secure and throttle our API endpoints.
It scales automatically and supports various authentication mechanisms. Here is an example of what we need to configure: we might want to limit API access to our website or to premium customers by configuring the access model.
The actual business logic can be implemented via Function as a Service (FaaS). The technical FaaS implementation in AWS is called Lambda. Lambda supports auto-scaling, many programming languages and has a fast execution time. The runtime is fully managed by AWS and we are not required to manage installations, updates, load balancing, auto-scaling or patching.
Examples of aspects that we need to configure are the security and throttling of API calls. For example a premium user might be allowed more requests per minute than a standard user. - Database:
There are several AWS Serverless database offerings that we can leverage.
We can use Amazon Aurora Serverless if we need a relational database. Amazon DynamoDB is a highly scalable key-value database for No-SQL queries. Additionally, we could also utilise the new Amazon Redshift Serverless offering if we need a data warehouse solution. Examples of things we need to manage are database users, the database schema and the actual data. - Observability:
For event management, logging, and monitoring we can use the AWS Event Bridge. Any events that occur (e.g. a file upload) can conveniently trigger other Serverless technologies, such as SNS (Simple Notification Service) for notifications. AWS X-Ray can be used for application monitoring and Amazon CloudTrail for logging of AWS API calls. Some aspects that we need to configure are monitoring metrics and data life-cycles for log files. - Automation:
AWS provides an entire automation tool chain to enable CI/CD (Continuous Delivery & Continuous Deployment). Technologies include: AWS Code Commit for source code management and AWS CodePipeline for the overall CI/CD orchestration. AWS Code Build will help to build our actual application. An example of a task we might need to do is compiling and packaging our application including any third party libraries. AWS Amplify is also very popular for web and mobile applications because of its simplicity. Another example of things that we need to manage ourselves is the implementation of functional and non-functional tests.
We can see that all key aspects of web application can be addressed with Serverless technologies. Due to the flexibility of Serverless architectures we can plugin other tools that might offer additional functionality that are not available out of the box.
Therefore Serverless should be one of the first architecture considerations if we want to accelerate our web application delivery and improve our customer focus.
