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.
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"?
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
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 ...
52. Network Protocol & Data Contract
Consume with any language and any technology!
Iterate and change over time!
No dependency on service implementation!
60. Enabled via independent common libraries
that consumers can choose to use
... or reimplement to suit their needs.
Standardization via Protocols & Contracts
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?
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.
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
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