Going Reactive in the Land of No
0 likes395 views
The document discusses the transition of a health and wellness client from a monolithic architecture to a reactive microservices architecture, overcoming significant technical and organizational challenges. Key accomplishments included enhanced velocity in core software development, production readiness by late 2015, and improvements in application stability and monitoring. The company now competes effectively in the market with a rebuilt platform that fosters innovation and growth.
Going Reactive in the Land of No
- 1. Going Reactive in the Land of No Sean Walsh | Field CTO (@SeanWalshEsq)
- 2. reactivemanifesto.org Reactive: the architecture for modern, scalable applications
- 3. Forces
- 4. • Exploding user bases • Cheaper and more available hardware • IoT • Science
- 5. Something was standing between my large health and wellness client and their customers. That something was about to put them out of business.
- 6. A Monolith • Expensive to maintain, lack of in-house capability due to repeated outsourcing • Non distributed • Dependency on a custom and very expensive Oracle installation • Ops heavy rather than developer heavy • Effectively…
- 7. A Big Ball of Mud
- 8. Late 2014 - A false start •Not “all in” •Large team engaged anyway •Missing real requirements churn…
- 10. Early 2015
- 11. Let’s start over but this time we do it wrong different, we do it my way! - That One Guy Same leadership churn churn churn… Sr Director No
- 12. Spring Boot Groovy Gpars Actors Gradle SBT Maven Java Scala Akka AnsibleGroovy
- 14. Department of Redundancy Department population Sean and Nicholas a final attempt at purity - one sprint to prove it
- 16. Finally the Light • Full company engagement (even Oprah!) • New, modern CTO working in close partnership with my team and others • Real requirements and mandatory Ops support • Good news and bad news
- 17. No No Noooo • Still risk adverse, CQRS and Event Sourcing sounded scary so NO • Ops was now devops and guess that their favorite word was? • NO clustering, NO Cassandra, NO Kafka
- 18. • And then were three - Sayre joins the team • They let us use Play/Akka/Cassandra • We had customers! • Core software was all rebuilt from the ground up
- 19. Accomplishments • Unheard of velocity in “core” - Play - simplicity • Core fully production ready by November of 2015 • 12 microservices - billion+ transactions per day capable • Modern aggregated monitoring and logging provided incredibly quick root cause analysis • Never before seen resilience and application stability
- 20. A Bit too much Compromise • Stateless applications easier to reason about at first but cost plenty in the long run • Perceived investment and value in Cassandra • Final waterfall caused some costly non-DDD design • Devops spaghetti in the form of Ansible scripts • Poor mans CQRS and Event Sourcing • And oh man no Kafka and now look…
- 21. THIS
- 22. What we really needed
- 23. Other Lessons Learned • Legacy, immature mobile, other contaminating feeds • Continuous delivery and deployment but tricky due to service coupling • Migration not as an afterthought • Oh and don’t ever give a developer both a load test script and access to production
- 24. Strive for Yes • Don’t roll your own • Need for clustered middleware • More emphasis on application tier • Need for durable pub/sub • Simpler devops abstractions - orchestration - dcos • Less code invasive monitoring • Fast data pipeline for anti-corruption
- 25. 1) The company is now on the same playing field as the disruptors 2) What was a monolith, now a platform for creative new product ideas 3) Thanks to the above and a famous 40 Lb weight loss the stock is starting to rebound
- 26. Build modern systems for the modern world www.lightbend.com