Embed Size (px)
Citation preview
Desafiando o status quo: quando e por que não usar microsserviços, Big Data, etc
Michael Nascimento Santos
Microsserviços(É, eita acordo ortográfico
complicado…)
There's no reason why you can't make a single monolith with well defined module boundaries -
Martin Fowler
“Microservices ... only work well if you come up with good, stable boundaries between the services - which is essentially the task of drawing up the right set of BoundedContexts. Any refactoring of functionality between services is much harder than it is in a monolith. Even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are, before a microservices design brushes a layer of treacle over them.” - Martin Fowler
Deploy e desenvolvimento complexo
I've heard people say that you need to use microservices because it's impossible to do Continuous Delivery with monoliths - yet there are plenty of organizations that succeed with a cookie-cutter deployment approach: Facebook and Etsy are two well-known examples. - Martin Fowler
The microservices approach is all about handling a complex system, but in order to do so the approach introduces its own set of complexities. When you use microservices you have to work on automated deployment, monitoring, dealing with failure, eventual consistency, and other factors that a distributed system introduces. There are well-known ways to cope with all this, but it's extra effort, and nobody I know in software development seems to have acres of free time. - Martin Fowler
Difícil de evoluir com múltiplos times
Remember that the microservices approach brings a high premium, one that can slow down your
development considerably. So if you can keep your system simple enough to avoid the need for
microservices: do. - Martin Fowler
I'm always reluctant to play the distribution card, and think too many people go distributed too quickly
because they underestimate the problems - Martin Fowler
First Law of Distributed Object Design: "don't distribute your
objects" - Martin Fowler
Pré-requisitos● Testes
● Provisionamento rápido
● Monitoramento
● Deployment rápido
● Saber lidar com computação distribuída (transações, caches
eventualmente consistentes, latência etc.)
Não siga a manada● Chamadas assíncronas
● Protocolo binário
● Design for failure
The additional complexity that comes from distributed systems requires an additional level of maturity and investment. We are concerned that some teams are rushing in to adopting microservices without understanding the changes to development, test, and operations that are required to do them well. Our general advice remains simple. Avoid microservice envy and start with one or two services before rushing headlong into developing more, to allow your teams time to adjust and understand the right level of granularity. - ThoughtWorks
Big Data
Seus dados cabem em RAM?
r3.2xlarge - 61GB - USD160r3.8xlarge - 244GB - USD638,4
Péssimo exemplo● Base com milhões de linhas :-)
Bons exemplos● Sensores (IoT)
● Dados não estruturados
● Bases que chegam a TB
● Processamento real-time (streaming)
Relational databases are mature technology, that lots of people are familiar with and have good tooling. Unless there is a good argument for something else, they are
currently still the default choice. - Martin Fowler
Referências● http://martinfowler.com/bliki/MonolithFirst.html● http://martinfowler.com/bliki/MicroservicePremium.html● http://martinfowler.com/bliki/MicroservicePrerequisites.html● http://martinfowler.com/articles/microservice-trade-offs.html● http://martinfowler.com/articles/distributed-objects-microservices.html● http://techblog.netflix.com/2011/07/netflix-simian-army.html● http://martinfowler.com/articles/bigData/● https://www.thoughtworks.com/radar/techniques/microservice-envy
Use se fizer SENTIDO!
Improving your business
