Breaking the monolith
1 like378 views
The document discusses the concept of monolithic architecture in software development and the potential benefits of breaking it into microservices, emphasizing maintainability, reduced complexity, and faster release cycles. It highlights key steps for successful transformation, including domain separation, interface coherence, and automation in deployment processes. Additionally, it addresses the challenges of microservices and suggests Kubernetes as a solution for managing container-based architectures.
Breaking the monolith
- 1. Breaking the monolith Jacopo Nardiello Founder & DevOps Engineer @jnardiello
- 2. What is a monolith anyway? ...functionally distinguishable aspects are all interwoven, rather than containing architecturally separate components...
- 3. One codebase to rule them all, Do you have to break the monolith? It depends.
- 4. Famous “monoliths” 1. Amazon split to services when it had roughly ~8000 employees 2. Google search is still a monolith 3. Github is a monolithic rails app 4. The linux kernel anyone? Monolith itself isn’t necessarily a bad thing. How your code is engineered is what truly matters
- 5. Should you break the monolith in first place? Splitting your code into services or micro-services is all about Making your code more maintainable, reduce coupling and regression bugs Higher throughput Faster release cycle where you can release single services separately
- 6. Ops Complexity is the pitfall Alright, before even starting...
- 7. DEPLOY verb· 1. To prepare and arrange (usually military unit or units) for use.
- 9. Complexity is the pitfall Automation is key
- 10. How do you break the monolith? What does it mean and what are the consequences
- 11. The code, splitting into (micro?)services 1. Split your monolith into different Domains. Domains are good candidates to be separate services. 2. Pay attention to have a ubiquitous dictionary between services. 3. Define coherent interfaces across services and domains.
- 12. The bare minimum (before you start) Acceptance tests
- 13. Ensure consistency as dishomogeneous services grow and evolve Automate your local environment OR
- 14. Automate how you ship the code (a.k.a. Continuous Integration) Make sure to automate all your builds and deployment processes
- 15. NOTE Note that CI/CD is NOT just running the tests (despite what some vendors will tell you)
- 16. Micro-services architecture Keep in mind: Single Responsibility Principle One operational unit per service
- 17. The architecture, VMs /1
- 18. The architecture, containers /2
- 19. Containers, we got the cookies! 1. Abstract your execution environment, any node can do any job. 2. More efficient infrastructure 3. They will shine in large orgs 4. Scale lightning-fast to accommodate spikes 5. Fully atomical deployments 6. ...
- 20. Containers, What’s not so good 1. What is running where? (Shared volumes? DNS resolution and load balancing? Networking across containers?) 2. Higher infrastructural complexity 3. Your application must be designed to be dynamic and reactive 4. Aggregated Logging? Monitoring? Autoscaling?
- 21. Kubernetes to the rescue Kubernetes is the class-standard system to run your containers-based architecture. 1. schedule and execute 2. expose an API to manage your containers 3. networking and storage 4. help with monitoring and logging
- 22. There’s a lot more beyond the tools aka what (most) consultants will not tell you. It’s a cultural change, conway’s law
- 23. Want to understand Kubernetes? KubePrimer workshop http://kubeprimer.sighup.io
- 24. That’s all! Questions? Jacopo Nardiello Founder & DevOps Engineer @jnardiello