43rd edition of GeekNight hyderabad

1. Akos, Anil, Chandan

2. ● Overview: Monoliths & Microservices
● Case Study 1 – Gradual migration
● Case Study 2 – Big Bang
Agenda

3. Overview:
Monoliths & Microservices

4. What is a Monolith?

5. A monolith is...
● ...an architecture style
● ...a way that your code
and business logic is
structured
● ...usually a single code-
base
● ...usually you can
deploy everything or
nothing
Image source: https://www.slashroot.in/difference-between-monolithic-and-microservices-based-architecture

6. Is a monolith bad?

7. It depends!
vs.
Image source: https://tech.findmypast.com/extracting-a-microservice-from-a-monolith/

8. Monoliths pros/cons
● Calls are inter-process
● Simple development
● Simple testing
● Simple deployments
● Simple infrastructure
● Lack of domain boundaries
● Single technology stack
● Difficult to change
● Slow build/test times
● Slow QA process

9. Most common issue:
Monoliths don’t scale

10. Most common issue:
Monoliths don’t scale
In terms of dev process

11. Where monoliths break down
● Large development teams (>20 devs)
● Lack of developer discipline
● Each change means that you need a full QA
● Bugs/issues break everything
● Rollbacks cause a bottleneck
● Lack of domain boundaries means it’s hard to upkeep a
good internal architecture

12. What you end up with
Image source: https://tech.findmypast.com/extracting-a-microservice-from-a-monolith/

13. Signs of a good monolith
● Strong, comprehensive, and quick test suite
● Requires no/minimal manual QA
● Can be deployed many times a day
● Internally structures code into modules
○ Domain Driven Design

14. What is a
microservice?

15. A microservice is...
● ...small enough
● ...not too large
● ...a single domain
● ...can be deployed on
its own
● ...owns its own data
Image source: https://spring.io/blog/2015/07/14/microservices-with-spring

16. Examples of microservices
● Email service
● Payments service
● Push notifications service
● Chat service
● Authentication service

17. The Distributed Monolith
Image source: https://www.programmableweb.com/news/tools-to-monitor-and-visualize-microservices-architecture/analysis/2016/12/14

18. Microservice pros/cons
● Clear boundaries
● Smaller teams
● Deploy in isolation
● Diverse technologies
● Scalable
● Complex infrastructure
● Network calls
● Distributed systems
● Difficult integration testing
● Difficult cross-domain changes
● Difficult local development

19. Microservices are
not a silver bullet

20. Distributed systems

21. Distributed systems

22. The 8 fallacies of distributed computing
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous https://www.rgoarchitects.com/Files/fallacies.pdf

23. Performance
● Typically decreases
● Inter-process calls: 0.1–1 ns
● Network calls: 10–900 ms (or killed after ~60 seconds)
● Many sequential network calls stack up
● gRPC can help instead of HTTP

24. Distributed transactions
● You can’t commit a single DB transaction anymore
● Many HTTP calls that don’t form a transaction
● What if one call fails, but the other succeed?
○ Sagas or event-driven architectures can help

25. Sagas
Image source: https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b

26. Testing
● Testing inside a microservice is easy
● Testing all interactions between microservices is hard

27. DevOps culture
● DevOps culture is required
● You build it, you run it
● Infrastructure complexity:
Service orchestration
Service discovery
Load balancing
Distributed logging
Distributed tracing
Retry strategies
Circuit breaking
Back pressure
Rate limiting
Metrics collection
A/B testing
Fault injection
Chaos engineering
Alerting
Health checking

28. Infrastructure

29. The good sides of
microservices

30. API contracts
● API-first design
● Harder to change
○ Need to think about it a bit more
● Backwards compatibility is a must
● Implementation does not matter

31. Forces Bounded Contexts
● Domain Driven Design
● Each service is responsible for one domain
● The service usually is a Bounded Context

32. Failures are contained
● Each domain can be releasing/rolling back features
independently
● Results in agility
● But: failures can also cascade!

33. So where does that
leave us?

34. Rule of thumb
● Think! — use your brain!
● Start with monoliths
○ Cheaper/quicker setup
○ Simpler to deliver business value
● Refactor into microservices later
○ Team has grown to a considerable size
○ Some functions need better performance

35. How do we break down a monolith?

36. Questions

37. Case Study 1
● Problem Statement
● Backend Separation
○ Two-phased approach
● UI Separation
○ Embedding the monolith UI into React
● Infrastructure

38. The Monolith
● Ruby on Rails
● 160 tables
● 380 server-side views
● 180 API endpoints

39. Problem Statement
● Break out one domain, promotions, from the monolith
● Recreate the UI with an improved UX for this domain

40. Promotions
Domain
● 45 fields in the table
● 30 relationships with
other schemas
● 100 of 380 server-side
views
● 50 of 180 API
endpoints

41. Backend Separation

42. Monolith
API Gateway
Web iOS Android
The Monolith
Emails
Notifications
160 tables
380 views 180 API
endpoints

43. Promotions
µS
API Gateway
Web iOS Android
Phase 1
● Separate business logic
into a new microservice
● µS uses the monolith
datastore
● µS serves the web portal
users
● Monolith continues
serving mobile apps
● Monolith exposes new
APIs for other domains
Emails
Notifications
Monolith
Emails
Notifications

44. Promotions
µS
API Gateway
Web iOS Android
Phase 2
● All traffic hits µS
● µS has its own
datastore
● µS still relies on the
monolith for some
domains
● Monolith relies on µS
for promotions domain
Emails
Notifications
Monolith
Promotions
Data
Other
domains

45. UI Separation

47. Legacy app in an iframe
Modern React container

48. UI Separation
● Render new windows using React components
● Remove all server-side rendered pages from the domain
● Use GraphQL to hook up µS APIs with legacy

49. Infrastructure
● Deployment via Kubernetes
● Logging and alerting
● Tracing a request across multiple services
● Service to service authentication

50. Working on...
● Handling distributed transactions and rollback
scenarios
● Data migration

51. Questions

52. Case Study 2
● UI Separation
● Backend Separation
● Data Migration
○ Event-based triggers
○ Two user groups

53. ● Two user groups
● Oracle ATG e-
commerce
● One database for read-
write
● Endeca search/
discovery tool for data
● Endeca indexes the
data for search
Endeca
Product
Inventory
Order
Management
Category
UI
Monolith
Architecture
User ProfilePromotions
Adornments
ProductsCategory
SKUs Recommendations
ATG
DB

54. ● ATG DB update
triggers an event
to RabbitMQ
● RabbitMQ sends
event based
triggers to service
● Services listen to
particular events
and store it into ES
● Different queues
for the different
kinds of message
ATG
DB
DATABASE
TRIGGERS
UI
Product Listing Product Display
Products SKU Promotions User Profile
Category
Category

55. New UI
ATG
µS
µS
µS
µS
µS
µS
µS
µS
µS

56. Questions

57. Go break a monolith

58. Go break a monolith
If you must.