Micro services Architecture: Not just an architecture pattern

People today always wonder. I am probably working on a monolith. What would it take to break it into micro services. Googling would give you the following result:

1. Define the granularity of the micro services and decide what capability to migrate first by understanding how modules can be independent and then creating independent services out of them
2. Start with a module and build it as a service from the ground up to roughly satisfy the same API contracts it did in the monolith
3. Spit the larger team supporting the monolith into smaller teams supporting the micro services
4. Decide how the services will communicate with each other (Event driven or database driven approach) and build the capability to send messages across services directly or indirectly through Databases or Message Queues like Kafka
5. Decide whether to split the database per micro service, per micro services etc and how to handle transactions across micro services. This may require the use of a distributed caching mechanism, transaction management in message queues, etc.
6. Decide how to expose the services as API contracts using API gateways
7. Decide which cloud provider to go for and how to deploy the services. This will entail an understanding of the actual underlying infrastructure (containerization using docker or VM per micro service, etc)
8. Take care of cross cutting concerns like Telemetry, Security, etc using open source solutions easily available on the internet.

Of course this would be a gross oversimplification of the entire process to adopt a micro services framework and should in no way serve as a guide (quick disclaimer from me for the uninitiated)

What nobody talks about though is the actual challenges in migrating to a micro services architecture, especially from an organizational standpoint and from a people management perspective.

The reality of the burgeoning IT industry

Today the sad reality is that the majority belongs to the monoliths and legacy applications. There are quite a few IT organizations that have massive teams supporting legacy infrastructure and application framework and millions of clients login to those applications everyday. The cost of revolutionizing the delivery pipelines for such setups can never outweigh the benefits of moving to a micro services framework. So such setups can directly be eliminated from this topic.

Then there are others who want to migrate to a micro services architecture but have no clue how they are going to go about it. Moving to the cloud seems like a herculean task and hiring the right talent to get them there seems to be a risky roll of he dice as they don’t even know whether the target state would actually be beneficial to them. Such organizations have such tightly coupled systems and thought processes that changing either would have them going out on a limb and probably failing due to lack of intent/ lack of proper guidance/ heart in the right place but lacking in education and so on. We will eliminate such setups as well from this topic.

The third kind: The ones that actually get it done. You know the type. Lets move on..

Onto the Fourth category which is essentially the target of this post. This strip from Dilbert kinda fits in with the theme:

Google Image Result for http://www.standardsuniversity.org/wp-content/uploads/dilbert-cartoon.jpg

In the comic strip, you see people throwing around some buzzwords and jargon that make 0 sense but because they heard about it and felt it applies to the topic of discussion they used them in the conversation. So essentially everybody just bullsh#$$ed themselves.

The fourth kind of setup is one where the belief is that micro services can and will be implemented. Just that the word is taken at face values and nobody really understands that its not just an architecture overhaul. It is

a. A thinking overhaul

b. A team structure overhaul

c. A way of conversing across teams overhaul

d. A different way of setting delivery expectations

e. A different way of communicating across teams

A lot has to change for you to be able to truly adopt that micro services mindset.

But the problem in such setups is

a. The delivery method is not likely to change

b. The hierarchies are not likely to change

c. Decision making is nonchalant and complacent

d. Structural design is flawed and duplication is rampant across services

e. People don’t want to take the time to truly understand why they are doing this and how they will do it

And what do they end up with — Micro Monoliths

So what needs to change? Everything!

1. Teams — Teams of 6 to 10 members per micro service. Developers spread across the application stack with a good mix of experienced vs fresh hires/juniors. Devops specialists to take care of delivery pipeline setup who also have application coding experience, essentially with the main language being used across the app stack. QA engineers working as developers to write automated test scripts/frameworks designed to break the application and regression test them.
2. Teams being able to work completely independently of each other. That’s where business analysts and product owners work across teams to ensure synergy and synchronization.
3. No micro management. The team decides what goes when and the team is completely empowered to make those decisions. An Agile mindset comes in handy here.
4. Managers as facilitators, functioning just like Scrum masters to remove impediments and ensuring teams are able to function without any blockages and have enough work units to fill their day.
5. Constant appreciation within teams and across teams to boost the morale and that is the one thing that really boosts productivity. The better the morale, the higher the velocity.
6. Making teams understand the bigger picture. There is always resistance to change but if you can make the teams believe that their changes will not just benefit the company but their personal growth as well, then they feel more invested in this. Delivering for a salary incentive will get you 1x. Delivering for a bonus incentive will get you 1x more. Making them believe that they are changing the world, one line of code at a time — PricelessX speed.
7. Understanding that there will be numerous failures along he journey but factoring that into the culture and encouraging people to not be afraid to fail as long as the teams learn from that experience.
8. Encouraging constant learning and constant re-skilling to have people keep their head in the game.

9. Learning from the best — most problems have already been solved. Before you set out to reinvent the wheel check out the architecture stacks undertaken by other organizations and how they solved specific problems related to yours. Design patterns, Architecture patterns and Design principles — learn them, imbibe them and make sure you implement them.

In conclusion, micro services is not just an architecture pattern or a delivery methodology. It is a way to inspire people to work together and create cogs in a massive machinery that move in synergy and create something awesome which changes the world. Micro services are only as good as the teams working on them. So smaller teams with the right motivations, the best intentions, the correct balance and the fearlessness to fail and learn from those — will always make good on that API promise.

Disclaimer: The views in this post are solely my views based on my observations working across Monolithic and Micro services setups. My observations are personal so quote them at your own peril :)