Microservices architecture pitfalls
?
13 likes?3,011 views
The document discusses some of the challenges and pitfalls of microservices architecture, including architectural, operational, and organizational issues. Architecturally, distributed systems are difficult to manage due to issues like lack of global clock, independent failures, and network latency and reliability. Operationally, deploying and upgrading many independent services requires extensive automation, monitoring, and incident response systems. Organizationally, acquiring distributed skills and managing loose coupling between teams presents challenges for companies adopting microservices.
Microservices architecture pitfalls
- 1. Microservices architecture pitfalls WJUG meeting ??march 2015 Mateusz Gajewski? Solutions Architect @ Allegro Twitter: @wendigo
- 2. About me given: I started working in Allegro in 2009 (5 mln AO, 50 devs) when: Allegro reached 40 mln AO, 400 devs then: I am Solutions Architect 2
- 3. Agenda ? Microservices, microservices, microservices! ;) ? Some challenges & pitfalls: ? Architectural, ? Operational, ? Organisational 3
- 4. Let¡¯s go back in time to year 2012 4
- 5. 5
- 6. Back then we wanted ? agile development, ? scalability, ? resilience, ? lower costs, ? hybrid cloud. 6
- 7. Basically SOA + JVM was an answer! 7
- 8. But our system was too BIG & too complex to do it with existing enterprise solutions 8
- 10. we¡¯ve started to do *buzzword* 10
- 11. And now, literally everyone is doing microservices!!?? 11
- 12. Microservices by Fowler 12 Lots of *buzzwords* http://martinfowler.com/articles/microservices.html
- 14. microservices architecture ¡Ö ?ne-grained SOA ? enterprise (commercial) sh*t ¡Ö highly scalable, distributed system 14
- 15. Distributed systems ? concurrency of components, ? independent failure of components, ? lack of a global clock. 15
- 16. The Eight Fallacies of Distributed Computing 16 by Peter Deutsch 1991
- 17. #1: Network is reliable 17
- 18. #2: Latency is zero 18
- 19. #3: Bandwidth is in?nite 19
- 20. #4: Network is secure 20
- 21. #5: Topology doesn¡¯t change 21
- 22. #6: There is one administrator 22
- 23. #7: Transport cost is zero 23
- 24. #8: Network is homogeneous 24
- 25. distributed systems are hard ¡ú? microservices are much harder ;) 25
- 26. What have we learnt? 26
- 28. CAP is not just theorem it¡¯s reality against us 28
- 29. bye, bye ACID semantics 29
- 30. Long live BASE guarantees! Basically Available, Soft state, Eventually consistent 30
- 32. it¡¯s far cheaper to do compensation 32
- 34. you need idempotent APIs and events sinks 34
- 36. So we¡¯ve built Hermes a.k.a circulatory system 36
- 37. network can be congested! 37
- 38. REST+JSON on top of HTTP/1.1? is ?ne 38
- 39. REST+JSON on top of HTTP/2.0? with TLS is ?ner 39
- 40. we don¡¯t rely on network anymore net splits in public clouds happens everytime! 40
- 42. 42
- 43. powerful tandem 43 + Reactive programming Circuit breaker pattern
- 44. you need to support non- native old services, clients and systems 44
- 45. 45
- 48. creating new service should be instant! 48
- 49. 49
- 50. automation? with gradle & axions 50
- 51. 51
- 52. so now we¡¯ve got over 1800 repositories grouped under 250 projects 52
- 53. all with CI, code quality checks, security checks, integrated with sonar & artefact repository 53
- 54. but what with? services upgrades? 54
- 55. we¡¯ve initially built our own service stack? ¡ and it was ok - for a while 55
- 56. now we are extending spring-boot? with so called andamio project 56
- 57. rapid deployments integrated with CI/CD environment and canary tests are must-have 57
- 58. war ?les? ? scp + puppet ? golden images ? docker (immutable images) ? 58
- 59. frequency of changes ¡ú ? automated? monitoring, logging ? & operational insights 59
- 61. Monitoring As A Service + SLA Monitoring + 61
- 62. we need to build real-time anomaly detection soon 62
- 64. strategic DDD is good for splitting up monolith 64
- 65. but leave tactical DDD up to teams 65
- 68. you build it - you run it 68
- 70. please don¡¯t audit me 70
- 72. So after two years¡ 72
- 73. 73
- 75. 75
- 76. 76
- 77. 77
- 78. Thanks! Any questions? Visit our blog: allegrotech.io Follow us on twitter: @allegrotechblog Check our OSS projects: github.com/allegro And meetup group: meetup.com/allegrotech 78