Why is Microservice?

So that took a while… Anyways I’m back with some lukewarm takes on IT infrastructure!

What the hell is a microservice anyways? Link to heading

Let me answer that by using a a sort of proof by conradiction and ask the question: The inverse of micro would be macro, so what is a macro service?

Back in the dark ages before 2014 (I’m not sure if they even had the Internet back then) there was one way your application worked, no matter what it required:

You have the entire code for everything in version control.
During development people would download that code, do their changes, test locally and push that code back up to version controlling (ideally there would be some quality checks and the like beforehand too).
When the time came for a release via whatever path your project uses for distribution, then this source of truth would be built into an actual package be that binary or something else, that is actually shipped to the end user.

That deployed application was one single thing, almost like a single slab of stone… a monolith. So this method was to be later called monolithic application development.

Now all of this was great, however, the early to mid 2010s were a time of a bit of a revolution. There used to be a bit of a devide, you had developers that write code which turns out to be the application and system administrators (or operations) that would actually be responsible for the infrastructure where the application would live (as well as deploy the code to it). This is a topic for another day (the birth of DevOps etc.) and a lot of other things started happening at the same time, but for the purposes of this article, we’ll just say that the two worlds started colliding. At least that’s what we thought at first, in reality what turned out to happen is that we treated the infrastructure side more as code.

While infrastructure people would start becoming more code savvy there was movement in the other direction and devs started looking at ways their applications might be talking to the infrastructure.

A problem was that to develop a huge app you would need to have somebody work on a project, they would need to understand the entire code base. Everything was connected and the levels of seperation were between “backend”, “frontend” and “middleware”. But this is not ideally efficient as you want each piece of work to be put into it’s own production line, it’s own “silo”. This way we can segment the “dev-team” monolith into “micro-teams” where each works on their own element of the app, relying as little as possible on the other teams. This way they can ship changes independently of eachother and work as fast as possible. An added bonus is that we also can hire people a lot more easily, as all they need to learn is the code their team is working on. Now if only we can figure out a way to implement this….

Here’s an idea - containers. We’ve already determined what a container is and why I use LXD for them. Although it’s a very old concept, as part of the convergence of changes happening around the same time, somebody decided that the answer to “We can’t ship your machine!” was “Hold my beer and see me try!”. Originally, designed to ship lightweight versions of an OS for security, what if we strip it down as much as possible and only ship a single element of the app? Like have the messaging layer be a a container that listens on some port for requests from the front end layer and sends a message to the backend container? But why even manage individual containers, what if our segment of the application requires several instances? Docker solved both of these by giving you an option to actually create a “service” out of your containers running the elements your team is responsible for.

So it seems like we’ve solved it, we’ve broken down the huge monolith into smaller micro-services, like miniature applications, with the ultimate goal of splitting our dev team into smaller and more agile structures. Right?

Well…

The problem Link to heading

Remmeber how I said everybody now got to work on their own silo? Heck this was a boon to recruitment as we just need to find and train a person in whatever the requirements of each micro-team are, rather than learn everything. I mean obviously, not every application can do this, if what you are writing is a graphics driver, a game or other such large blobs then you can’t do the microservice proper, but you can always do the team seperation as much as possible.

Turns out that in technology people like to swing far in one way, discover some new method and we swing far in the other way, so after several years in this whole “microservices” thing we’ve seen the bad sides. Mainly, when you silo people so hard, they tend to loose sight of the overall picture. While it is easy to hire an expert in only one thing you still need an architect or at least a senior person that knows how their service talks to others and what the others do. This is to ensure personal growth and understanding, so that the software we have at the end of the day is better.

The other issue is that when you have a hammer everything looks like a nail. This is another classic tech world problem (look at blockchain being used for everything) and I get it. When you find something that works somewhat well you figure “This worked once, why not try it again?” To which you then begin asking why sites such as mine for example are running on containers? You don’t need a container to run HTML and a web server. If anything it makes administering it harder. But because all we’ve done for the past years was deploy Kubernetes clusters we don’t have the simple infrastructure to deploy a simple web page in many businesses. I find this inefficient.

The solution Link to heading

First of all we need to understand that there are two sides to each coin. Microservicing and siloing of teams is a technical approach but requires the approapriate managerial oversight. You need to ensure collaboration between the squads, be it through team buildings, get togethers etc. If people are friends they are a bit less likely to do the classic “Throw it over the fence to Team X!” tactic and forget about a problem that actually requires collaboration from both side. How you do that as a manager is up to you, but ultimately your teams need to know and trust each other and work on problems together rather than have fences between themselves. You want to foster this, so maybe de-silo a little bit.

Then we also need to stop being alergic of the idea of non-microserviced elements of our stack. Having to have a seperate Apache container and build that, just to run 2 HTML files is a bit much.

Ultimately the pendulum needs to settle in the middle and we need to take a hybrid approach. Use everything where approapriate and after proper consideration. “Microservicing” is a tool, same as monolithic appraoches, the same as blockchain or machine learning (so called AI, but we forgot it’s old name, don’t worry I’ll get to it some day).

Tech leaders tend to keep that inner child and be excited about new developments which is great. Being excited and hyped about something is good, but we need to keep that child in check some times and ask ourselves: “Does everything look like a nail, because I really like my hammer?"