16.4.16 Java/Scala Lab Upcoming events: goo.gl/I2gJ4H Термин микросервисы уже стал buzzword при разработке enterprise приложений. Они вездесущи и помогают решить кучу проблем, присущих монолитным приложениям. Но действительно ли микросервисная архитектура является той самой серебряной пулей? Я расскажу, как красивая и элегантная парадигма проектирования разбивается о суровую реальность корпоративной разработки и как постараться максимально уберечь себя от этого.

1. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I1
From monolith to microservices
or why cool theory could be a painful practice

2. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I2
Boring Theory
“Whenever a theory appears to you as the only possible one, take
this as a sign that you have neither understood the theory nor the
problem which it was intended to solve.”― Karl Popper

3. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I3
Spherical Monolith Architecture in Vacuum
Pros:
1. Simple to develop
2. Simple to deploy
3. Simple to scale
4. Simple to test
Cons:
1. Huge codebase
2. Need to deploy whole app
3. Loyalty to technology stack
chosen once
Don't put all your
eggs in one basket

4. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I4
Spherical Microservice Architecture in Vacuum
Cons:
1. Relationships could be tricky
2. Testing is more difficult
3. Complex deployment
4. Increased resource
consumption
Pros:
1. Easy to develop and
understand
2. Independent developing,
testing and deployment
3. Easy to scale
4. Fault tolerant
5. Easy to experiment with
technology stack

5. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I5
Theoretical Monolith to Microservices Migration
1. Split up monolith by functionality
2. Find dependencies
3. Make each part as a service
4. ???
5. PROFIT

6. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I6
Funny Practice
“It doesn't matter how beautiful your theory is, it doesn't matter how
smart you are. If it doesn't agree with experiment, it's wrong.”
― Richard P. Feynman

7. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I7
Real Life Monolith architecture
1. Your app knows how the T-Rex looks like
2. If it’s working do not touch it
3. If you know how to do better look at p.2
4. Monolith is huge and sometimes you think
even sales guys pushed some code there
5. Lucky you if test coverage exists

8. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I8
Real Life Microservice architecture
1. You always depend from service which not released yet
2. Microservices are often macroservices
3. Microservices temporary depend from monolith
4. I’m joking not temporary
5. Regression testing is a significant challenge
Monolith
DB service
Feature Service A
Feature Service B
Feature Service C

9. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I9
Migration to microservices in practice
1. Impossible to migrate by one shot
2. Microservice could become a new monolith
3. Two pizzas is not enough to feed your team
4. There is no place for refactoring
5. Dependencies Dependencies Dependencies

10. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I10
w
How to deal with it?
“A man who carries a cat by the tail learns something he can learn in no
other way.” ― Mark Twain

11. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I11
Useful tips and tricks
1. There is no silver bullet
2. Think about cross team communication
3. Think about shared resources
4. Think about regression testing
5. Think about integration in existing
infrastructure
6. Think about service size
7. Stay calm it’s real world, dude

12. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I12
Useful links and resources
1. Igor Vahromeev: Archmage presentation on Opower Open Doors
2. Dropwizzard framework http://www.dropwizard.io/
3. Apache Zookeeper https://zookeeper.apache.org/
4. Any book of system analysis. Don’t you think microservice is a
brand new idea?
5. Choose your own ninja way

13. O P O W E R C O N F I D E N T I A L D O N O T D I S T R I13
Questions?