Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolith - Ben Christensen, Facebook
19 likes3,237 views
The document discusses avoiding distributed monoliths by not coupling systems with binary dependencies like shared libraries and network clients. It recommends using contracts and protocols instead of shared libraries to allow for independence between services. Common examples of binary coupling that should be avoided are shared libraries for routing, discovery, logging etc. Coupling systems in this way leads to lost benefits like inability to use different languages, platforms or concurrency models for individual services.
![message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
message AddressBook {
repeated Person person = 1;
}](https://image.slidesharecdn.com/microservices-jan2016-160224005648/85/Microservices-Practitioner-Summit-Jan-15-Don-t-Build-a-Distributed-Monolith-Ben-Christensen-Facebook-83-320.jpg)
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolith - Ben Christensen, Facebook
- 1. Ben Christensen @benjchristensen Microservices Summit – Jan 2016 AvoidDistributedMonoliths
- 2. Don't Couple Systems With Binary Dependencies
- 4. Shared Libraries that are required
- 5. Shared Libraries often called "the platform"
- 6. Shared Libraries (and the transitive variety)
- 7. Network Clients of the "official" variety
- 8. What does binary coupling look like?
- 9. Common Examples ... Routing Discovery Logging Tracing Fault Injection Guava RxJava Log4j Apache Commons Spring etc ... Spring Struts Netty Tomcat Apache HttpClient
- 10. Not long until 100s of libraries are required to exist in a given system
- 11. Not long until 100s of libraries are required to exist in a given system This is a "distributed monolith"
- 12. Have you ever seen it take months to upgrade a library across your company?
- 13. Have you ever seen it take months to upgrade a library across your company? This is a "distributed monolith"
- 14. Will it take a ~year to use a new language for a new service?
- 15. Will it take a ~year to use a new language for a new service? This is a "distributed monolith"
- 16. These Symptoms == Lost BenefitsLost Benefits
- 18. Lost Benefits Polyglot Can Java, .Net, Node.js, Go, Rust, C++, etc co-exist in your system? idiomatically?
- 19. Lost Benefits Organizational and Technical Decoupling
- 20. Lost Benefits Organizational and Technical Decoupling Can an individual team adopt a new language or platform without convincing a central authority?
- 21. Lost Benefits Organizational and Technical Decoupling Can individual teams choose a different concurrency model than the "core platform"?
- 23. Lost Benefits Temporal Decoupling Can an individual team upgrade their networking stack?
- 24. Lost Benefits Temporal Decoupling Can they upgrade to the newest version of Guava?
- 25. But isn't shared code good?
- 26. But isn't shared code good? Not Always
- 27. Not necessarily the right principle to prioritize across system boundaries. But isn't shared code good?
- 28. "First, you lose true technology heterogeneity. The library typically has to be in the same language, or at the very least run on the same platform." "Building Microservices" – Sam Newman
- 29. "Second, the ease with which you can scale parts of your system independently from each other is curtailed." "Building Microservices" – Sam Newman
- 30. "...you cannot deploy a new library without redeploying the entire process, so your ability to deploy changes in isolation is reduced." "Building Microservices" – Sam Newman
- 31. "And perhaps the kicker is that you lack the obvious seams around which to erect architectural safety measures to ensure system resiliency." "Building Microservices" – Sam Newman
- 32. But DRY!?!?
- 33. "Building Microservices" – Sam Newman Page 59, "DRY and the Perils of Code Reuse in a Microservice World" "This approach, however, can be deceptively dangerous in a microservice architecture."
- 34. "Building Microservices" – Sam Newman Page 59, "DRY and the Perils of Code Reuse in a Microservice World" "One of the things we want to avoid at all costs is overly coupling a microservice and consumers such that any small change to the microservice itself can cause unnecessary changes to the consumer."
- 35. "Building Microservices" – Sam Newman Page 59, "DRY and the Perils of Code Reuse in a Microservice World" "If your use of shared code ever leaks outside your service boundary, you have introduced a potential form of coupling."
- 36. "Building Microservices" – Sam Newman Page 59, "DRY and the Perils of Code Reuse in a Microservice World" "The evils of too much coupling between services are far worse than the problems caused by code duplication."
- 37. Page 59 "DRY and the Perils of Code Reuse in a Microservice World" Just go read it ...
- 39. Client library becomes ONLY official way to access the service.
- 40. Service logic drifts into the client.
- 41. Nearly impossible to adopt new architectures, languages, etc.
- 43. Consuming team is at the mercy of the service-owner.
- 44. Brittle "Black Market" Clients
- 45. Projection of technical decisions, architecture, and resource utilization on all service consumers.
- 46. Operational complexity is spread to all consumers.
- 47. Team consuming 10 services now potentially has arbitrary code from 10 teams to operate and debug.
- 48. So what is the alternative?
- 50. Like programming languages use interfaces and APIs.
- 51. Services should hide all implementation details.
- 52. Network Protocol & Data Contract Consume with any language and any technology! Iterate and change over time! No dependency on service implementation!
- 53. Just like the Internet!
- 54. But, but, but!!!
- 55. What about ... ?
- 56. What about ... ? standardized logging, fault injection, distributed tracing, discovery, routing, bulkheading, etc, etc, etc
- 57. Legitimate Needs for Standardization
- 58. Standardization Does Not Need Binary Coupling
- 59. Standardization via Protocols & Contracts
- 60. Enabled via independent common libraries that consumers can choose to use ... or reimplement to suit their needs. Standardization via Protocols & Contracts
- 61. Standardization via Protocols & Contracts Example Public AWS APIs with various available clients
- 63. Standardization via Auditing An "integration test" for new services. Tracing? Logging? Fault injection? Routing?
- 64. Doesn't this make it harder to start a new service?
- 65. It could. But it doesn't need to.
- 66. Common "Tech Stacks" do not break this pursuit of decoupling
- 67. Key is that existence of protocols and contracts allow new stacks to be built.
- 68. Anything achieved by any library should be replaceable by coding against protocols and contracts.
- 69. Litmus test ... Can a group of engineers wanting to use the new hotness build a new stack without convincing the rest of the company? and without resorting to sidecars and proxies?
- 70. What might this look like?
- 73. Shade Internal Dependencies Transitive Dependencies
- 74. or copy/paste the needed method! Transitive Dependencies
- 75. If part of public API ... Transitive Dependencies
- 76. If part of public API ... it can't ever have a breaking change. Transitive Dependencies
- 77. (so no libraries that bump their major version every 6-12 months) Transitive Dependencies If part of public API ... it can't ever have a breaking change.
- 78. OkHttp & RxJava as examples http://jakewharton.com/java-interoperability-policy-for-major-version-updates/ https://publicobject.com/2015/12/12/com-squareup-okhttp3/ https://github.com/ReactiveX/RxJava/issues/3170 https://github.com/ReactiveX/RxJava/issues/3173 Transitive Dependencies
- 80. /pets: get: description: Returns all pets from the system that the user has access to produces: - application/json responses: '200': description: A list of pets. schema: type: array items: $ref: '#/definitions/pet' Swagger / OpenAPI
- 82. 5: optional TweetType tweetType = TweetType.TWEET; 16: optional string language = "english"; } typedef list<Tweet> TweetList struct TweetSearchResult { 1: TweetList tweets; } exception TwitterUnavailable { 1: string message; } const i32 MAX_RESULTS = 100; service Twitter { void ping(), bool postTweet(1:Tweet tweet) throws (1:TwitterUnavailable unavailable), TweetSearchResult searchTweets(1:string query); oneway void zip() }
- 83. message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } message AddressBook { repeated Person person = 1; }
- 84. @version("0.1.0") package hello { @doc("A value class for Request data for the hello service.") class Request { String text; } @doc("A value class for Response data from the hello service.") class Response { @doc("A greeting from the hello service.") String result; } @doc("The hello service.") interface Hello extends Service { @doc("Respond to a hello request.") @delegate(self.rpc, {"timeout": 3000}) Response hello(Request request); } @doc("A client adapter for the hello service.") class HelloClient extends Client, Hello {} @doc("A server adapter for the hello service.") class HelloServer extends Server<Hello> {} } Quark by DataWire
- 85. /pets: get: description: Returns all pets from the system that the user has access to produces: - application/json responses: '200': description: A list of pets. schema: type: array items: $ref: '#/definitions/pet' Single | Multi | N | Infinite Beyond Request/Response
- 86. Caching Tiers Default Fallback Values Flow Control & Health
- 87. So why do we fail at this so often?
- 88. Ease. Short-term feels more productive. Service-owners have "first-mover" advantage.
- 89. Delayed cost of decoupling is high. And it's very hard.
- 90. The solutions have limited tax on the short-term. So let's look beyond the short-term ease.
- 91. Avoid Binary Coupling by using Contracts, Protocols & Automated Tooling