Let's microservice all the things
github.com/nanovazquez
@nanovazquez87
Agenda
- Some Microservices theory (MUST know)
- Our architecture: everything seems to fit!
- Microservices: what
work for us - Microservices: what we hate
- (some of) Docker and (a little bit of) Azure
- Conclusions (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.
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!
Or not..
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
T-shirt time
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
Thanks!
Let's microservice all the things github.com/nanovazquez @nanovazquez87
Let's microservice all the things
By Mariano Vazquez
Let's microservice all the things
- 1,243
