Microservices vs Monolothic the hottest debate topic in IT world where micro have been at par than mono. Recent evolutions and transformations have been paving way for microservices world irrespective of technologies or domains.

Pressure to go live to market quickly have pushed IT to use microservices approach which is faster to develop, test and deploy. Teams often tradeoff with quality over delivery time, this leads up into quick and dirty code leading into bad design, huge technical debt.

So grass is not all greener on this side too, only few organizations and teams have understood those problems and working towards fixing those along with using the benefits of microservices approach.

  • Mostly organizations and teams end up using same database , non-distributed systems which adds up to complexity and dependency for services on each other.
  • With development over agile model, emerging demand and features , new APIs are plugged in over services to serve the purpose without following proper design. This makes design more of patch-work.
  • Architecture and Design on papers might have quickly evolved to microservices principles but the dev thought process takes longer as they spent large time of their life on monolithic applications. This cause the first version of the services to be a masterpiece but gets tainted over the time with bug fixes and workarounds plugged in to be highly available and evolving solution. Also middle, small sized organizations often tends to use same teams for most of the services, which causes teams to add more cohesion between service over the time with same set of eyes on all the services. Further comes the challenge on planning and managing APIs deployments as now those are dependent on each other.
  • Time to test a microservices application is much more than testing a monolithic application due to complexity and variety of test needed on all APIs- This often leads projects/teams to decrease test cycle and release application version which is not tested fully.
    More the microservices – more are deployments, code management, configurations, hostings – there are often misconfigurations , miscommunications between teams and more vulnerable to attacks.
  • Finding an issue in microservices world is like finding a needle in a haystack – with microservices approach its important to have SRE principles strictly followed to have SLIs and SLOs in place to be able to find an issue/problem quickly between the services.
  • Not to forget, Technical debt- often these are overlooked and forgotten due to “faster time to market” benefit of the APIs.

In summary, microservices might have allowed us to evolve our softwares, applications to keep up with the pace of market but its important to understand, fix problems which will be faced to cope up with and maintain these applications. Its important to help code , quality engineers to be able to quickly evolve and change mindset, have more cohesion between development, operations and less between services. Spend more time in identify and fixing reliability of platform , technical debts over tight deadlines of the projects.

Author: Prateek Srivastava
Lead Solutions Architect / Engineering Manager
Original Post:  https://www.linkedin.com/pulse/micro-service-prateek-srivastava/