Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Fest 2018. Леонид Молотиевский. Как выжить с микросервисами


Published on

В данном докладе я хочу поделиться опытом, который мы получили, разрабатывая огромную распределенную систему с нуля. Наша команда прошла долгий путь от монолита к микро-сервисной архитектуре. Результатом этого опыта стал как анализ правильных решений, спасших наш проект, так и анализ ошибок, которые его чуть не потопили.

Published in: Education
  • Be the first to comment

  • Be the first to like this

.NET Fest 2018. Леонид Молотиевский. Как выжить с микросервисами

  1. 1. Surviving with microservices by Leonid Molotiievskyi Application architect, SoftServe @lmolotii
  2. 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. 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. 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. 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. 6. Staring the project Imagine you were asked to start enterprise level project from scratch...
  7. 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. 8. Growing What was our goals?
  9. 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. 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. 11. Right decisions What technology decisions helped us to survive
  12. 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. 13 Why full stack is bad idea
  14. 14. 14 Context driven development Structure management Calculation management Order management Reporting User management User settings Computer based Notes
  15. 15. Operations How we automate development process
  16. 16. 16 Trash out Jenkins (2016)
  17. 17. 17 GitLab CI
  18. 18. 18 CD pipelines
  19. 19. Monitoring What infrastructure metrics keep silence about
  20. 20. 20 How is it going?
  21. 21. 21 What’s about application level metrics?
  22. 22. IS IT ENOUGH?
  23. 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. 24. Anti-patterns and pitfalls What costs us a lot
  25. 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. 26 Anti-pattern: hire super hero
  27. 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. 28 Anti-pattern: split monolith starting from the code
  29. 29. 29 Anti-pattern: microservices = freedom
  30. 30. 30 Pitfall: extract microservice now Does your infrastructure ready to have one more service?
  31. 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. 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. 33 Pitfall: tell nothing to business about microservices architecture
  34. 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. 35 Follow me @lmolotii on Q&A
  36. 36. THANKS FOR WATCH !!!