Dismantling the Monolith: Scaling with Microservices
•Descargar como PPTX, PDF•
1 recomendación•1,060 vistas
An intro to Microservices given at a Tech Talk at One Kings Lane
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a Dismantling the Monolith: Scaling with Microservices
Similar a Dismantling the Monolith: Scaling with Microservices (20)
Último
Último (20)
Dismantling the Monolith: Scaling with Microservices
- 1. { Dismantling the Monolith Scaling with Microservices Jenny Kim August 28, 2014
- 2. Schedule September 11: Refactoring Patterns by Erich Lin September 25: Cleaning with SPEED! by Lawrence and Diana October 9: Riveting Topic by YOU! Email: jennykim@onekingslane.com or abahouth@onekingslane.com Level Up Tech Talks Confluence Wiki https://confluence.newokl.com/x/DQG8 Nominate a topic and a speaker!
- 3. 1. Microservices in a nutshell 2. The problem with monoliths 3. The Microservice Way 4. Iterating to Microservices 5. Questions / Discussion Agenda
- 4. Microservices are an architectural approach to developing a single application as a suite of small services. • Each service runs in its own process • Communication via lightweight mechanisms • Service -> single bounded context • Loosely-coupled and independently deployable • Minimal central management, technology-agnostic • Polyglot persistence: each service with its own data store Microservices in a Nutshell
- 5. The Problem with Monoliths
- 6. The Problem with Monoliths
- 7. The Problem with Monoliths
- 8. The Problem with Monoliths
- 9. The Problem with Monoliths Domain-driven design Value Objects Concerns Entities Policy Object Decorators Data Transfer Object
- 10. New features and changes become increasingly difficult to: 1. Accurately Scope 2. Build and integrate in an efficient and safe manner The Problem with Monoliths
- 11. Testing Monoliths • Test suites grow long, slow, flaky • Quality control and root cause analysis harder as many features are implemented at the same time • Increasing reliance on manual regression testing to ensure no new bugs introduced • Longer testing and deployment cycles not amenable to CI or CD The Problem with Monoliths
- 12. Scaling Monoliths 1. Horizontal scaling of web and app servers 2. Database replication or sharding The Problem with Monoliths
- 13. The Problem with Monoliths Monolithic Apps require scaling the entire monolith What if one component requires much more resources than the others?
- 14. The Problem with Monoliths Gilt • Members-only flash sales site • Luxury brands at up to 70% off • Sales launch at noon EST • Members can reserve physical units for a limited time, by adding to cart
- 15. The Problem with Monoliths
- 16. The Problem with Monoliths
- 17. April 8, 2009: “The Louboutin Incident” The Problem with Monoliths
- 18. The Problem with Monoliths Sales Volume by $/hour at peak by day
- 19. The Problem with Monoliths
- 20. The Problem with Monoliths Gilt Transaction Sequence Modules
- 22. Bounded Contexts Autonomous components, with their own domain models and specific responsibilities. The Monolithic Way
- 23. The Monolithic Way Keep It Small. Keep It Simple. Services should be small enough for any developer to easily understand all aspects of the service, and where rewriting would be straightforward.
- 24. The Monolithic Way Communication Not Coupling Interaction with each other through interfaces (APIs), or via messaging broker. (And no, sharing data models with ActiveResource does not count.) OR
- 25. The Monolithic Way Decentralized Governance Flexibility and freedom to write and build each service in any language or technology.
- 26. What’s the difference between Microservices and SOA? The Microservice Way Microservices == SOA for Hipsters?
- 27. Independent Deployability and Scalability 1. Services must be deployed on-demand, independently, preferably automatically. (added perk: zero-downtime?) 2. Services can be distributed and scaled independently, as individual resource-needs dictate. The Microservice Way
- 28. Design for Failure 1. Distributed systems mean designing for fault tolerance. 2. Any service could fail at any time! (server failure, network unavailability, etc) 3. Detect failures quickly and if possible, automatically restore services that go offline. 4. Real-time monitoring, insight and proactive alerts on network traffic, monitoring of service request latency. The Microservice Way
- 29. Decentralized Data Management The Microservice Way
- 31. Soundcloud Iterating to Microservices Source “Building Products at SoundCloud —Part I: Dealing with the Monolith” https://developers.soundcloud.com/blog/building-products-at-soundcloud-part- 1-dealing-with-the-monolith
- 32. Rule 1: Stop the Monolithic Growth Iterating to Microservices
- 33. Rule 2: Every existing feature that requires significant rework will be removed and rewritten as a micro service. Iterating to Microservices
- 34. Rule 3: Microservices should only communicate via well-defined interfaces. Iterating to Microservices
- 35. Rule 4: Use coarse-grained, loosely- coupled services. Iterating to Microservices
- 40. How you implement microservices depends on your context! Balancing and rebalancing is the key. Iterating to Microservices
- 41. 1. Monolithic Problems: complexity! coupling! testability! scalability! 2. Microservices: small services, independent deployments, decentralized governance 3. Iterate to success! Summary
Notas del editor
- The idea of Microservices has been gaining a lot of attention in the industry lately. Companies like Twitter, Netflix, and LinkedIn have very publicly shared the number of benefits they’ve reaped by moving from a monolithic app to a Microservices approach. What do we mean by the term microservice. In short: The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around a bounded-context (which we'll revisit later) and are loosely-coupled and independently deployable. There's a bare mininum of centralized management of these services, and they can even be written in different programming languages. Also, ideally, microservices bring their data with them, using their own data storage technologies.
- So when you hear the term monolithic app, most likely you're envisioning something that resembles this: a single app, composed of a user-interface, server-side logic layer, and a single database
- But really, monoliths don't necessary need to be a single application, and actually in many cases they're composed of several applications, libraries, or even so-called services which are bundled into a single executable and deployed together. This is an example of what a monolithic generic storefront-app might look like in Java, and despite the logical modularization of the various components for Catalog, Orders, and Customers, the app is still built as a single WAR file and backed on a single database.
- In both cases, we start with what was a modestly-sized application that's easy to understand, test, and deploy, and over time what we often end up with is a system that grows to be massive, where even the subcomponents become complex, large and tightly-coupled to the other components in the system.
- And we've come up with entire disciplines to help us manage the complexity of building big systems. Things like: - domain-driven design - entities - value objects - concerns All these programming constructs that we invent and employ in order to make some logical sense out of these big monolithic systems
- But inevitably, the mental overhead of keeping these modules separate gets huge, and we find these systems getting to a point of complexity where things are too difficult to change. New features or changes to a component become increasingly hard to: accurately scope the effort for (need to build in time to investigate, familiarize with legacy components) build and integrate in an efficient and safe manner. There's just inherently more risk in making a change to a large system where there are a lot of complex dependencies and side-effects are hard to predict.
- With monolithic systems, testing also becomes a problem, as test suites grow long, slow, and flakey. Quality control and root cause analysis is harder too, as many changes are being implemented at the same time So the team increasingly relies on manual regression testing to ensure that new releases don't introduce bugs. Unfortunately, these longer testing and deployment cycles not only slow down the release pipeline and increase the chance of errors, but they also make it really challenging to reconcile large monolithic apps with continuous integration and continous delivery.
- With monolithic applications, we implicitly make certain tradeoffs with regards to scalability and flexibility. On one hand, scaling a monolithic app seems pretty straightforward right? Since everything is running in a single process, we can scale horizontally by replicating the app on multiple servers and sticking a load balancer in front. On the data side, depending on the technology, you could set up read slaves or, even set up sharding so that writes get forwarded to the appropriate write-master.
- Unfortunately, we’re still stuck with the fact that scaling requires scaling the entire app, rather than the specific parts of it that require more resources. And this becomes a particular problem when simple horizontal scaling won’t cut it for the high-impact parts of your app, or when you realize that the technologies you’re using for the monolith, which work perfectly fine most of the components, isn’t the best fit for another component.
- Gilt is a members-only flash sales site, it started in 2007, initially focused on women’s luxury apparel brands but now I believe have expanded to men, children, home, city, etc. Every day there are a handful of sales of limited-inventory luxury goods Sales begin at noon EST Members can reserve items for a limited time, by adding to cart, after which they have to buy or release the reservation back into the inventory pool
- The fact that the sales launch every day at noon, presents some unique load properties. This is a graph of traffic history in a 7-day span for Gilt in 2009. You might be able to guess what time each of these spikes corresponds to. Although the spikes might be higher on some days than others, depending on what the sales are, this isn’t too difficult to anticipate and plan for as far as scaling-out
- In fact, Gilt started off as a monolithic Rails app, deployed on Rails Thin servers, with load balancers and Zeus traffic managers (now called Stingray) To handle scaling, just add more thins?
- Graph of peak hour sales volume at Gilt leading up to that Louboutin event. Fluctuations generally mirror their traffic graph, with a steady slope upward. That red line, is half the average peak sales volume on a typical day at Amazon. This spike, is the Louboutin Sales Event. Took them from less than ¼ to over half an Amazon.
- The end result looks something like this. When Gilt’s engineering team went back for the postmortem, they realized that the problem was isolated specifically to cart and checkout.
- basic tenet of microservices is to decompose applications, not into modules or libraries or gems, but into small services that are actually independent of each other. The way these services are partitioned out is guided by the notion of bounded contexts, or autonomous components, with their own domain models and specific responsibilities
- Each service should be small enough so that any developer, given an hour or two, can easily understand all aspects of the service, and where rewriting the implementation would be a fairly straightforward task. The net-result is not only higher developer productivity, but also the freedom to evolve the system since each service can be easily replaced or upgraded.
- Each service should only be able to interact with each other through their interfaces, or via a broker, whether that be an API gateway or some sort of messaging broker.
- Because of the lack of central governance, you have the flexibility to write and build each service in any language or technology that best suits it.
- The essence of a microservice architecture isn’t new, and in fact the concept of distributed systems is very old, so an obvious question is how are microservices any different than SOA? Microservices go further than SOA by saying that yes, size does matter. Some even advocate that each service should be limited to under 100 lines of code, but the key is that microservices seek specifically to implement services in a way that solves the specific development and deployment problems that were mentioned earlier.
- The point about these services being independently deployed is critical, because in order for microservices to deliver on that promise of agility and reliability, you need to be able to change, release, and scale any service independently This also results in the added perk of theoretical zero-downtime, since deploys are separated from each other and you can continue to serve requests from a previous version until you’ve deployed the latest version of a service
- When you partition your components as remote services, you do have to pay the price of having to design for fault tolerance. Any service could fail at any time, whether the server went kaput, or slowness or unavailability of the network, so its important to detect failures quickly and if possible, automatically restore services that go offline. Microservice architectures put a lot of emphasis on real-time monitoring, and insight into network traffic and latency of service requests.
- Microservices advocate decentralizing data storage decisions, and allowing each service to manage its own database, which can use whatever data technology best meets its requirements. Because the core principle of microservices is to decouple and encapsulate components behind facades, this should also extend to the data layer as well. This allows us to experiment with and utilize different data stores without polluting the overall ecosystem with the particulars of each data store.
- Team behind Soundcloud put out really great series of blog posts describing how they migrated from a monolithic Rails app to a microservice architecture using mainly Scala, Clojure and JRuby. https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith
- Rule 1, is to stop adding new features to the monolith, except for critical fixes. This ensures that precious resources aren’t spent on making the monolith bigger and adding more technical debt. Instead, make a commitment to writing every new feature as a micro service.
- Rule 2: Every existing feature that requires significant rework will be removed and rewritten as a micro service. This rule depends on your definition of “significant rework” but in practice, if the team has made the decision that some part of the existing system requires a significant level of refactoring or rewriting, determine if you can break that off into one or more bounded-contexts that can be extracted out as microservices.
- Microservices should only communicate via formal interfaces. The protocols that are used is up to the team, but it’s best to not go crazy pants and choose a few well-known protocols that are easy for everyone to implement (HTTP for REST APIs, AMQP, Thrift, etc). Communication can be thru the APIs or via asynchronous message passing to a message broker. But the important thing is to be disciplined and adhere to the interface contract, so that services are independent and well-isolated from each other.
- The biggest issue in migrating from a monolith to microservices is replacing fine-grained communication patterns (in-memory method invocations and function calls) to a coarser-grained RPC approach.
- So a key question is how do microservices actually communicate with each other? Conceptually you might start off by thinking that a microservice architecture looks like this, where you have microservices are calling each other directly:
- or this where clients are responsible for calling each service directly. But there’s a mismatch in the granularity between the APIS of the individual services and data required by the clients, and then you have the problem of all this assembly logic in the consumers.
- A much better approach is for clients to make a small number of requests per page, perhaps as few as one, to an API gateway which sits between the clients and the microservices.
- You could even take this approach further and set up multiple verticals of gateways. Not only does the API gateway optimize communication between the clients and the services, but it also encapsulates the details of the microservices. This enables the microservices to still evolve without impacting the clients, because only the API gateway needs to be updated to reflect changes.