A text message received on a Thursday morning from a source with too much clout to be ignored caught my attention. An excerpt from GoTime #114 titled “Monoliths are the future” by one of my industry heroes (Kelsey Hightower). Its filled with truth and, despite my attempts to offer a rebuttal, I can’t help but acknowledge he’s on to something.
In an effort to split up a monolith I wrote my first “microservice” nearly 5 years ago. Doing a search today for microservices brings up relics of blog articles from a bygone age when I believed that simple internet searches could cover the gamut of distributed software systems. The recommendations were straightforward enough, but the reality of implementing microservices is a far cry from an internet source.
His conclusion is essentially that microservices are circular. You start with a complex system that you break into smaller digestible systems that eventually become too complex to manage. You then circle back to integrating the small systems into the single monolithic system because it has less complexity. His observation is that the complexity of software is not actually reduced with microservices, it is simply moved somewhere else; namely to the infrastructure. His synopsis hits the bullseye.
“Well, normally I’m against big things. I think the world is going to be saved by millions of small things. Too many things can go wrong when they get big.” – Pete Seeger
The article alludes to the theoretical fall of the microservices empire. A simple search for quotes about empires yielded the preceding quote. A general sentiment towards a 90th birthday plays into the culture of microservices in such a simple and meaningful way. I have no association with the author; in fact, I had never heard of him before I read the quote, however it would be impossible to miss the point made in his statement.
Nobody comes into the world at 90. Years are accumulated adding 365 charateristically unique days to the lifetime of an individual. In the same way, microservices acting as the unique parts of a whole of a software system add their unique functionality. It cannot be overstated that in the same way that our bodies must be fully operational in order to sustain another year of life, our infrastructure and software lifecycle must be equally up to the task of sustaining the software we put on it.
Let’s put a few common microservices concepts into perspective.
Independently Deployable
Microservices must be indendently deployable. Microservices are like plumbing. Each service represents an isolated set of pathways that deliver water to respective sources. A sink here, a dishwasher there. Each system is connected at a junction point. If changing out one isolated pipe network requires changing another isolated pipe network, the system isn’t designed correctly. Each system must be connected by a well defined connection specification, for example, “each connection must be a 4” fitting”. The equivalent of plumbing junction points in microservices terms would be API contracts. These must be rigid and, once decided on, cannot change. Period.
Each Service Manages It’s Own Data
Microservices must manage their own data. Every organization has a chain of command. If a given department requires information from another, the handling of that information should be managed through an individual with the proper access to said data and provided to the requesting party. The requesting department should not be given direct access to the data from another. In terms of microservices no service should be making direct access to the database of another. How services manage data should be a black box. That is the point of APIs.
Microservices Are Self Contained
Microservices must contain all business logic in order to manage the specifics of a given business domain. Every team is made of subject matter experts. The marketing team handles print and media efforts to get product visibility. The sales team closes the business opportunities acquired through marketing; and the development and support teams are responsible for the delivery and maintenance of sold solutions. In the same manner microservices manage the responsibility of their respective business domain. A shopping cart service should be able to manage adding items, removing items, and changing quantities without the need for outside sources. By limiting services to business domains you create clear boundaries between where service responsibilities begin and end. Properly defining these boundaries ensures that software only becomes as complex as business needs require rather than creating needless complexity for the sake of calling services “micro”.
There are countless patterns and anti-patterns out there outlining how to accomplish the above goals. It cannot be overstated that hitting the mark on these is essential, but as the referenced article stated, the greatest pitfall with microservices isn’t usually related to the software itself.
All the planning, opportunity, and resources in the world cannot help if the body is unwell, and the same is true with microservices. Are you exercising? Are you eating healthy? Are you getting enough sleep? With microservices we should be asking, Do you have deployment pipelines? Are there automated tests? Can your code and infrastructure handle failures? These are the tip of the iceberg for a paradigm shift in the software industry. We are moving towards more reliance on software systems. Higher visibility, higher availability, and higher quality cannot be ignored.
Monoliths being the future means we live with their achilles heel, “Too many things can go wrong when they get big.” Monoliths carry the burden of failure on a single set of shoulders. Microservices break up points of failure. With proper monitoring and logging in place we can effectively track down failures, patch them, and prevent total system failures.
After 90 years of life it can be concluded that an individual will have received a good amount of support from others. Many pitfalls in life can be avoided with assistance from an experienced resource, be it a friend, parent, educator or otherwise. In my time building microservices systems and providing professional consulting services I can say one thing with confidence…
If you attempt microservices without prior experience, you will fail.
Failure is a necessary part of the process of learning. I could not grasp the concepts properly until I broke or misunderstood the rules and learned the hard way. These failures cause many organizations to thrown in the towel on microservices but it doens’t have to be that way.
If you are considering microservices don’t hesitate to drop us a line. Let’s work together, leveraging our experience learned through real world failures to keep this growing industry moving forward. The future of microservices and the benefits therein depends on it.
