Start with Monolithic and then move to Microservices?

I read an article this morning which quoted someone who suggested that you should start with a monolithic application and then switch to Microservices as you discover what parts of the system need to scale and scale separately from others.

This is great advice.

With two massive problems. Most developers don't know how to break a monolith into microservices. And most developers don't know how to determine which parts of their system should scale separately.

I'm not saying that the advice is bad. I still understand that it IS good advice. But, if you've ever read the comments on an article suggesting Microservices architecture and have been through such a migration yourself then you know that what I said above is true. Also, most people reading the advice will think "great, I don't need to worry about Microservices now". Which is completely wrong.

It simply puts an different burden in its place. You should be asking: "how can I gather the data that will inform me when I need to make the transition and along which sections/domains in the application?"

The thing to note here is that the original advice did not say to never build Microservices. But, the comments on that articles (and other similar ones I've read) show most people believe it is an "all or nothing" proposition.

My view is different. I suggest (assuming you don't know whether you need microservices or where to apply them) that you should choose exactly one thing to build as a Microservice. 

This allows your team to learn what it means to deploy multiple services, deal with things like communication, security and shared dependencies. But, you get to do it in a controlled fashion (you choose that ONE thing you separate from everything else). 

I'll take my advice one step further. When in doubt, build an API Gateway with authentication as your first microservice.

Why an API Gateway? A few reasons:

• It allows you to centralize aspects of your application. In this case authentication and routing.
• Authentication and routing are two of the biggest concerns which pop up first when splitting from a monolithic application into microservices, so you get a head start.
• Routing can provide benefits for the monolith (load balancing, blue/green testing, etc...)
• It provides a centralized place to collect metrics (so you know where you will get the most value)
• If you implemented global rate limiting in the past, you will need something central like an API Gateway to maintain that in the future anyway.

Honestly, I could make that list quite a bit longer. The point is that an API Gateway is a rather critical piece of any distributed application. But can also be indispensable in front of a monolith. 

Most people don't even know that they are using one. AWS, Azure and GCP all provide their own generic ones (or a mesh of services which act as the equivalent) and people end up paying to use them because they didn't end up building one of their own in the first place. And that usually comes with compromises.

And as a bonus, it is a clean, logical bit to separate out in most cases. It is typically a layer "above" your business logic. So you're getting the benefits of learning what it entails without worrying that you chose the wrong part of your business logic to split out.