Download as PDF, PPTX
Uploaded byJacopo Nardiello
Breaking the monolith
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.
More Related Content
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Breaking the monolith
- 1. Breaking the monolith JacopoNardiello Founder & DevOps Engineer @jnardiello
- 2. What is amonolith anyway? ...functionally distinguishable aspects are all interwoven, rather than containing architecturally separate components...
- 3. One codebase torule them all, Do you have to break the monolith? It depends.
- 4. Famous “monoliths” 1. Amazonsplit 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 breakthe 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 isthe pitfall Alright, before even starting...
- 7. DEPLOY verb· 1. To prepareand arrange (usually military unit or units) for use.
- 8.
- 9. Complexity is thepitfall Automation is key
- 10. How do youbreak the monolith? What does it mean and what are the consequences
- 11. The code, splittinginto (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 asdishomogeneous services grow and evolve Automate your local environment OR
- 14. Automate how youship the code (a.k.a. Continuous Integration) Make sure to automate all your builds and deployment processes
- 15. NOTE Note that CI/CDis NOT just running the tests (despite what some vendors will tell you)
- 16. Micro-services architecture Keep inmind: Single Responsibility Principle One operational unit per service
- 17.
- 18.
- 19. Containers, we gotthe 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 notso 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 therescue 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 lotmore beyond the tools aka what (most) consultants will not tell you. It’s a cultural change, conway’s law
- 23. Want to understandKubernetes? KubePrimer workshop http://kubeprimer.sighup.io
- 24. That’s all! Questions? Jacopo Nardiello Founder& DevOps Engineer @jnardiello