1. Ben Christensen
@benjchristensen
Microservices Summit – Jan 2016
AvoidDistributedMonoliths

2. Don't Couple Systems
With Binary Dependencies

3. Shared Libraries
&
Network Clients

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

17. Lost Benefits
Polyglot

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"?

22. Lost Benefits
Temporal Decoupling

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 ...

38. Observed Outcomes

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.

42. Far Reaching Effects

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?

49. Contracts & Protocols!

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

62. Standardization via Auditing

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?

71. Shared Libraries
&
Network Clients

72. Transitive Dependencies

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

79. Shared Libraries
&
Network Clients

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

81. 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