How different are managed and serverless services?
Tags: cloudskills, cloud, cloudnative, serverless
Published: 2021-05-16 15:17:23

A common confusion between people who have their first touchpoint with cloud technologies is

> What is the difference between serverless technologies and managed services?


![Clouds. Credits to Zbynek Burival](https://images.unsplash.com/photo-1517685352821-92cf88aee5a5?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=700&q=80)


## What Are Managed Services?

A managed service enables the end-user to focus on *using* a service rather *setting up* the service. Not that the cloud provider can detect your thoughts. Rather any input the service requires is happening via a user-friendly form. Managed services fit into the category of PaaS products (Platform as a Service).

One of the most famous managed services around is Amazon's [Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/). In ElasticBeanstalk you can 
a) set up some parameters 
b) provide a docker image

and the service will set up the rest for you. Things like:

- Virtual machines
- A webserver (if needed)
- Expose your application to the public
- Monitoring and logging infrastructure
- Semi-automated configuration
- Load balancing
- Scaling etc.

You will be able to see the results of the Elastic Beanstalk operation e.g. the virtual machines, that were bootstrapped, as a result. Usually, you won't be able to access and fiddle around with them. Otherwise, it is not a managed service, you are the manager.

![AWS ElasticBeanStalk](https://cdn-images-1.medium.com/fit/t/1600/480/1*Fd6rk1k1FHPZcg4aK_OXtQ.png)

So a managed service is essentially an abstraction of a... non-managed service. The abstraction is usually interfaced via web forms. Additionally in a managed service as a user, you don't bother with updates, patches, etc. 

This is because you have no access to the machines, someone has to do the laundry. Usually, you have only limited choices, if any, on the underlying system. That might be the operating system, version of the software used.

Fairly simple, right? Let's go to serverless who is a bit more complex.

## What Does Serverless Mean?

With the word serverless we refer to a different computing model, on the contrary to the "traditional" one which is server-oriented. In server-oriented computing (or serverfull if you like more sophisticated words), we use virtual or physical machines to set up and execute our application.

Qualities like the availability and the performance of our applications are strongly bound to the health of your machines. 

Clusterisation solutions have been perfected over time (amongst other reasons) to make the decline of machines' health less and less important. 

What about the cost though? Why do we still pay for idle or underutilized servers (either in money or in lost CPU cycles)? If we need to scale a cluster of machines why does this take time?

Here comes serverless. Serverless fits in the category of FaaS products (Function as a service).

The name is a bit misleading; the server where "the code" runs does exist. 

Though you don't care, just like in managed services. Serverless goes a bit further. Your application runs, when it is needed and for just as long as it should. Idle times are eliminated.

You never get to see the server in your virtual machine dashboard and of course, you don't know any details about it/them.

Serverless implementations are usually event-driven. The instances are idle unless an event occurs. 
> N.B: There might be a case where you have instructed them to not be idle which is known as "scale-to-one". They get busy and when done, they go idle again. If they get too busy they get support from other clones aka horizontal scaling.

There are few benefits with serverless implementations. A big one is that they are scaling easily and effectively. That is because they are usually based on lightweight installation media, like Docker images/containers and there is no need to provision extra machines.

In theory, with serverless computing, you have the whole cloud infrastructure of the provider on your feet. With the respective cost of course. :)

Speaking about costs, serverless code is billed per second and at a higher rate than a machine lease. So it is recommended to run for relatively short workloads in time.

Some providers put a hard limit on how long serverless code can run. this is to also avoid unpleasant surprises on your bill.

One notable example of full-stack serverless and the cost benefits that come with it is acloud.guru. 

I remember studying for the AWS Architect certification using one of their courses (awesome content btw, highly recommended), and the instructor mentioning that "We pay 400$ per month with Serverless and it would be around 100000$ using servers".

One of the cons serverless architectures have is on time-critical applications. Usually, newly deployed serverless functions, experience some kind of latency also known as "cold start". There are mitigations around that, called -surprise, surprise- "warm starts". But you may want to check other architectures for such a requirement.

By the way, serverless solutions provided by the cloud providers are i.e AWS Lambda, Azure Functions are...managed too. That means you can set up your serverless architecture using high-level abstractions and input your preferences/configuration with provided forms.

## Managed Services + Serverless

As you have probably figured by now, serverless and managed services have some interesting similarities. We can sum them up like: Don't worry about the infrastructure, focus on your business value.

There is a very interesting public service that comes with both flavors, managed and serverless. This is AWS Aurora. Aurora is a managed database, compatible with MySQL and Postgresql. There are two flavors of Aurora.

![Lend from David Zhang](https://miro.medium.com/max/960/1*1_5fnrCrSYmyCUhugLxU5A.jpeg)

The managed one, where you set up a database using a form, and brings up a few virtual machines, and takes care of their health. You may just focus on deploying a good database schema. 

In this flavor, the database is running 24/7/365. Or at least that's the goal, as it offers very high availability and otherwise works in the same way as any database server you have used in the past.

There is also the serverless flavor, where Aurora is set up as such. In that case, you have the storage "deployed" 24/7/365 as above. You cannot have serverless storage, which is contradictory (according to my current knowledge at least). :) 

The processes though, that perform data manipulations on your data, like fetch and update, can be easily converted to serverless functions. Aurora serverless can have significant cost reductions, as the data manipulations run on an as-needed basis. Though if the database is fairly busy the cost might be higher than in a serverfull architecture. That being said Aurora serverless is better used when your workload is intermittent and unpredictable.

## Openfaas

During this article, I explained those technologies with public cloud providers.

If you want to run serverless computing / FaaS without relying on a public provider you may use OpenFaas (future article to come). 

![OpenFaaS logo](https://avatars.githubusercontent.com/u/27013154?s=280&v=4)

This technology will not only give you more control over your architecture. It will also help you realize that the serverless model relies on clustering technologies like Kubernetes. Also, you will learn how you can set up scaling rules and cold/warm starts.

## Conclusion

Thank you for reading till the end. We spoke about Serverless technologies and compared them with managed services. They have serious overlap but cover different needs too. If you need to add something I would love to hear your view.