The document provides an extensive overview of microservices architecture, detailing its benefits, challenges, and the essential components involved in its implementation. It emphasizes the need for a strategic approach to adopt microservices in organizations, focusing on agility, scalability, and flexibility while balancing the associated complexities. Additionally, it outlines various tools and frameworks for developing and managing microservices, alongside best practices to minimize risks and maximize efficiency.

1. NG’s Microservices
Microservices
for
Application Modernisation
&
Roadmap
 Ajay Uppal

2. What is a Microservice?
Microservice (or Microservice architecture)
✓ is a development architectural style
✓ a variant of the service-oriented architecture (SOA) structural style
✓ arranges an application as a collection of loosely coupled services.
✓ services are fine-grained and
✓ the protocols are lightweight.
The term "micro" refers to the sizing of a microservice which must be manageable by a single development team ( 5 to 10 developers).
In this methodology, big applications are divided into smallest independent units.
➢ Microservices are not necessarily exclusively relevant to cloud computing
▪ Frequently they go together because microservice is a popular architectural style for new applications and the cloud being a
popular hosting destination for new applications.
➢ Primary benefits of microservices architecture are
▪ the utilization and cost benefits associated with deploying and scaling components individually.
▪ the combination of small, independently scalable components coupled with on-demand, pay-per-use infrastructure is where real
cost optimizations can be found.
▪ each individual component can adopt the stack best suited to its specific job.
▪ stack proliferation can lead to serious complexity and overhead when it is on-premise; but consuming supporting stack as
cloud services can dramatically minimize management challenges.

3. Executive Summary
EA Recommended Microservices Tool-kit/Solutions
Requirements
❑ Choice of tools/technologies/vendors to build
consistent and secure microservices across Orgn.
❑ Use flexible runtime with a built-in gateway to easily
implement microservices
❑ Manage all microservices centrally
❑ Observe and optimize distributed microservices
architectures — all in one place
❑ Increase microservices discoverability and empower
teams to reuse them to develop faster
❑ Components are independent deployment units.
Core Capabilities
❑ Microservices may consist of one or many components
with business logic, and one or many system components
including load balancers, databases, caches, message
queues, etc.
❑ Microservice may use Data-as-a-Service, or message-
queue-as-a-service and should have its own isolated
container within these systems.
❑ Microservices integrate with each other over API.
❑ Role Based Access Control , Security
❑ Data Governance, Data Protection
Purpose
❑ Drive Practicality and Pragmatism over Agnosticism
❑ Have standard set of tools/technologies to reduce
❑ Faster approach to develop Business Capabilities
❑ Facilitating Orgn.’s Digital Strategy
❑ Reducing Risk & Lowering TCO
❑ Data Monetization
❑ Data Democratization
❑ Multi-purpose over ‘best-of-breed’.
▪ Best of breed leads to more Tech-Debt
Development &
Orchestration Platform
Other Development
Frameworks
Package Solutions SecDevOps (CI CD)
Cloud ▪ MS Azure Service Fabric
▪ MuleSoft Anypoint Platform
▪ Node.Js
▪ Spring Boot Java
▪ .NET
SAP Cloud Platform Extension
Factory
MS Azure DevOps services
Awaiting inputs from Jerome, Som,
Kerry and Vendors.
On-
prem
▪ RedHat OpenShift Service Mesh
▪ MuleSoft Anypoint Platform On-Prem Edition
▪ standalone Azure Service Fabric
▪ Node.Js
▪ Spring Boot Java
▪ .NET
▪ Python / temporary
Low code process and
platforms
▪ Salesforce
MS Azure DevOps server
Awaiting inputs from Jerome, Som,
Kerry and Vendors.
Traditional Service Fabric clusters on Azure are available as a managed service, while standalone Service Fabric clusters are self-service.
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

4. Need for Enterprise-wide Microservices Strategy?
Pros of Microservices Cons of Microservices
Greater agility Needs more collaboration (each team has to cover
the whole microservice lifecycle)
Faster time to market Harder to test, control and monitor because of the
complexity of the architecture
Security – ensuring security at individual service
level
Tough to track data across various service
boundaries.
Each Microservice focuses on single business
capability
Increases delay due to remote calls
Multiple services can be developed and deployed in
parallel
Difficult to move code between services
Better scalability, light-weight, and allowing frequent
releases
Poorer performance, as microservices need to
communicate (network latency, message processing,
etc.)
Faster development cycles (easier deployment and
debugging)
Harder to maintain the network (has less fault
tolerance, needs more load balancing, etc.)
Easier to create a CI/CD pipeline for single-
responsibility services
Doesn’t work without the proper corporate culture
(SecDevOps culture, automation practices, etc.)
Isolated services have better fault tolerance Security issues (harder to maintain transaction
safety, distributed communication goes wrong more
likely, etc.)
Platform- and language agnostic services. Freedom
to use multiple languages, frameworks, patterns…
Multiple languages and components may eventually
result increased troubleshooting in short-term &
TechDebt over long-term.
Leverages API Economy Cloud-readiness
NEED
✓ Practical + Pragmatic approach
✓ Maximise Pros
✓ Minimise Cons
✓ Encourage Standardisation
✓ Adopt best practices
✓ Embed 12 factor App Principles
✓ Adhere to Basic Security Requirements
✓ Define Use-Cases, Patterns, Frameworks
✓ Maximise use/re-use of existing stack
✓ Limit the number of languages
✓ Design for failure - provide fallbacks
✓ Chose the right pattern e.g. Circuit Breaker
pattern.
✓ Embrace Asynchronous Communication
✓ Leverage orgn’s preferred API Gateway
✓ Lower Tech-Debt in long-run
✓ Versioning and separate release train(s)
✓ Before by a new ensure you retire at-least 2.

5. Major Components of Microservices
A typical Microservice Architecture(MSA) consists of the
following components:
✓ Clients
✓ Identity Providers
✓ API Gateway (Organisation’s Preferred e.g. MuleSoft)
✓ Messaging Formats
✓ Databases
✓ Static Content
✓ Management
✓ Service Discovery
There are a handful of core items that have become essential and borderline definitional to microservices:
➢ Containers, Docker and Kubernetes : With the proliferation of services and containers, orchestrating and managing large groups of containers quickly
became one of the critical challenges. Kubernetes has emerged as one of the most popular container orchestration technologies.
➢ Messaging and event streaming: It is necessary to couple state-establishing API calls with messaging or event streaming so that services can broadcast
changes in state and other interested parties can listen for those changes and adjust accordingly.
▪ By combining microservices with event driven architecture developers can build distributed, highly scalable, fault tolerant and extensible systems
that can consume and process very large amounts of events or information in real-time.
➢ Serverless architectures and Functions-as-a-Service (FaaS) platforms share affinity with microservices, as they are both interested in creating smaller
units of deployment and scaling precisely with demand.

6. When to use Microservices?
These figures illustrates the relationship between
• functionality, coupling, agility
• frequency of updates, and
• relative percentage of the codebase.
High Risk, Business Critical Services that reside in
the upper right portion are candidates for
Microservices that are frequently updated by
small, dedicated teams.
The Lower Risk Functions that rarely change can be
grouped together into larger, monolithic services
or package solutions as shown in the bottom left.

7. When to use a Microservices Architecture?
Orgn.’s Solution Engineering
Team can use this decision tree
to quickly determine whether
developing Microservice(s)
makes sense or not.

8. Decision Tree for segmenting into smaller microservices
Solution Architects can use this decision tree
to quickly determine whether a service or
function should be segmented into smaller
microservices, be grouped together with
similar or dependent services, or remain in a
multifunctional, infrequently changing
monolith.

9. Microservices Use-cases
Industry-wide Common Use-Cases for Microservices
• Legacy applications refactoring. Rebuild IT capabilities in order to change the functionality or add some new features, move to cloud or just
conduct global system modernization.
• Applications dealing with big data, AL/ML Big data apps require a complex data pipeline-oriented architecture, where each stage is
managed by one (or a few) particular task, e.g. data collection, processing, delivery, storage etc.
• Real time data processing applications. Streaming platforms like YouTube or SoundCloud, radar systems
• Large-scale systems with complex logic.
• (Third-party) Applications serving a big amount of users simultaneously.
• Rapidly growing applications providing third-party services (like plugins, data transfer apps, analytics and monitoring tools, data indexes,
etc).

10. Microservices Principles & Patterns
Principles underpinning Microservices
Architecture
✓ Scalability
✓ Availability
✓ Resiliency
✓ Flexibility
✓ Independent, autonomous
✓ Decentralized governance
✓ Failure isolation
✓ Auto-Provisioning
✓ Continuous delivery through DevSecOps

11. Integration Patterns for Microservices

12. Microservices Platform a must

13. For organisation with various separate business units and highly complex IT landscape; it is
recommended to
❑ Use and leverage matured, well-supported and proven set of tools and technologies
Challenges that the solution engineering, production operations, and infrastructure teams face when
migrating to the cloud and microservices.
➢ Increase in the number of configuration points across multiple dimensions
➢ Services and components become smaller, the number of them increases, and they become more interconnected.
➢ Development teams produce more changes and demand that they be deployed in production more frequently to enable
continuous innovation.
➢ Infrastructure components - such as VMs, containers, and load balancers - become more lightweight and increase in number.
➢ Dynamic environments, auto-scaling, and self-healing lead to the increased frequency of changes to the infrastructure components.
Challenges in Microservices without the proper support

14. Azure Service Fabric – Cloud & On-Premise
Compliant with Orgn.’s Secu
Azure Service Fabric is a distributed
systems platform that makes it easy to
package, deploy, and manage scalable
and reliable microservices and
containers.
Service Fabric provides a sophisticated,
lightweight runtime that supports
stateless and stateful microservices.
Key differentiator is focus on building
stateful services using the Service
Fabric programming model or run
containerized stateful services written
in any language or code.
Service Fabric clusters anywhere,
including Windows Server and Linux on
premises and other public clouds, in
addition to Azure.

15. MS Azure Services Decision Tree
MS Azure Service Fabric for
developing microservices and
orchestrating containers on
Windows and Linux.
MS Azure Kubernetes Service
for deployment, management,
and operations of Kubernetes.

16. MuleSoft Anypoint Platform

17. MuleSoft – ‘Code’ Microservice

18. Integrations and Microservices leveraging MuleSoft
● Assets
● Projects
● Investments etc Prebuilt microservices in other
technologies
SOAP services layer
Tactical Oracle gateway
replacement
Like-for-like SOAP services
SaaS applications
Prebuilt microservices in other
technologies
Microservices platform(s)
hosted
applications
GIS
Large/complex/legacy ‘monolithic’ applications
such as asset management and ERP
Example: Ellipse
System APIs provide a consistent façade, hiding
underlying complexity.
e.g. e.g.
The MuleSoft ‘System API’ layer can be thought of as an
implementation layer for microservices, with orchestration
overlaid by the ’Process API’ layer.
Microservices style APIs implement granular
operations to be reused by the orchestration
layer
Modern applications, whether SaaS or on-prem
Strategic ‘microservices’ style API for
granular Ellipse operations
e.g. ‘Create project’ (hides multiple SOAP
calls and JobEstimate/WorkRequest
internal data model)
System layer
(services)
Process layer
(orchestration)
• Discoverable in one place (MuleSoft Exchange)
• Consistent technology for consumers (REST)
• De-coupled architecture provides agility
Existing microservices built in other
technologies
MuleSoft provides simple proxy
which can then be discovered, policy
managed etc.

19. 19
MuleSoft Anypoint Service Mesh
Sequence of events
1. The client (possibly another microservice or
any Kubernetes Ingress component) sends a
request to the service.
2. Envoy captures the request and redirects it to
the Istio Mixer.
3. The Mixer adapter calls the Anypoint Service
Mesh adapter to perform policy checks and
verifications.
4. The Anypoint Service Mesh adapter performs
policy checks and responds back to the
Mixer.
5. The Mixer communicates the outcome of the
policy checks to the Envoy proxy.
6. When no policy violations occur, the request
is routed to the microservice. The
microservice runs the service logic and sends
the response back to the client.
The Anypoint Service Mesh adapter
communicates with Anypoint Platform in the
background to keep up-to-date on the latest
policies and contracts, and also sends back API
analytics information.

20. VMware Tanzu Service Mesh

21. Preferred Microservices Development Frameworks
.NET NodeJs Spring Boot Java
✓.NET is a general purpose development platform.
With .NET, you can use multiple languages, editors,
and libraries to build native applications for web,
mobile, desktop, gaming, and IoT for Windows,
macOS, Linux, Android, and more.
✓ Tight integration with visual studio
✓ Stable code, Light-weight, Speedy, Fast
✓ Reliable and strongly typed server side language.
✓ Fantastic documentation, eco-system, support & 3rd
party libraries
✓ Great MS Azure integration
✓ Highly Productive and Performant
✓ Powerful Web application framework (ASP.NET MVC)
✓ Powerful ORM (Entity Framework)
✓ Constantly improving to keep up with new trends
✓ Dependency injectio
✓ TFS
✓ Security
✓ Useful IoC
✓ Scaffolding
✓ Asynchrony
✓ Concurrent
✓ Default Debugging tools
✓ Node.js uses an event-driven, non-blocking I/O
model that makes it lightweight and efficient, perfect
for data-intensive real-time applications that run
across distributed devices.
✓ Npm
✓ Javascript
✓ Great libraries, community, support and
documentation
✓ Good for Web Applications, APIs, Realtime
applications, Data Streaming
✓ Asynchronous
✓ Great for command line utilities
✓ Node Modules
✓ Websockets
✓ Great modularity
✓ Can be used as a proxy
✓ Cross platform
✓ Easy concurrency
✓ One language, end-to-end
✓ TypeScript Support
✓ Easy to learn, use
✓ Less boilerplate code
✓ Performant and fast prototyping
✓ A key element of Spring is infrastructural support
at the application level: Spring focuses on the
"plumbing" of enterprise applications so that
teams can focus on application-level business
logic, without unnecessary ties to specific
deployment environments.
✓ Java
✓ Open source
✓ Great community, documentation & libraries
✓ Very powerful
✓ Enterprise
✓ Easy setup
✓ Dependency injection
✓ Stability
✓ MVC
✓ Integrations with most other Java frameworks
✓ Easy Integration with Spring Security
✓ Best practices
✓ Large ecosystem with seamless integration
✓ Java has more support and more libraries
✓ Supports vast databases

22. NodeJs vs Springboot Java
NodeJs Springboot Java
➢ Single-threaded which implies that one request can be dealt with
one thread.
✓ Multi-threaded which means that several tasks can be performed
concurrently.
➢ Not recommended for CPU-intensive applications that include
video encoding, image manipulation and Big Data computing.
✓ Good for IoT, Big Data, Streaming, eCommerce Platforms etc. Very
useful when dealing with long or repetitive operations.
✓ Due to non-blocking I/O, developers can send many requests at the
same time.
➢ Has a Blocking I/O and as such developers will have to wait for every
I/O request.

23. Features of NodeJs and Spring Boot Java
NodeJs
• Single -threaded. Low memory utilisation
• Enterprise application development is easier to start because it is a
great option to prototype.
• Follows the agile development methodology which is apt for highly
scalable enterprise application development services
• Enterprise application with NodeJs development work two times
faster than Java with fewer resources.
• Lightweight and fast
• Node employs 33% lesser lines of code, 45% lesser files.
• Huge resource pool of libraries that are available to NodeJs
developers.
• Event-driven , non-blocking I/O model and Asynchronous. Due to this
feature, it is more light-weight and great for data-intensive enterprise
application development.
• Node.js is a runtime environment used for executing JavaScript code
outside of a browser. Express.js is the de facto web application
framework for Node.js.
Spring Boot Java
• Muliti-threaded. High memory utilisation
• Java is simple and supported by all devices and operating systems.
• In-built language security features embedded by Java Compiler and
the machine making it trustworthy especially for web development.
• Employs robust code which lets your application development
consider all cases of errors with the help of a code.
• Great garbage collection mechanism with an equally good type-
checking scale.
• Better integration capability. Supports client-side technologies.
• Spring boot avoids writing boilerplate code and XML configurations
• Embedded HTTP servers like Jetty, Tomcat and tests web applications
easily.
• CLI is great for developing and testing Java applications from the
command prompt.

24. SAP Cloud Platform Extension Factory
SAP Cloud Platform Extension Factory help developers
create extensions in the form of microservices that are
event-driven.
This prevents one-to-one integration and therefore
increases the extension’s flexibility.
The existing services available in SAP software, such
as SAP S/4HANA or SAP C/4HANA, are reused and can
be combined with the services available on SAP Cloud
Platform and those offered by other providers of value-
added services.
To facilitate this flexibility while maintaining a high level
of IT security and integration, SAP has developed SAP
Cloud Platform Extension Factory, which is based on
the open source project Kyma.

25. Microservices vs Monolithic
Microservices Monolithic Architecture
Every unit of the entire application should be the smallest, and it should be able to
deliver one specific business goal.
A single code base for all business goals
Service Startup is relatively quick Service startup takes more time
Fault isolation is easy.
Even if one service goes down, other can continue to function.
Fault isolation is difficult.
If any specific feature is not working, the complete system goes down. In
order to handle this issue, the application needs to re-built, re-tested and also
re-deployed.
All microservices should be loosely coupled so that changes made in one does not affect
the other.
Monolithic architecture is tightly coupled.
Changes in one module of code affect the other
Businesses can deploy more resources to services that are generating higher ROI Since services are not isolated, individual resource allocation not possible
More hardware resources could be allocated to the service that is frequently used. Application scaling is challenging as well as wasteful.
Microservices always remains consistent and continuously available. Development tools get overburdened as the process needs to start from the
scratch.
Data is federated. This allows individual Microservice to adopt a data model best suited
for its needs.
Data is centralized.
Small Focused Teams. Parallel and faster development Large team and considerable team management effort is required
Change in the data model of one Microservice does not affect other Microservices. Change in data model affects the entire database
Interacts with other microservices by using well-defined interfaces Not applicable
Microservices work on the principle that focuses on products, not projects Put emphasize on the entire project
No cross-dependencies between code bases. You can use different technologies for
different Microservices.
One function or program depends on others.

26. Microservices vs SOA
Microservice SOA
Architecture Designed to host services which can function
independently
Designed to share resources across
services
Component sharing Typically does not involve component sharing Frequently involves component sharing
Granularity Fine-grained services Larger, more modular services
Data storage Each service can have an independent data
storage
Involves sharing data storage between
services
Governance Requires collaboration between teams Common governance protocols across
teams
Size and scope Better for smaller and web-based applications Better for large scale integrations
Communication Communicates through an API layer Communicates through an ESB
Coupling and cohesion Relies on bounded context for coupling Relies on sharing resources
Remote services Uses REST and JMS Uses protocols like SOAP and AMQP
Deployment Quick and easy deployment Less flexibility in deployment

27. Multi-Architectural Patterns & Polyglot Microservices
Microservices can be build
with many technologies and
languages, such as
• ASP.NET Core Web APIs,
• Node.js,
• Python,
• Java,
• C++,
• GoLang, and more.
No particular architecture
pattern or style, nor any
particular technology, is right
for all situations.
This figure highlights some
approaches and technologies
(although not in any particular
order) that could be used in
different microservices.

28. SecDevOps/ DevOps Market Insights

29. Azure DevOps Services – managed cloud services