{"id":12244,"date":"2019-02-10T16:09:00","date_gmt":"2019-02-10T14:09:00","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=9999"},"modified":"2019-02-10T16:09:00","modified_gmt":"2019-02-10T14:09:00","slug":"modular-monolith-microservices","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/modular-monolith-microservices","title":{"rendered":"Modular Monolith Or Microservices?"},"content":{"rendered":"<div class=\"page\" title=\"Page 1\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<p>It\u2019s impossible to ignore the topic of microservices today. We hear about them from social media, conferences, specialized websites, books, framework vendors, communities, colleagues. It seems like they\u2019re the only way to go.<\/p>\n<p>But are they? To answer this question, we first need to explore why are microservices so useful, what are their downsides and what are the alternatives.<\/p>\n<h3>Using Conway\u2019s Law for fast development<\/h3>\n<p><em>organizations which design systems &#8230; are constrained to produce designs which are copies&nbsp;<\/em><em>of <\/em><em>&nbsp;the communication structures of these organizations \u2014 Melvin E. Conway<\/em><\/p>\n<p>Conway\u2019s Law has been first stated in 1967, and it has been proven empirically again and again. To understand it, let\u2019s discuss a few examples of its application:<\/p>\n<ul>\n<li>Teams who can communicate easily (typically small and collocated) tend to create monoliths<\/li>\n<li>Teams who communicate through intermediaries (managers, architects etc.) tend to work on separate modules<\/li>\n<li>Teams who communicate through hierarchies tend to work on complex structures. For example&nbsp;one core \/ framework team, front-end teams, back-end teams etc.<\/li>\n<\/ul>\n<p>Fred George started <strong>one of the first microservices projects with a big challenge<\/strong>: <strong>the work had to be organized in a way that allowed adding developers fast<\/strong>. He decided to use Conway\u2019s Law to their advantage, and create an architectural structure that allowed adding pairs of programmers to the development. The only option was to create many small services that communicated asynchronously and that were completely independent of each other, each developed by a pair of programmers. Enter microservices.<\/p>\n<h2>A few rules for microservices<\/h2>\n<p>According to Fred George, they followed very specific rules for the architecture of the microservices. They started with a long session of domain modelling (about two weeks), that resulted into bounded contexts* and then into well-defined services. Each service:<\/p>\n<ul>\n<li>&nbsp;uses its own database<\/li>\n<li>depends only on a message pipeline, never directly on another service&nbsp;<\/li>\n<li>when needing something from another service, posts a message to the pipeline describing the need<\/li>\n<li>periodically reads the messages from the pipeline and decide if anything needs to be done<\/li>\n<li>self-monitors: if something doesn\u2019t work, report and try to self-heal<\/li>\n<li>is deployed separately<\/li>\n<li>when changed, a new service instance is deployed. Once the callers&nbsp;switched to the new instance, the old instance can be deleted<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n<div class=\"page\" title=\"Page 2\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<p>In addition, code duplication between services is ignored. Otherwise, libraries will be extracted that increase deployment complexity and can lead to dependency hell.<\/p>\n<p>These constraints allow for independent development by a lot of programmer pairs. Architecture and Conway\u2019s Law work hand in hand, helping the development go faster.<\/p>\n<h2>Why are microservices useful?<\/h2>\n<p>In conclusion, microservices are useful because of two things:<\/p>\n<ul>\n<li>scale up the team very quickly by taking advantage of Conway\u2019s Law<\/li>\n<li>modular development<\/li>\n<\/ul>\n<p>In addition, <strong>microservices can scale very easily <\/strong>and<strong> minimize spending on the cloud<\/strong>. The reason is that when load increases, more specific instances can be started at a minimal cost.<\/p>\n<p>As we can see from the industry examples, these criteria apply very well for large projects that need to scale quickly. So if you need to start such a project, by all means, use microservices. But if you don\u2019t need to scale that quickly, there are easier ways. The reason is that microservices, like any architectural approach, are a trade-off.<\/p>\n<h2>A downside and a huge mistake<\/h2>\n<p>Microservices have one important downside and can lead to one huge architecture mistake.<\/p>\n<p>The downside is that<strong> microservices architecture leads to huge complexity increases for deployment and operations<\/strong>. Deploying one monolith is very different from deploying 100 or 1000 separate services. Monitoring and de-bugging then become a very difficult job. There are solutions, but each adds to costs and complexity. This investment might not pay o for smaller products.<\/p>\n<p>The architecture mistake is to create microservices that directly depend on other microservices. This is just a re-creation of the dependency hell&nbsp;problem in deployment. If dependencies are hierarchical, changing a service propagates and require a lot of redeployments. Instead, aim for services that completely encapsulate one atomic change. This is the hardest thing to do about microservices; no wonder it took Fred George\u2019s team weeks to figure it out (and probably a lot more time after starting the development).<\/p>\n<\/div>\n<\/div>\n<\/div>\n<div class=\"page\" title=\"Page 3\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<h2>Modular monolith<\/h2>\n<p>There is an alternative to microservices, one that we used successfully for <a href=\"https:\/\/eventrix.co\" class=\"broken_link\">eventriX<\/a>: the modular monolith.<\/p>\n<p>The idea of a modular monolith is to preserve the idea of encapsulation from above but deploy it in a different manner. We don\u2019t have to deploy a module as a service until we need to scale it. Instead, modules can be deployed as&nbsp;libraries, plugins, namespaces etc., resulting into one file that can be very easily deployed, monitored and debugged. As long as we follow a good modular structure inside the monolith, we can easily extract a service.<\/p>\n<p>So how can we structure such a monolith? It obviously depends on the application. In the case of <a href=\"https:\/\/eventrix.co\" class=\"broken_link\">eventriX<\/a>, we follow a few clear rules:<\/p>\n<ul>\n<li>there are three large bounded contexts: speaker, event organizer, and reviewer. More will appear in time.<\/li>\n<li>each of the bounded contexts has its own URL mapping: \u201c\/s\u201d for speaker, \u201c\/o\u201d for organizer, \u201c\/r\u201d for reviewer<\/li>\n<li>the bounded contexts don\u2019t depend on each other. When changing some- thing for speaker, nothing changes for organizer. This means that some views, although containing the same information, are duplicated between speaker and organizer. That\u2019s acceptable because speaker views can change with a different speed and in a different direction than organizer views<\/li>\n<li>each request goes through a clear set of classes: a controller, a command object that validates the request, one or more queries, one or more application service etc. It\u2019s very easy to follow the path of each request, and the paths are different for each request<\/li>\n<\/ul>\n<p>All these rules allow us to quickly extract separate services or plugins if needed&nbsp;while maintaining the operational complexity at a minimum.<\/p>\n<h2>Conclusion<\/h2>\n<p>We <strong>have found microservices<\/strong><strong> to be a great idea for large projects that need to scale quickly<\/strong> and save money when the load increases. But they also add huge operational complexity. We\u2019ve also seen that the most complex part of developing microservices is getting the modularity right. But teams who master modular architecture have more than one option.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<div class=\"page\" title=\"Page 4\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<p>A modular monolith&nbsp;or a well-thought combination between&nbsp;plugins, modular monoliths and libraries allow fast development while maintaining low complexity. They also allow evolving to a more appropriate architecture when the need appear&nbsp;since logical modules can easily be extracted into physical modules.<\/p>\n<p>The decision between microservices and modular monolith is not easy. It requires careful consideration of the trade-offs and of the context. It\u2019s up to the person(s) playing the role of the architect to end the best way. We hope this article helps you reach a decision.<\/p>\n<p>Modularity is a core module (pun intended) of our <a href=\"https:\/\/mozaicworks.com\/public-trainings-and-workshops\/software-architecture-principles\/\">Software Architecture Principles<\/a> workshop.&nbsp;<em>If you need something specific related to architecture,&nbsp;<a href=\"https:\/\/mozaicworks.com\/contact\/\">let us know<\/a>.&nbsp;<\/em><\/p>\n<\/div>\n<\/div>\n<div class=\"layoutArea\">\n<div class=\"column\">\n<p><em>*Bounded contexts are a core pattern in Domain Driven Design, grouping related domain entities<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>It\u2019s impossible to ignore the topic of microservices today. We hear about them from social media, conferences, specialized websites, books, framework vendors, communities, colleagues. It seems like they\u2019re the only way to go. But are they? To answer this question, we first need to explore why are microservices so useful, what are their downsides and [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":10003,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[1147,1103],"tags":[1403,1404,1405,1406,1407,1338],"acf":[],"_links":{"self":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12244"}],"collection":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/comments?post=12244"}],"version-history":[{"count":0,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media\/10003"}],"wp:attachment":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media?parent=12244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/categories?post=12244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/tags?post=12244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}