Microservices

(some theory)

Microservices

An approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

Microservices

Microservices

There's a desire to build systems by plugging together components, units of software that are independently replaceable and upgradeable.

Microservices

...splitting up into services organized around business capability, not application layers.

Microservices

...preferring the notion that a team should own a product over its full lifetime ("you build it, you run it")

Microservices

...aimed to be as decoupled and as cohesive as possible, receiving a request, applying logic as appropriate and producing a response.

Microservices

...using the right tool for each job, instead of the same language/technology every time

Microservices

...letting each service manage its own database, either different instances of the same database technology, or entirely different database systems (polyglot persistency)

Microservices

... and promoting the working software 'up' the pipeline automatically when all validations have passed.

Microservices

..but also be designed so that they can tolerate the failure of any service at any time

Microservices

...and the ability to make frequent, fast, and well-controlled changes to software.

Microservices architecture

• Componentization via services
• Organized around business capabilities
• Products not Projects
• Smart endpoints and dumb pipes
• Decentralized governance
• Decentralized data management
• Infrastructure automation
• Design for failure
• Evolutionary design

Our architecture

API Manager (initial setup)

API Manager (sept '15)

API Manager (nov '15)

API Manager (jul '16)

API Manager (nov '16)

ARM

ARM

Everything seems to fit!

Microservices

(what worked for us)

Microservices

(what we hate)

But also..

Split services into modular components

Helps with the distribution of work between large and remote teams

Split services into modular components

..But you need to define contracts properly and design for failure

Independent deployments

Simple services are easier to deploy and are autonomous, what could go wrong?

Independent deployments

...yeah, but try deploy 50 services in 50*n machines  (n>2), in proper order and with a rolling update fashion

Technology Diversity

Mix multiple languages, development frameworks and data-storage technologies. Yay!

Technology Diversity

ONLY works if the DevelOps team takes full responsibility for the software in production ("you built it, you fix it")

Public APIs

Every microservice is a Public API

Public APIs

..including your (internal) microservices!

Public APIs

..yes, those lil bastards

Conclusions

(or "what we learned")

Think about the infrastructure & automation first

People over tools, always

Coordination between teams, done right

Every microservice is a Public API, not a "backend" of a (single) app

Don't do big bangs: prototype & create swarm teams

Everyone needs to adopt new things

And, as always, deliver soon & often