Microservices Are (Not) the New Black!
The ultimate purpose of this article is to make people break out of the bubble surrounding microservices' adoption— but to expose their shortcomings.
Join the DZone community and get the full member experience.Join For Free
The ultimate purpose of this article is to make people break out of the bubble surrounding microservices' adoption and their supposedly instantaneous healing effects for our legacy applications.
Microservices are not some magic IT elves able to put an end to our struggles while building software, but as a matter of fact, pieces of code thought of, designed and written by human beings. This means that the old IT process (be it agile or waterfall) of requirement gathering, coding, testing and deploying, unfortunately, still applies. (I know that it is hard to swallow, but it is nonetheless the reality you have to face).
Therefore, moving to microservices cannot be done without a clear vision: why exactly do you need to abandon all or part of your well-established legacy, assets, and processes for the whole new world that you have not practiced before.
You may also like: What Is the Future of Microservices?
Once the vision is adapted to your context and pains, getting the key players on board, body, and soul, is what will define your success or failure in this endeavor.
If you have done (or plan to do) your thinking about all these aspects carefully (and not some one-size-fits-all-copy-paste-approach) please disregard the article and accept my apologies for your wasted time.
Otherwise what will follow may come in handy for what is needed to increase your chances to get a successful transition.
At first glance, it may seem that the word microservice has a straight-forward definition (and purpose):
- Micro: Very small (Merriam Webster dictionary).
- Service: The works performed by one that serves (Merriam Webster dictionary).
In other words: a piece of code that serves its consumers by providing a very small work.
This is far from the reason this new way of building software was thought of in the first place.
As Sam Newman (one of the former folks from Thought-Works that contributed to coining the term microservice back at the time in 2012) states:
The concept of size is actually one of the least interesting things…the concept of size is highly contextual…and I urge people not to worry about size
What do you need to worry about then when planning a migration to a microservice architecture.
Did I hear someone say: Technology? …well not so true, as Sam Newman again states:
It can be all too tempting to grab a whole load of new technology to go along with your shiny new microservice architecture, but I strongly urge you not to fall into this temptation
What is of the utmost importance when considering this transition is to prepare a solid ground around people, culture, processes, and finances for this new way to thrive. and here are some hints to help you set the foundational pillars:
Craft a Clear Vision and Get the Business, the Management, and the IT Team Buy-In
During your journey, many decisions will be wrong and the management and business need to give the team enough autonomy and safety to experiment with new approaches, make mistakes and learn from these mistakes.
What is important to remember here, is that the company is abandoning consciously a state of mastery of the legacy processes and systems to enter a new (non-mastered) era of processes and applications. Hence, some chaos and a steep learning curve should come as no surprise and all the costs that go along. On average, you should probably start reaping out some benefits after a year of hardship.
Adopt an Incremental Approach for Building Your Microservices
which means that you should define exactly what you want to achieve during an increment (2-3 weeks), keep it very small (even tiny) understandable by all your team members and keep pushing toward that goal until you reach production and then inspect and adapt. How your new microservice behaves in production and the interactions it has with the final consumers should be your ultimate goal before moving to the next candidate.
After collecting the feedback (and key metrics) in production, adapt your strategy consequently for building microservice, adapt or change the tools or language if not suitable, and please do not measure your success on the number of microservices build.
Ask yourself continuously questions like: Are my customers happier, can my services (micro) be deployed independently, are my team autonomous in the whole construction process going forward to production…if the answer is no to some of these questions, then either you aim too high (which means that your approach is not so incremental after all), or maybe this new architecture is not what you need.
Create a Safe and Collaborative Ego-Free Environment
An environment where the team is empowered to come with a plan for building debt-free ready-to-be-shipped microservices. The cross-functional team should brainstorm regularly a backlog that includes all the activities, and the acceptance criteria needed to “build the beast”. The backlog needs to be as clear and non-technical as possible to get everyone on board all the team members (and not only techies) and hence drive everyone toward a common goal.
A microservice’s external interface (or contract) needs to be defined clearly, collaboratively and without any ambiguity with the consumers. This is not a single-sided exercise and the consumer's involvement since day one is vital. The management role, during the transition, is to support the empirical facets of building microservices.
Think All the Aspects Regarding Non-Functional Requirements Carefully
the team should pay the greatest attention to the communication and interactions between the microservices more than how the microservice behaves inside. Technology and tools should be a facilitator and not an objective.
Avoid Copying Someone Else Methodology or Priorities
the transition should suit your needs and solve your problems. Retrospect about the whole approach frequently and honestly and tailor it to your context and pain points. Keep your vision always as your north star.
- A clear vision and actionable measures of success are needed before the adoption of microservices (preferably based on real issues identified and documented).
- Microservices are far from cheap, they may be even very expensive especially during the first year or so.
- Switching to microservices does not come to fruition overnight (or even after 100 nights, as in politics…).
- Transitioning to microservices means abandoning consciously a state of mastery and getting out of your comfort zone, so expect some chaos and learn from it.
- Real collaboration and involvement are key.
- Microservices do not solve scalability, performance, deployment, automation, orchestration, and customer satisfaction by their very nature. So, roll up your sleeves, and think these aspects through!
- All the tools in the world (even containers, Kubernetes or the likes) will not help you write a good microservices, if you don’t give it the necessary thoughts upfront (what will my microservice do and how it will communicate with its friends).
- You are not Amazon or Netflix (unless you are, and hence thank you for reading my article anyway, I feel so flattered), so what works for them will not necessarily work for you.
Finally, beware! Your customers or consumers will never pay for a microservice, but they will pay for the delivery of the value they expected from using it (be it a delivered via a microservice or a UFO*).
*UFO: an unidentified flying object
Opinions expressed by DZone contributors are their own.
Comparing Cloud Hosting vs. Self Hosting
Hiding Data in Cassandra
Five Java Books Beginners and Professionals Should Read
Implementing a Serverless DevOps Pipeline With AWS Lambda and CodePipeline