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.

When to stay with modular monoliths over microservices

Microservices architecture style has been a prominent talking points over the last few years. Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. This talk briefly covers characteristics of microservices, monoliths and modular monoliths. We will discuss the topics like, does microservices suits all problem domains? Where does it fails? Can we re-look at the existing styles and look for continual improvements in architectural style? By (re)visiting various styles, we will look at the guidelines which can be used to choose between a modular monolith and microservices.

  • Be the first to comment

  • Be the first to like this

When to stay with modular monoliths over microservices

  1. 1. Manu Kadichapally Oracle Code, Bengaluru, March 15 2019 When to Stay with Modular Monoliths over Microservices
  2. 2. Manu Kadichapally • Engineering Manager @ Schneider Electric • Twitter - @manupk12 • • Developer, team leader and software architect • Topics of Interests • Modern Software Architectures • Cyber Security • Organizing Teams to build Digital Product
  3. 3. Microservices Architecture Approach to developing a single application as a suite of small set of collaborating services.
  4. 4. Microservices architecture - Characteristics • Organized around Business Capabilities • Independent • Governance • Technical Stack • Deployment • Consumer first interfaces • Smart endpoints and dumb pipes • Improved fault isolation • Eventual Consistency for Data Source: content/latest/microservices-on-aws/characteristics-of-microservices.html
  5. 5. Evolutions of the Ecosystem The move towards microservices were highly influenced by the changes in the disruptions in the ecosystems • Cloud Services • Powerful Frontend capabilities
  6. 6. • Re-think “Modularity” • Is all monolith BAD? • Big-ball of mud to “distributed Big-ball of mud” • How do we evaluate the need?
  7. 7. The value of modularity • Always be modular in the business context. • Ability for vertical slice. • Decide on source code tree / deployment unit if required.
  8. 8. Just another product! Adding a new Product to the sales platform
  9. 9. ROI – Speed of execution • System grew to 12+ products over the next 3 years. • Every configurator was developed as independent project / service.
  10. 10. Public version of an API Change in the scaling requirement of a service due to business decision to allow everyone to access the tool
  11. 11. Business Context - Using DDD - Driven by stakeholder group - Application / Team Size Relative Scaling - Significant difference in scaling needs. - Impossible to use the same deployment unit. Over simplified version of decision tree come down to two criteria's,
  12. 12. Microservices Premium Source: emium.html
  13. 13. Thank you for listening @manupk12 Questions / Comments / Feedback are welcome!