The presentation from our online webinar "Design patterns for microservice architecture". Full video from webinar available here: https://www.youtube.com/watch?v=826aAmG06KM If you’re a CTO or a Lead Developer and you’re planning to design service-oriented architecture, it’s definitely a webinar tailored to your needs. Adrian Zmenda, our Lead Dev, will explain: - when microservice architecture is a safe bet and what are some good alternatives - what are the pros and cons of the most popular design patterns (API Gateway, Backend for Frontend and more) - how to ensure that the communication between services is done right and what to do in case of connection issues - why we’ve decided to use a monorepo (monolithic repository) - what we’ve learned from using the remote procedure call framework gRPC - how to monitor the efficiency of individual services and whole SOA-based systems.

1. Design patterns for
microservice architecture
x

2. whoami
• Lead Software Developer
@ The Software House
• adiqpl @ twitter
• adrian@zmenda.com
• linkedin.com/in/adrianzmenda
Adrian Zmenda

3. What we’ll cover today
• Basics
• Communication
• Internal Communication
• Security
• Availability
• Configuration
• Logging

4. Should I use microservices?

5. What is a microservice?
• Loosely coupled
• Independently deployable
• Highly maintainable and testable
• Organized around business capabilities
• Owned by a small team

6. When microservices are good idea
• Complex application
• High scalability
• Rapid and frequent delivery

7. Drawbacks
• running distributed system is hard
• maintaining consistency is challenging
• ops complexity is high

8. Should I start with microservices?

9. Monolith

10. Monolith
source: CBS

11. source: Simon Brown

12. Modular Monolith
source: Simon Brown

13. Can we go even further?

14. Self-Contained System
source: Roman Stranghöner

15. Self-Contained System
sooo, it’s like microservices. right?

16. Communication

17. Direct

18. Gateway

19. Backend For Frontend

20. Internal Communication

21. Remote Procedure Invocation
• Synchronous
• Simple
• Easy to understand
• Follows Request / (Response)

22. REST
• Familiar
• Based on HTTP
• No intermediate broker
source: nginx

23. Apache Thrift
• Backed by Facebook
• Language neutral contract-file
• Code generation
• Support for notifications

24. • Backed by Google
• Calls visible as internal
• Code generation
• Simple contracts (Protocol Buffers)

25. Message Broker
• Asynchronous
• Follows Publish / Subscribe
• Increases complexity
source: nginx

26. Message Broker

27. Combined Messaging
source: nginx

28. Security

29. No ACL
• Simple
• Rarely possible
• No additional over-head

30. ACL in every microservice
• Duplication of ACL logic
• Redistributes ACL across all microservices
• Contexts mixing

31. ACL as dependent microservice
• ACL defined as single microservice
• Prevents duplication and redistribution
• Could be a Single Point of Failure

32. ACL on Gateway
• ACL on Gateway (could be implemented as microservice)
• No duplicated ACL code in microservices
• No huge over-head, simplifies internal communication

33. Availability

34. ?

35. ?
DNS

36. ?
Load Balancer
(router)

37. Service Discovery

38. Client-Side Service Discovery

39. Server-Side Service Discovery

40. Service Registries

41. Self-Registration

42. 3rd Party Registration

43. Consul
• Service Registry
• Healthchecking
• Key/Value Storage
• Secure Communication
• Multi Datacenter

44. Handle Failures
• Define network timeouts
• Limit no. of outstanding requests
• Provide fallbacks

45. Circuit Braker

46. Configuration

47. Externalized Configuration
{
"sectionA":{
"valueA":"ABC123",
"valueB":"XYZ321"
}
}

48. One configuration to rule them all
{
"sectionA":{
"valueA":"ABC123",
"valueB":"XYZ321"
},
"sectionB":{
"valueC":"ABC123",
"valueD":"XYZ321"
}
}

49. One configuration to rule them all
{
"sectionA":{
"valueA":"ABC123",
"valueB":"XYZ321"
},
"sectionB":{
"valueC":"ABC123",
"valueD":"XYZ321"
}
}
{
"sectionA":{
"valueA":"ABC123",
"valueB":"XYZ321"
}
}

50. Logging( )
Tracing

51. How to debug microservices?
• Aggregate all logs in one place
• Track Exceptions
• Trace requests
• Visualize

53. Measure
• Monitor relevant platform details:
• execution time of db queries;
• request execution time;
• number of request per minute;
• response times;
• success/failure ratio;
• resources usage

54. Prometheus

55. Grafana

56. Now, we can do microservices
the right way

57. Can we do them fast?

58. Define standards / contracts

59. Embrace tooling

60. Example: Service structure generation

61. Example: GRPC code generation

62. Example: GRPC code generation

63. How to organize microservices
in code repositories?

64. Multi-repository
• Pros:
• better owner (team) separation;
• clear scope
• Cons:
• hard to keep consistency (versioning is complex);
• risk of becoming a monolith;
• introduces more CI/CD setup costs

65. Mono-repository
• Pros:
• easy to maintain consistency;
• easier versioning
• Cons:
• different teams may affect each other;
• might lead to tight coupling;
• longer build times

66. • Databases
• Testing
• CI / CD as essential tool
• Destructive Testing
• Deployments
• many, many more…
What we didn’t covered today
youtu.be/D8l19VEokBA

67. Summary
• think twice if you really need a microservice architecture
• ensure you have all necessary resources to operate distributed systems
• make cold and educated decisions what’s best for your case, not netflix
• embrace contracts and tooling

68. Resources
• microservices.io
• martinfowler.com/microservices
• scs-architecture.org
• codingthearchitecture.com
• nginx.com/blog/introduction-to-microservices

69. Don’t miss our upcoming webinars!
Sign up for our newsletter! ✍
tsh.io/newsletter

70. Thanks 😉
tsh.io