This post walks you through a framework for adopting new technologies. Microservices is a placeholder in this post. It is a generic framework that you can apply to any new technology that you are planning to adopt.
Should we do microservices?
The above question plagues the minds of software developers.
Popular programming culture made microservices the de facto way to build software. Now, many are second-guessing their choice.
Here is a post from Segment on why they consolidated their microservices into a monolith.
Microservices is archetypical of software trends following the Hype cycle. In the Hype cycle, microservices has passed the “Peak of Inflated Expectations.”
A framework for making new technology choices
Before adopting any new technology, you have to:
- Clearly define the problem you are trying to solve with the novel technology.
- Understand how the new technology solves the problem.
- Build perspective by studying the evolution of the technology.
- List the supporting structures needed to make the new technology work.
[ Click to Tweet (can edit before sending): https://ctt.ac/zcw9I ]
The above may sound meh, but taking the pain to define them to the T is the key to the success of new technology adoption.
Clearly define the problem you are trying to solve
Nailing down the problem is the first step. You would be surprised by the number of people who try to solve a problem without defining it formally.
When the problem that you are trying to solve is vague, it becomes tough to find a solution to it. How many times has it happened to you that you describe a problem to someone, and in the process of doing so, you get closer to the solution?
Clearly define the problem that you are trying to solve with microservices. Is it a performance problem with the application? Are you trying to increase the productivity of the team with microservices?
When you do this, sometimes you find non-disruptive ways to solve the problem. Better communication between teams might be the solution, not microservices.
Understand how the new technology solves the problem
Understanding how the new technology solves the problem will help you to evaluate it objectively. Defining the problem, as stated in the first step of the framework, is essential for this.
There are two broad reasons for microservices adoption—technical and logistical.
Technical
The application has grown in complexity and has workloads vying for different types of resources. You are not doing justice to any of these workloads by packing them in a monolith. For example, some workloads might be CPU intensive, some IO heavy, and the others hungry for memory. By extracting each of these workloads into a microservice, you have the freedom to host them in different servers conducive to their demands.
The application has grown in complexity and has workloads better solved in different programming languages. Breaking the monolith into microservices gives you the ability to code them in the programming language of your choice.
Logistical
The application has evolved as well as your company. Different teams are responsible for different areas of the application. You want these teams to be independent. If you break the monolith into microservices that mimic the team structure, you will achieve this independence. These teams can work independently without stepping on each other’s toes, thus being more productive.
Build perspective by studying the evolution of the technology
When you try to dig up the history, keep in mind that you are not going after the rigorous academic definition of the term, but the cultural context of its evolution. The common definition of a term may not match with its formal description. For example, when people say microservices, they are usually referring to Services Oriented Architecture(SOA) and not microservices in particular.
Microservices exploded due to big companies like Amazon and Netflix evangelizing(maybe unintentionally) them. These companies have thousands of employees and divisions. Once you understand this and build a perspective, you will naturally ask, is this applicable to me? If you are a small startup that can count your tech team with one hand, in all probability, the answer is no. It is tough to build this perspective without studying the evolution of the technology.
Supporting structures needed to make the new technology work
Whenever you introduce a new technology, you might have to make some changes to the way you work. Some of these changes might be inconsequential, and others extensive.
For microservices to be successful, you will have to invest in tooling. You will have to have a robust monitoring system because, with microservices, you are treading into distributed computing where failure is a given. I will stop here as this requires a post in itself.
In many circumstances, these changes might be far-reaching negating the benefits of the new technology. Be keenly aware of this trade-off.
Summary
Doing this might sound time-consuming, but it pays off by preventing unmitigated disasters down the line, once you are in the middle of adopting the new technology. Many new technology choices bomb because someone did not do the above painstakingly enough.
Follow @abhyrama
Hype Cycle image By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051.
Photo by Miguel Á. Padriñán from Pexels
Abhirama's Blog 