Distilling the monolith to microservices journey at CMG
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
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.
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
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
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:
Thank you all for taking the time. Buchi and I will share some of the lessons we learnt in our own journeys in microservices.
At traceable, we are enabling application security for your cloud-native applications. We are combining the power of distributed tracing and machine learning to help our customers discover and understand the security posture of their Applications and Protect those applications. We also enable investigation of potential attacks with insights from the distributed trace data.
Over the years we have seen the migration of monolithic services to Microservices. The rapid adoption of K8S has further enabled the migration. The applications are becoming distributed API driven and mobile driven and exposing the business logic directly to the outside world. The biggest problems with these complex architectures is in understanding the performance, security and business impact.
Since traceables goal is to help our customers protect their applications. Let me take security as an example in the world of microservices and discuss why it is a concern for a majority of security practitioners as they adopt microservices.
Having introduced traceable and the problem we set out to solve. Let us take a step back and start to think about the migration to microservices and some of the challenges with it and learnings on our end.
Thanks Buchi. As we discussed Microservices is hard and takes a lot of effort to operate them. At traceable we recognized this and internally we were using a distributed tracing platform to build application security solutions for our customers. We decided that what we were using ourselves can be helpful for the broader microservices community and hence we open sourced the project called Hypertrace. One of the best things that happend in the tracing community was the formation of Opentelemetry as a project. OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. We fully support otel with hypertrace. We hope with hypertrace we are doing our part in enhancing the use of distributed tracing with your microservices