1. Surviving with microservices
by Leonid Molotiievskyi
Application architect, SoftServe
@lmolotii

2. 2
About me
• Hands-on software architect and technological consultant
• Good at splitting a monolith to microservices
• Built a huge enterprise financial solution from scratch
• Technical guy who believes that right people decisions are
more important than technological ones
• Speaker and mentor

3. 3
Spoilers about what we are going to talk
Agenda
Starting the project
What you can get from the begging
Growing
How did project grow from
20 to 80 people?

4. 4
First right steps
Description of what was done right
from technical standpoint.
Operations
Why do we moved from Jenkins to the
GitLab and what benefits we got from
it.
Monitoring
What’s wrong with the
infrastructure monitoring?
Conway’s law
How this simple law impacts entire
project

5. 5
Q&A
Pitfalls and anti patterns
What we did in the wrong way, and
what are our results.
Lessons learned
What’s worth to remember from this
talk

6. Staring the project
Imagine you were asked to start enterprise level project from scratch...

7. 7
Project setup
Task:
You got about 280 pages of screenshots to develop financial
modeling system from scratch having 20 people from the
begging of the project.
Initial technology stack:
• Jenkins (CI)
• .NET Framework 4.5.1
• ASP .NET MVC
• Angular JS
• TFS
• On premise VMs for hosting

8. Growing
What was our goals?

9. 9
How do you manage to grow having…
• Achieve ~500SP velocity
• Deliver 30 features per iteration
• Have ability to scale (more people, more velocity)
• Manage operation complexity
• Having requirements changes on the way

10. 10
How did we manage it?
Microservices as
a technical solution
We decided to extract bounded
contexts and distribute them between
different teams
Technical debt management
We spend about 20-50% dev time,
continuously refactoring and dev tools
Backlog development
Technical onboarding
Increase efficiency of the team by
building knowledge models needed
specifically for the project
Invest into infrastructure
CI/CD pipelines, automation of
software delivery, integration testing,
environment setup
We started to distribute backlog based
on features and bounded contexts

11. Right decisions
What technology decisions helped us to survive

12. 12
Split backend and frontend development
• Split backend and fronted development into
separate repositories
• Trash out ASP .NET MVC and use pure Web API
2.0 and SPA
• Gitlab as scv system (who knew about it in 2015)

13. 13
Why full stack is bad idea

14. 14
Context driven development
Structure
management
Calculation
management
Order
management
Reporting
User
management
User settings
Computer
based
Notes

15. Operations
How we automate development process

16. 16
Trash out Jenkins (2016)

17. 17
GitLab CI

18. 18
CD pipelines

19. Monitoring
What infrastructure metrics keep silence about

20. 20
How is it going?

21. 21
What’s about application level metrics?

22. IS IT ENOUGH?

23. 23
Conway’s law and microservices
“Organizations which design systems ...
are constrained to produce designs
which are copies of the
communication structures of these
organizations.”

24. Anti-patterns and pitfalls
What costs us a lot

25. 25
Engineering pitfalls & Anti-patterns
• Antipattern is something that
seems like a good idea when you
begin, but leads you into trouble.
• Pitfall – never a good idea even
from the start.

26. 26
Anti-pattern: hire super hero

27. 27
Pitfall: hire more and quick
• From the initial hiring set of 20 people, only 2 survived.
• In 2.5 years from the begging about 60 technical people left
the project.

28. 28
Anti-pattern: split monolith
starting from the code

29. 29
Anti-pattern: microservices = freedom

30. 30
Pitfall: extract microservice now
Does your infrastructure ready to have one more service?

31. 31
Anti-pattern: split your team
on QA, BA,FE,BE
• Backlog distribution between FE and BE
• Resolving integration/contract issues
between FE/BE
• Collaboration and good relations
between teams

32. 32
Anti-pattern: business prioritization only
• Design mistakes and reimplementation of
existing features
• Chain of dependencies between stories
with high priority
• Interdependencies between teams
• One epic per team for example “security”

33. 33
Pitfall: tell nothing to business about
microservices architecture

34. 34
Lessons learned
• Architecture worth nothing if you have no
smart people to implement it
• Prefer boring technologies
• Microservice complexity has a huge
organization and infrastructure complexity
• If you cannot structure monolith application
– you will fail with microservices
• Superheroes won’t help you to survive

35. 35
Follow me @lmolotii on
Q&A

36. THANKS FOR WATCH !!!