A couple of days ago I started looking at job vacancies for backend developers.

I started to notice some sort of pattern.

They almost all required some sort of experience with cloud providers such as AWS.

I don't have any such experience, and this was the inspiration behind this article.

I've scoured the internet for all sorts of information on cloud providers, it turns out there is a common unifying architecture behind all of them.

It's called Serverless.

In this article, you will learn:

• How companies manage their infrastructure before introducing serverless
• The core concepts behind the serverless architecture
• The benefits and drawbacks of using the serverless architecture
• Common misconceptions about serverless

The History Behind Serverless

Serverless is the latest evolution of managing software infrastructure.

Every evolution eases the management of infrastructure, making it easier, faster, and cheaper.

Let's go over each of them.

Do it All Yourself (D.I.A.Y)

In the beginning, if you wanted to publish your software, you had to do all the "grunt" work yourself.

Meaning, you had:

1. Buy a server
2. Set it up (operating system, firewalls, etc...)
3. Copy your code over to the server
4. Maintain it

This is slow and pretty expensive.

You had to manually upgrade your servers and fix any hardware issues that come up.

Another big issue with this approach is scalability.

You have to get additional servers, and your gonna have to deal with load balancing, which may get very frustrating.

But on the bright side, you have full control of the server and the contents inside it.

Virtual Machines

CPU's nowadays are much faster than they were in the past.

This advancement has brought a new way to manage infrastructure.

Instead of configuring one workload/program with one physical server, we can have multiple workloads on a single physical server.

This is made possible by installing a hypervisor such as VMware vSphere or Microsoft Hyper-V. This allows us to support multiple guest operating systems by sharing the host's resources, such as memory and processing.

In comparison to physical servers, virtual machines are more:

• Cheaper: You can have multiple workloads on a single physical machine.
• Efficient: The hypervisor efficiently distributes resources to virtual machines.
• Scalable: To scale, you can simply add more virtual machines on a single server.

But it's not all sunshine and rainbows, the downside is that it is much more complex to manage virtual machines than it is physical servers.

Containers

Containers are pretty popular nowadays.

They were mostly popularized due to Docker.

Containers are essentially an "upgrade" to virtual machines.

It jumbles your program, with the minimum dependencies needed to run it into a single unit.

Instead of booting up a whole operating system for your program, containers share the hosts operating system. This makes them very light and fast.

This is the basics of containers, but if you want a more thorough explanation, check out our post on Docker and Containerization.

Serverless

Serverless is the latest addition to infrastructure management.

It essentially uses a cloud provider (AWS, Azure, or Google Cloud) to completely manage your infrastructure.

You don't have to worry about servers, scalability, fault tolerance, etc...

It's all managed by the cloud provider.

Initially serverless started out as:

• Backend as a Service (BaaS)
• Function as a Service (FaaS)

Let's delve a bit deeper into each

Backend as a Service

Serverless was first thought of applications that partially or fully use third party cloud provided services to manage server-side logic.

Examples include mobile apps or single pages applications (SPA) that use:

• Cloud Accessible Database (ex. Firebase, Parse)
• Authentication Services (ex. OAuth, AWS Cognito)

These types of services are known as Backend as a Service (BaaS).

Function as a Service

The most popular meaning of serverless is Function as a Service (FaaS).

This is where application code is still run by the developer but it’s run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party.

The most popular FaaS is AWS Lambda, others include Google Cloud Functions and Azure Functions.

We usually refer to FaaS when talking about Serverless.

Benefits

You might ask me:

"why would I use this?"

This is a very valid question, and to answer that we will go over the benefits that serverless provides us.

• Cheap — In serverless, you only pay for what you use. For example, in a traditional server of 100GB, if you're only using 10GB of the 100GB, you would still pay for the full 100GB. While in serverless you would only pay for what you use. This can be extended to both BaaS and FaaS, it might be cheaper to not implement some features if you can directly use a backend service provided. While for FaaS, the cost benefits come in scaling. Meaning that you only pay when your functions are being run. When they aren't being run, you don't pay a single dime.
• Fast — When you don't have to worry much about infrastructure, you have the ability to focus most of your energy on development. Essentially making time to market, much faster.

Drawbacks

It's time to face reality.

Nothing is perfect.

It's time to go over the drawbacks of using serverless:

• Vendor control — Your cloud provider controls your whole infrastructure, which may cause issues if they have any problems on their end. Problems such as system downtime, unexpected limits, cost changes, loss of functionality, forced API upgrades, and more.
• Vendor lock-in — Cloud providers aren't interchangeable, they may have the same services but most likely that they are implemented differently. If you want to move from one provider to another, you will be forced to do some code changes or even architectural changes.
• Complexity — Things get complex when you have many functions. Complexity may arise in code, architecture, or even simply debugging.
• Testing — Unit testing functions isn't that hard, because they are stateless and isolated. The difficulty comes when you have to do integration tests between two or more functions.

Common Misconceptions

Serverless started in 2015, it's still fairly new, with that comes a lot of misconceptions.

Let's break down the most common misconceptions that people have about serverless.

Serverless = No Servers

Serverless doesn't mean there aren't any servers involved.

Your code must be stored somewhere.

It just means that you don't have to deal with it anymore.

Serverless = Fewer Servers

Serverless Means Functions as a Service (FaaS)

Most people think that Serverless are essentially FaaS such as AWS Lambda, but there are many other services that can be considered to be serverless.

Here are the ones provided by AWS:

Serverless doesn’t perform as well

Many people say that serverless functions take way too long to start but this happens when you don't properly configure the right memory size for each function.

Some functions simply require more memory and some less. It's up to you to find the right balance.

Serverless is super cheap

There's this meme going on about huge bills coming from cloud providers.

Sadly it's true, this happens when you just use an absurd amount of services or not optimizing the use of your services.

Conclusion

Serverless is definitely the future.

There's no resisting it.

But you pushed through it, and have gotten the basics of serverless down.

Today you learned:

• The history behind serverless
• Core concepts of serverless architecture
• Benefits and drawbacks of serverless