Who slowed us down? I want my monolith back!

Talk given at microXchg 2017
https://www.youtube.com/watch?v=ZNLKvWRDgto

Transcript

1. Who slowed us down? I want my monolith back! Markus Krogemann markus@qixxit.de @mkrogemann
2. That's me on twitter @mkrogemann
4. Why this talk?
5. An anecdote from product camp Berlin 2016
6. Startup with established product and growing customer base Business based on a monolithic application Occasional crashes and overload issues CTO hired to address the problems
7. Microservice architure style Event Sourcing Kubernetes Small team(s), spread across (few) time zones What could possibly go wrong?
8. “Ever since we started with the new architecture, it has taken us much longer to get any feature out of the door.” “No story ts into our two-week sprints anymore.”
9. What could be the problem here?
10. Premature adoption of Microservices Martin Fowler — MicroservicePremium "So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services."
14. Mary Poppendiek at GOTO Berlin 2016 "... so you have to gure out how to migrate. ... if you take that company's solution, it's their solution to their problem. ... at amazon, the service orientated architecture took ve or six years. ... every one of those things took that long to go from an idea to actually developed at scale. ... and if you think you can do it in 5 months, you're crazy. Ain't gonna happen."
15. Net ix stack rules!
16. So what can we do?
17. Do good monoliths exist?
20. Functional, dynamically typed language Immutable data structures, Pattern matching Implements the Actor Model Fault tolerant, Distributed runtime system Hot code swapping, no need to stop the system The AXD301 achieved 99.9999999% reliability
21. So how did they do this?
22. Functional Programming with immutable data structures Actor Model: Isolation & Share nothing architecture Actor Model: Communication only through message passing Let it crash: Fault tolerance through supervision trees Good skills? Probably!
23. How can we bene t from this today?
24. Enter Elixir Umbrella projects $ mix new abc --umbrella $ cd abc/apps $ mix new a $ mix new b --sup $ mix new c --sup Deployments: All, some or one app per node Location transparency: Works in one node → Will also work in distributed mode Supervision trees often represent bounded contexts
25. Wrapping up
26. Dev teams are quick to adopt Microservice style... ...but required capabilities may not be in place. And they are scarce, not easy or quick to build up. Team skills will outweigh architectural style! Consider Erlang and Elixir :-)
27. Questions?
28. References Martin Fowler • MicroservicePremium GOTO 2016 • The Future of Software Engineering • Mary Poppendieck The True story about why we invented Erlang and A few things you don’t want to tell your Manager • Mike Williams AXD 301 • Ericsson Review No. 1, 1998 Erlang's nine nines Joe Armstrong's PhD thesis on the creation of Erlang José Valim • Elixir in times of microservices