Microservices: What’s with the micro?

Naming things is hard. Programmers, specifically, struggle to come up with meaningful variable names or comments describing code clearly. Somehow we end up with names for things that may or may not be exact or convey their desired meaning. Yes, perhaps I’m about to be pedantic, but hear me out, it may, or may not, be worth your while. I make no guarantees.

In today’s world of software engineering there is a tidal wave of buzz behind microservices. You can’t go a day or two without hearing how big company X or big company Y is doing amazing things by leveraging the microservice architecture.

The word microservices itself simply means “very small” services. Alright, so build smaller services and suddenly we’ll get access to a utopian world of awesomeness where software is easy and everything automagically works (and we are suddenly on par with Netflix)? Well, no, not exactly.

It’s hard to argue that smaller services doesn’t “help” the programmer but in my opinion the term “micro” emphasizes the wrong part about a service. Only emphasizing the relative size of the codebase of a service ignores the other, and perhaps more important, details about a service. Does small inherently mean a service is maintainable, deployable, testable, operable, reasonable, stable, and any other -ables? Well… no. Not exactly.

Let’s not forget that the minute you begin creating smaller services you also agree to taking on the complexity of deploying many services and dealing with how those services may, or may not, communicate with each other. As a simple example I may have one larger service that could be broken into six microservices. While managing the code itself is easy, managing the deployment, testing and monitoring has gone up 6x. Again, creating microservices itself is easy, but is creating the deployment pipelineand putting the service into a production environment easy? Well… no, definitely not.

Luckily there are huge community movements to manage the complexity of handling these smaller services. It’s becoming common to create a docker container around your service and then manage the deployment using Kubernetes or another container orchestrator. Without using the right platform or environment, your newer shinier smaller service is unlikely to succeed. Therefore, when you say you want microservices what you are really saying is that you want smaller services that live on a certain eco system and meet certain criteria.

Implied in the “microservice” name is likely dockerization and choosing a container orchestrator that works for your business. It also means a lot of learning on how to scale and manage things correctly to handle the -ables mentioned earlier. Many of your devops practices will change as well to accomodate these other platforms.

Having said all of that I strongly believe that we collectively need to adopt “microservices” due to all of the advantages outlined in the copious amounts of other microservice articles. But let’s all agree to stop calling them microservices, maybe?

When you decide to adopt what is being called the microservice architecture you are signing up for so much more than just smaller services. Maybe we could just start calling it SOA 2.0? No can’t do that, Web 2.0 was a silly name and never did make any sense. Alright fine, how about uberservices, which loosely interpreted means outstanding services. I can buy into that, build better and smaller services that become outstanding through a quicker more refined pipeline and platform. Wait what? You don’t like that name either? Well, as I said earlier, naming things is hard.