Practical Microservice Architecture (edition 2022).pdf

Ahmed MISBAH - December 2022
Practical Microservice
Architecture
2022 edition

About the speaker
Role and previous talks
• Chief Software Engineer
• Independent Consultant and Coach
• Speaker at:
‣ DevOpsDays Cairo
‣ AMECSE
‣ Orange DevTest Days
‣ GDG
‣ Delta Technopreneurs
‣ JDC

About the speaker
Topics of interest
• DevOps
• Agile and Lean
• Cloud-Native Apps and beyond
• Software Architecture
• Java
• FOSS
• Arti
fi
cial Intelligence and ML

About the speaker
Experience
• 9 years at Orange Innovation Egypt
• Delivered two award winning innovative
solutions
• Worked at two startups
• Helped many others!
• Winner of Dell Hacktrick 2022 UI/UX track
• MSc. degree in ML and many other
professional certi
fi
cations
Nile University
J;.lll ~l:J.. Qtertifirate
(3/'~
This is to certify that
Ahmed Mahmoud Amir Misbah
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Has successfully completed the program of study
and fulfilled the requirements for
BigData & Data Science Diploma
for the period from October 2015 to July 2016
...f:.!.l...~'!!~~!.tf....El..#.!(!.~.1..
INF Program Director
~~.__QI II
C.a.::::a..;r:q;;; AU J M
IW fl ,
: ~t '-M4'
October 2016 ·
····························••-
•··············
Date

Practical Microservice Architecture
Agenda
• Section 1: Introduction
• Section 2: Microservices for Greenfield projects
• Section 3: Microservices for Brownfield projects

Agenda
➡ Section 1: Introduction

Introduction
Topics
• Motivations
• What is Microservice Architecture?
• Why Microservice Architecture?
• Microservice Architecture Challenges
• When and when not to go for Microservices?

Introduction
Topics
➡ Motivations

Motivations
Why this session?
• Been working with Service Oriented Architecture (SOA) since 2009.
• Been working with Microservices since 2016 in both green
fi
eld and brown
fi
eld
projects and products.
• Seen Microservice Architecture being adopted and implemented both right
and wrong, mostly wrong!
• Was inspired by Lean practice of “Do it Right the First Time” (DRIFT).

Introduction
Topics
• Motivations
➡ What is Microservice Architecture?

What is Microservice Architecture?
The De
fi
nition
Microservice Architecture is an architectural
style that structures an application as a
collection of services that are:
• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities or
bounded context
• Owned by small teams

The Seven Principles
Principle Patterns / Practices
Modeled around business domain Conway’s Law, Domain Driven Design (DDD)
Hide implementation details Remote Procedure Invocation (RPI) and Messaging
Culture of automation Extreme Programming (XP) Practices, DevOps
Highly decentralized Domain Driven Design (DDD)
Deployed independently Continuous Delivery and Deployment
Isolate failure Circuit Breaker Pattern, Reactive Manifesto
Highly observable Continuos Monitoring, Service Mesh

The Patterns

Enablers
• Domain Driven Design (DDD)
• DevOps (and its extensions)
• Agile Software Development
• Containers (e.g., Docker)
• Container Orchestration (e.g., Kubernetes)
• Service Mesh (e.g., Istio or eBPF)
• Message Brokers and Streaming (e.g., Kafka)
• Public Cloud (e.g., AWS)

Is it new?

Is it new?
• Dr. Peter Rodgers used the term “Micro-Web-Services” in 2005 during a
presentation on cloud computing.
• The term “microservices” was discussed at a conference / workshop of
software architects in May 2011 to describe what the participants saw as a
common architectural style that many of them had been recently exploring.
• March 2012, Microservices were presented as a case study in March 2012 at
33rd Degree in Krakow in “Microservices - Java, the Unix Way”.
• Adrian Cockcroft at Net
fl
ix, described this approach as "
fi
ne grained SOA”.

Is it just SOA++?
2005 2008 2016

Introduction
Topics
• Motivations
➡ Why Microservice Architecture?

Marc Andreessen
“Software is eating the world.”

Watts S. Humphrey
“Every business is a software business.”

Satya Nadella
“Every company is a software company. You have to start
thinking and operating like a digital company.”

Why Microservices?
Business and Digital Transformation
• Transformation (aka. Organization Transformation) is the process of
implementing changes across di
ff
erent core organization pillars (people,
process, technology, and culture) in order to improve, boost and benchmark
the organizational performance and sustain such results in a resilient way.
• Business Transformation: an umbrella term that is used for referring to the
fundamental changes in how an organization conducts its business.
• Digital Transformation: the process of using digital technologies to: (1) meet
the needs of the transformed business processes and (2) create innovative
customer engagement mechanisms.

Why Microservices?
Microservices and Digital Transformation
• Microservices enable organizations to evolve their structure and technology
stack through structuring their application(s) as a collection of services.
• In Digital Transformation, Microservice Architecture is a catalyst for the
creation of exceptional customer and employee value through signi
fi
cant
change that leverages the potential of process, technology, data and culture
to create this value.

Why Microservices?
Digital Transformation Trends - Past and Present
Development Process Application Architecture Deployment and Packaging Application Infrastructure
Waterfall
Agile
DevOps
Monolithic
N-Tier | SOA
Microservices
Physical Servers
Virtual Server
Containers
Datacenter
Hosted
Cloud

Why Microservices?
Technical Bene
fi
ts
• Technology Heterogeneity
• Ease of Deployment
• Scaling
• Robustness
• Composability

Why Microservices?
Organizational and Business Bene
fi
ts
• Improve Team Autonomy
• Reduce Time to Market
• Scale Cost-e
ff
ectively for Load
• Improve Robustness
• Easily scale teams
• Embrace New Technology

Introduction
Topics
• Motivations
➡ Microservice Architecture Challenges

Microservice Architecture Challenges
It’s not all sunshine and roses!
1. Learning Curve
2. Monitoring
3. Troubleshooting and debugging
4. Handling failures
5. Security
6. Testing
7. Latency
8. Data Consistency
9. Infrastructure provisioning
10. Deployment

Introduction
Topics
• Motivations
➡ When and when not to go for Microservices?

When and when not to go for Microservices?
Questions to ask
• What are your goals and vision on scaling up?
• Is your business model tested and proven?
• Is your business mature enough to adopt Microservices?
• Do you have a complete understanding of what Microservices are and how they
could in
fl
uence your development operations?
• How strong is your practice of application infrastructure?
• Do you have a tried and tested agile or DevOps practices?
• Is your data management team skilled enough to support the incorporation?

When to go for Microservices?
• If you’re building a highly agile application (product or service) that demands
swift speed of delivery, innovation and more
• When you want your (legacy) monolithic application to accommodate
scalability, agility, manageability and delivery speed
• When you have standalone business applications or modules that have to be
reused across diverse channels

When not to go for Microservices?
• When you’re a Startup.
• The application is too small to justify Microservices.
• The domain is unclear or uncertain, which makes the domain model uncertain.
• The organization can’t change to adapt to the Microservice way.
• Team lacks experience and understanding of Microservice concepts, DDD, or conceptual
design.
• Team is not mature, technical skillset is not adapted, or turnover is high. Since code
cleanliness and architecture tend to decay over time because of entropy, and since a more
complex architecture is harder to maintain, this may exacerbate consequences of point.

Agenda
➡ Section 2: Microservices for Greenfield projects

Microservices for Greenfield projects
What are Green
fi
eld projects?
• In many disciplines, a Green
fi
eld project is one that lacks constraints
imposed by prior work.
• The analogy is similar to that of construction on green
fi
eld land where there is
no need to work within the constraints of existing buildings or infrastructure.
• In Software Development, a green
fi
eld project is a brand-new project
developed from scratch.
• This project does not rely on any existing code, use minimal to no established
infrastructure, and don't need to
fi
t any particular mold.

Microservices Adoption Strategies
Is the the team(s) and
organization in need of and ready
for Microservices?
Microservice-
fi
rst
Monolith-
fi
rst
No Yes

Assess Team Readiness

Assess Ability - The checklist
✓ Conway’s Law
✓ Domain Driven Design (DDD)
✓ Distributed Architecture
✓ Event-driven Architecture
✓ Microservice Architecture, its patterns, and its test strategies
✓ DevOps (CI/CD, Release Strategies, IaC, etc.)
✓ Cloud-native architecture and technologies
✓ Agile software development and organization at scale
✓ Test Automation (Application - functional non-functional and Infrastructure)
✓ The domain and its sub-domains are clear

Situational Leadership
R1 R2
R3 R4

Monolith-
fi
rst Approach
• If your team and organization are not yet ready to adopt Microservice
Architecture, it is advisable to start with Monolith-
fi
rst approach.
• Not all monoliths are bad!
• Start with a Modular Monolith (aka. Modulith).
• A modular monolith can be achieved by applying DDD with Hexagonal,
Onion, or Clean Architecture.
• Once the team and organization are ready, the monolith can be split and
migrated to Microservice architecture (to be discussed in Section 3).

Basic forces acting on software design
• Those were incepted in the mid-70s by Yourdon and
Constantine in “Structured Design” and haven’t changed.
• Their argument goes like this:
‣ We design software to reduce its cost.
‣ The cost of software is = the cost of changing the software.
‣ The cost of changing the software is = the cost of the
expensive changes.
‣ The cost of the expensive changes is generated by
cascading changes (i.e., Coupling)
‣ So, design = cost = change = big change = coupling.
‣ Transitively, software design = managing coupling.

Monoliths are not bad!
• Teams hastily jump to Microservices
• That is because they’re seeking bene
fi
ts they aren’t currently getting and
expect them from Microservices
• We need to remember that Microservices aren’t the point!

Microservice-
fi
rst Approach
1. Choose a decomposition strategy:
• Business Capability (Conway’s Law)
• Sub-domain (DDD)
• Team
2. If Decomposition by Sub-domain is chosen, the
fi
rst step is to identify the
sub-domain and bounded contexts. Event Storming can be used for that.
3. Design your architecture and choose your technology stack.

Melvin E. Conway - Conway’s Law (1968)
“Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the
organization's communication structure.”

Spotify Engineering Culture

What’s next?
• Remember the goals!
• Start with a walking skeleton (the MVP of architecture)
• De
fi
ne measures
• Compare with maturity matrix
• Implement feedback loops
• Continuously measure and improve
• Once you have something implemented, deployed and releases, you know have a
brown
fi
eld project. Check the next section!

Measuring Software Architecture
• Four Key Metrics:
‣ Deployment Frequency
‣ Lead time for changes
‣ Change failure rate
‣ Time to restore service
• Fitness Functions

More Metrics
Scan QR for my LinkedIn
post

Fitness Functions
• “An architectural
fi
tness function is any mechanism
that provides an objective integrity assessment of
some architectural characteristic(s).”
• “An objective function used to summarize how
close a prospective design solution is to achieving
the set aims.”
• “Fitness functions, a concept borrowed from
evolutionary computing, are a concise method that
can also be used to de
fi
ne software system
metrics.”

Fitness Function Categories
Mandatory Optional

Tools used to de
fi
ne Fitness Functions
• Monitoring Tools (performance, scalability, etc.)
• Code metrics (coupling, cyclomatic complexity, etc.)
• Chaos Engineering
• Architecture Testing frameworks
• Security scanning

An example of a Fitness Function (1)
“Unit Test Coverage > 0.9;
Execute on each CI Build; Fail when below target coverage”
• Breadth of feedback: Atomic
• Execution Trigger: Triggered
• Execution Location: CI
• Metric Type: a speci
fi
c value (90%)
• Quality attribute requirement: maintainability
• Static or dynamic: static

An example of a Fitness Function (2)
“Deploy the new release to our production system (at night, 01:00 AM).
While the release is rolled out, constantly perform the regression test set
containing the 5 main end user use cases (login, put item to cart,
remove item from cart, view cart, checkout). The system performs all actions
and responds within 100ms. Fail when test case fails; Fail when system doesn’t perform actions and respond < 100ms”
• Breadth of feedback: Holistic
• Execution Trigger and location: Triggered, production environment
• Metric Type: discrete (performance), true/false (system is deployed or not)
• Quality attribute requirement: performance, reliability
• Static or dynamic: static

Agenda
➡ Section 3: Microservices for Brownfield projects

Microservices for Brownfield projects
What is a Brown
fi
eld project?
• A brown
fi
eld project is one that carries constraints related to the current state
of the site.
• In other words, the site might be contaminated or have existing structures that
architects have to tear down or modify in some way before the project can move
forward.
• Brown
fi
eld software development refers to the development and deployment of
a new software system in the presence of existing or legacy software systems.
• Brown
fi
eld development usually happens when you want to develop or improve
upon an existing application, and compels you to work with previously created
code.

Is the project a
Monolith?
Refactor or rewrite
existing project to a
modular design
No Yes
Is the the team and
organization ready?
Yes
No
Migrate to
Microservices
1
We will talk
about this

Are bounded contexts
well de
fi
ned?
Merge the services
No Yes
1 Using Microservices
Are you
succeeding with
Microservices?
No Yes
Continue using
Microservices
Refactor or improve
based on the problem
We will talk
about this
We will talk
about this

Is the project a
Monolith?
Refactor or rewrite
existing project to a
modular design
No Yes
Is the the team and
organization ready?
Yes
No
Migrate to
Microservices
1

Migrating to Microservices
Migration Approaches
1. Big Bang Approach: Creating a new application from scratch
2. Incremental Approach: Gradually migrate to Microservice Architecture
Big Bang Approach Gradual Approach

Incremental Approach
• Monolithic functionalities can be extracted gradually to be implemented in
Microservices by splitting the monolithic application based on business
capabilities, teams, or sub-domain (DDD).
• Such Microservices include business functionalities exposed as API calls.
They can also access the monolithic database or have their own autonomous
database.
• Many patterns exist for splitting monolithic application. One of the most
useful and commonly used techniques is the Strangler Fig Application.

Strangler Fig Application Pattern
• The idea of Strangler Fig Application
Pattern is to have the new system
initially supported by the existing
system.
• The old and the new systems can
coexist, giving the new system time
to grow and potentially entirely
replace the old system.

Bene
fi
ts of Incremental Approach and Strangler Fig
• Allows new evolutions to be delivered during the migration phase.
• The new system will always be up-to-date.
• Zero Downtime Deployments (ZDD).

Stages of Strangler Fig Application Pattern
1. Identify: identify parts of the legacy
application that will be migrated. DDD can be
used to identify various bounded contexts
2. Transform: implement this functionality in a
new Microservice
3. Co-exist: leave the existing module in the
legacy application as is. Incrementally re-route
calls from the monolith to the new micro service
4. Eliminate: once the tra
ffi
c is completely
redirected to the micro service, eliminate the
legacy module

What about the Databases?
• You can start with a shared DB,
• Then start decomposing the DB using a
pattern,
• Finally, you should end up with one DB per
Microservice.

Microservices gone wrong!
How can you tell if you’re doing Microservices wrong?
• There are no bounded contexts
• You have a Microservice per resource (like REST APIs)
• A single team is working on multiple services
• There is high coupling between services
• Your deployment strategy is Multi-service deployment
• Deployments are hard
• Operational costs are high with no real ROI
• Not meeting organization goals (and not having measures to know that)

well de
fi
ned?
Merge the
services
No Yes
Are you
succeeding with
Microservices?
No Yes
Continue using
Microservices
Refactor or improve

Merging the Services
Microservice Architecture gone wrong
When teams and their organizations implement Microservice architecture before
they’re ready, two main anti-patterns occur:
1. Distributed Monolith
2. Nano-services: an SOA anti-pattern where services are too
fi
ne grained
that their overhead (communications, maintenance etc.) out-weights their
utility.

Merging the Services
Fixing Distributed Monoliths and Nano-services
• These two anti-patterns can be solved by merging services so that:
1. It is back to a single service (a monolith that is either layered or modular)
2. Bounded contexts are properly identi
fi
ed and services are merged to
represent these bounded contexts and be owned by small teams
• Stranger Fig pattern can be used in merging nano-services

Refactor or improve based on
the problem

well de
fi
ned?
Merge the services
No Yes
Are you
succeeding with
Microservices?
No Yes
Continue using
Microservices
Refactor or improve

Refactor or improve based on the problem
How does it work?
• One technique that can be applied is the OODA Loop.
• OODA Loop can be completed with other techniques like 5 Whys, Fishbone
analysis, and Gap analysis.

Refactor or improve based on the problem
Common problems and possible solutions
• Dependency between services:
‣ Monorepos
‣ Feature Toggles
‣ Release Trains
‣ DDD
• Poor observability: Service Mesh
• Failures on production: Microservice Test Strategies (Martin Fowler)

My website
Scan QR to access my
website

Book a free call to arrange a workshop
• Microservice Architecture workshop
• Serverless Architectures workshop
• Service Mesh session
• DevOps Maturity Assessment workshop
• DevOps for Enterprises workshop
• CI/CD workshop
• Hands-on DevOps mentorship
Scan to book a free call

Practical Microservice Architecture (edition 2022).pdf

More Related Content

What's hot

Similar to Practical Microservice Architecture (edition 2022).pdf

More from Ahmed Misbah

Recently uploaded

Practical Microservice Architecture (edition 2022).pdf