Top 6 Challenges of Using Microservices

Introduction

In continuation to my previous article about microservices, i would like to highlight a few key factors that need to be considered before adopting microservices into the ecosystem of any organization. Microservices architecture is NOT a one size fits all solution for all scaling problems faced by an organization. This article highlights some of the common challenges faced by organizations in adopting microservices.

01. Embracing the DevOPS Culture

Developers working in a traditional ecosystem normally handle design, development and enhancement of the features in their application. Bringing the 'OPS' part into the lifecycle of engineering means demanding more resposibility, maturity and efforts from the developer's end. This will be a key challenge if you are an emerging startup or an young enterprise - as its tough to find people or align them to this change of culture. It is also mandatory to have DevOPS automation around rapid provisioning and app deployment as this involves saving efforts of developers as the granularity of applications grow. This in turn results in additional cost for implementation and maintenance of DevOPS pipelines.

02. Functional Testing & TDD of Microservices

Adopting a TDD(Test Driven Development) over a monolothic application is far easier compared to the microservices world. Each microservice has a defined set of dependencies which can in turn affect the stability of the testing and in some cases, transitive dependency too. Functional testing of microservices to verify end to end functional changes is also a challenges as it requires even the junior developers to understand the microservices communication and ecosystem clearly. ATDD(Acceptance TDD) and BTDD(Behavior TDD) may not be possible where a DTDD(Developer TDD) aka unit testing may be easier.

Design for Failures - a key paradigm to be kept in mind while designing microservices. Identifying points of failure and setting up the resilience ensures scalability.

03. Understanding Logging, Monitoring & Tracing of Microservices

It is very trivial for a developer to understand the difference between logging, monitoring and distributed tracing in the context of microservices. In case of any issues that occur during the product development or after the product release, following parameters are critical

• the ability to navigate and locate root cause of the issue
• ability to determine the time taken for remote calls
• ability to monitor the availability of the microservices, resource consumption etc.

For a developer belonging to the open source world, a combination of EFK(Elastic Fluentd Kibana) or ELK( Elastic Logstash Kibana) is highly recommended. In case of enterprise ecosystems, Datadog is an excellent choice. This may sound simple, but talk to someone who did this setup recently and you will understand the pain in enabling and onboarding developers to use the same.

04. Ensure Data Consistency

Each microservices operates within its own boundary and has a dedicated datastore to handle its operations. This results in a lot of data redundancy and synchronization challenges. Even DDD( Domain Driven Design ) - which is one of the best ways to implement microservices results in data redundancy [for a lot of good reasons]. This poses a unique challenge of maintaining relationships across a cluster of services while still ensuring data consistency. CQRS (event sourcing), Event journaling and recovery etc are some of the ways to handle these challenges. While solutions exist in the open source world, this keeps adding complexity to the life of the developer.

05. Security Model with SAST & DAST support

Security is one of the weakest links in the microservices architecture - often underlooked. A standard microservices implementation needs to have a service mesh like ISTIO to ensure the consistency in security across microservices. Key externalization, key rotation and compelexity mandates using a centralized security storage like Vault is a minimum recommendation. Most of the microservices implementation do not cover the scope of the above recommendations and ends up exposing a good amount of vulnerable security spots. A DAST or SAST scan on the microservices can uncover 75% of the underlying security issues. If you are in the microservices world already and not using DAST or SAST, then you are in for some serious trouble.

06. Architecure and Design Complexity

Let's face it - the choice of architecture and design involves a high level of skill expertise normally and this becomes even more challenging when it comes to microservices. Architecture choice in creation of microservices, data management, integration, infrastructure etc. demands the need for a clarity and experience in each of the choices. As an organization, you need a Development team + Architecture house which has already executed and experienced the challenges that are lying in the future roadmap. API gateways, Load balancers, Communication with middlewares, Service mesh, etc are some of the commonly used framework components for a microservices implementation. In addition to all of this, enterprises think that once they go to microservices architecture the infrastructure cost will be drastically less. This is one of the biggest misconceptions and as the architectural complexity goes up, the cost of implementation & maintenance also rises.

Conclusion

The objective of the blog is to not spread the fear about the hidden complexities of a microservices implementation, rather making an informed choice. The choice you make determines the path that lies ahead and the problems that come with it. A seamless implementation with a right set of team members ensures building a scalable business application.