Critical Thinking About Microservices vs. Bandwagoneering - The Latest Buzzword Bingo: Microservices, Containerization, etc.
Every profession is rife with buzzwords, and tech is replete with them. The specific details change, though the basics remain the same, and often recycle old-as-new every 20 years or so. This posting discusses the current bandwagon buzzwords about old-is-new microservices and monoliths primarily, though with some ancillary mentions regarding containerization, and more on Jitsi.
With the latest fad buzzwords, there are individuals and companies that are quite passionately emphatic about _everything_ having to be migrated to microservices. And also many people often incrrectly conflating containerization, Docker, Kubernetes, etc. with microservices. This posting focuses mostly on the microservices discussion.
- How many of these people have consistent, written, and grokked definitions as the criteria of a microservice?
- Do they have any clearly defined, written, definitions about their infrastructure's business domains and their boundaries?
These are required to define the scope of a microservice architecture in order for it to actually work effectively.
Even the major creators and proponents/consultants fanning the current flames of enthusiasm about microservices, warn against this approach of using the same tool for every problem.
It is strongly recommended to instead employ critical thinking and analysis, assessing which areas microservices will be most effective at solving specific, well-scoped, problems that aren't being solved by other methods.
This should be executed incrementally, not all at once. Furthermore even the greatest proponent creators of current microservices approaches strongly emphasize that an overall mixed methodology and broad architectural toolset approach including, where appropriate, use of single and other types of monoliths and other approaches, are often a better fit for many business needs than microservices.
A mixture of tools is generally highly preferred.
Don't get me wrong, microservices very much have their place in the broader toolbox of solutions for a wide range of needs. They should be taken into account, but they should be handled by critical thought and analysis, not just because it is the latest "cool thing".
A little trivia, just as cloud computing is, in a basically maybe overly reductionist explanation, the third incarnation of the mainframe days. The concepts upon which microservices evolved and are dependent, are from older designs, from the mainframe days of 1968, 1971, and 1979 development days. *
There is to date, even the proponents admit, very little published quantitative research on the efficacy of microservices compared to other approaches which have been well researched. Fortunately there are some research projects currently in the works trying to assess their efficacy, but this will take many years for the early data to become useful information, that we can digest into effective optimal knowledge and we grow into deeply grokked wisdom.
Ask Questions First!
Before you or your organization jump on the microservices bandwagon: have any of the following questions been answered in the push to convert to "all microservices everywhere":
- What specifically is your company hoping to achieve with the transition to microservices?
- What specific, well-scoped, problems does the time and expense of migrating to this methodology solve, that isn't solvable with other, potentially easier, less resource intensive (less expensive), more proven-to-be-effective-though-maybe-more-"boring" approaches?
- Have you considered other alternatives to using microservices in trying to solve these issues that aren't being solved with the current methodologies (if any)?
- How will you know if the transition is working?
- What are the specific measures of success?
"Microservices Are Not The Goal!"
"Microservices are _not_ the goal. You don't 'win' by having microservices." (Newman, 2020).
"Microservices buy you options" (James Lewis), which means they come at a cost, and you must evaluate through cost-benefit analysis.
Anyone considering the extensive time and resources to migrate to microservices, should be doing so in the terms of the goal.
- What do you achieve with microservices that can't currently be achieved with the existing system architecture?
- What pre-well-defined business domains and boundaries will be addressed with specific microservices migration?
These boundaries are critically important!
I have a bevy of potentially valid reasons that would make a good argument for _some_ areas, for some organizations, to make changes to their infrastructure, _incrementally_, migrating to microservices. However, this should be handled methodically on a case-by-case, well-scoped, and with a needs-based approach.
Does your organization have clearly defined service boundaries of business domains identified and specified that are being targeted for specific known problems?
Again, I need to hammer on this, because this is a must for microservices to be successful.
- Does anybody in your organization even have any information regarding these questions?
Too many individuals, leaders, and organizations are jumping in without this information first.
How This Relates to Jitsi
Now, a side-note about Jitsi, since I'm working heavily with it the past few years, and this debate has been ongoing.
Regarding Jitsi. It is NOT a tightly-coupled single large monolithic (in the classical use of that term in tech prior to 2012 or so) application (which is a good thing).
Many changes can be made to each component separately without necessarily breaking or needing to change other components (within limits).
However, it is not technically a microservice in its current incarnation, and the core components, while capable of being containerized, will probably never be microservices as-is. There would have to be a quite significant overhaul of the core architecture. Though I wouldn't be surprised if someone/some-group, somewhere, is making such an effort. Please let me know if you are!.
Jitsi is in microservices parlance a highly flexible, decoupled, scalable, effective modular monolith by default, especially the core components: Prosody + Jicofo + Jicofo + JVB. They are however highly modular and can be effectively containerized, but they are not a microservice in a business domain, and scope of maintenance sense.
Most of the other features are however: Jibri, Jigasi, Vosk, wav2letter, and many others we're using. They are each specific services able to meet very specific business needs, and can be modified and maintained separately from the rest, or even completely swapped out for alternative technologies to achieve the same business goals. So they can potentially qualify as microservices compatible. And would be less challenging to migrate to a more "pure" microservices model.
Reasons to Consider Microservices for Your Organization
Here are some _potentially_ good reasons to consider microservices for your organization.
Definition of microservices in this context:
"Independently deployable services modeled around a business domain."
"They communicate with each other via networks..."
"...based on multiple collaborating..."
"... are a type of SOA..."
"...independent deployability is key."
"...technology agnostic." Allows mixing and matching different technologies.
"...information hiding..."
"...a form of distributed system."
"... encapsulate data storage and retrieval, exposing data, via well-defined interfaces."
"... these services could be written (or rewritten) in a few days)."
"... able to make a change to [the] service and deploy that service into production without having to change anything else."
-- Newman 2020
Important Considerations
In addition to the questions earlier in this posting, consider:
- How many microservices can you handle?
- Use incrementation migration to microservices, not all at once.
- How do you define your domain boundaries to get the most out of microservices?
- Levels of distributed systems cohesion and coupling.
- Make changes in as few places at once as possible.
- As you learn about these approaches, when breaking up architecture into smaller services, split them around aggregate boundaries.
Some food for thought and conversation on the discussion. Your thoughts?
Regards,
Hawke Robinson
* Constantine, Modular Programming, 1968 and 1979 on a Structured Design. Decomposing systems into modules, Parna's 1971.