Looking to migrate from monolithic application to microservice? Take a peek at some lessons learned from organizations who underwent this journey!

1. Confidential, Dynatrace, LLC
Architectural commandments for building & running
microservices at scale
August 15th, 2017

2. 1. Avoid Anti-Patterns
2. Continuous Deployment
3. Infrastructure Utilization
Microservices Techniques

3. 1. N+1 call
2. N+1 query
3. Payload flood
4. Granularity
5. Tight Coupling
6. Inefficient Service Flow
7. Dependencies
Common Anti-Patterns

4. Confidential, Dynatrace, LLC
Our Setup
Source Code:
https://github.com/Dynatrace-Reinhard-Pilz/dt-micro

5. Service Instance A
Service Client
Request
Service Instance B
Service Instance N
Router/Service
Registry
Register
Our Setup

6. Our Code

7. Confidential, Dynatrace, LLC
Anti-Patterns

8. Confidential, Dynatrace, LLC
N + 1 Call Pattern

9. Monolithic Code
public double getQuote(String type) {
double quote=0;
for (Product product: products) {
quote += product.getValue();
}
return quote;
}
N+1 Call Pattern
Works well within 1
process

10. N+1 Call Pattern
Product Service
Quote Service
1 call to Quote Service
= 44 calls to product
service

11. Confidential, Dynatrace, LLC
N + 1 Query Pattern

12. N+1 Query Pattern

13. N+1 Query Pattern
1 call to Quote Service
= 87 calls to DB
Product Service
Quote Service

14. Confidential, Dynatrace LLC
slide 14
Payload Flood

15. Payload Flood
Document creation is
split across multiple
services

16. Payload Flood
Increasing payload between services
call

17. Payload Flood
Payload could be significantly reduced by calling
individual services from document service.

18. Confidential, Dynatrace, LLC
Granularity

19. Granularity
Doc Processor Doc Transformer Doc Signer
Doc Encryption
Doc Shipment
Document Encryption is carved out at a separate
service. May not be the best option to run it as a
separate service
Documents

20. Confidential, Dynatrace, LLC
Tight Coupling

21. Tightly coupled. Really Distributed?

22. Confidential, Dynatrace, LLC
Inefficient Service Flow
(drawing parallels to Web Performance
Optimization)

23. WPO (Web Performance Optimization)
taught us optimizing resource dependencies
when loading a web page by analyzing
Resource Waterfalls

24. Especially useful when page loads get very
complex and overloaded:
3rd party dependencies, non optimize
resources, wrong cache settings, loading too
much data too early, …

25. SFPO (Service Flow&Performance Optimization)
has to teach us how to optimize (micro)service
dependencies through Service Flows

26. Especially useful to identify: inefficient 3rd party services, recursive
call chains, N+1 Query Patterns, loading too much data, no data
caching, … -> sounds very familiar to WPO

27. Understanding where time within a
service and between service calls is spent

28. Classical cascading effect of recursive
service calls!

29. Confidential, Dynatrace, LLC
Dependencies

30. Look beyond the “Tip of the Iceberg”:
Understanding Dependencies is critical!

31. Who is depending on me? What is the risk of change?

32. Confidential, Dynatrace, LLC
Continuous Deployment

33. Continuous Deployment
Consumer 2
v1
Consumer 1
v1
Micro
service
v1
Consumer 2
v2
Consumer 1
v1
Micro
service
v2

34. Consumer 2
Consumer 1 Microservice
v2
Microservice
v1
Continuous Deployment
Service identifier = unique Id + version
Semantic versioning
(major.minor.patch)

35. Consumer 2
Consumer 1 Microservice
v2
Microservice
v1
Continuous Deployment

36. Consumer 2
Consumer 1 Microservice
v2
Microservice
v1
Continuous Deployment
Gatekeeper
Gatekeeper != O/R mapping service
Beware of N+1 patterns

37. Best Practice: Proper Tagging of Services

38. Confidential, Dynatrace, LLC
Real Use Case

39. 2015201420xx
Response Time
2016+
1) 2-Man Project 2) Limited Success
3) Start Expansion
4) Performance
Slows Growth Users
5) Potential Decline?
Scaling a Search Service for Online Sports Club

40. Early 2015: Monolith Under Pressure
Can‘t scale vertically endlessly!
May: 2.68s 94.09% CPU
Bound
April: 0.52s

41. From Monolith to Services in a Hybrid-Cloud
Move Front End
to Cloud
Scale Backend
in Containers!

42. Go live – 7:00 a.m.

43. Go live – 12:00 p.m.

44. What Went Wrong?

45. 26.7s Load Time
5kB Payload
33! Service Calls
99kB - 3kB for each call!
171!Total SQL Count
Architecture Violation
Direct access to DB from frontend service
Single search query end-to-end

46. The fixed end-to-end use case
2.5s (vs 26.7)
5kB Payload
1! (vs 33!) Service Call
5kB (vs 99) Payload!
3!(vs 177) Total
SQL Count

47. Confidential, Dynatrace, LLC
Infrastructure Utilization

48. Infrastructure Utilization
Is the load on microservices equally load
balanced?
When do you scale up/down?
• CPU
• Memory
• Load
Use automation process to scale up/down

49. Basic Infrastructure Utilization Monitoring

50. Utilization over time correlated with deployments!

51. Deployment and Infrastructure Dependencies

52. Keep an eye on active Docker containers

53. Treat containers just as hosts: CPU,Memory, Traffic, …

54. Confidential, Dynatrace LLC
Infrastructure Utilization: Throughput
54

56. Confidential, Dynatrace LLC
N+1 Pattern
56
Product Service
Quote Service
Watch out for N+1 pattern

57. Confidential, Dynatrace LLC
Payload Flood
57
Payload between services can impact performance

58. Confidential, Dynatrace LLC
Granularity
58
Doc Processor Doc Transformer Doc Signer
Doc Encryption
Doc Shipment
Not every functionality needs to be its own microservice

59. Tightly Coupled
Too specialist services? No Caching?

60. Service Flow
Optimize your End-to-End Service Flows!

61. Dependencies
Reduce risk when changing highly depending services!

62. Continuous Deployment
Consumer 2
v1
Consumer 1
v1
Micro
service
V1
Consumer 2
v2
Consumer 1
v1
Micro
service
V2
Ensure multiple versions of services are supported

63. Infrastructure Utilization
Ensure equal load across all microservice instances

64. Q & A
Source Code:
https://github.com/Dynatrace-Reinhard-Pilz/dt-micro
Free Trials:
Dynatrace FullStack: http://bit.ly/dtsaastrial