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.

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

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

• 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 (oct '15)

API Manager (feb '16)

ARM

Everything seems to fit!

Microservices

(what worked for us)

Microservices

(what we hate)

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, try deploy 50 services in 50*n machines (n>2), in order

Technology Diversity

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

Technology Diversity

ONLY works if the dev 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

Every microservice is a Public API

Docker & Azure

(a little bit of)

Azure Container Service

Docker Swarm

Docker Buenos Aires Meetup #9

Docker en Azure Container Services

Conclusions

(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

Don't do a big bang: prototype & create swarm teams

And, as always, deliver soon & often