Understanding

Modernization
Niranjan Kumar Pandey
Objective

• Legacy Landscape
• Evolution of 3-tier as Architectural Paradigm
• Limitations of 3 tier and Constraints of Legacy Application
• Modernization Myths
• Case of Modernization
• Conventional Modernization Approaches and Limitations
• Architectural Paradigms for Modernization
• Modernization Strategies and Services
Legacy Technologies

• Most legacy applications

have a monolithic
(tightly coupled) code
base and 2/3-tier
architecture.
• explosion in number of
modules with
interdependent business
and data logic .
• Huge Complexity
Problems with 2-tier
and Evolution of 3 tier
• inefficient, resource intensive,
• incremental changes to the
application will need significant
effort.
• significant deployment &
maintenance challenges
3-tier
Architecture
• clear separation of
concerns
• dominant and most
widely used
architectural
paradigm
 Non-responsive

Software complexity
Limitations Monolithic code base
of 3-tier and
constraints Limitation of CRUD operations

of Legacy Inflexibility
Application Lack of modularity and integration challenges

Inability to scale
Myth Around Modernization
Modernization Mindset

Unprecedented
Technology and
Continuous Process business disruption
makes modernization
business imperative
Why Modernize

BUSINESS DRIVERS TECHNOLOGY ENABLER

 • Shift from on-premise to cloud based SaaS
• Ability to integrate
• Enhance Customer expireince
Business • Business agility
Drivers • Modern stack
• Increase Operational efficiency
• Support changing regulations
• Support multiple business models
 • Changing enterprise needs and demand to
leverage exponential technologies including
SMAC, AI, ML, AR, VR, IoT etc.
• Proliferation and popularity of a new generation
of robust programming languages, and
architectural paradigms
Technology • Demand for responsive UI to support a wide
range of devices
Enablers • Demand for flexible, modular applications that
can scale and also integrate easily with other
applications and systems
• Ability to support state-of-the-art access and
security in terms of people, organizations, and
devices
Conventional Modernization Approaches

LAYERED APPROACH EN MASSE APPROACH

 UI facelift
Layered
Modernization Code Migration
Approach

Database Migration
 En masse Approach

Lift-and-shift Rebuild Rip and Replace

 Reactive Systems
Event Sourcing and CQRS
Microservices
Architectural
Paradigms for NoSQL
Modernization
Responsive UI/UX Frameworks
Model-driven Development
Containerization
 Right modernization Strategy
A REACTIVE SYSTEM THAT IS FLEXIBLE, A FUTURE-READY APPLICATION BUILT
LOOSELY COUPLED, SCALABLE, RESILIENT, WITH MODERN PROGRAMMING
AND RESPONSIVE. LANGUAGES, USING FLEXIBLE AND
MODULAR ARCHITECTURE, AND CAPABLE
OF DELIVERING CONSUMER GRADE
EXPERIENCE – AT SCALE, USABILITY AND
INTELLIGENCE
PROCESS AND DEPLOYMENT
MODERNIZATION TO SUPPORT RAPID
DEVELOPMENT, CONTINUOUS DELIVERY
AND DEPLOYMENT
A MODERN, REACTIVE AND OPEN
APPLICATION THAT IS EASY TO
INTEGRATE AND WHICH CAN SUPPORT
MULTIPLE BUSINESS MODELS AS PART OF
DIFFERENT PLATFORMS
 Enable digital business, you need to transform your approach
to the apps that are at the core of your operations.

Transforming existing software, taking an agile approach to

What is
development across people, processes, and technology, and
embracing cloud-native development

Modernization Rethinking your approach to application services to

transform it into a powerful driver of innovation.

Ensures you have the ability to execute quickly, respond and

adapt to continuously evolving market conditions, and pivot
to new business models ahead of the competition.
 • Efficiency: 25–70% reduction in platform
support
Quality: <1% production code with defects
Continuity: Zero downtime and a serverless
provisioning model
Setting up Self-healing: 2–10 minutes average failure
Expectation recovery
from Speed: 25–50x improvement in release
velocity
modernization Compatibility: No cloud provider lock-in
Flexibility: Increased configurations and
infrastructure as code
TCO optimization: Optimize legacy apps to
get more out of existing investments
Tenets of Modernization

Discovery Transformation Operations

Discovery
 Understand Understand Objective

Build Build Business case and Roadmap

Start Start with assessment

Discovery Build Build the Approach

Plan Plan to Manage Change

Decide on Decide on Application Modernization Approach

Fundamental Question -Areas
• User Experience Research
• Understand pain points
• How user interacts with app
• Code remediation
• What language app is written in
• What is architecture:3 –tier ,multi-layered
• What is platform
• 3rd party components
• What
• Why
• Identify external system and service dependencies
• What
• Endpoints
• WSDL-Service description file -----port binding -----what protocols----what is being used
• What communication protocols are supported /required by app
Is application directly using native OS functions
How sessions are being managed :sticky session, session replication (synchronous /asynchronous ):multiple nodes ?cluster
Are any batch jobs being used ? Scheduler is being used ? Which scheduler ? Quartz
Does current app relies on file access
Technology stack ?frameworks ,versions ,
Is testing (unit test /Integration test ):
What framework : junit ,nunit,mocktio,mobile app testing framework
TDD or BDD:mocing /stubbing
• Identity management system
• What are roles and groups
• Key management system
• Inhouse/federated/externalized
• Code+dependencies+container (threats /vulnerabilities):how you are
testing them
• Authentication mechanism
• Is specified compliance being met
• PCI/DSS
• SI
Decision
Framework
 Decision Path
based on goals
Choosing a
migration
strategy
Gartner’s Pace-Layered Application Strategy
What Modernization Approach

Refactoring Rearchitecting Replacing

Approach What
Refactoring • Process of restructuring code to
improve performance without
changing its intended function.
• Refactoring involves customizing
an application so it can run on a
cloud platform.
Selecting Right Approach -Refactoring
Why
refactored applications can receive
all vendor software updates,
ensuring security standards and
performance are maintained
How
• A partial refactoring modifies only
specific portions of the application to
enable the migration to the cloud
platform
• complete refactoring modifies
applications so they can perform at a
much higher level of efficiency and
optimizes them so they can operate
at much lower costs.
Approach What
Architecting transforms single-tier architectures into
distributed systems in which functions
and processes are divided in a modern
cloud implementation.
When rearchitecting, applications
transform from monolithic to
microservices-based architectures.
Selecting Right Approach-Rearchitecting
Why
Rearchitecting provides the maximum
benefits of cloud transformation given
that the new versions of applications are
custom designed to align to business
requirements and operate with maximum
performance and efficiency. This is far
more efficient and more reliable than
refactoring.
How
Rearchitecting an application involves the
complete remodelling of the application
across all layers to incorporate the latest
technologies and architecture best
practices.
This may involve decomposing a
monolithic application into a number of
autonomous microservices or serverless
functions and deploying them on private
or public cloud platforms.
Approach What
Replacing • There are two choices when it
comes to replacing aging, on-
premises systems: redeveloping
with new code built for modern
cloud infrastructures using
current development tools or
shifting to SaaS.
• Replacing is the most labor-
intensive option of the
approaches and may involve
some level of business
disruption.
Selecting Right Approach-Replacing
Why
• The replace option is for companies that
are in need of a specific function, such as
payroll or inventory, but know that the
legacy system is so out of date that starting
from scratch in the cloud or moving to SaaS
would be the most efficient option.
• Companies that rebuild have an
unprecedented opportunity to create
functionality that exactly matches current
needs and future requirements.
How
• Replacing an application involves
analyzing a suitable SaaS or cloud-
native platform that provides
enhanced or like-to- like features
from a functional perspective and yet
offers all the benefits of cloud.
• A critical aspect of replacement is
developing a phase-out strategy,
migration plan, and reconciliation
design and deployment architecture.
Transform
 Transform

organization must transform across multiple application-modernization initiative should

pillars- Technology, Processes and people include a consideration of architecture,
technology, and organizational structure.
 Architecture
Transformation
What
Technology
Transformations
are Needed Transformation

Organizational Structure
Transformation
 Fifteen-factor Design
One codebase,
Backing Environment
one
services parity
application

Authentication
Administrative
API-first Disposability and
process
authorization

Dependency
Logs Port binding Telemetry
management

Design, build, Configuration,

Stateless
release, and credentials, Concurrency
processes
run and code
 provides a framework with best practices and
proven patterns

Platform Defines base set of capabilities and features that

provide the foundation to optimize and innovate
within a cloud- native environment.
Centric
Approach for
modernization can encompass technology elements as well as
processes.

provides the infrastructure for transforming from

haphazard communication between legacy
systems to well-defined reusable services.
 A platform is essentially a pre-defined set of APIs and
services that enable and support applications, data, and
business capabilities for the enterprise.
What should It can include operational, orchestration, data, and
a platform network components as well as lead up to AI algorithms,
DevOps tools, and security services.
consist of platform also includes a mechanism for standardizing
across lines of business, allowing specific teams to
request features via self-service provisioning.

It also includes a sandbox for trying out new capabilities

to be added.
Phased approach
to modernization
Phase:2 State
Phase:1 Initial load
synchronization with
phase
legacy systems
Initial Load Phase
company migrates all available reference data, user
information, required history and transactional data from
legacy applications to the new platform.

Mapping is important in this phase. This includes

mapping entities from the legacy application to the
modernized equivalents on the new platform,

transforming data from legacy applications to address

the domain model of the new platform,
State synchronization with legacy systems

• Every time a feature or service is migrated, users need to be updated with

the new location.
• Use Strangler patterns which facilitate this by creating a routing facade.
• Options of State Synchronization
• Modifying monolithic functionality
• Utilizing event-choreography patterns
Transform Leveraging Cloud Native

key objective of app modernization is to shift to cloud-native development,

where applications are built directly in the cloud or on a PaaS platform
rather than on-premises physical infrastructures.

The shift to cloud-native development can help organizations realize

significant gains in agility and quality.
 Assess the application portfolio and
identify priorities for cloud-native
development.

Start small, and then scale up to develop

Driving Cloud a skilled team.

Native
Modernization Adapt the IT operating model to support
both business agility and stability.

Be pragmatic in selecting technologies;

lock-in risks and integration challenges
are not insurmountable.
Tools for Modernization IT Model
• Dicovery: RAD,Archi
• Transformation
• Business Logic Layer:RMI/Corba-----EJB2.1 ------EJB3.0--------------Services (Web
Service)(SOAP/REST)-------Microservices----------Serverless
• Presentation Layer
• HTML4/javascript ---------------HTML5/ES6-----------HTML5/typescript----àFrameworks ----
MEAN,MERN ,VUE
• Presentence Layer: RDBMS---------JDBC/ODBC ,ORM—hibernate,iBatis,------
JPA(configure-hibernate or iBatis): API independent of ORM
• Dependency Management: Hardcoded,configurable ,IOC-spring
• Agile: Jira (SCRUM)

• DevOps ( git-----CI tool--------CM--------CD -------CM -----Feedback)

 Foundation of Cloud-Native-Microservices

1 2 3 4
Build for the Design for Ensure Enable
business resilience observability Automation
 Scalability

Key
outcome of Elasticity

cloud
Native cost savings as compared to the traditional
on-premises architecture.

adoption rapid uptake of cloud and microservices

architectures is helping enterprises innovate
and grow their businesses faster than ever.
 Containerization helps to mitigate challenges

Dealing with r Associated with continuous delivery to managing

distributed and granular application components
new
requirements – hybrid infrastructure across the build, deploy, and
operate lifecycle.
Using enables a vendor-agnostic ecosystem that operates
Containerization seamlessly across hybrid and multi-cloud scenarios.

Containerization allows applications to be written

once and run anywhere.
Kubernetes to manage containerization
Serverless for availability

Application infrastructure is provisioned by the cloud platform, are taking

center stage.

It allows companies to shift away from the 24/7 run of servers

Pay only for the compute cost of specific business functions through fully
modularized applications, serverless is an increasingly popular option.
Misconception about Serverless

Performance

Expense

Vendor lock-in

Security

Management
Operate
Operate

modernized landscapes can deliver business value much faster, they also
require management of a highly distributed ecosystem from application
features down to containers, platform, and infrastructure layers.

Because of this, managing modernized environments using traditional

application-development and support models does not provide the level
of scalability that is required by modernized applications.
 leveraging managed services
and POD-as-a-Service (POD)
models

Optimize Embracing the POD model for

Operations ADM

Enable to drive efficiency, and,

as a result, savings
POD Model for ADM
 Entire
Journey
Application modernization
challenges
Top Challenges
 Align Align the application modernization roadmap with prioritized business capabilities.

Balance In application portfolio rationalization, balance business factors with technology factors.

Enable and Enable and transform: Enable the workforce on emerging technologies; adopt
transform Agile/DevOps and transform into new ways of working.

Establish Establish an engineering culture with a focus on software craftsmanship and mastery.

Mitigating Streamline
Streamline processes to identify and eliminate redundant functionalities and invest in
new features.

Challenges Identify Identify performance baselines and KPIs to measure outcomes.

Define Define a maturity path to measure and upgrade application modernization initiatives.

Modernize Modernize data. Data modernization is an essential aspect of application modernization.

Unlock Unlock business value

Identify Identify white spaces and build new digital products

 Business- Platform-
centric centric
Principles principles principles
Driven
Approach Process-
centric
People-
Centric
Principles Principles
Principles of
application
modernization
Analyzing
impact of
principles
Modernization Readiness
Assessment
 process of putting together an assessment

helps determine the modernization readiness of an

organization’s applications.

Modernization Uses application questionnaire

Evaluation
determine the business, functional, technical, and
financial significance of applications in the portfolio.

determines how well your organization can support

the future state architecture
 Steps
Modernization
Readiness
Outcomes
Assessment
Process
Best Practices for stake
holders
Outcome of modernization readiness review

ROADMAP MODERNIZATION ACTION PLAN

BLUEPRINT
 Schedule the readiness assessment meeting and require
Schedule attendance.

Readiness Conduct Conduct interviews with key stakeholders or personas for each
application suite.

Assessment
Process
Gather information by using the application modernization
Gather questionnaire , analyze the gathered information, document
observations, and determine next steps.

Schedule Schedule and conduct a debrief meeting.

and conduct
 Strategic or business fit

Functional adequacy
What is
objective of Technical adequacy
assessment Financial fit

Digital readiness
 Prerequisite Check

Asset Alignment
Blueprint
to Define iterations and releases

modernize Identify Actions of each area of

organization
Identify deadlines and owners.
 Grouping, ranking, and sequencing for applications

Key Target and interim operating models

observation Key technology and regulatory requirements

and
analysis Applications that have extensive data migration
requirements

The scope and volume of data to be converted

Scalable
Modernization
roadmap
 provides a process for determining the
value of moving from the current state
Application to the future state for the enterprise.
Evaluation- determine the priority of your
modernization application or application suite for
cloud modernization
diagnostic
playbook help to identify the components that
need to addressed during
modernization.
 Application grouping
Sequencing
Technology landscape
Dependencies
Diagnostic Environments

dimensions Storage
Operating model
Delivery Model
SkillSets
Approach of modernization
Modernization Timing
Cost Analysis
 Business agility

Building Organizational agility

blocks
Engineering effectiveness
 Identify the goal or outcome
that you are undertaking.

Identifying Derive the questions that must

be answered to determine
Metrics whether the goal is being met.

Product
Decide what
metrics
should or could be
Operational
measured Metrics
 IDENTIFY THE BUSINESS VALUE ESTABLISH THE BASELINE (FOR
TEST OR HYPOTHESIS (FOR EXAMPLE, THE CURRENT
EXAMPLE, FREEING X PERCENT OF CAPACITY OF XTRANSACTIONS
TRANSACTION CAPACITY WILL SUPPORTS Y CUSTOMERS).

Product
ONBOARD Y PERCENT OF NEW
BUSINESS).

metrics

VALIDATE THE OUTCOME (FOR

EXAMPLE, YOU HAVE IMPROVED
CAPACITY BY X PERCENT, SO CAN
YOU NOW ONBOARD Y PERCENT
NEW BUSINESS?)
Lead time – How much time does it take for a scope of
work to go from request to production?

Cycle time – How long does it take to implement a scope

of work, from start to finish?

Deployment frequency – How often do you deploy Operational

metrics
changes to production?

Time to restore service – How long does it take to

recover from failure (measured as the mean time to
repair or MTTR)?

Change failure rate – What is the mean time between

failures (MTBF)?
 Code

Build and test

standards Release

and best
practices
Operate

Optimize

Readiness
Code
Provide code comments that document the functionality of your software, and use them to generate
documentation.

Follow code management and deployment processes that support frequent code check-ins and
traceability to feature requests.

Build test suites that include unit, functional, performance, and critical path tests, with 100 percent
code coverage.

Encourage code reuse to deliver the same or similar functionality in your code base.

Develop prototypes to validate features with users before investing in full code development
 Redefine feature completeness based on testing, to improve quality
and prevent recurring issues.

Automate acceptance tests.

Build and Monitor all automated tests, and establish a process for handling

Test
failures in place.

Track performance in both production and non-production

environments, define service-level objectives (SLOs) based on realistic
traffic and load testing, and provide the ability to scale to meet
performance requirements.

Abstract sensitive data from configuration files, and provide tools that
automate and monitor configurations
 Automate deployments with support for dependencies (for example, database releases),
Automate regression testing, and tracking.

Release Release code to the production environment incrementally, after every successful build.

Release Manage Manage feature flags (toggles) effectively: support run-time configuration, monitor
usage, maintain flags throughout the development cycle, and assign owners by category.

Provide traceability in your build pipelines, to track triggers, failure notifications, and
Provide successful completion.

Run automated deployment processes and tests for “zero touch” code updates in
Run continuous delivery.

Use Use zero-downtime, fully automated blue/green deployment methodologies.

Make sure that your database schema changes are implemented consistently across all
Make development and production environments.
 Create Create a DevOps triage runbook that’s integrated with your notification system.

Make sure that your monitoring and notification system meets service-level objectives
Make (SLOs) and supports thresholds, health checks, non-standard HTTP responses, and
unexpected results.

Operate Establish Establish effective risk management and disaster recovery processes.

Develop Develop a log rotation and retention strategy that meets your business and legal
requirements.

Develop Develop dashboards that track product performance, measure the success of new
features, and display alerts when metrics don’t meet expectations.
Optimize

Review and improve processes regularly, based on performance and

quality measures.

Implement root cause analysis and prevention processes to prevent

issues from recurring.

Provide data-driven metrics that capture product health, and make

sure that all notifications and actions are based on these metrics.
Readiness • Dedicate a cross-functional team (including
business partners, developers, testers, and
architects) to your modernization efforts.
Application Architecture
 APPLICATION ARCHITECTURE

Microservices SOA Monolithic

Services can range in size anywhere from
Monolithic applications evolve into huge size, a
Services are built in small units and expressed small application services to very large
Design situation where understanding the entirety of the
formally with business-oriented APIs. enterprise services including much more
application is difficult.
business functionality.
Services exposed with a standard protocol,
Services exposed with a standard protocol,
such as SOAP and consumed/reused by Limited re-use is realized across monolithic
Usability such as a RESTful API, and consumed/reused
other services – leverage messaging applications.
by other services and applications.
middleware.
Services exist as independent deployment Dependencies between services and
Scaling monolithic applications can often be a
Scalability artifacts and can be scaled independently of reusable sub-components can introduce
challenge.
other services. scaling challenges.
Smaller independent deployable units ease Enhances components sharing that increases Difficult to achieve operational agility in the
Agility build/release management, thereby high dependencies and limits management repeated deployment of monolithic application
operational agility. capabilities. artifacts.
Monolithic applications are implemented using a
Developing services discretely allows
Reusable components and standard practices single development stack (i.e., JEE or .NET),
Development developers to use the appropriate
helps developers with implementation. which can limit the availability of “the right tool
development framework for the task at hand.
for the job”.
 Java
Enterprise
App
Integration Concept
ESB
How to identify if existing Architecture is
monolithic
• You are unable to deploy your application fast enough to meet requirements
because of difficulty maintaining, modifying, and becoming productive quickly,
which results in long cycles of time-to-market to roll out new services
• You are unable to apply a single deployment. Usually it is necessary to involve
other modules or components to build, test, and deploy, even for a small change
or enhancement
• Only a single choice of technology exists and you cannot take advantage of new
technologies, libraries, or techniques that are being adopted by other enterprises
• High amount of data in memory
• – High-use CPU operations
• – Unable to scale a portion of the application; usually the entire application must be scaled
• – Cannot be easily updated and maintained
• – Code dependencies are difficult to manage
Layered Application
Microservices
Modernize application
remove duplication of effort for manual
Remove entry
Reduce reduce programmatic development risks
Provide Provide a single, unified view of the data
improve the control and synchronization
Improve of systems
1. Identify logical components.
2. Flatten and refactor components.
3. Identify component dependencies.
4. Identify component groups.
5. Create an API for remote user interface.
6. Migrate component groups to
macroservices (move component groups
to separate projects and make separate
deployments).
7. Migrate macroservices to microservices.
8. Repeat steps 6-7 until complete.
 Traditional vs Modern Application Architecture

Traditional Modern

Monolithic Decomposed

Design for Predictable Design for elastic scale

Scalability/Relational database Polyglot persistence

Synchronized Processing Asynchronous processing

Design to avoid Failure(MTBF) Design for failure(MTTR)

Occasional Large updates Frequent small updates

Manual Management Automated self management

Snowflake servers Immutable Infrastructure

Architecture
design and
implementation
Steps
design principles for applications

1 2 3 4 5 6 7 8 9 10

Design for Make all Minimize Design to Partition Design for Use managed Use the best Design for Build for
self healing things coordination scale out around limits operations Services data store for evolution needs of
redundant the job business
Technology Choices

Compute

Container options

Identity Services
 Highly observable

Support for automation

Criteria for Consumer-first approach
Choosing a Independent deployment
Technology for
Modelled around business domain
Microservices
Decentralization of components

Support for continuous integration

 • In a monolithic architecture,
Monolithic vs Microservices for a large application, it is
hard to comprehend the
complexity and sometimes it
is tough to handle the code.
• Applications require
extensive manual testing in
order to comprehend the
impact of alterations.
• Even for a small change, the
entire application requires to
be deployed again.
• The heavy application with
monolithic architecture can
slow down the start-up time.
 Easier Process Adoption

Small Modules

Benefits of Independent Scaling

Microservices
DURS

Unaffected
Programming Languages

Java Golang Python

NodeJs .Net
Monolithic to
Microservices
 Step:1 Decompose monoliths
into microservices
Decomposing
monoliths
into Step:2 Integrate Microservices

microservices
Step:3 Enable Data persistence
for Microservices
 Decompose by Business capability

Patterns to Decompose by subdomain

Decompose
Monoliths Decompose by Transactions

Service per team pattern

 Decompose by
business capability
Advantages
•Generates a stable
microservices architecture
if the business capabilities
are relatively stable.
•Development teams are
cross-functional and
organized around
delivering business value,
instead of technical
features.
•Services are loosely
coupled.
Disadvantages
•Application design is
tightly coupled with the
business model.
•Requires an in-depth
understanding of the
overall business, because
it can be difficult to
identify business
capabilities and services.
Decompose By
Subdomain
Advantages Disadvantages
•Loosely coupled •Can create too
architecture many microservices,
provides scalability, which makes service
resilience, discovery and
maintainability, integration difficult.
extensibility, •Business
location subdomains are
transparency, difficult to identify
protocol because they
independence, and require an in-depth
time independence. understanding of
•Systems become the overall business.
more scalable and
predictable.
 Decompose by transactions
Advantages Disadvantages
•Faster response times. •Multiple modules can be
•You don’t need to worry packaged together, and this
about data consistency. can create a monolith.
•Improved availability. •Increased cost and
complexity due to multiple
functionalities being
implemented in a
microservice, instead of as a
separate microservice.
•Transaction-oriented
microservices can grow if the
number of business domains
and dependencies among
them is high.
•Inconsistent versions might
be deployed at the same
time for the same business
domain.
 Service per team pattern
Advantages
•Teams act independently
with minimal coordination.
•Code bases and
microservices are not shared
by multiple teams.
•Teams can quickly innovate
and iterate product features.
•Different teams can use
different technologies,
frameworks, or programming
languages. Important: These
should be hidden behind a
well-defined and stable public
API.
Disadvantages
•It can be difficult to align
teams to end-user
functionality or business
capabilities.
•Additional effort is required
to deliver larger, coordinated
application increments,
especially if there are circular
dependencies between
teams.
Activity :Monolithic to Microservices
How to proceed

Possible candidates that How to run the monolithic

could represent a app in parallel while you
microservice. develop the microservices.

How to tackle the How to manage

database, which is also transactions that span
monolithic. across microservices.
 Service Decomposition

Identify which service goes first

Essential Adopt Strangling Journey Approach

Tasks
Analyze existing codebase

• Discover monolithic APIs

• Model-Driven Approach
Strangler Pattern Example
 Case of Reference tables in Monolithic Database

Managing
Managing Data in microservices

• Data as API
• Projection of Data

Monolithic Case of Shared Reference and static data

Managing Shared references and static data in Microservices

Database • Static Data per database

• Data as an API
• Static data as configuration

Case of Shared Mutable Data

Shared Mutable Data
Shared Table
Tackling Transactions from monolithic to Microservices
Two Phase Commit
Case of Saga Transaction
Reporting IN-APP REPORTING
across
Distributed CENTRALIZED REPORTING
Microservices
Other essential elements for Reporting
• Aggregate via service calls
• Data Pumps
• Event Carried State
Aggregate
via service
calls
Data
Pumps
Event
Carried
State
 Spring Boot
Essential
Vert.x
Technologies-
Microservices
Helidon
Frameworks
Quarkus
Comparison
 Client Library

Service Registry
Software Load balancer
Stack - Circuit Breaker
Spring Boot Externalized Configuration
framework Distributed Tracing

Proxy/Routing
 Ribbon
Client
Library
gRPC
Invoking Service –Consuming Service

Client MiicroServ
Libraries ice
Web app
Ribbon/gRPC Service
Server side
code
(Parquet)
Service
 Eureka

Service Consul
Registry Zookeeper

Opernshift
 Ribbon
Load
gRPC
Balancer
OpenShift Service
Circuit Breaker • Hystrix
 Spring Cloud
Config
Externalized
Configuration
openshift
ConfigMaps
 Sleuth/Zipkin
Distributed
Tracing
Jaeger
 Zuul
Proxy/Routing
Istio
Lab:01
Creating Microservice using
Spring boot

Lab 01 Creating
Microservice.docx
 Spring's client/server approach for storing and serving
distributed configurations across multiple applications
and environments

Spring This configuration store is ideally versioned

under Git version control and can be modified at

Cloud
application runtime.

While it fits very well in Spring applications using all the

Config supported configuration file formats together with

constructs like Environment, PropertySource, or @Value,

It can be used in any environment running any

programming language.
Configuration in the Cloud

• Spring Cloud Config

provides server and
client-side support for
externalized
configuration in a
distributed system.
• With the Config Server
you have a central place
to manage external
properties for
applications across all
environments.
 • build a central config server with
Spring Cloud Config, configure a
Spring Boot application with it,
and refresh the config at
runtime.
• https://iresearchpl-
Lab:02 my.sharepoint.com/:w:/g/person
al/niranjan_pandey_alchemyinfo
tech_com/EWEbDQnxvDBNvxGu
WWi2A-wB-
cYJgx_GgMHvFtbOXqJB7A?e=Nr2
sX4
 Used to register and discover
services
Registry
Server Netflix Eureka server can be used
for building the service registry
:Netflix server

Eureka Eureka clients which will register

themselves and discover other
services to call REST APIs
 Client-side service discovery allows services to find and communicate
with each other without hard-coding the hostname and port.

Client side
The only ‘fixed point' in such an architecture is the service registry, with
which each service has to register.

discovery drawback is that all clients must implement a certain logic to interact
with this fixed point.

With Netflix Eureka, each client can simultaneously act as a server to

replicate its status to a connected peer. In other words, a client retrieves
a list of all connected peers in a service registry, and makes all further
requests to other services through a load-balancing algorithm
 For aiding Netflix Asgard — an open source tool for
managing cloud deployments.

How is
Fast rollback of versions in case of problems avoiding
the re-launch of 100’s of instances.

Eureka In rolling pushes, for avoiding propagation of a new

version to all instances.

used at For our Cassandra deployments to take instances out of

traffic for maintenance.

Netflix For our Memcached based Evcache services to identify

the list of nodes in the ring.

For carrying other additional application specific

metadata about services.
How does the
application client
and application
server
communicate?
 • Netflix Eureka Server And Client Setup With Spring Boot
• We will set up a Eureka server (service registry used to
register multiple services/microservices).
• We will set up multiple Eureka clients(REST services that
Lab register to Eureka Server).
• We will do client-side load balancing and service discovery
through Eureka.