There's a big hype circulating around microservices & serverless and I see a lot of people struggling on deciding whether they should move their architecture to microservice followed by a completely serverless approach or not. But before we proceed, let's understand a bit more what they really mean and their purpose.

What's a microservice?

Consider an application as one big block of an engine of a car. This block consists of several small pieces that work together to make the engine work and each piece executes one kind of service, with their own responsibility and own goal. Each one of these pieces is exactly what we call a microservice.

But imagine the following situation: one small part of the engine needs an update or stops working and you need to replace this part, but in order to do it you have to remove the whole engine, throw it away and create a full brand new one and put it in place. This is what we call a Monolith application, which is nothing more than lots of pieces glued together forming one unique single piece of software.

In a microservice architecture, each service is independent in its creation, language, execution, usage and replacement, being completely held responsible for everything it does and the data it produces. If it somehow fails, you just have to replace this single part without having to stop any other service, in other words, replacing the broken part while the engine is working and the car is running 🚗💨.

From the user's perspective, here's how an application looks like in both scenarios:

Although a microservice has a "micro" in its name, doesn't mean that the service has to be super small. The application can be broken down per domain, per area, per business departments, per product requirements, etc. whatever makes sense to you and your company.

Summing it up, here are the main reasons why you should be using a microservice architecture:

• Resilience: Whenever one microservice crashes, it does not necessarily affect other services, keeping the main application running and more stable.
• Scalability: One single microservice can scale according to its usage, without having to scale the entire application at the same time. This boils down into effectively distributing power to those services that really need it.
• Deployment: A microservice can be deployed independently of the whole application, which makes things way faster to roll out an update or a hotfix.
• Flexibility: Microservices don't have to be written in the same language of the entire application. Developers can choose the better one that suits their needs.
• Independence: Ability to have multiple projects, features, fixes going on at the same time by different teams being deployed concurrently or at their own pace.

But (there's always a but)...

If you're starting an application from scratch or working on a big legacy monolith, don't think that this microservice architecture will be the solution to all of your problems. Starting or migrating a project to a microservice architecture adds lots of new technical complexities that didn't exist before, such as microservice communication, concurrency, data (de)duplication, data sync, failure handler, queues, messages, events, history, (e2e) testing, logging, etc. 🤯 So be aware and only move if it really makes sense for you and your business. But don't worry, I'll be explaining in upcoming articles different strategies to overcome every single one of them 💪🏼. So stay tuned for what's about to come!

But coming back to the topic, I believe that you have a clear idea of what a microservice is, but now the questions are rather: where / how / when do I run them? Should I start all the microservices independently in the same server? Should I run them in containers? Docker compose? What about Kubernetes / Openshift? Any service online to make my life easier? Well... although all the previous options are also possible, here's where the next part of this article comes in place: Serverless computing!

What is serverless?

In the beginning days of the internet, anyone who wanted to build any web application had to own a physical server, which was expensive and not scalable. Some time went by and the Cloud arrived, where servers with a specific configuration could be rented remotely. Companies used to rent more than what they needed only to be on the safe side. In case of a possible spike in traffic, they would be able to handle it, but this would generate a big idle for most of the time. This means that lots of computing power was being paid and rarely used. And now the serverless computing comes to solve this situation.

Serverless computing is basically a method of providing backend managed services in a cost-per-usage basis. The main principle of a serverless architecture is that the developer can write and deploy code without worrying about the underlying infrastructure, but in contrast to what the name proposes, there are still servers behind of it, but in a way that you don't have to worry about setting it up, its performance, scalability and maintenance at all. All of these concerns are taken care by the vendor.

The main advantages of serverless are the following

• Scalability: No need to worry about servers and how to scale them. The serverless vendor handles all of the scaling on demand in a very simplified way.
• Development: Focusing only on your code and on what you're trying to achieve with it, the serverless architecture will leverage your delivery as there are so many great and powerful services that can easily be used.
• Time-to-market: Developers can update their code and make it available in a much faster way, instead of needing to work on the infrastructure or complicated deploy process, for example.
• Lower costs: Since serverless has a different pricing model (cost-per-usage), it tends to be pretty fair and much lower on a short and long term basis. And if you consider the costs of maintenance and dedicated people to it, the difference is even bigger.

And now we can have the best of both worlds: A Serverless Microservice!

How can this combination help you?

When you run a microservice in a serverless architecture, you reach the maximum level of flexibility and scalability in the backend as both of architectures share the same principle: Independence!

Of course, some limitations apply: It's not recommended to run a microservice that has complex calculations and lasts hours to be processed (see limits in table below) in a serverless environment, for example. If you want to do something similar, you should either run it in your own environment or break it down into several smaller (and faster) calculations.

The ability to run a microservice in a serverless environment has different names in the main Cloud providers. They are called AWS Lambda, Azure Functions and Google Cloud Functions.

Here's a comparison table between them:

You can get more information about this comparison in this article from Simform.

⚠️ But attention. Be aware that by using this combination, you fall into a vendor-lock situation. The more managed serverless services you use from a specific vendor, the more attached you are to them and your business will be completely dependent on them. You can minimize this lock by using the Serverless Framework and be able to deploy some microservices to different Cloud providers, but do it with care as most services differ in several aspects (as seen above) and might put you into a very delicate situation if you have to change your infrastructure or move among Clouds.

If vendor-lock is a problem for you or maybe the limitations do not serve your needs, you can still use the same approach but in a more custom way, such as containerizing your microservices and running them in a Kubernetes environment with technologies like Knative, that allows to build your own serverless environment 🤩. AWS, Azure and GCP offer managed Kubernetes Clusters that can help you get away from handling hardwares, but this leads to another long article as it adds a lot more on your plate.

For now, if vendor-lock is not an issue and the limitations shown above fit your use case, I highly recommend you to try it out. Just remember to architecture your application in a way that you can focus on putting the effort of your team on solving primarily your company's mission & vision by effectively using the available resources and the managed services provided by your Cloud provider.

Here at Cazoo, we're a big supporter of this approach and we have been extensively expanding it in our daily development and pushing this technology even further and I'm happy to share these steps with the tech community. But what about you? Have you ever used a similar approach? If so, how do you like it so far? If not, do you plan on migrating your architecture? Tell me about it!

Stay tuned for more articles. And by the way, thanks for reading until here 🤗. Have a nice day and happy coding!

‍