Pitfalls & Challenges Faced During a Microservices Architecture Implementation
Total Page:16
File Type:pdf, Size:1020Kb
Cognizant 20-20 Insights Cognizant Digital Systems & Technology Pitfalls & Challenges Faced During a Microservices Architecture Implementation Microservices are the de facto design approach for building digital applications. However, issues highlighted in this paper can and do lead to implementation challenges and even failures. Here are a few strategies to avoid and overcome them. Executive Summary Organizations across industries are at various stages suboptimal implementations of microservices of their journey toward adopting a microservices architectures that have emerged since our initial take architecture style.1 Some have been successful in on the topic.2 delivering real business benefits, while others are This white paper provides readers with guidance on still experimenting. fundamental design decisions required to properly While the benefits delivered by a microservices implement a microservices architecture to realize all the architecture such as agility, selective scalability and benefits available to organizations willing to take availability still hold true, we are dismayed by the various the plunge. February 2020 Some teams tend to think of the “micro” in microservices as a lever to design smaller-scoped systems, while others think of micro as the lever to deploy and operate manageable systems. Microservices architecture pitfalls A large number of the teams developing systems to be scoped? How we can maximize reuse for based on microservices architecture have a system component or service in its functional some form of experience in service-oriented form? Basically, identifying the right boundaries architecture (SOA) that was heavily influenced and granularity are two of the biggest challenges by the middleware vendor products such as for a solution designer, especially as the selection enterprise service buses (ESBs) or Web standards depends greatly on the domain and context of the such as Simple Object Access Protocol (SOAP) and solution space. Web Service. Application developers using microservices style While SOA experience helps in developing face similar challenges. Some teams tend to think service-oriented thinking, we have found that this of the “micro” in microservices as a lever to design background can also have a negative influence, smaller-scoped systems, while others think of micro resulting in pitfalls such as sub-optimal granularity as the lever to deploy and operate manageable of service, representational state transfer (REST)- systems. We see three major variations of this issue only mindset, excessive service calls (chatty in microservices scoping (see Figure 1, next page). services) and database as shared resource mindset. ❙ Entity scope: Data entity-oriented design Continuous technological improvements have tends to cause inflexibility at the individual caused some teams to fall into a technology-only microservices layer and change complexity at thinking trap, causing even more complexity when the overall system level. these systems experience high-volume production ❙ Process scope: Designing microservices at this traffic. These pitfalls manifest in multiple forms. level of granularity tends to result in fragile and (Read on to see what we have observed across volatile services. projects.) ❙ Utility scope: The notion of utilities treated as microservices causes the provisioning of The “micro” in microservices operational sophistication without reaping architecture adequate business benefits since such Application architects have struggled with the utilities are often non-differentiating to most granularity dilemma for a long time. What’s the enterprises. right level of granularity for a system component 2 / Pitfalls & Challenges Faced During a Microservices Architecture Implementation Cognizant 20-20 Insights Microservices granularity levels Policy Claim Customer ENTITY Email PROCESS Users Notification Issue policy UTILITY Address Process change claim Figure 1 While all granularity levels are expected to be microservice designers must pay close attention served in a system, the main benefits of such to the context-dependent interactions that architecture design can easily be missed; that is, the microservice needs to participate in. This balancing agility (speed of change) with resiliency requires the designers to think in terms of loosely (safety of change). Two issues are typically coupled, event-oriented boundaries and the observed: context mapping. ❙ It’s difficult to get business buy-in to the The database monolith program that’s delivering such services. Microservices adoption moved quickly from an ❙ Operational complexity increases without real emerging concept to the de facto design pattern benefits. for application architecture. However, as with any Finally, as IT organizations embrace a system over-hyped technology, the design patterns and paradigm across all non-trivial business domains, best practices were not very well established and event-oriented collaboration patterns have understood, which led to poor implementations. become a mainstay of such microsystem Among the major obstacles are large databases architecture design. These pitfalls tend to become a used as a persistent store for many -- or all -- of the big bottleneck that thwarts event-oriented thinking microservices. This database can lead to a monolith on the journey toward evolutionary system design. at the data persistence layer, resulting in several To avoid these pitfalls, IT organizations must ensure challenges such as: that no microservice is designed without an explicit ❙ Performance bottlenecks. One of the key alignment and traceability with business capability drivers for microservices architecture is the of the domain, as advocated by bounded context ability to scale horizontally and dynamically. strategy of domain-driven design.3 In addition, the 3 / Pitfalls & Challenges Faced During a Microservices Architecture Implementation Cognizant 20-20 Insights Quick Take Advancing Innovation & Time to Market in Consumer Lending One of our APAC clients in the consumer lending domain that wanted to enable innovation and improve speed-to-market transformed a single monolithic application into microservices with little or no focus on the design aspect of microservices. The result was 500-plus microservices with extreme complexity leading to performance bottlenecks due to chatty inter-service communication. We have recommended a domain-driven rationalization to address this situation. This not only helps address performance challenges, but also ensures evolution of the application in a completely autonomous manner. However, with a monolithic database, the scaling changes in other microservices, which defeats of microservices puts additional load on the the core purpose of microservices. database, creating a performance bottleneck. There are many reasons we have seen that lead to ❙ Coupling between microservices. this anti-pattern; two key ones are risk averseness Microservices architectures offer agility in that to move away from the monolithic database and they are loosely coupled and independently database designers who are not fully skilled in deployed. However, if multiple microservices are newer patterns like microservices, leading to tied to the same tables in the database, then any traditional database design. change in the schema will result in cascading If multiple microservices are tied to the same tables in the database, then any change in the schema will result in cascading changes in other microservices, which defeats the core purpose of microservices. 4 / Pitfalls & Challenges Faced During a Microservices Architecture Implementation Cognizant 20-20 Insights To avoid these pitfalls, IT organizations must ❙ Adopt CQRS pattern to use read replicas. ensure that the database design complements the Command query response segregation (CQRS) microservices by following best practices: is an architecture pattern but it can be applied to microservices database design to answer the ❙ Database per service in a no-share model. biggest question: Can data be shared between Each microservice needs to have full ownership microservices? of the data it requires. This does not mean a ❙ separate physical database but ownership of the Break distributed transactions with a saga 4 data it masters. pattern. The division of database objects into groups of logical schemas in bounded context of ❙ Polyglot persistence model. Making a the wider transaction boundaries require multi- relational database a default storage of all types phase commits. Avoid this with saga patterns of data leads to poor results, hence all types of that keep intermediate states. databases (e.g., NoSQL, Graph, in-memory, etc.) must be used. Quick Take Overcoming Centralized Database Shortcomings One of the new cloud-native features of a consumer lending solution implemented in pure microservices style was undermined by a single centralized relational database. This design led to the database becoming a performance bottleneck and hindrance to system scalability and resilience. We addressed this issue by refactoring the database into multiple domain-centric physical instances with microservices-based logical separations. This allowed domain-based isolation, which enabled resiliency, scalability and performance improvements. 5 / Pitfalls & Challenges Faced During a Microservices Architecture Implementation Cognizant 20-20 Insights Breaking the data monolith through bounded context and polyglot design MS 1 MS 2 MS 1 MS 2 MS 3 Full access Full access Read only