Microservicios en todos lados
Mariano Vazquez
@marianodvazquez
Agenda
- Some Microservices theory (MUST know)
- Our architecture: everything seems to fit!
- Microservices: what worked for us
- Microservices: what we hate
- Conclusions (or what we learned)
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!
Or not..
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
T-shirt time
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
Thanks!
Microservicios en todos lados Mariano Vazquez @marianodvazquez
Microservicios en todos lados
By Mariano Vazquez
Microservicios en todos lados
- 1,879
