Desafiando o status quo: quando e por que não usar microsserviços, Big Data e soluções em moda

1. Desafiando o status quo: quando e por que
não usar microsserviços, Big Data, etc
Michael Nascimento Santos

5. Microsserviços
(É, eita acordo ortográfico
complicado…)

8. There's no reason why you can't make a single
monolith with well defined module boundaries -
Martin Fowler

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

10. Deploy e desenvolvimento
complexo

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

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

13. Difícil de evoluir com
múltiplos times

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

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

17. First Law of Distributed Object
Design: "don't distribute your
objects" - Martin Fowler

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

19. Não siga a manada
● Chamadas assíncronas
● Protocolo binário
● Design for failure

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

22. Big Data

23. Seus dados cabem em RAM?

24. r3.2xlarge - 61GB - USD160
r3.8xlarge - 244GB - USD638,4

25. Péssimo exemplo
● Base com milhões de linhas :-)

26. Bons exemplos
● Sensores (IoT)
● Dados não estruturados
● Bases que chegam a TB
● Processamento real-time (streaming)

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

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

29. Use se fizer SENTIDO!

30. Obrigado!
michael@improving.com.br
@mr_ _m

31. Improving your business