From Monolithic to Microservices in 45 Minutes
•Download as PPTX, PDF•
6 likes•3,373 views
This document discusses moving from monolithic applications to microservices architectures. It begins by defining monolithic applications and how they can become difficult to scale. It then introduces the concepts of decoupling applications and microservices as an architecture where independent processes communicate via APIs. Some benefits discussed are improved scalability, release cycles, and fault tolerance. The document provides examples of microservices for tasks like text search and recommendations. It concludes by recommending starting with a monolithic approach and refactoring to microservices as needs require for scalability.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to From Monolithic to Microservices in 45 Minutes
Similar to From Monolithic to Microservices in 45 Minutes (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
From Monolithic to Microservices in 45 Minutes
- 2. Monolithic to Microservices in 45 min
- 6. "Amonolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function"
- 7. 7
- 8. 8
- 9. 9 Monolithic Applications • It’s very easy to start building applications that become Monolithic – Projects start small – If successful they will grow Super Cool Application UI Component Business Logic Persistency Layer
- 10. Monolithic Applications Super Cool Application UI Component Business Logic Persistency Layer
- 11. Monolithic Applications Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance
- 13. "Decoupled architecture is a framework for complex work that allows components to remain completely autonomous and unaware of each other"
- 14. Decoupling your applications Super Cool Application UI Component Business Logic Persistency Layer
- 15. 15 Reasons to Decouple • The different components of your application have different: – Density – Release and Development cycles – Requirements • Functional • Architecture
- 16. Decoupling your applications UI Layer Business Service Layer Scalable Data Layer
- 17. … for scalability UI Layer Business Service Layer Scalable Data Layer UI Layer UI Layer UI Layer UI Layer
- 18. … for different integrations Mobile UI Business Service Layer Scalable Data Layer Web UI Mobile UI Web UI Specific UI
- 19. … for function segregation
- 21. Scale Axis Y-axis: Functional Decomposition X-axis: Functional Duplication Z-axis: Data Partitioning
- 22. Microservices
- 23. "Microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs"
- 24. Application Stack UI Layer Business Service Layer Scalable Data Layer
- 25. Microservices
- 27. Microservices
- 28. Microservices – Service Registry Service Registry Service Registry allows client side discovery of existing and available services
- 29. Host OS Virtual OS Virtual OS Virtual OS Microservices – Virtual Machines Virtual Machines are a familiar topic, it is the backbone of many PaaS and IaaS services out there
- 30. Host OS System Kernel Microservices – Containers Containers are a typical approach to deploy and maintain microservices because they're highly scalable and isolated.
- 31. Microservices – Containers Host OS System Kernel Host OS System Kernel Host OS System Kernel REHL v7 Windows 2008 Web Search v1 Web Search v2
- 33. "I'm getting dizzy" Norberto Leite – 2015/10/06
- 35. 35 MongoDB - Containerized • Benefit from MongoDB Scalability – Replica Sets for HA – Sharding for Horizontal Scalability But Keep In Mind: • Sharding requires knowing well your data • Replication is much more than just spinning a few more instances! Ops Manager is Important for these environments!
- 36. Use Cases
- 37. Otto Use Case Batch analytics Layer Frontend – System Profile Service Customer Service Session Service Persona Service Shared Nothing architecture Clear Isolation of services Hundreds of Virtual Instances
- 38. How to do it
- 39. 39 Best Approach • Start monolithic – There's nothing wrong with starting small – Your team will be small enough so they will know all the code • Start Decoupling when you grow – In number of features and functionality – In number of teams working side by side • Go Microservices – When you become Netflix!
- 40. 40 When do Microservices Fail • Contracts – It's important to agree on the interfaces – Developer Philosophical Beliefs • Service Separation – Granularity – Dependencies • Maintenance – Devops and Release Manager Burden – Monitoring – Orchestration "…language-agnostic APIs" "completely autonomous" "composed of small, independent processes"
- 41. 41 Best Approach - Data • Replication from Day 0 – No excuses to have a single node in production • Shard when you grow – Functionally – By Volume – Regionaly • Ops Manager to the rescue – Makes you life easier!
- 42. Now that you understand it… I hope
Editor's Notes
- To understand scalability there are a few things that one should take in consideration: The different components of your application do not scale on the same order of magnitude There are different dependencies that have different scaling needs You need to understand where your bottlenecks are You need to understand what architecture design changes can impact the overall performance of the system This book "the art of scalability" has a quite nice visualization model for the scalability approaches
- Babel tower is one of the best analogies between an molothic application and what engineers have been trying to built in the past.
- And it's most recent version: Burj Al Khalifa
- We start small with given a quick and dirty web framework / web application that is self contained. It can be, and generally is, very composable where I can introduce some external libraries and components that make it extensible. But at the end of the day we need to run this has a block In terms of deployment Development practices Release cycle And scalability
- So this seems to work, right ? What's the problem with this approach ? This is called brute force scalability The same recipe for all components of your application Carry a lot of dead weight Same approach for both the particular functionality And what about data? Does you persistency layer scales in the same order of magnitude has your business logic? Generally they don't.
- To start decomposing your application you should start to it from a functional perspective Offload your front-end Decouple your persistency layer Segregate your business logic
- Good examples of these acthictire design have been made available by
- Good examples of these acthictire design have been made available by
- So let's get back to our decoupled application. We have the different layers of service. But these can be further decomposed into single purpose services
- It's based on single responsibility principle http://www.objectmentor.com/resources/articles/srp.pdf
- It's based on single responsibility principle http://www.objectmentor.com/resources/articles/srp.pdf
- It's based on single responsibility principle http://www.objectmentor.com/resources/articles/srp.pdf
- Each instance of a service exposes a remote API such as HTTP/REST, or Thrift etc. at a particular location (host and port) The number of services instances and their locations changes dynamically. Virtual machines and containers are usually assigned a dynamic IP address. An EC2 Autoscaling Group, for example, adjusts the number of instances based on load. Consul Etcd Zookeaper
- Although VM's should be a familiar topic around, where the objective is nto to have multiple stacks running per VM but having a single process running on top of a VM. This allows a clear separation of concepts and makes the system more scalable from the functional perspective.
- LXD canonical
- We can have different OS, different baseline server resources, different distribution of container images but the underlying configuration is the same no mater what.
- And if sale this we might end with another level of complexity. There are several different technologies that handle the clustering part and many other aspects of the deployment of these complex architectures.
- Your container images should have an agent installed so they can be properly configured and managed from ops manager.
- There is no reason why to need to start from day one with Microservices if the team is you and a couple of friends. Microservices require serveral layers of isolation and segregation that demand significant levels of independency and management You don’t just scale services, you end up scalling your teams too. Single purpose segregation principle One verb isolation
- There are plenty of detailed examples out in the web of failed projects using Microservices. And the most common reasons very common: - Service Contract Disagreements