Micro services Architecture: Not just an architecture pattern

  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.

The reality of the burgeoning IT industry

  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.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Evolution Of Cloud Computing And Enhanced Business Efficiency

How to solve Django memory leak

Generators in Python

Working with Unity’s NavMesh System for Smart AI

Handling bugs in your development process: the impossible question — Blog — Ponicode

Solution for Problem Code: HELPSANT in Numbers Quest contest conducted by The Coding Culture

The Database as Code Landscape

Linux Basic Commands

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ritesh Shergill

Ritesh Shergill

More from Medium

Old is Gold : Slack believes it

Is Supple Design the servant of the Deep Model?

Software Requirements Specification — Your Blueprint for Building Software Solutions

Performance Testing: Load vs Stress vs Soak