Building Microservices Oreilly - Summary and Notes - Chapters 1 - 4

Here's a copy of my loose notes from this great introduction to Microservices.  It's a really novel way of looking at an old problem.  It's also increasily relevant as I am becoming responsible for larger and larger systems.  The world has come a loooooong way since I started getting into development.  It's interesting (and a little scary) to see so many of the patterns we've grown accusomted to over the years, finally start to change again.

Preface:

Micro Services - Distributed systems with their own lifecycles which collaborate together, modeled around business domains

Chapter 1:

Domain-Driven Design: representing the real world in code
Continuous Delivery: easily get software into production, every check in
Hexagonal Architectures: less layered architectures to hide business logic
Virtualization: provision and resize machines at will
Agile: Small teams owning lifecycle
Netflix: how to build anti-fragile systems at scale (Microservices)

MS do one thing well, like Linux commands
We want modular code, but that breaks down in big systems

• Gather together those things that change for the same reason, and separate those things that change for different reasons

As you build smaller systems interdependence increase, but so does complexity from moving parts
You should be able to change independently of each other and be deployed by themselves without requiring consumers to change
The golden rule: can you make a change to a services and deploy it by itself without changing anything else?
Each MS and its team can pick their own tech stack

Ex: social network, stores user interactions in graph DB, posts in document store

Should be able to rewrite Microservice in two weeks, this mitigates risk of embracing new tech

Resilience Engineering: the bulkhead, failure shouldn't cascade, isolate the problem and the rest of the system can carry on working

Monolithic: Scale everything together, big and risky to change, one code change and redeploy everything

Microservices: Scale just the parts we need, deploy that service independent, align arch to organization, design for everything, not just web, easy to replace, can be complicated, it's not a golden hammer

Ms is NOT SOA
Ms isA form of SOA

Shared libs, this looses heterogeneity, same language, same platform, but they do have their place

OSGI is a thing, we may see it in java 9, more complex than benefits, lends to coupling 

Chapter 2

This is the authors opinion of the architect role

Arch and tech lead are same role, vision for a program of work, coordinate teams

documents and diagrams to crate a perfect system in unknown future

let's focus on creating framework so the right systems can emerge, continue to grow as we learn more

arch is like a town planner for the environment, we optimize the layout of the city

we help influence direction, don't build a sewer here, do that here, (we are zoning)

teams can pick a diff tech stack, but remember they need to move between teams too

a system doesn't accommodate users, it also accommodates devs and ops

multiple messaging systems are a nightmare to consume, stay focused

be worried about what happens between the boxes and be liberal in what happens inside

join a team for a short period and pair program

rules are for the obedience of fools and the guidance of wise men

find out where the org is heading and align technology to it

principals (goals)

ex: 

• Decrease time to market: delivery teams have full control over sdlc
• Grow in other countries: principle entire system to be portable and allow for local deployment

practices: coding guidelines, log data centrally, rest, only centos, dev teams own lifecycle, everything in aws, 

  * change more frequently

these guide how the system evolves

use sample code people can run the embody these p and p

Netflix: a cohesive system made of many small parts with autonomous lifecycles, but all coming together (don't loose sight of the bigger picture)

monitoring: system wide, not service wide, all services emit health and monitoring

metrics: Graphite

health: Nagios

(integrate means connect to each other, interface means what the do this on)

Interfaces: HTTP/REST

  * pick a small number of defined techs to help integrate

be wary of failure of downstream calls

governance: setting controls in place for sticking to the vision

 * make it easy to do the right thing

 * use (live, domain specific) code examples (exemplars) to show best practices

programs to help generate this stuff, Dropwizard and Karyon

mandate circuit breaks like Hystrix

mandated frameworks can make for unhappy developers

deviating from tech vision might have short term gain, but long term cost

the arch looks at bigger pictures and balances

arch job ensures tech vision, governance ensures we are building matches this vision

don't require working practices that make devs miserable, keep up to date with tech, knows when to make the right tradeoffs

chair (and champion) the group that makes these decisions

be cool, let teams make mistakes and learn from them

ms has more opportunity to own something

Chapter 3 - Modeling Services

Let’s think about boundaries of ms through MusicCorp example

two keys: loose coupling and high cohesion

loose coupling

  * doesn't bind tightly to other services so changes don't cause other services to change too

  * limit number of calls between services, chattiness is tight coupling

 high cohesion

  * related behaviors sit together

  * not having to make changes in lots of different places (slow and risky)

bounded context: domain has multi bctx with things in them that don't need to be communicated outside. they share some things with other ctxs, they all have interfaces that decided what it will share

  * they have specific responsibility enforced by explicit boundaries

  * cells are similar, they define what comes in, what stays in, and what goes out

ex: finance and warehouse dept, they have internal process and external data, finance doesn't care how warehouse works, but needs to know some things about inventory, warehouse can have an internal representation and a diff external representation we expose. 

* same name could have diff meaning in contexts, a return; customer preints shipping label, sends package, waits for refund.  the warehouse creates restock request, waits on package, restocks item

think about what should be shared and how it's diff from your internal rep, identify a boundaries in domain where like minded capabilities should live

bounded contexts are like compositional boundaries: we can keep modules hidden inside boundary to reduce coupling.  lets find bounded contexts and create them as modUles with hidden models 

  * MSs should clearly align to bounded contexts

  * service boundaries align to bounded contexts

  * MS represent bounded contexts

don't split them to quickly, can lead to issues, example of doing this and merging back to monolithic to better understand, then splitting back a year later.  its actually easier to split existing than a new one because of experience

don't think about data shared between ms think about capabilities contexts provide to the rest of the domain

  * this can lead to designing CRUD based services

  * "what does this context do", then "what data does it need to do that"

BCs can contain other BCs, you can even take a warehouse BC and split it out into parts others can use after a while

  * warehouse split to.... order fulfillment, goods receiving, inventory

if a team ends up maintain multi MSs, consider nesting them, are they closly tied?

chunk of arch to simp testing, don't want to stub multi services in the warehouse context

think of data sent around MSs like hand filled forms

case study: incorrectly modeled system grows, front half stateless, back half rpc directly connected to DB, passing around db objects makes this brittle, change db, have to change everything (onion arch), but not if you're just passing what you need through the web services 

Chapter 4 Integration (how these things talk to each other)

Getting integration right is most important for MS

if ms adds new fields when sending out, existing consumers shouldn't be impacted

avoid integration tech that dictates what tech stacks we use to implement our MS (SOAP forces Java)

a DB is basically a big shared API that when changed causes waves down your application, lets hide the db and focus on the concepts that pass around the app

split it up right and you can store some of your data in a type of db and other data in a document store or something, do this by hiding db implementation from consumers (loose coupling)

don't spread logic amongst consumers (bad for cohesion), only customer services should change customers

synchronous: waits for operation to complete

  * request response: init request wait for response, but can be async too with callbacks (let me know when done)

asynchronous: doesn't wait, carries on

  * event-based: says "this thing happened", other parties know what to do with that (highly decoupled)

orchestration: complex locic to deal with processes that stretch across the boundaries of services (create customer, send email notification, inform billing, all handled by one big brain), inherently request/response

choreography: say customer was created, decoupled, subscribe to this event, business process don't map as well to this, additional work to track, needs good monitoring

comm methods...

rpc:  remote procedure call, soap, protocol buffers, thrift.  separate interface def, tight coupling same underling tech, gen client and server stubs, rmi fast start but coupled, removes complexity, if lots of in process calls marshalling and unmarshalling can be significant bottleneck, the network is not reliable, brittle, if you change the interface, everything needs to be updated (lock step), rpc still better than database integration

protobuffs and thrift mitigate by working better with missing fields

rest: has "resources", internal rep could be diff than ext rep, has "verbs", get post put and these can all point to one endpoint, put post get from one endpoint, built on http with chacing and load balancers, security and auth certs. soap over http but ignores verbs

HATEOAS: hypermedia as engine of application sate, links, web page, user follows links, clients should perform interactions with the server via these links to other resources

  * at amazon.com shopping cart button has moved over time, humans smart enough to see it though

  * the gist: a response with product data, but also a "link" embedded in an xml response to the purchase endpoint

  * this works well with xml, but not json

  * big decouple between client and server

  * it's a little chatty

* some rest implementations are starting to look like rpc, not good, watch out

* cant easily generate stubs for rest

* jersey has proper rest support (put and delete)

* rest over http good choice for service to service

websockets: stream data for browser, low latency, small, not well supported, can run on the fast UDP protocol (less error checking)

--- event based async communication

rabbitmq: publish event to broker allow consumer to be informed, good for loosely coupled, event-driver arch, careful not to push to much logic to the middleware (the enterprise service bus)

atom: rest compliant, publish event to feed, consumers poll, careful the message could get processed twice (link: synchronized messaging), we have to manage shared state

with event based, be careful, lots of things can go wrong when things go down

ex: bank pricing system, events picked off queue would bring down worker, failed backed to the queue and eventually brought down all the workers, implemented a message hospital (dead letter queue) to be manually addressed

  * use good monitoring, and correlation ids to trace messages through the system

reactive ext (rx): observe outcome of operations, solves multi calls to single operation, (like how zookeeper notifies all listeners something happened, observer pattern?)

--- 

shared libraries dangerous in ms arch, avoid, creates tight coupling, changes to shared code causes ripple effect

ex: common domain object changes, all services now need to be updated, and messages in queus are invalid (things like logging libs should be find though), logging libs ok, you can hand copy in libs to avoid coupling, keep as much logic out of client libs as possible

Netflix libs do service discovery, failure modes, logging, and things unrelated to the service they perform, that's ok to share, but even still can be problematic, we need to be able to release independent of each other

if a service retrieves a customer record, then passes info of it to another service, that means it could be out of date in the future, make sure to pass the id for sanity checks

try to avoid versioning, rest helps with this because internal changes don't break external output (if done right), your parsing should be tolerant of changes in rest payloads, accept alot, send a little

semantic versioning: MAJOR, backward incompatible, MINOR, backwards compatible, PATCH, bug fix no breaks

this works well with dist systems

coexist interfaces for backwards compact, give time to move over, then deprecate (expand api, then contract)

/v1/customer
/v2/customer

but have to fix bugs in two places

think holistically, desktop, mobile device, wearable, brick and mortar store, your services will feed them all

weigh the benefits, binary proto fast, but bad for web browsers, maybe your service could take params and return only what is asked

or you can put services over services to allow web to interact easier, a backend for frontends, this is not an api gateway which connects to all services for ease of access but can end up holding too much behavior

------

buying services: COTS commercial off the shelf software, SaaS, "buy if your use of the tool isn't special to your business", this come with lack of control though, the vendor controls your destiny, expensive to customize, migrate off SaaS with a service front end that can eventually be switched out when ready or in steps, intercept calls and use "strangler application pattern"

avoid database integration, consider rest/rpc tradeoffs, but rest and request/response integration a good starting point, choreography over orchestration, avoid a system the requires versioning with tolerant response reading, use compositional layers