This document discusses considerations for migrating from a monolithic application architecture to microservices. It outlines a three stage process: 1) separating services but keeping a shared database, 2) separating databases but still requiring synchronous access to other services' data, and 3) fully decoupled services and data using event-driven architecture. Key challenges discussed include tight coupling between initial microservices, integration testing difficulties, maintaining backward/forward compatibility, and securing communication between services. The presenter advocates for evolving the architecture gradually and investing in tooling to manage complexity.

1. Distilling the monolith to
microservices journey
Oct 13, 2020
Sanjay Nagaraj Buchi Reddy
CTO/Co-Founder,Traceable Platform Engineering
Lead,Traceable

2. 2
About the Speakers
Agenda
Evolution: Monolith to Microservices
Microservices migration by the Book
Considerations when migrating from a
monolith to microservices
“Successful software gets changed”
- Fred Brooks from ‘No Silver Bullet’
HYPERTRACE_

3. 3
The Traceable Team
Creators of Traceable & Hypertrace
TEAM PROFILE_
● Founded 2019
● Series A funding via Unusual Ventures
● 32 Engineers & Domain Experts across San
Francisco Bay Area and India
● 150+ Years of Combined DevSecOps Experience
● Team Hails from companies such as AppDynamics,
Inmobi, Wallarm, IDF, Amazon, Informatica &
Redis Labs
● Hypertrace released as open source project
July 2020
Sanjay Nagaraj
Buchi Reddy
CTO/Co-Founder,Traceable
VP Engineering,AppDynamics
Platform Engineering Lead,Traceable
Director of Engg, Data Platform,
AppDynamics
Jyoti Bansal
CEO/Co-Founder,Traceable
CEO/Co-Founder,Harness.io
CEO/Founder,AppDynamics

4. Evolution:
Monolith to
Microservices
4
MICROSERVICES APPMONOLITHIC APP

5. Security gaps new in Microservices
5
Single source of logs from the
monolith
Difficult to trace root-cause
analysis across systems
Release every 3-6 months;
firewall and WAF rules developed
over years
Pace of development much
higher than the pace of security
Most threats are network or
legacy static OWASP
Existing tools are ineffective
against emerging threats
Monolothic systems and multi-
page apps.
Proliferation of APIs with poor
lifecycle management
Microservices
Monolithic
MODERN SECURITY_
For almost half of those adopting
microservices, security is a top
concern.

6. Microservices
migration by
the Book
6

7. Evolution: From Monolith to Microservices
7
Stages:
● Start with Monolith
1. Microservices, but with Tight Coupling
2. Microservices with Loosely Coupled Services, but Temporal Data
3. Microservices with Loosely Coupled Services AND Decoupled Data

8. Start: Monolith
8
Database 1
Application
Status
● All code in one application service
● In-process calls to other modules
Pros
● Fewer moving parts. Less complex
● Simpler deployment & management
● Fewer failure points
Cons
● Teams can’t deploy services independently
● Teams can’t use different languages, versions
● Can’t scale parts independently
● Single point of failure

9. 1. Microservices, but with Tight Coupling
9
Database 1
Application
Progress
● Separated the services, but database
is still shared
Pros
● Teams can deploy services
independently
● Teams can use different languages
and versions
Cons
● Must be careful not to overwrite data or
schema owned by other services
● Tight coupling because each service is
dependent on each other

10. 2. Microservices with Loose Coupling, but Temporal Data
10
Progress
● Completely separated the
databases. so each service has its
own databases. None are shared.
Pros
● Can deploy services AND database
changes independently
Cons
● You must access other services
data via synchronous APIs
● Still ‘tight coupling’ because each
service requires the other services
data
Database 1 Database 2
Application

11. 3. Microservices with Loose Coupling AND Nontemporal
11
Progress
● Event-driven Architecture
● Each Service maintains a local query
view of external data
Pros
● Fast access to data
● All data needed is local
Cons
● Data duplication
● Local data is eventually consistent
Database 1 Database 2
Application

12. 12
Considerations
when migrating
from a monolith
to microservices

13. Migrating to Microservices: Build pain points
13
● Need fairly new ways to build, version, package artifacts
○ Be ready to invest in a lot of *new* build tooling
● Components are often too tightly coupled
○ Start small and have a plan; baby steps are the key
○ First create modularity within the monolith
○ Re-architect parts of the system?
○ Re-write a service?
● Intimidated to break down some parts
○ Evolve slowly: Monolith → tight coupling → temporal coupling → fully decoupled
● Integration testing is harder
○ Mocking services FTW

14. Migrating to Microservices: Build pain points
14
● Functionality is often broken
○ Start caring about backward and forward compatibility
○ Test the API and data format compatibility in the CI
○ Resiliency
○ Idempotency?
○ Mocks needed for integration testing
○ Automated testing as guardrails
○ Continuous end-to-end product feature validation
● No control over what Docker images or OS are used
○ Common base images, security controls, standards
○ Standards around service user, accounts, etc

15. Migrating to Microservices: Maintenance pain points
15
● Deploying and managing multiple services isn’t as simple
○ Have (pick) a framework to orchestrate multiple services at scale
○ Pick service packaging model, versioning
● Impossible to debug a broken deployment
○ Continuously deliver to reduce payload
○ Canary or B/G deployment
○ Tooling to surface issues easily
● Old school APM tools aren’t enough to monitor
○ Welcome to distributed tracing!
○ Use Hypertrace (shameless promotion)
● Logs aren’t in single place
○ Invest in a logging solution

16. Migrating to Microservices: Security posture
16
● Service to service communication isn’t as secure anymore
○ Secure service to service communication
○ Embrace a service mesh and mTLS, if it makes sense
○ Zero-touch certificate management and rotation
● Larger attack surface for your APIs
○ Invest in proper security tools to detect security attacks and protect
○ Shift left
● AuthN & AuthZ can’t be enforced in a single place now
○ Centralized Auth servers or distributed?
○ Latency is super critical
○ Distributed policy rollout

17. Microservices: Are you overdoing them?
17
● Too many microservices
○ Mini services?
○ API inventory tools
○ Service discovery tools
● Too many repositories
○ Unless you’re Google, you have separate repositories. Tooling to easily
work across repos
○ Consider macro repos
● Who should own the on-call issues?
○ Automate alert routing and trivial triaging
○ RCA tools
○ SLAs, SLOs

18. 18
Hypertrace

19. Hypertrace provides observability into your
application architecture. It includes global, service
and backend dashboards, allowing teams fast
insight into service level objectives.
Hypertrace & OpenTelemetry
19
● Collect distributed traces
● Enrich your tracing data
● Visualize real-time activity
Deploy Using:
http://hypertrace.orgMore at:
Hypertrace Supports Tracers and Agents:

20. Thank you very much!
sincerely,

21. 21
This slide intentionally left blank.