Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Refactoring the monolith

182 views

Published on

Alternatives to microservices

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Refactoring the monolith

  1. 1. Refactoring the Monolith? Steven Hicks http://theexceptioncatcher.com
  2. 2. Who am I? Steven Hicks http://theexceptioncatcher.com @theexceptioncat
  3. 3. The Monolith The monolith is a full application that encompases the entire life cycle of a user’s interaction: Web services Web Rendering Serving up static resources Business Logic
  4. 4. Microservices ● Independent operations ● Small in context ○ Smaller Cognitive load ● Can embrace new technologies and languages without a full cultural shift
  5. 5. What Happens In Reality ● Harder To Standardize ○ Multiple Code bases ○ Duplicated Code Bases ● Serialization and communication overhead ● Lack of code reuse ● DevOps issues ● Tracing /Fragile system ● Overly Reliant on REST/JSON ● Client is up to the requestor ● Various instances of the same microservice (WEB SCALE) ● Fiefdoms Develop
  6. 6. How did we get here? What can we do about it?
  7. 7. Popular Frameworks for Enterprise Solutions Spring J2EE
  8. 8. Approach #1: Modular Monolith
  9. 9. Modular Monolith ● Addressed the complexity issue that microservices solves ● Makes smaller modules within the system ● Addresses the network communication problem ● Relies on the build to put everything together ● It’s an easier step towards breaking up the monolith ● Domain Driven Design approach ● Local builds are easy to run locally
  10. 10. Modular Monolith: Downsides ● Tooling is a bit difficult to handle (multiple dependencies with auto updates) ● A bit hard to extend and change design ● It’s still a “monolith.” * ● Cognitive Load still requires system level interaction
  11. 11. Approach 2 Message Queuing
  12. 12. Message Queuing ● Communication and Messaging is handled by a central communication service (the message queue) ● Separation of Responsibility ● Removes need for custom serialization ● Storage of communication *
  13. 13. Message Queuing: Downsides ● Single Point of Failure ● Tracing (throughout the system) requires a lot of logging ● Replying to a request may get complicated ● Versioning becomes difficult
  14. 14. Approach 3 Pipeline and Nodes
  15. 15. Pipeline and Nodes ● Isolation of processing and service delivery ● Handles the processing of requests without slowing down other users ● Very Fast Requests ● Can handle complicated requests ● Easy to scale up ● Workflows-like design ● Smaller components to handle logic
  16. 16. Pipeline and Nodes: The Downsides ● Hard on databases ● Doesn’t handle state well ● Consensus and Split Brain Issues ● Large Memory Requirements ● Not great for round trips on live requests for large transformations ● Still requires a bit of Devops setup (Less so than microservices)
  17. 17. Questions? Comments? Experiences? http://theexceptioncatcher.com @theexceptioncat

×