Recently I was asked "Do you have experience with developing microservices?" Well, I don't have experience with microservices per se but I am doing serverless so that must be similar right? I asked myself "Why people do microservices?" We can enumarate some of the reasons.

1. Each team can be responsible for their microservice(s) end to end.
2. You can deploy and scale different pieces of the application separately.
3. Your application can be more fault tolerant. Ideally, breaking one microservice doesn't mean that your whole application is down.

What are the downsides then?

1. When different pieces of code become services that are separately developed and deployed, you need to be extra careful when dividing your domain so that each service has responsibility clearly set.
2. Network calls are slower than function calls and they can randomly fail.
3. Debugging becomes a problem, you need to have things like tracing.

This is the view of the person that didn't work with microservices ever. It's based on what I read, what I think and on presentations I watched.

How serverless fits in?

What is the serverless application in that case?

This is serverless application. Notice the arrow direction. It points from serverless to the application. Serverless depends on the application. What is the application? This is you differentiator. It's your business logic. Your modules live there. I am working on connecting employers with candidates right now so my domain contains modules like job recommendations, ability to apply for a job and candidate profiles.

If this is the case, what is this serverless thing?

It's your deployment platform. I am developing on AWS, so endpoints to my domain are AWS Lambda functions. They can receive HTTP requests, events from the queue, messages from a topic, and many different AWS-specific events.

How this tech fits in the monolith/microservices battle?

With microservices - each team can be responsible for their microservice(s) end to end.

With serverless many teams can be responsible for different serverless applications.

With microservices - you can deploy and scale different pieces of the application separately.

That's true for sure with serverless. Lambda functions scale up and down with incoming traffic, but it won't scale infinitely. If you are starting to hit cloud vendor limits - you should be lucky because your business is getting noticed. Also you should think then about using something else for your very popular endpoints.

With microservices - your application can be more fault tolerant. Ideally, breaking one microservice doesn't mean that your whole application is down.

Definitely - one failing lambda doesn't mean that the rest of the application is unavailable.

With microservices - When different pieces of code become services that are separately developed and deployed, you need to be extra careful when dividing your domain so that each service has responsibility clearly set.

Here I see the real power of the serverless. Software applications are living creatures. Developers try to foresee the future as much as they can and they try to make assumptions of what future needs they will need to satisfy. Product people on the other hand have different agenda. They try to figure out what will work for the customers. They pivot all the time. This is good because it means business is going forward. But for developers it's just nightmare. You try to divide your domains into modules, bounded contexts, subdomains and everything changes all the time. The serverless gives you advantage here. You can start small, couple of lambda functions calling the code they interested in. But as the requirements change, you can alter your domain code as well until it evolves into something mature. With microservices you can end up with the situation where you already divided your domains and different microservices are responsible for different things but when new requirement or feature comes in - you think - where do I put it? In the service A? In the service B? Maybe I should create service C? You need to carefully calculate what other modules will be called. If they live in different services - you might end up with too many network calls and it might not be as reliable as you would like to.

I believe that with serverless live is easier. You develop your application. You add features to it and you are careful about it. You studied "A Philosophy of Software Design" by John Ousterhout and you know how to design beutiful, functional, deep modules but when requirements change you can painlessly change modules as well. Later you create endpoints to the domain code by attaching lambda functions to it. Ideal situation is when you have a software module that is called by couple of lambdas and they form unity. They are separated. Later you can do whatever you want - you can take these lambdas and the domain code and pull them out of the serverless application and even create microservice from it if you want to!

My point here is that with serverless there is no struggle as to when to move from monolith to microservices. Serverless allows your software to evolve in direction designated by product.

Is it something that rarely changes and needs to handle huge load? Pull it out and create microservice.

Is it something that often changes and you need to tweak it frequently? Develop it further with serverless.

My real point is this: Serverless supports evolution.

With microservices - network calls are slower than function calls and they can randomly fail.

I believe I touched on this subject before, if you want to - you call the function from other module.

With microservices - Debugging becomes a problem, you need to have things like tracing.

With serverless you need to have tracing too. When things become really distributed it is invaluable tool to figure what is wrong.

Let's go back to the original question.

Can you develop microservices?

I believe that everyone who once developed serverless application will be able to develop any microservices because principles you need to follow are similar, yet serverless gives a little bit more elasticity.

Let's go back to the title.

Serverless and microservices are... pretty much the same?

They aren't the same, they are similar. There is place for both solutions. If your doing something completely new and you don't know where it will go - defintely choose serverless and benefit from the elasticity it provides. If you exactly know what you want and you will handle really huge traffic - create microservice and scale it infinitely on the platform of your choice.