From monoliths to microservices

Transcript

1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Danny Burkes @dburkes Slides available at https://speakerdeck.com/dburkes From monoliths to microservices What, how, and why
2. First, I need to set expectations...
3. I’m a text guy
5. Let’s start with some definitions...
6. What is a monolith?
7. Characteristics of a monolith
8. • A single codebase- typically, a single repository Characteristics of a monolith
9. • A single codebase- typically, a single repository • Owned and maintained by a single, sometimes large, team Characteristics of a monolith
10. Characteristics of a monolith • A single codebase- typically, a single repository • Owned and maintained by a single, sometimes large, team • Built and deployed as a single unit
11. • A single codebase- typically, a single repository • Owned and maintained by a single, sometimes large, team • Built and deployed as a single unit • May be deployed frequently or infrequently Characteristics of a monolith
12. • A single codebase- typically, a single repository • Owned and maintained by a single, sometimes large, team • Built and deployed as a single unit • May be deployed frequently or infrequently • Moderate- to high-risk deployments Characteristics of a monolith
13. All user value is delivered via a single unit
14. It’s an app
15. Q: What’s wrong with that?
16. Q: What’s wrong with that? A: Nothing
17. Q: What’s wrong with that? A: Nothing necessarily...
18. What is a microservice?
19. Characteristics of a microservice
20. • A single codebase- typically, a single repository Characteristics of a microservice
21. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team Characteristics of a microservice
22. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable Characteristics of a microservice
23. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable Characteristics of a microservice
24. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable • Governs its own state Characteristics of a microservice
25. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable • Governs its own state • Incorporates resiliency patterns Characteristics of a microservice
26. • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable • Governs its own state • Incorporates resiliency patterns • Encapsulates a single domain model Characteristics of a microservice
27. Characteristics of a microservice • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable • Governs its own state • Incorporates resiliency patterns • Encapsulates a single domain model • May be deployed very frequently
28. Characteristics of a microservice • A single codebase- typically, a single repository • Owned and maintained by a single, usually small team • Independently evolvable • Autonomously deployable • Governs its own state • Incorporates resiliency patterns • Encapsulates a single domain model • May be deployed very frequently • Lower-risk deployments
29. User value is delivered via composed sequences
30. It’s a piece of an app
31. Q: Why would I want that?
32. Q: Why would I want that? A: More frequent delivery of value
33. This isn’t just about code
34. Adopting microservices
35. Implications of adopting microservices
36. • Each microservice should be an independent, autonomous, empowered team Implications of adopting microservices
37. • Each microservice should be an independent, autonomous, empowered team • These teams must collaborate very closely to avoid deadlock Implications of adopting microservices
38. • Each microservice should be an independent, autonomous, empowered team • These teams must collaborate very closely to avoid deadlock • Microservices must adopt things like automated service discovery, circuit breaker patterns, etc., to automate as much of the coordination as possible Implications of adopting microservices
39. • Each microservice should be an independent, autonomous, empowered team • These teams must collaborate very closely to avoid deadlock • Microservices must adopt things like automated service discovery, circuit breaker patterns, etc., to automate as much of the coordination as possible • You need a deployment platform that supports your teams in working like this Implications of adopting microservices
40. Implications of adopting microservices • Each microservice should be an independent, autonomous, empowered team • These teams must collaborate very closely to avoid deadlock • Microservices must adopt things like automated service discovery, circuit breaker patterns, etc., to automate as much of the coordination as possible • You need a deployment platform that supports your teams in working like this • If microservice boundaries aren’t aligned with the change dimensions of the business, you’ll realize little (maybe negative) benefit
41. Implications of adopting microservices • Each microservice should be an independent, autonomous, empowered team • These teams must collaborate very closely to avoid deadlock • Microservices must adopt things like automated service discovery, circuit breaker patterns, etc., to automate as much of the coordination as possible • You need a deployment platform that supports your teams in working like this • If microservice boundaries aren’t aligned with the change dimensions of the business, you’ll realize little (maybe negative) benefit • If you don’t get all of this right, it can be way worse than a monolith
42. Evolving to microservices
43. Existing monolith to microservices
44. • Use techniques like Domain Driven Design and Event Storming Existing monolith to microservices
45. • Use techniques like Domain Driven Design and Event Storming • Identify and expose core business domains Existing monolith to microservices
46. • Use techniques like Domain Driven Design and Event Storming • Identify and expose core business domains • Identify bounded contexts, aggregates, and commands Existing monolith to microservices
47. • Use techniques like Domain Driven Design and Event Storming • Identify and expose core business domains • Identify bounded contexts, aggregates, and commands • Identify risks and potential trouble spots Existing monolith to microservices
48. • Use techniques like Domain Driven Design and Event Storming • Identify and expose core business domains • Identify bounded contexts, aggregates, and commands • Identify risks and potential trouble spots • A obvious starting point usually emerges quickly Existing monolith to microservices
49. Huh?
51. How do I learn more?
52. • Google “event storming” and “domain driven design” and start pulling on some of those threads • Google “Should that be a Microservice?” and find Pivotal’s blog series • Read Domain-Driven Design Distilled, by Vaughn Vernon • Watch this video: http://bit.ly/dburkes-stack2018 • Try these analysis techniques on one of your existing monolithic apps! Next steps
53. Towards better monoliths
54. • Use the same techniques to identify the bounded contexts of a monolithic application that we are building Towards better monoliths
55. • Use the same techniques to identify the bounded contexts of a monolithic application that we are building • Implement the contexts separately, enforcing the boundaries, but assemble it all into a single monolithic application for deployment Towards better monoliths
56. • Use the same techniques to identify the bounded contexts of a monolithic application that we are building • Implement the contexts separately, enforcing the boundaries, but assemble it all into a single monolithic application for deployment • The quick-start and conceptual simplicity of a monolith, with a clear path to extracting services when the time is right to do so Towards better monoliths
57. Huh?
58. Modular monoliths
59. Modular monoliths
60. How do I learn more?
61. • Google “modular monoliths” and start pulling on some of those threads • Visit http://www.appcontinuum.io for a practical approach, including code • Try it on your next greenfield monolithic app! Next steps
62. Takeaways
63. If your monolith isn’t holding your business back, don’t change anything.
64. Microservices can be a way of enabling teams to deliver value faster.
65. Getting microservices right requires a deep understanding of your users and your business.
66. Getting microservices wrong will leave you way worse off than you are now.
67. There are some simple techniques to help you get microservices right.
68. Transforming How The World Builds Software Slides available at https://speakerdeck.com/dburkes © Copyright 2018 Pivotal Software, Inc. All rights Reserved.