Four Myths about Microservices

Microservices have moved into the mainstream. The question isn’t if you’re going to move to microservices — it’s when.

There’s a plethora of advice out there about what you “need” to be a microservice. You need AWS and Docker and Kubernetes and use 128 megs of ram. Otherwise, you’re not doing microservices. The truth of the matter is that this list has nothing to do with microservices. Absolutely nothing.

Microservices are an architectural decision to align your services with a company’s business units. It is understandable that there is confusion between deployment, packaging, scheduling, and resources utilization and microservices themselves. The motivation behind these concepts is not the same reason you move to microservices — even if they are often used in concert. Let’s take a quick look and see if we can make the situation less confusing.

Not about Deployment

Moving to the cloud is motivated by two main desires — shifting your business from capital expenditures to operating expenditures and gaining new compute capacity without having to rack and stack servers. Deploying your monolith to the cloud doesn’t magically transform it into a microservice. All you’ve done is deploy a monolith to the cloud.

Not about Packaging

What about Docker? It’s definitely for microservices. Alas, no, it is not. A container allows you to put libraries and applications into a reusable package. There are no rules about what can run in this package. It can be a tiny one API app or a 10 gig monster with a thousand APIs. Containers offer a convenient package to deploy your applications in without having to worry about library conflicts etc. Packing your monolith in a container doesn’t magically transform it into a microservice. All you’ve done is put a monolith in Docker.

Not about Scheduling

Kubernetes is not an application server. It schedules Docker containers — and runs whatever is contained within. It has some other features to help make the scheduled containers available, but its primary purpose is to utilize computing resources efficiently. If anything, Kubernetes is replacement for something like vSphere. Scheduling your application using Kubernetes doesn’t magically transform it into a microservice. All you’ve done is schedule a monolith in Kubernetes.

Not about Resources

Everyone talks about how small microservices are — so it’s the size of service, right? Resource usage doesn’t determine if it’s a microservice or not. There are very resource-light monoliths and incredibly resource-hungry microservices. It’s actually possible to make your monolith more resource-hungry in aggregate when you switch to a microservice architecture because of all the serialization that you end up doing (a topic for another day). Making your monolith resource-efficient doesn’t magically make it a microservice…

It’s about the Code

Microservices are an application implementation detail. It doesn’t matter where you deploy it, how you package it, how you schedule it, or how resource intense it is. If you want to use microservices, architect your application that way. It’s only a microservice if it is coded that way.