Why I love serverless architecture

Anything on the web (websites/web apps/web services/api’s etc) has to be hosted and served to you from some kind of server to be accessible on the internet, this usually takes the form of Cloud Computing. In this post I’ll explain my thinking on why I love serverless architecture, which is a specific use of Cloud Computing.

What is Cloud Computing?

Cloud computing is the service that providers like AWS, Azure and GCP offer, to allow people to rent computer resource for tasks such as data storage and compute resource (e.g to serve a website).

There are different types of cloud computing, the four I’ll be talking through are: Infrastructure-as-a-Service, Platform-as-a-Service, Function-as-a-Service, Backend-as-a-Service, Database-as-a-Service and Software-as-a-Service. In this post I’ll go through what these mean, in addition to On-Premises, which is a step that leads to Cloud Computing.

A diagram showing the various types of Cloud Computing, demonstrating how delegation of responsibility for resource management becomes more dependent on the Cloud Provider, the closer you get to SaaS. This also shows where Serverless Architecture fits into the equation.

Infrastructure-as-a-Service

Typically when putting a website on the internet, you would rent a server from a cloud computing platform and pay them a monthly cost for the size of storage/amount of memory you require.

Using a cloud platform to spin up servers to run an application you’ve written would fall under the category of Infrastructure-as-a-Service (IaaS).

This is really handy as you don’t need to:

• purchase a computer with the storage/memory required to compute your web application.
• ensure that the server has firewalls/basic security/networking/operating system updates/back ups enabled.
• worry about maintaining a physical computer in a location you own (e.g power, theft, operation etc).

Whilst these features are great, you still have to:

• pay for the monthly upkeep of this service, even if the resource is not actively being used.
• work hard at ensuring that the security of the application running on the rented resource is correctly set up.
• put effort into 3rd party technology integrations that you’d like your web app to make.

The most straightforward way to build an application for the web using IaaS, is to build all the features you need into one single app and deploy it to your server. This is known a building a Monolith application.

An example of a Monolith application where the whole application (including the database) is housed on one server. This is how my blog is currently built.

Platform-as-a-Service

Taking a step up from IaaS would be Platform-as-a-Service (PaaS). This is essentially a cloud-based software that you can utilise to build your web application.

Using a PaaS to run your application has all the benefits of IaaS, with the addition of:

• not having to stress about how to scale resources vertically (increase memory/RAM) or horizontally (increase number of compute resources).
• built in analytics/monitoring of resources that are running in the background.
• ease of secure integration with other 3rd party technologies such as databases.

PaaS may not be for everyone though as:

• you will become locked into your cloud provider, some prefer to be cloud agnostic (in case of failure).
• if the cloud provider was to ever increase their prices, you’re locked into their costing structure and have to pay it.
• even though scaling of resources are automated on your behalf, this does not mean that your app will be performant at scale. To give an example, in a case when you’re not using a serverless architecture, running a cluster of servers with a load balancer might help make your application run better at scale – this could result in high costs.

One way of creating an app using PaaS, is to split your app into different services, that can be horizontally scaled by hosting those services on their own server when required. This is called a Microservices architecture.

An example of Microservices architecture, showing the database, cache/session store, api services and web app separated from each other, so that they can be scaled and routed to via the load balancer. This is managed and maintained by Beanstalk, which can horizontally scale any of the services by generating more comput resources.

Serverless

Going deeper from PaaS would lead you to into the territory of Serverless technologies.

Serverless does not mean that servers are not used. Through a combination of Function-as-a-Service (FaaS), Backend-as-a-Service (BaaS) and Database-as-a-Service (DBaaS), you can create a architecture where you do not need to manage compute resource (aka servers), instead the cloud provider manages this for you – aka ‘Serverless’.

Function-as-a-Service

Function-as-a-Service (FaaS) is essentially storing a function that you’ve written in the cloud, which you then set up to be triggered by events. An example of this is Lambda.

Backend-as-a-Service

Backend-as-a-Service (BaaS) is the automatic creation and management of backend services by the cloud provider. A good example of this is AWS Amplify.

Database-as-a-Service

Database-as-a-Service (DBaaS) is the automation of read and write functions to a database that can automatically scale based on requirements. An example of this would be DynamoDB.

Writing your application that utilises Serverless has the benefits of PaaS, as well as being the:

• most efficient method of running cloud resources as computing power is only used when triggered.
• cheapest way to run an application as you are only charged when the computing power is active.
• easiest method of scaling your architecture. Your cloud provider takes responsibility for ensuring that they can run your resource, regardless of scale.

Serverless does have some drawbacks:

• it is not straightforward to ‘just turn’ a pre-existing application into a Serverless based application, as its architectural style is very differerent from Monolith architecture.
• depending on what functions you’re writing, you may find difficulty in testing them.
• cold starts can result in slow response from the function you’ve written. There are ways around this, but unless implemented, this is still a consideration.

An example of what serverless architecture looks like. Building this architecture comes with unusual quirks, I’ve written a blog post about this and documented how to get past these unusual behaviours such as: Authentication on S3 buckets, storing data in S3 buckets using Lambda, using Lambda functions to trigger a Code Pipeline deployment to a S3 Bucket, Lambda routing fix for Cloudfront and Lambda function 301 redirects.

Software-as-a-Service

Lastly, there is Software-as-a-Service (SaaS), an entire application is hosted and managed for you by the cloud provider, it requires no programming or integration effort to use.

Often SaaS is really useful because:

• an entire software of functionality is ready for you to use out of the box.
• security and scalability is often fully handled for you.
• it is often much cheaper to leverage than building your own application.

SaaS can also be frustrating, as you fundamentally lack control over the application:

• if functionality does not exist, there may not be an option to add it, or possibly it could be done at a high expense.
• its level of customisation may be geneneric and not as bespoke as you’d like.
• perfomance can be varied, you could find the application to be slow during peak usage.

Most of what you use on the internet is considered SaaS: Facebook, Pinterest, Google, Twitter, Office 365, Gmail etc.

Any application which requires no coding knowledge from you, which is hosted on the internet, can be considered SaaS. That’s probably most of the applications that you use on a daily basis!

Conclusion

In summary, all types of cloud computing have their place. When it comes to creating an application at scale that has to be reliable, secure and cost effective, serverless is the one for me!