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
data it masters. pattern.4 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

Shared table

NoSQL RDBMS Graph In-memory

POLYGLOT DESIGN
MS1 bounded context
MS2 bounded context

Figure 2

The REST compulsion ❙ Reactive services need additional messaging

infrastructure to implement besides
The microservices architecture grew during the
microservices, which is not generally available.
decline of traditional SOA. As most of the traditional
SOA was built on HTTP-based SOAP, the natural To avoid these pitfalls, we recommend the following
evolution for microservices was to expose its best practices as shown in Figure 3 (see next page).
functionality through HTTP-based REST services.
❙ Understanding the distinction between API
The pitfall here is that most developers consider microservices and core microservices. During
HTTP REST as the default way to expose the the microservices design, there should be a
functionality of a microservice rather than clear distinction between API microservices
considering asynchronous messaging alternatives. that expose their functionality to the external
This leads to various challenges of performance and world against core microservices that are used
complex transaction management. by other microservices. The core microservices
should be implemented on a reactive pattern.
The key reasons why HTTP REST is used as the
❙ Developer awareness of reactive system
default for microservices implementation:
architecture is key. Developers should
❙ REST API has become very popular understand reactive system architecture and
and developers are comfortable with its associated benefits such as responsive and
implementation. resilient microservices.

❙ Most developers are not experienced in reactive

patterns and hence avoid implementing services
based on asynchronous messaging.

6  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Quick Take
Overcoming REST Challenges
One of our large banking clients has implemented a core platform that offers both
message-based and service (REST) interfaces. However, in pursuit of REST-only
integration, the company implemented a REST interface on top of messaging that
resulted in interface complexity, transaction losses and latency issues due to the increased
processing pipeline and number of components engaged.

This is now addressed by offering APIs as either messaging or services. Inter-service

communication is now being handled through messages directly across components,
helping with both loose coupling and high reliability.

Overall, while REST is a very useful protocol

to expose functionality for microservices,
Reactive microservices and
indiscriminate use can lead to challenges that can
integration be avoided by using asynchronous patterns.

Chatty services
A chatty application is one that relies on numerous
MS1 API MS 2 API services to fulfill a request or a process. In
most cases, chattiness is a result of designing
microservices that are too fine-grained and break
the bounded context and independent business
capability principle.
Event bus
While calling other services to fulfill a request is
often considered as normal and acceptable, chatty
services incur numerous overhead such as:
Reactive Reactive Reactive
microservice 1 microservice 2 microservice 3
❙ Network latency, disk reads, database queries,
etc. on both the calling service and the service
being called.
For any microservices-based implementation, the
architecture should have a provision for core messaging ❙ Runtime dependency between the
infrastructure. For more complex architectures, a more microservices, resulting in a distributed
elaborate event bus architecture should be considered. monolith. All dependent microservices need to
Figure 3 be available and operational at the same time.

7  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Quick Take
Embracing an Event-Driven
Architecture
A large bank had embarked on a transformation program to modernize its payment
landscape using a microservices architecture style.

A centralized service orchestration model was implemented for payments processing

that led to chattiness between orchestrator and functional services. This affected both
latency and throughput of the platform. Additionally, the orchestrator became a scalability
bottleneck for the system.

Our recommendation was to consider an event-driven architecture and implement long-

running processes using service choreography since it results in a highly scalable and
performant design due to loose coupling and non-blocking.

❙ Testing, which can become challenging as all the

dependent microservices need to be available.
Sharing data across microservices
If such issues are observed, then first revisit the
microservices design to ensure that the essential
principles of domain-driven design have Customer Customer
been followed. service service

It is also worth analyzing the dependency on other

microservices. If the dependency is on the data
KYC
provided by another microservice, then the IT team Personal details
details
should consider replicating that data to avoid the
remote call. This also allows the service to transform
and store the data in a way that is optimal for a given
Address Customer
microservice. Additional benefits result beyond an snapshot

avoided remote procedure call. For example, within Contact

customer management and know your customer
(KYC) bounded contexts, a customer snapshot Customer management
bounded context KYC bounded context
remains persistent, which avoids the need for a
remote call. See Figure 4. Figure 4

8  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Loose coupling through asynchronous communication

Customer KYC
service service

Publish: Initiate Consume: Initiate

KYC event KYC event

Event bus

Figure 5

In some cases, one microservice might need to call microservice design systems that are misaligned
another microservice to trigger the business logic with business objectives. In addition, the evolution
it contains. In these situations, one service cannot of these microservices tends to be influenced by
avoid communicating with the other, but the the technologists.
IT team can implement it as efficiently as possible
In the majority of cases, this snag is a result of
via asynchronous communication protocols
problems on both sides. The business thinks
(see Figure 5).
topics like microservice design are too “techie”
Technology-only thinking and thus believes it has no role to play. IT thinks
business doesn’t have any useful know-how to
While designing microservices, we often see
contribute to microservices design and thus
development teams acting in complete isolation
shouldn’t be invited/consulted. System designers
with business stakeholders. IT teams tend to
create application boundaries that do not align
think that once the business has provided its
with the business capabilities and the experience
project requirements, design is an IT-only activity
design that the business requires. The result:
and sub-system decomposition, and defining
the microservices identified for such projects do
microservices and release mechanisms are the
not reflect the business domain (both problem
technology team’s agenda. This turns out to be
and solution) and instead are filled with technical
a major shortcoming in projects where business
services.
subject matter experts (SMEs) are not involved in

9  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Our experience suggests that, more than technology, it’s the culture
and systems thinking that influences how well we deal with these
pitfalls in microservices-based systems.

To avoid this pitfall, solution architects must play a Docker” are becoming commonplace. We believe
major role. They need to ensure that business has a this pitfall is one of the biggest issues facing
seat at the table while designing microservices and microservices adoption today.
both business and IT are able to offer reasons about
Technology is a strong enabler to get
design for delivery, lifecycle management and
microservices right, but that’s not the endgame.
evolution of business capability in scope.
Teams should not let these technologies steer
Another major issue in this category tends their efforts toward microservices. Once they
to be rooted in the accelerating evolution of have designed the right level of microservices
technology. Every few months (sometimes even that are aligned to the business being automated,
weeks) a new shiny technology is released by technology innovation should be used to deliver
vendors who talk up their use of microservices. the promise of high quality and agility. Some of
While continuous technology evolution is a the areas where microservices will really benefit
good thing, it tends to stimulate interest in the from technology evolution include elements
technology by business and IT teams, who steer such as automated deployment, release, scaling,
their project in this direction without really secure communication, high performance,
understanding the implications. availability, monitoring and provisioning. In
fact, our experience suggests that, more than
An example is Docker and Kubernetes.
technology, it’s the culture and systems thinking
Statements like “We are designing our
that influences how well we deal with these
microservices using Kubernetes” or “These
pitfalls in microservices-based systems.
performance problems will now be gone as we
are structuring our system as microservices on

Confronting the challenges

A microservices implementation is no easy task how these systems are operated and managed in
and there are many challenges that test a team’s production. For example, architects and developers
abilities. at one of Europe’s major banks, whose operations
pivot around a large mainframe and database-rich
While the pitfalls can be attributed to speed
landscape, had a hard time grasping the design
of change and a lack of perspective (this is just
of business-aligned microservices using domain-
new SOA technology), there are some genuine
driven design.
challenges that teams face while adopting the
microservices architecture style. In another case, one of our clients implemented
a series of microservices but had a hard time
Although some of these challenges are related
achieving production stability of these services
to how systems are designed, others concern

10  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

or obtaining a good view of service integration ❙ Architects or technologists always consider

across applications. In addition, we observed that data as the most important thing and use a
teams faced real challenges in terms of people skills data-centric view when modeling a problem
and capabilities and teams have spent substantial domain. Without logic, the data is meaningless.
efforts and money to carry out workforce re-skilling. Hence, architects and technologists should
We’ll look at intricacies of these challenges next. start with context (business capability) and logic
instead of data.

Design challenge ❙ At times, UI screens are used as guidelines

for identifying data ownership and service
Organizations struggle consistently with
boundaries. User interface (UI) doesn’t help
microservices design challenges such as
here as data matters only when it is involved
determining the optimal boundaries between the
in some business logic – not when it is just
microservices, size of microservices, integration
displayed.
between microservices, etc. Microservices
architecture design challenges include: ❙ There is a tendency to focus on database
transactions instead of business transactions
❙ The team only consists of IT specialists or or business processes. Focus should be on real-
technology architects. Defining capability- world processes, such as actions, their outcomes
aligned service boundaries requires domain and compensating for the failed actions if
experts. Fundamentally, this should be a failures occur. A properly designed bounded
combined exercise independent of technology context modifies only one aggregate instance
used. per transaction.

Quick Take
Going Domain Driven
One of our clients faced challenges in correctly modeling the microservice
aggregate – the cohesive core model of any microservice. The team fell into a trap
of designing for compositional convenience and the resulting aggregates were too
large, with data consistency problems.

We recommended a domain-driven design approach to discover the aggregates in

a business operating construct aligned with boundaries called bounded contexts.
This approach resulted in a domain-aligned, coherent model with true invariants
that addressed the data consistency problems.

11  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Quick Take
A Decoupling Approach
One of our financial services clients faced outages on its online portal as result of resource
starvation by a system performance monitoring solution. The agents on the tool exhausted
resources required for business logic processing, causing the portal to go down.

Not isolating the system software from business software was one of the reasons for the
failure, and detecting and isolating it was a difficult job.

The recommendation to decouple the system policy concerns from functional software
was applied through proper runtime-decoupling to resolve this issue. Additionally, the
monitoring and resiliency test practices were enhanced to detect such dependencies
through DevOps continuous integration/continuous delivery (CI/CD).

❙ Developer-centric terms such as create, read, Resiliency challenge

update and delete are too technical and have
Microservices bring a host of benefits – primarily
no specific business meaning. The team must
enhanced operational agility; however, a
always think from the business’s point of view,
microservices implementation increases
and give a clear context to it.
complexity by its decomposition of application
❙ Building a large organization’s system of functionality into many independent deployable
microservices is difficult and requires building units. One challenge that emerges with this
a view, context by context. A starting point for complexity is of resiliency due to the following
representing a system of microservices can be a factors:
context map.
❙ The distributed nature of request processing.
❙ Consistent use of unambiguous language
In a microservices environment, most requests
is missing, which leads to a lack of domain
are processed by multiple microservices, which
understanding. The technical and business
increases the dependency on network and
obstructions in the language may not discover
infrastructure services, thus increasing the
the vital concepts hidden or assumed by domain
probability of failure.
experts. For example: a customer enrolls using
a social profile. “Enroll” here has a technical ❙ Challenges in failure detection. In a traditional
or business obstruction because of various monolithic system, failures are simple to detect
questions about issues, such as what happens due to fewer probable causes and failure of
during enrollment? Is the customer enrolled for application as a whole. In a microservices
any product/s or is the customer enrolled only to environment, the failure can be of many causes
create his or her profile? such as the microservice itself, the container

12  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

it is running on, and the network that is Idempotency is the feature to retry the same
interconnecting the microservices. request without impacting the state. With
❙ Recovery after failures. As the failure usually idempotency, each of the inflight transactions
results in complex intermediate states, it is can be retried without compromising the overall
often difficult to recover from. While respective system state.
microservices can be restarted, the transactions ❙ Delegation of intercommunication to a
that were in-flight must be recovered from their service mesh. While some of the microservices
failure state, which is often difficult. implementations use patterns like a circuit
Some strategies that we have found helpful to breaker, in any complex microservices-
address the challenge of resilience in a distributed based application circuit breaking is not
microservices environment include: enough. Implementation of a full-service
mesh (e.g., Istio5) or simpler side car proxy
❙ Observability as a key architecture concern. (e.g., Envoy6) can take away the complexity of
For a microservices environment to be highly intercommunication.
resilient it needs observability implemented at
In summary, resiliency is a big challenge in
each level (i.e., infrastructure and application).
microservices-based applications and unless
The capability to log, monitor and trace requests
dedicated architecture and design focus is given,
across the network is key to providing resiliency.
the desired outcomes will not be achieved.
❙ Design for recoverability more than failures.
While any well-implemented system is defined
Complexity challenge
for failures, it is recoverability more than failures
that address the concern of resilience. The Complexity reduction through well-defined
application should have the ability to recover bounded contexts and communication patterns
from a failure automatically at the container is one of the critical benefits that microservices
(e.g., restarting a container), a microservice (e.g., provide. If done right, microservices offer excellent
reinitiating a connection pool) and application support for autonomous evolution of business
state level (e.g., maintaining consistent state capabilities. Typically, such microservices are also
after recovery). business-capability driven and therefore act as
the common vocabulary used by both business and
❙ Design for idempotency. One of the key
IT teams, resulting in effective evolution of business
features to be implemented at the microservice
capabilities.
level to enable flawless recovery is idempotency.

Complexities introduced by microservices architecture

DEVELOPMENT DELIVERY OPERATIONAL

COMPLEXITY COMPLEXITY COMPLEXITY

• Design approaches • Runtime infrastructure • Scalability & performance

• Implementation guidance • Runtime dependencies • Runtime monitoring
• Frameworks and libraries • Environment parity • Container technology
• Integration and data • Deployment automation • Lifecycle management
• Build, integration & testing • Release strategies • Security & resilience

Figure 6

13  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

However, microservices come in systems, which Finally, how to build and generate these polyglot
means that often any non-trivial enterprise system microservices as a coherent whole through the
tends to have dozens or hundreds of these systems complex continuous integration/continuous
(each developed as a microservice). As each delivery (CI/CD) pipeline is a major concern that
of these systems are narrowly focused, single- many teams must overcome. Last but not least,
purpose microservices, any business process or testing microservices is still an evolving area and
user interaction tends to result in invocation and poses a major challenge to the majority of teams.
interaction of multiple microservices, resulting in
Delivery complexity
challenges across multiple phases of projects:
With the advent of CI/CD and automated
Development complexity infrastructure provisioning through APIs,
Microservices development requires teams to deployment and release practices have evolved over
think in terms of distributed application design the last few years. In addition, the use of containers
and interaction patterns. Applying concepts such and managed cloud environments in the platform-
as CQRS, functional interfaces, CAP,7 BASE,8 and as-a service (PaaS) model requires teams to work
sagas9 in contemporary programming languages with constructs provided by these technologies/
and configuration is not something that developers services.
are used to.
While developing microservices in this environment,
Moreover, this is a new area of complexity for many deployment and release is typically coded in the
teams. Data persistence and integration requires form of YAML or JavaScript Object Notation (JSON)
them to not just understand aspects such as polyglot scripts and these artifacts have become a first-class
persistence,10 persistence ignorance11 or event- citizen of the code repositories for microservices.
driven messaging,12 but also poses challenges in Technology diversity, a lack of standards and a
terms of frameworks, libraries and programming plethora of agility-oriented release mechanisms
languages to choose from. (canary release, blue-green deployment, push-to-

Quick Take
Going Serverless
In one of our serverless microservices-based applications consisting of 100-plus
serverless services, we recommended using log streaming for application logs,
infrastructure logs and security logs to a central log store.

With log streaming, we were able to add various log processors and generate
a variety of real-time metrics such as configured memory vs. memory used.
Ultimately, this technique helped us to establish a centralized log store for
monitoring application, infrastructure and security events in a unified manner.

14  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

green release, dark release, “dogfooding,” etc.) Being able to achieve production stability and a
are among the areas of complexity that teams must real-time view of the hosted services is anything
deal with. but trivial. Security of interactions and APIs across
bounded contexts and partner systems is another
Finally, the element of release environments
area of complexity. A good API management,
with necessary dependencies required for a
messaging infrastructure and monitoring approach
microservices-based system to be deployed, tested
is essential to overcome these challenges.
and operated is another area of complexity that
many large enterprises have to solve. We strongly suggest that teams consider these
challenges and set up the right infrastructure,
Operational complexity
processes and practices to deal with them
Once released into production, microservices
proactively.
present challenges in the areas of capacity
utilization, scaling, failures and monitoring -- to
name a few. Operating an infrastructure with tens or Observability challenge
hundreds of microservices requires sophisticated Systems can be understood only if they are
tooling for automated provisioning in a secure and observable. Observability, monitoring and analysis
resilient manner. are in a symbiotic relationship, which is depicted as a
pyramid (see Figure 7).
Technologies such as Kubernetes provide the
necessary foundation for this but require operational Key challenges faced by microservices
procedures and practices beyond technology. In the implementation teams include:
13 14
case of monitoring, tools such as ELK, Grafana,
15 16
Jaeger, Prometheus, or cloud providers (e.g., AWS ❙ Observability vs. monitoring. Observability is
CloudWatch) help deal with this complexity, but about making the data available from within the
orchestrating all of these tools at scale is not a trivial system to be monitored; monitoring is the task of
task. If the microservices are operated in container collecting and displaying that data. Microservices
or serverless runtime, then these complexities are teams focus on monitoring tools without making
amplified as the infrastructure is quite dynamic. the software observable.

The observability pyramid

ANALYSIS

MONITORING

OBSERVABILITY

Figure 7

15  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Quick Take
Working Around Event-Driven
Obstacles
In one of our banking client’s event-driven straight through processing (STP) applications,
the team was struggling to monitor the event processing.

We proposed a mechanism in which each functional module published an event before and
after processing. We also defined application logging standards, log aggregation and monitoring
approaches, which helped the team to enable effective observability and monitoring.

As a result, incident resolution improved and business KPIs provided real-time insights to the
business.

❙ Distributed tracing. The most difficult part significant, which puts pressure on developers.
of observability is distributed tracing with and This results in developers spending time on
between application services. A great deal of writing instrumentation for monitoring rather
work is involved in implementing distributed than the functional code.
tracing. Microservices teams lack the underlying Guidelines that we have found helpful to address
principles of tracing requests that flow between the observability challenges include:
services. Organizations typically need a cultural
overhaul to embrace observability as part of the ❙ Establish standards and governance. For
development process. observability, it is critical to establish standards
and governance. Without standards, the
❙ Contemporary tools. Modern application
collection and correlation of event logs
delivery has shifted to containerization,
and metrics becomes highly challenging,
microservices, and polyglot environments,
compromising the outcomes. IT organizations
which cause problems for monitoring tools.
must establish the following standards.
The speed of deployment has increased along
with the number of software components that Logging standards:
are deployed. The existing monitoring tools or > Standards such as, log format, log level usage
production profilers are finding it difficult to and logging frequency.
keep pace. Additionally, these tools have trouble
identifying and connecting dependencies > Business data standards: Logging of business
between microservices, especially at the data (masking and hiding).
individual request level. > Technology standards: Clear guidelines on
❙ Automating observability. The practicalities tools usage for dev engineers.
of implementing observability can be quite

16  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Governance standards: business is now strongly influenced by techniques

> Tollgates to validate right logging and tracing favoring agility in software delivery.
done in the functional code. Given these developments, microservices
> Awareness and enablement of dev engineers developers must evolve their skills and thinking.
for knowledge and the capability to Architects and designers need to develop skills
implement the right tooling. across multiple areas such as evolutionary
architecture, distributed design, polyglot data
> Feedback loop: Incidents should result in
architecture, event-centric integration, service
changes in log/trace implementation.
meshes, domain-driven design, CQRS, resiliency
❙ Tooling guidance: Frameworks that automate engineering, etc.
logging, tracing and tools for monitoring and
analyzing the metrics. Systems engineering and operations need to
develop newer skills in disposable, immutable and
> Logging and tracing: Istio, Jaeger, Sleuth,
ephemeral infrastructure design, technologies such
Zipkin, Dynatrace.
as Cloud Foundry, OpenShift, Docker, Kubernetes,
> Log aggregation: Logstash, Elastic Search, etc. Most of these technologies also require the
Graphite. operations teams to pick up new skills in systems-
oriented declarative programming as many rely on
> Monitoring and analysis: Prometheus, Kibana,
software-defined infrastructure models.
Grafana.
In terms of practices, all teams need to ensure
People challenge that there is collective broad-based capability on
Lean Product Development (LPD), continuous
Microservices-style architecture has forced
delivery and reliability engineering practices.
changes across all three dimensions of system
These practices have become the mainstay of
development – design, operations and delivery
high-quality software delivery on an ongoing basis.
practice.
It is safe to assume that these are prerequisites
As outlined in Figure 8, these systems possess for all non-trivial projects based on microservices
internet scale characteristics that require architecture.
developers to (re)think the way we design
In our experience, microservices efforts in
applications. In addition, the environment in which
enterprise IT organizations are still in their
we operate enterprise applications is changing
nascent stage. To move forward, IT management
dramatically to improve quality of service. Finally,
must invest in people capabilities in addition to
the practices and processes to deliver software to

Three dimensions of system development

DESIGN OPERATIONS PRACTICES

• Distributed system of systems • Infrastructure as code • Continuous delivery

• Highly resilient and scalable • Container runtimes • Lean product development
• Polyglot in nature • Cloud & PaaS • Reliability engineering

Figure 8

17  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Quick Take
Team Building
One of our clients decided to modernize its IT landscape using microservices architecture
style. Since the domain was complex and the landscape was large scale, we worked
with the client to enable a diverse workforce on microservices design, cloud-native
infrastructure, SRE disciplines and DevOps practices in a dedicated infrastructure setup.

This enablement and competency development led to a strong team of developers across
locations delivering microservices-based projects in a consistent manner.

technology infrastructure modernization. industry exposure by participating in industry

These efforts may include a wide variety of conferences, hackathons, cloud sandbox
measures such as formal training, certifications environments, specialized labs, etc. Engaging an
(for specialized technologies), hiring experts to external specialist or consultant for a short time to
augment existing teams, creating community handle capability enhancement challenges is not a
of practices, collaborating with partners for pilot scalable option.
projects and providing developers with broad

Looking forward
Microservice architecture style is one of the challenges so that microservices benefits can be
prominent and relevant design approaches for effectively achieved. Wherever any of these pitfalls
developing cloud-native systems. We strongly or challenges result in tactical decision-making, we
consider that our clients apply this style in should ensure that such exceptions are handled
distributed systems development. However, the though a proper technical debt-management
pitfalls and challenges presented in this paper mechanism.
tend to result in sub-optimal applications of this
Finally, the extent to which enterprises can address
architecture style, leading to an environment in
these issues depends on infrastructure maturity
which teams start to think that microservices is yet
and design competency within IT and alignment
another adopted fad.
of business and IT overall. Try to evolve toward that
The additional complexity in operations of and state instead of trying to address all of these pitfalls
troubleshooting these systems creates further and challenges upfront, learning and adapting your
issues. Hence, we highly recommend keeping an approaches along the way.
eye on these pitfalls and proactively addressing the

18  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

Endnotes
1 James Lewis, “Microservices,” Martin Fowler, March 25, 2014, http://martinfowler.com/articles/microservices.html.

2 Cognizant, “Overcoming Ongoing Digital Transformation Challenges with Microservices Architecture,” November 2015,
https://www.cognizant.com/InsightsWhitepapers/Overcoming-Ongoing-Digital-Transformational-Challenges-with-a-
Microservices-Architecture-codex1598.pdf.

3 Domain Driven Design – Bounded Context, https://martinfowler.com/bliki/BoundedContext.html.

4 A saga is a sequence of local transactions where each transaction updates data within a single service. The first transaction
is initiated by an external request corresponding to the system operation, and then each subsequent step is triggered by
the completion of the previous one (Rosa, 2018).

5 Istio, https://istio.io/.

6 Envoy, https://www.envoyproxy.io/.

7 CAP Theorem and Distributed Database Management Systems, https://towardsdatascience.com/cap-theorem-and-

distributed-database-management-systems-5c2be977950e.

8 BASE – database transaction processing, https://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-

transaction-processing/.

9 Saga pattern, https://microservices.io/patterns/data/saga.html.

10 http://www.martinfowler.com/bliki/PolyglotPersistence.html.

11 https://deviq.com/persistence-ignorance/.

12 https://en.wikipedia.org/wiki/Event-driven_messaging.

13 ELK – Elasticsearch, Logstash and Kibana, https://www.elastic.co/what-is/elk-stack.

14 Grafana, https://grafana.com/.

15 Jaeger, https://www.jaegertracing.io/.

16 Prometheus, https://prometheus.io/.

References
❙ A. Brandolini, Strategic Domain Driven Design with Context Mapping, November 25, 2009, Retrieved from infoq.com:
https://www.infoq.com/articles/ddd-contextmapping.

❙ M. Fowler, BoundedContext, January 15, 2014, Retrieved from martinfowler.com: https://martinfowler.com/bliki/

BoundedContext.html.

❙ D. Rosa, Saga Pattern, January 10, 2018, Retrieved from blog.couchbase.com: https://blog.couchbase.com/saga-pattern-
implement-business-transactions-using-microservices-part/.

19  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

Cognizant 20-20 Insights

About the authors

Dinkar Gupta
Senior Director & Chief Architect, Cognizant Banking and Financial Services

Dinkar is a Senior Director & Chief Architect with Cognizant’s Banking and Financial Services (BFS)
Technology and Architecture Office. Based in Switzerland, Dinkar leads the practice for Europe and the
UK region. He has a post-graduate degree in computer science and applications from National Institute
of Electronic and Information Technology, India, and has over 20 years of architecture and technology
experience across diverse industry segments with a strong focus on financial services. Dinkar can be
reached at [email protected] | LinkedIn: www.linkedin.com/in/dinkargupta/.

Mrudul Palvankar
Former Principal Architect, Cognizant Banking and Financial Services

Mrudul is a former Principal Architect in Cognizant’s Banking and Financial Services (BFS) Technology and
Architecture Office, where she previously headed the architecture and technology team assisting a global
BFS client. She has a post-graduate degree in business administration from Institute of Management
Development and Research, India, and has 19 years of software development experience across multiple
industry segments. She is also TOGAF certified and is actively engaged in architecture transformation
consulting and solution delivery for BFS customers. Mrudul can be reached at LinkedIn: www.linkedin.
com/in/mrudul-palvankar-593398/.

Acknowledgments
The authors would like to thank their former colleague Vivek Kant (www.linkedin.com/in/vivekkant/)
for his contributions to this white paper.

20  /  Pitfalls & Challenges Faced During a Microservices Architecture Implementation

About Cognizant Banking and Financial Services
Cognizant’s Banking and Financial Services business unit, which includes consumer lending, commercial finance, leasing insurance, cards, payments,
banking, investment banking, wealth management and transaction processing, is the company’s largest industry segment, serving leading financial
institutions in North America, Europe, and Asia-Pacific. These include six out of the top 10 North American financial institutions and nine out of the
top 10 European banks. The practice leverages its deep domain and consulting expertise to provide solutions across the entire financial services
spectrum, and enables our clients to manage business transformation challenges, drive revenue and cost optimization, create new capabilities, mitigate
risks, comply with regulations, capitalize on new business opportunities, and drive efficiency, effectiveness, innovation and virtualization. For more,
please visit www.cognizant.com/banking-financial-services.

About Cognizant
Cognizant (Nasdaq-100: CTSH) is one of the world’s leading professional services companies, transforming clients’ business, operating and technology
models for the digital era. Our unique industry-based, consultative approach helps clients envision, build and run more innovative and efficient business-
es. Headquartered in the U.S., Cognizant is ranked 193 on the Fortune 500 and is consistently listed among the most admired companies in the world.
Learn how Cognizant helps clients lead with digital at www.cognizant.com or follow us @Cognizant.

World Headquarters European Headquarters India Operations Headquarters APAC Headquarters

500 Frank W. Burr Blvd. 1 Kingdom Street #5/535 Old Mahabalipuram Road 1 Changi Business Park Crescent,
Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Plaza 8@CBP # 07-04/05/06,
Phone: +1 201 801 0233 London W2 6BD England Chennai, 600 096 India Tower A, Singapore 486025
Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Phone: + 65 6812 4051
Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Fax: + 65 6324 4051

© Copyright 2020, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means,electronic, mechanical,
photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is subject to change without notice. All other trademarks
mentioned herein are the property of their respective owners.

Codex 5066