What does serverless mean?
Serverless means that no servers need to be maintained by the development vendor or client. This is not to say that it is not running on servers at all, there will always be servers involved with web applications. But in the case of our serverless architecture, the servers are hidden behind a managed software layer provided by Amazon Web Services (AWS).
The client and the developers only ever see and interact with this software. The servers that it runs on are entirely managed, updated and secured by AWS. The client pays only for actual use of the software and not the 24/7 cost of keeping the servers up and running. The client and the developers do not need to factor in scaling of servers, redundant infrastructure or operating system security. They also do not need to maintain servers or keep the operating system and software up to date.
It’s a bit like staying in a hotel, you pay for your room while you use it and you don’t have to worry about the plumbing, electricity or the beds being changed.
Besides not having to update any servers, you can also rely on the uptime guarantee promised by AWS and their highly redundant, fault tolerant and secure infrastructure.
What does the serverless architecture look like?
This next part is a bit technical, so feel free to skip to the next section about the benefits if you are not interested in the technical parts
There are 3 parts to the serverless applications we have architected. The backend - where the logic and processing happens, the frontend - what the user sees, and the API - which connects the backend and frontend so they can communicate data between each other.
- Backend
The backend code of an application is where the processing happens. Incoming data can be validated and stored in a database for example. Or requested data can be retrieved, formatted and returned to the API.
For serverless applications we use the AWS Lambda service which can store and execute backend code when requested via API Gateway. It can interact with the database and storage servers and do all kinds of processing. AWS Lambda supports Python and NodeJS. We typically use the latter in most cases. On Lambda you can use either or even both within the same application.
For databases we usually use NoSQL types in our Solution Architecture. This includes DynamoDB and SimpleDB. We use S3 for storage. Scripts on Lambda can interact with all these services effortlessly. Even automatically as you can setup events to trigger Lambda scripts. For example, when a user uploads a file to S3 you can have a Lambda script trigger which will take that image and resize it as well as creating a thumbnail, all completely automatic. You only pay for that one execution of the script and not the 24/7 server costs. - Frontend
The part that your users will see. This can include a browser based web interface as well as mobile app interfaces. The frontend will also contain your visual assets such as fonts, photos and other graphics. Web frontends are hosted on AWS S3 service. A great advantage of this service is that you can easily create copies of the contents across multiple regions. Ensuring that all the more heavy visual elements are as close to your various global users as possible. Also keep in mind that CloudFront - AWS’ CDN service, can be linked to S3 stores to further speed up access to your application. - API
An API, or Application Program Interface, is basically how 2 pieces of software can communicate with each other. In the case of a serverless application this will be used for communication between the front-end web or mobile interface (what the user sees) and the back-end (the code that does all the processing). The API is only a portal, a standardized messaging structure to allow ease of communications between 2 different systems. It does not contain much logic itself or do anything particularly complex.
For building API’s on AWS we use API Gateway. This is configured using a format called SWAGGER which is an industry standard method for defining how a specific API communicates. It receives a request from System A and passes it along to System B. It then receives a response from System B and passes it back to System A. The added advantage of using SWAGGER format is that this can be exported into a file and then used to generate human-readable documentation on http://editor.swagger.io/.
API’s consist of methods, which are the different requests that can be made. Each method has parameters that allow one system to pass data to the other system. Each method can be publicly accessible or restricted with a login and password.
Other Services
Other notable parts of a serverless application are the Route53 name server service. This service can do geo recognition. Meaning it can recognize where new visitors are located and direct them automatically to a Frontend hosted in a region closest to them.
AWS app services such as SES for sending/receiving email, SQS for creating queues and SNS for sending notifications are also frequent participants in the serverless applications that we architect.
We use AWS CodeCommit as our repository. For those that know what GIT is this is basically the same as that. It stores and versions all of the code of an application as a kind of backup and collaboration facility between developers.
AWS has a service called Cognito that can handle authentication and user profiles for serverless applications. You can store all of your personally identifiable information with this service to keep it out of your application and making it slightly easier to be privacy-compliant.
Websockets (live feedback / pushes to a web application from the backend), are not supported directly by Lambda but can be done via the AWS IoT services, or with a third party service such as Fanout.io.
Benefits of a serverless application
Cost
The main non-technical benefits of serverless applications are cost and risk. You are not paying for unutilized computer power because you are not being billed for a 24/7. You only pay for number of requests and the time that a script is running. A downside is that this makes it very difficult to calculate cost as the calculation is quite complex. A simple comparison based on some one of our applications looks like this:
- Redundant server environment: 80 USD / month
- Serverless environment: 18 USD / month
This is of course, completely dependent on number of users per month but it shows that the minimum you will pay is significantly lower. There will certainly be a point where it breaks even for pure hosting, but add on maintenance costs and additional manpower for monitoring and managing the servers and that break even point becomes much higher.
Risk
Because you are moving most of the infrastructure maintenance to AWS you are also significantly reducing your risk exposure. AWS has 24/7 technical and security teams monitoring and maintaining every aspect of their infrastructure to ensure maximum stability, security and fault tolerance. Because you are using a software layer this also makes it incredibly easy to replicate all of your serverless application across any number of regions to ensure quick failover. And because they won't be used until they are needed you would only pay for storage, unlike a multi-region setup with servers where you would be paying for the running servers in each region even when not used.
Backend/Frontend separation
There is a very strict separation of the backend and the frontend. They are hosted on completely different services. There is no overlap at all, which this is where the API comes in. The frontend and backend communicate data back and forth exclusively via the API.
Example: a search function
The user inputs a search query, the front-end will pass this to a search method in the API which, in turn, will pass it on to a specific Lambda nodejs script. This script validates the search query and retrieves data from the database that matches the query. This data is then formatted and passed back to the API which returns it to the frontend where it can be displayed to the user.
This separation has many advantages. You can have 2 completely separate teams working on the system at the same time that have no dependencies on each other. The API has been fully architected beforehand so the different methods, parameters and responses are known. Using this knowledge dummy responses can be created that the frontend team can work with until the actual API and backend have completed.
Local frontend
For web based interfaces, the frontend is usually the heaviest part of the application in terms of bandwidth. For a serverless application it takes a matter of minutes to launch a frontend in another region anywhere in the world where AWS has a region available. There is no need for data migration, you can enable region replication and setup Route53 to point users to the appropriate frontend location. A similar process can be done with any S3 stores with data content such as a media library.
Centralized logic & data
All frontends - web or mobile - will use the same API. This keeps data going in and out of the system consistent and all processing and data store in a single centralized location.
Fast and structured setup
It is relatively fast to setup, deploy and replicate applications. Tasks such as setting up servers and software are no longer required. It forces developers to work in a structured and well-documented way. The required SWAGGER formatting needed to setup the API can be extracted into documentation for example.
Downsides of a serverless application
SEO/Social
A dynamic serverless application with a frontend that retrieves all its content data from the API does not work well for SEO and social sharing. A website or ecommerce platform that relies on search engine position and social sharing is currently not a good project for serverless. This is slowly changing and it would be possible to build a serverless CMS that generates static pages that SEO and Social can see.
Function-rich web applications and intranets with no requirement for seo/social sharing are ideal candidates. Web applications can also be paired with a purely informational static website on S3 that would be SEO friendly and social shareable.
AWS Dependency
The serverless applications we architect are heavily dependent on AWS. They would not function with other providers or other methods of hosting without significantly changing them first. Some would consider this a negative aspect but we are heavily invested in AWS and are clear about this with our clients.
Cost calculation
Calculating what a serverless environment is going to cost is somewhat complex. With a server environment you need to know the approximate number of users and how much resources your application will need. You add some margin to that and you can figure out the size of the servers you need. Once you know that it is just a case of multiplying the servers’ hourly cost to get the monthly cost. For serverless it is a bit more complex. You need to know how many users, how often each user will request each of your backend scripts and how long each of your scripts will run when it is requested. It is explained in more detail by AWS here: https://aws.amazon.com/lambda/pricing/
Limited Languages
AWS Lambda supports Python and Nodejs. PHP is not supported nor does it lend itself very well to this kind of infrastructure. Whether this is a “con” or not will depend on your developer’s experience. Nodejs is a relatively new (2010) but already very popular backend language. It is a backend version of Javascript which is a language that has been around since 1997. Python has been around since 1991 but it has a steep learning curve so finding a good Python developer can be difficult in some regions. For most applications Nodejs will be more than sufficient. Python can be faster for heavy algorithmic processing of data however.
Decoupled task-based back-end with Microservices
Another option you have with serverless on Lambda, is to create a task-based microservice architecture. This is essentially a queue where the handlers (the functions that the user can call directly via API queries), can hand tasks off to. Depending on the type of task, the queue will then trigger a microservice - stand-alone function with a specific purpose, to pick up the task and process it. The task stays in the queue, but it is hidden for a specific amount of time and it is only once the microservice completes the task that it is removed from the queue entirely. This means that if the microservice fails for whatever reason, the hidden task will become available again in the queue and another instance of the microservice can pick it up. This gives a much higher level of fault tolerance in your architecture. Once completed, the microservice sends the results back to the queue which triggers the originating handler to feedback to the client (if needed).
Example of a generic, serverless architecture using tasks and microservices
Final note
This was a bit of a technical article but it’s difficult to convey the awesomeness of Amazon Web Service’s serverless application potential without this information. In short, for many applications it will save you money and reduce risk, certainly in the begin stages of an application. It is a relatively new offering so finding a good developer that can do this without having to first take time to research can be difficult. Considering the benefits this will hopefully change quickly. It is most beneficial to applications that have both web and mobile applications and don’t require strong SEO for the entire platform.