Micro services architecture - considerations

As technologies are evolving and product and engineering teams are trying to catch up with latest trends and the we take motivation from successful big companies, we get motivated to emulate without knowing what we are getting into.

A Netflix or facebook  may not be right model to emulate.  Monolithic applications have their own advantages, while micro services propose new way of looking at things. 

Monolithic advantages

• One team,  there are multiple people in the team who can solve a problem
• Tech stack is streamlined. Everyone works on same stack.
• Easy to manage, there is an order to everything
• Transactional systems are lot easier to build, triage and fix issues with monolithic.

Micro services advantages

• Multiple services, shared responsibilities. Each team is isolated with other teams by contract / APIs.
• Polyglot.  Teams can chose their own tech stack.
• Scale is easier, each service can scale independent of other services. 

As much as micro services are tempting,  review your context, what is your business current architecture. One advice is not to jump into one vs other without looking at the trade off

Your context

• Working legacy- Is it a product running for many years with fewer original team members who built the product remaining? Is your product on prem deployment per tenant and licensing is expensive that you are making lot of money with each tenant deployment? customers are happy with what they are getting, but you find scaling and deployment management a problem? You have more in devops and support than engineering?
• Recent monolithic - Your product is built few years back and you got most of your core team still with you, you didn't start with micro services architecture, you got decent customer base but want to get into what scales better for future.
• Startup -You are a start up building a product and are passionate about going with latest technical architecture.
• Giant / Unicorn

Trade offs

Not every application is Netflix  or  Amazon. There are tons of great companies that provide lot of products and services and making lot of money.  One size doesn't fit all.  

• If I have a homogeneous tech stack  , probably wouldn't worry too much about a polyglot system.
• Scale - Amazon vs Artsy.  Systems may look similar in nature but some do not need too much of scale. a beautiful , fully functional system is what is sufficient.  If your product doesn't need millions of hits every second, you can think differently.
• Redesigning existing product into micro services vs adopting existing code base into cloud infrastructure (build your code into a docker image and deploy into k8s).
• Resource planning. If all the team is deployed to build micro services architecture, you may be risking customers leaving your product for competition as you spend years in building your new system with micro services depriving customers of regular feature updates or bug fixes/enhancements.

Image courtesy:

Images are sourced from internet and links are provided to sources.