COGNIZANT 20-20 INSIGHTS

Accelerating Executive Summary

Rapid digitization is causing tectonic shifts in

Microservices
customer expectations across industries. Many
are struggling to adapt to this accelerated change.
As a result, many businesses are aggressively

Design and
pushing IT to cut delivery time, reduce cost and
improve quality – all simultaneously.

Development
Microservices architecture (MSA) has emerged as
one way to address these challenges. MSA
describes a new way of designing software
applications as suites of small, loosely-coupled
independent services. While there is no precise
definition of this architectural style, these
To proactively deal with changing architectures encompass certain common
business requirements inside characteristics around organization, business
capability, automated deployment, intelligent
and outside the enterprise, IT service endpoints, and decentralized control of
organizations must embrace languages and data. Like their predecessors, they
more modular and extensible bring their own set of unique challenges that
should be addressed up front to prevent the
software development and
architecture from turning into a tangled mesh of
deployment methods built on point-to-point communication paths.
a solid microservices reference
This white paper describes an approach to
architecture. microservices design and development that is

Cognizant 20-20 Insights | May 2017

Cognizant 20-20 Insights Cognizant Solutions Overview

based on adoption of RESTful services design and “The Seven Waves of Change That Will Pow-
best practices.1 Rather than conforming to a er, or Crush, Your Digital Business.”
checklist of design and development guidelines
and best practices that encompass our collective DEFINING MICROSERVICES
knowledge of the right ways of developing ARCHITECTURE
microservices, we recommend a tool-based
A microservices architecture is an architectural
approach that generates code compliant with
style for developing software applications as a
microservices best practices and the chosen
suite of small, autonomous services that work
technology stack.
together running in its own process and that
We believe that given their distributed nature communicate with other services using a
and myriad moving parts, microservices can lightweight communication protocol. The two
easily turn into an implementation nightmare, protocols commonly used are HTTP request-
unless their design and processes are enforced response and lightweight messaging.
and validated on an ongoing basis using
Microservices architectural styles2 are best
best-in-class software engineering tools.
understood by comparing them to traditional mono-
This paper offers a comprehensive microservices lithic architectural styles – a style of application
design and development technique that not only development where an entire application is deployed
leverages rapidly evolving best practices but and scaled as a single unit. In monoliths, business
also supports and enforces them using a logic is packaged in a single bundle and run as a
development workbench that we call Cognizant single process. These applications are usually scaled
COSMOS. It builds on our thinking shared in by running multiple instances horizontally. Figure 1
previous works on the topic, “Overcoming depicts MSA’s architectural implications in com-
Ongoing Digital Transformational Challenges” parison to monoliths.

Microservices: Architectural Implications

A larger number of independently deployed services increases

Larger Service operational complexity. This shifts complexity from the application
Count developers to the operations team.

Fast-Changing The system landscape is very dynamic, with services redeployed,

System Landscape replaced, deprecated and spawned on a continuous basis.

Remote Service Services communicate remotely with one another. Remote calls
Communication impact service performance and increase chattiness.

Larger Attack Modularity limits the privileges an attacker gets in a single attack.
But it also increases the attack surface, as more services are
Surface exposed to the external world.

Frequent Service Higher-service modularity and remote calls increase the risk of
Failures failures while reducing the failure complexity and resolution time.

Figure 1

Accelerating Microservices Design and Development | 2

Cognizant 20-20 Insights
Each microservices implementation should
not only be designed for failures but should
have built-in fallback mechanisms to degrade
gracefully with minimum impact to the service
invocation chain.

MICROSERVICES ARCHITECTURE Verification that all services are up and

running is critical. Components for monitoring
Implementation Challenges the service health and usage characteristics
As IT organizations migrate to a microservices ensure a constant watch on service liveness
architecture, they typically contend with a by collecting run-time statistics and create a
number of challenges, most of which are not consolidated picture of service health. Besides
apparent in the monolithic world. As a result, IT service health, components to monitor the
organizations need a proven mitigation strategy health of the virtual machines are also an
and a reference architecture consisting of essential part of the reference architecture.
components that we believe are essential for
implementing a microservices architecture from For debugging, a component for centralized
a design, delivery and operational perspective. logging of all the services is needed; this can
Many of the challenges arise out of the very store log data in a central repository with
nature of the MSA paradigm. search and dashboard capabilities.

Microservices use distribution to improve • Resiliency: Each microservices implementation

modularity. But distributed software has the should not only be designed for failures but
following inherent challenges: should have built-in fallback mechanisms to
degrade gracefully with minimum impact to the
• Performance: Remote calls are slower service invocation chain. Patterns like Circuit
compared to in-process function calls. While Breaker3 or Bulkhead4 should be used to design
we may limit the number of remote calls, services to avoid such cascading failures.
collaborating services need to be called at
Mitigation Strategies & Reference
least once and in many cases as a chain of
Architecture
invocations. From an operational standpoint,
a microservices implementation must have As Figure 2 (next page) shows, a microservices
components for monitoring service reference architecture must have components
performance and for tracing the service-call that address issues that arise due to its dynamic
chain across processes and hosts. and distributed nature.

• Reliability: Remote calls have a higher • Service discovery: Tracking microservices

likelihood of failure than in-process calls. A endpoints in a rapidly changing system
large number of microservices thus means landscape is a complex yet necessary task. Such
more potential failure points. Health rapid microservices configuration changes are
monitoring of microservices and their hosts hard to manage manually. Instead, IT
are key for ensuring system reliability. organizations need service registration and

Accelerating Microservices Design and Development | 3

Cognizant 20-20 Insights

discovery functionality that enables query to fetch configuration information.

microservices to self-register to a central service
registry on startup. Service consumers use the • Service access and routing: A typical enterprise
discovery API to locate the requested system landscape will contain many
microservice from the service registry. Additional microservices. Some will be exposed externally
load balancing components can determine over public networks, while others will be for
which instance of the microservice to route the internal consumption. All services, internal and
request to, assuming multiple instances are external, are exposed through their respective
deployed for the requested service. (mostly RESTful) API models. While this unified
approach to wrapping all business functionalities
• Configuration management: Microservices as services simplifies access, it demands
architectures with their large number of additional infrastructure for access management.
deployed services make configuration
management tedious and error-prone. Local To expose microservices externally and to
file-based configurations are ineffective. Instead, prevent unauthorized access, IT organizations
a centralized configuration manager is a need an API gateway through which all external
necessity. In addition, the configuration manager traffic is routed. A routing service, which acts as
should provide APIs that the microservices can an entry point to the microservices environment,

Microservices Reference Architecture

IDENTITY MONITORING
SERVICE PERFORMANCE
RESILIENCY LOG ANALYSIS
MANAGER

MONITORING & TRACING

STORE

DASHBOARD DASHBOARD
API

API

DASHBOARD DASHBOARD

DISCOVERY SERVICE CONFIGURATION SERVICE ADMIN CONSOLE

ROUTING SERVICE
API GATEWAY

MICROSERVICES CONTAINER 1 MICROSERVICES CONTAINER 2 MICROSERVICES CONTAINER n

EXECUTION INTEGRATION EXECUTION INTEGRATION EXECUTION INTEGRATION

FRAMEWORK FRAMEWORK FRAMEWORK FRAMEWORK FRAMEWORK FRAMEWORK

CLIENT LIBRARIES CLIENT LIBRARIES CLIENT LIBRARIES

DEPLOYMENT ENVIRONMENT
DEVELOPER WORKBENCH
CONTINUOUS INTEGRATION/DELIVERY PIPELINE

Figure 2

Accelerating Microservices Design and Development | 4

Cognizant 20-20 Insights

may often double up as the API gateway. The deployment. Continuous integration (CI) and
routing service uses dynamic routing and continuous delivery (CD) automate testing
load-balancing capabilities to route external and delivery, ensuring that the software is
requests to the selected service by looking up working as per expectation every time. (For
services from the service registry. In addition, an more on CI and CD, read our white paper,
edge management portal may be required for “Patterns for Success: Lessons Learned When
administering routing rules. Adopting Enterprise DevOps.”

To design the API model, with its constraints and • Data strategy: One of the major challenges of
design attributes, a developer workbench is migrating to a microservices architecture is to
needed to support the API modeling archetypes. adopt the database-per-service design pattern.
The workbench should have features to publish In monolithic service architecture, business
the API model to an API store with support for transactions converge on the database layer,
the full API lifecycle. The API model also needs to making it a shared service. This goes against
be access-controlled using state-of-the-art the notion of an end-to-end loosely-coupled
security standards. From an API consumption component, which is strongly advocated by
perspective, we believe that a component in the microservices purists. The best solution to
microservices reference architecture is needed mitigate this challenge is to use an eventually
to support the definition of usage policies and its consistent database.5
association with consumers.
OUR APPROACH TO MSA
• Infrastructure automation: DevOps is a key
EXCELLENCE
ingredient of a microservices reference
architecture. Microservices, by nature, are COSMOS is an open-standards-based solution for
agile and rapidly move from development to microservices design and delivery (see Figure 3)

Peering into the COSMOS

Cognizant COSMOS: A unified Governance component

solution for developing generation: Generates critical
Modeling APIs
microservices; generating that promote infrastructure service
microservices governance RESTful design components required for
components; modeling, publishing best practices operational governance –
and managing the microservices; routing service, discovery
and building required artifacts Supports Generates service, configuration service,
for cloud-based and multiple operational performance monitoring and
on-premises deployment. technology governance management components.
options and components
interaction

Generates
Publishes API
Deployment options: business Business service
model to API
Supports ongoing service services generation: Generates
store
components
deployments by packaging skeleton projects for the
Generates
the developed artifacts into deployment core and composite
executable, deployable bundles for business microservices.
bundles appropriate for the different
deployment environment deployment
environments
(on-premises, IaaS, PaaS).

Figure 3

Accelerating Microservices Design and Development | 5

Cognizant 20-20 Insights Cognizant Solutions Overview

Each microservices implementation should

not only be designed for failures but should
have built-in fallback mechanisms to degrade
gracefully with minimum impact to the service
invocation chain.

which implements the reference architecture individual microservices (and other

described above. It also provides a unified supporting components) to register at
workbench for the following activities: startup, including client libraries to look
up and discover the service instances
• Developing microservices: Microservices from the service registry.
characteristics include the organization of
a logical block of functionality around a »» A configuration service that centrally
specific business capability, programming stores and manages all configuration
language agnosticism and decentralized data across business and
control of data. Thus, each microservices infrastructure services.
project will have its API interface and
implementation classes, its own data »» Performance monitoring and
persistence and management module, management components that
client libraries required to efficiently monitor virtual machines, support
communicate with other microservices and log aggregation, visualization and
the operational governance infrastructure. analysis, ensure service resiliency
Optionally, it may also include the client through intelligent routing and
classes required to connect with back-end enable distributed call tracing.
resources.
• Modeling and publishing APIs for accessing
• Generating components for operational microservices: Our workbench provides an
governance: The reference architecture intuitive API designer interface to model
recommends a group of critical RESTful APIs for the microservices. The
infrastructure service components for modeling activity promotes the adoption of
operational governance. These may be best practices and the typical constraints of
broadly classified into the following: the RESTful design pattern. It supports the
use of various media types, including
»» A routing service that acts as a hypermedia constructs, in responses.
reverse proxy at the edge of the Modeling activity is typically followed by
microservices network with support automated code generation with the
for dynamic routing rules. capability to generate a RESTful services
interface and implementation classes using
»» A discovery service that allows multiple technology options. The libraries

Accelerating Microservices Design and Development | 6 1

Cognizant 20-20 Insights

required by the microservices to connect with • Building and deploying the artifacts to cloud
other microservices and to exchange data or on-premises infrastructure: The
with the operational governance infrastructure workbench supports service deployments to
is also injected into the skeletal classes. both on-premises infrastructures and cloud by
Custom service logic needs to be added to the packaging the developed artifacts (compiled
generated code. Some microservices are code, configurations, etc.) into executable,
exposed for invocation over the public deployable bundles. COSMOS can also be
network. The reference architecture integrated with continuous delivery infra-
recommends inclusion of infrastructure structures (CI/CD) whereby any changes made
components for API management. These to components may trigger the CI/CD build
components typically consist of an API and deployment pipeline directly from the
manager to manage, an API store to host and workbench.
an API gateway to act as a single entry point
for the public APIs. IMPLEMENTING MICROSERVICES
VIA OPEN SOURCE
We believe that API management
infrastructure forms an integral part of the One of the key characteristics of a microservices
reference architecture for microservices architecture is technology diversity and the
implementation. The convergence of these support for it. There are a variety of libraries and
related yet distinct technology paradigms is a frameworks available today that implement the
critical success factor for microservices various components of the reference
architecture. COSMOS has support for architecture shown above. The variety exists not
different API management solutions, both only in terms of programming languages, but
open-source and commercial. also in terms of the various communication

Accelerating Microservices Design and Development | 7

Cognizant 20-20 Insights

“One of the key characteristics of a

microservices architecture is technology
diversity and the support for it. ”

patterns between these components. Components depicted in Figure 4 that directly

Synchronous interaction between microservices map to the Spring Cloud Netflix, Spring Framework
may not always be the optimum option. The and other recommended open-standard,
exchange of data with operational components open-source stacks are represented in bold
for performance monitoring or call tracing, for italicized font. COSMOS can also integrate with
instance, typically adopts the asynchronous custom-built and third-party solutions for
message exchange pattern through an under- implementing components of the reference
lying message broker. architecture as needed.

COSMOS supports the open-source Spring Cloud Support for additional technology options are
Netflix stack as one of its technology options for being continuously added to COSMOS. Apache
implementation. Figure 4 depicts how Camel and Eclipse Vert.x support for implementing
components of the Spring Cloud Netflix stack a microservices architecture are in the works and
map to our reference architecture. planned for release in the next version.

Springing Forward with Microservices

OAUTH2.0 MONITORING

HYSTRIX ELK CONSUL ZIPKIN

MANAGER

DASHBOARD DASHBOARD DASHBOARD DASHBOARD

STORE
API

API

EUREKA ARCHAIUS SPRING BOOT

ADMIN CONSOLE
API GATEWAY

MICROSERVICES CONTAINER 1 MICROSERVICES CONTAINER 2 MICROSERVICES CONTAINER n

ZUUL

SPRING APACHE SPRING APACHE SPRING APACHE

REST/JAX-RS CAMEL REST/JAX-RS CAMEL REST/JAX-RS CAMEL

RIBBON, HYSTRIX RIBBON, HYSTRIX RIBBON, HYSTRIX

DEPLOYMENT ENVIRONMENT
ECLIPSE COSMOS PLUGIN
CONTINUOUS INTEGRATION/DELIVERY PIPELINE

Figure 4

Accelerating Microservices Design and Development | 8

Cognizant 20-20 Insights

LOOKING FORWARD • A wide array of technology options for

implementing different components of a
COSMOS offers a wide variety of technology microservices reference architecture.
options and communication patterns to
implement microservices architecture. It is • Auto-generating the plumbing code based on
envisioned to be an extensible development the chosen technology stack, ensuring a high
tool in which support for newer libraries, quality of coding standard compliance and
frameworks and deployment platforms can be consistency across implementations.
added incrementally through plug-ins as they
mature and are ready for production use. We • Enforcing a common standard for API modeling
believe that a solution like COSMOS provides a across teams, business units and geographies.
number of compelling benefits, including:

Accelerating Microservices Design and Development | 9

Cognizant 20-20 Insights

FOOTNOTES

1
http://www.drdobbs.com/web-development/restful-web-services-a-tutorial/240169069.

2
James Lewis and Martin Fowler, “Microservices,” http://martinfowler.com/articles/microservices.html.

3
Martin Fowler, “Circuit Breaker,” http://martinfowler.com/bliki/CircuitBreaker.html.

4
Michael T. Nygard, “Release It! Design and Deploy Production-Ready Software,” https://pragprog.com/book/mnee/release-it.

5
Vogels, W, “Scalable Web Services: Eventually Consistent,” ACM Queue, vol. 6, no. 6, pp. 14-16, October 2009.

ABOUT THE AUTHORS

Dipanjan Sengupta Dipanjan Sengupta is a Chief Architect within the Software

Engineering and Architecture Lab of Cognizant’s Global Technology
Chief Architect, Office. He has extensive experience in service-oriented integration,
Software Engineering and integration of cloud-based and on-premises applications, API
Architecture Lab management and microservices-based architecture. Dipanjan has
a post-graduate degree in engineering from IIT Kanpur. He can be
reached at [email protected].

Hitesh Bagchi Hitesh Bagchi is a Principal Architect within the Software

Engineering and Architecture Lab of Cognizant’s Global Technology
Principal Architect, Office. He has extensive experience in service-oriented architecture,
Software Engineering and API management and microservices-based architecture, distributed
Architecture Lab application development, stream computing, cloud computing and
big data. Hitesh has a B.Tech. degree in engineering from University
of Calcutta. He can be reached at [email protected].

Pijush Kanti Giri Pijush Kanti Giri is an Architect within the Software Engineering and
Architecture Lab of Cognizant’s Global Technology Office. He has
Architect, extensive experience in Eclipse plug-in architecture and developing
Software Engineering and Eclipse RCP applications, API management and microservices-
Architecture Lab based architecture. Pijush has a B.Tech. degree in computer science
from University of Kalyani. He can be reached at Pijushkanti.Giri@
cognizant.com.

Accelerating Microservices Design and Development | 10

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 businesses. Headquartered in the U.S., Cognizant is ranked 230 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

500 Frank W. Burr Blvd. 1 Kingdom Street #5/535 Old Mahabalipuram Road
Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam
Phone: +1 201 801 0233 London W2 6BD England Chennai, 600 096 India
Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000
Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060

© Copyright 2017, 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.

TL Codex 2533