Who slowed us down? I want my monolith back! LP version

Talk given at GOTO Night Berlin, April 27, 2017
https://www.meetup.com/GOTO-Nights-Berlin/events/238490079/

Transcript

1. Who slowed us down? I want my monolith back! Markus Krogemann markus@qixxit.de @mkrogemann
2. Agenda 30 mins Presentation Open discussion Slides will be made available Including references
3. That's me on twitter @mkrogemann
5. Why this talk?
6. An anecdote from product camp Berlin 2016
8. 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
9. Microservice architure style Event Sourcing Kubernetes Small team, located in two o ces in Europe What could possibly go wrong?
10. “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.”
11. What could be the problem here?
12. 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."
16. 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."
17. Net ix stack rules!
18. Current Job o er #1 You will be working in a small team of top developers, building features and microservices for our online platform. We are in an early stage of the development Several years of experience working with JS/Node.js, PHP, or Python How about experience in building distributed systems?
19. Current Job o er #2 Small team of 5 Devs, looking for one more Agile software development — SCRUM Docker — Kubernetes — Microservices Three monitors for every developer! Do I want or need three monitors to build the system?
20. So what does all this mean for our profession? We have a new silver bullet — This time it's Microservices Managers happily pick up the good news — expect quicker development, delivery and value creation Many organisations jump on the train — often ill prepared And by introducing these boundaries so early, teams may loose TODO... I fear that this is as wrong and harmful as any silver bullet previously seen in IT
21. So what can we do? Silver bullets — maybe we'll always have that — part of human nature? Keep talking about it, sharing what we know with co-workers and management — such as here today and every day at our work place. Maybe we can still get more value from the monolithic approach.
22. Do good monoliths exist?
25. 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
26. So how did they do this?
27. 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?
28. How can we bene t from this today?
29. 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
30. Supervision trees
31. All apps on all nodes
32. Subsets of apps per node
33. So what does the Umbrella architecture bring to the table?
34. A system structured into equal-shaped applications (services) Microservice style communication (messaging) and con guration (separate databases) A single repository and monolithic deployment option, plus... ...any combination of apps can be deployed per node If and when the need arises: Separate along apps and supervisors
35. Wrapping up
36. Organisations today quickly adopt Microservices, but keep in mind: Deployment is complex and you create hard to change boundaries. Testing the system as a whole is di cult. Team skills will outweigh architectural style! Consider Erlang and Elixir :-)
37. Discussion
38. 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
39. References José Valim • Elixir in times of microservices Mashooq Badar • PREMATURE MICROSERVICES Fred Hébert • Learn You Some Erlang for Great Good! Eric Entin • pg2 and You: Getting Distributed with Elixir Erlang: The Movie