{"id":56,"date":"2023-09-04T18:37:17","date_gmt":"2023-09-04T18:37:17","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/monolith-versus\/"},"modified":"2026-03-16T14:21:15","modified_gmt":"2026-03-16T14:21:15","slug":"monolith-versus","status":"publish","type":"chapter","link":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/monolith-versus\/","title":{"raw":"Monolith versus Microservice Architectures","rendered":"Monolith versus Microservice Architectures"},"content":{"raw":"<div class=\"imgbleed\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter06.png\"><img class=\"aligncenter size-full wp-image-54\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\"><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 5\nMonolith <span class=\"chtitlesmall\">versus<\/span> Microservice Architectures<\/h2>\n[pb_glossary id=\"866\"]High-level architecture[\/pb_glossary] is the software\u2019s all-encompassing code design. When described with a diagram, a high-level architecture usually looks like a few to dozens of interconnected shapes with short labels, an abstraction that usually represents the entire codebase. In this chapter, we\u2019ll use \u201carchitecture\u201d interchangeably with \u201chigh-level architecture\u201d (in other contexts, [pb_glossary id=\"867\"]software architecture[\/pb_glossary] can refer to code design at lower levels).\n\nIn this chapter, <strong>I won\u2019t be covering every high-level architecture<\/strong>. Instead, I\u2019ll concentrate on two distinct high-level architectures: [pb_glossary id=\"868\"]monolith[\/pb_glossary] and [pb_glossary id=\"869\"]microservices[\/pb_glossary]. Talking about the ways they\u2019re different will lead us through concepts applicable to high-level architecture in general.\n<h1>5.1 Monolith Architecture<\/h1>\nMonolith software is one interconnected codebase that <strong>cannot easily be divided<\/strong> into multiple independent components that run separately and are individually useful.\n\nIf you\u2019re trying to think of an example of a monolith and nothing is coming to mind, that\u2019s probably because this architecture is so common that it can arise without having to plan. Your first computer program was probably a small monolith. If you keep adding more code\/files\/classes\/components, the software becomes a bigger monolith\u2014unless you change the architecture.\n<h1>5.2 Microservice Architecture<\/h1>\nMicroservices are <strong>separate applications<\/strong>, each of which runs in a <strong>separate process<\/strong> and could be <strong>individually useful<\/strong>. This section describes core characteristics of software that uses the microservice architecture. The subheadings are borrowed from Lewis &amp; Fowler (<span class=\"citation\">[pb_glossary id=\"683\"]2014[\/pb_glossary]<\/span>). <a href=\"https:\/\/martinfowler.com\/microservices\/\">Martin Fowler\u2019s Microservices Guide<\/a> (Fowler, <span class=\"citation\">[pb_glossary id=\"681\"]2019[\/pb_glossary]<\/span>) provides additional discussion.\n<h2>5.2.1 \u201cSmart End Points and Dumb Pipes\u201d<\/h2>\n<div class=\"textbox textbox--sidebar\">\u201cDumb pipes\u201d does not imply simple message contents.<\/div>\nThe [pb_glossary id=\"871\"]communication pipe[\/pb_glossary] within a microservice architecture is <strong>simple,<\/strong> and the services themselves take care of translating and otherwise processing messages. For example, microservices commonly communicate through a REST API, which allows these kinds of messages: GET, POST (create), PUT (update), or DELETE. The contents of the messages can be complex, but it\u2019s the job of the services to deal with that.\n<h2>5.2.2 \u201cComponentization via Services\u201d<\/h2>\n<div class=\"textbox textbox--sidebar\">Even though it provides a service, a library is not a service if you\u2019re including its code in your code.<\/div>\nIn a microservice architecture, <strong>components are services<\/strong>. The Lewis and Fowler (<span class=\"citation\">[pb_glossary id=\"683\"]2014[\/pb_glossary]<\/span>) definition of a [pb_glossary id=\"870\"]component[\/pb_glossary] is \u201ca unit of software that is independently replaceable and upgradeable.\u201d A [pb_glossary id=\"872\"]service[\/pb_glossary] provides functionality while running in its own process. A monolith typically has code with tight [pb_glossary id=\"873\"]coupling[\/pb_glossary] and components that run in the same process.\n\n<p class=\"page-break-before\"><strong>Advantages of splitting components into services:<\/strong><\/p>\n<ul>\n \t<li><strong>Independence<\/strong>: Each individual service can be updated, tested, launched, and stopped without requiring the same from other components of the software. In contrast, with some monolithic software, all tests must be run each time a developer commits to a change, which can make for a long wait. If a service fails, any software depending on it will be without that service, but the rest of the software needn\u2019t be affected.<\/li>\n \t<li><strong>Standardized component communication<\/strong>: Service communication pipes can be simple and the same each time. This can make for less thinking, fewer mistakes, and less violation of [pb_glossary id=\"874\"]encapsulation[\/pb_glossary] when connecting two components\u2014just use the pipe.<\/li>\n<\/ul>\n<strong>Disadvantages of splitting components into services:<\/strong>\n<ul>\n \t<li><strong>More expensive communication<\/strong>: Components in a monolith can communicate via direct calls (fast, lightweight); in contrast, microservices <strong>often communicate over a network<\/strong>. Microservice requests typically need to include request metadata, and because the pipes are \u201cdumb,\u201d responses might contain extra data (slower, heavier).<\/li>\n \t<li><strong>Potentially less secure communication<\/strong>: Communication over a network can be more prone to interception and alteration.<\/li>\n<\/ul>\n<h2>5.2.3 \u201cOrganized around Business Capabilities\u201d<\/h2>\nYou may have heard of the [pb_glossary id=\"875\"]client-server[\/pb_glossary] architecture, in which multiple instances of client-side software communicate with server-side software, which communicates with a database. That architecture is organized around technology. Another way to put that: someone unfamiliar with the differences between client-side software, server-side software, and a database would not get much out of seeing a diagram of this architecture.\n\n<p class=\"page-break-after\">In contrast, microservices are organized around business capabilities. This term has multiple definitions. Michell\u2019s (<span class=\"citation\">[pb_glossary id=\"684\"]2011[\/pb_glossary]<\/span>) integrated definition of a [pb_glossary id=\"876\"]business capability[\/pb_glossary] fits what we\u2019re talking about: \u201cthe potential of a business resource (or groups of resources) to produce customer value by acting on their environment via a process using other tangible and intangible resources.\u201d<\/p>\n\n<strong>Examples of business capabilities:<\/strong>\n<ul>\n \t<li>The manufacturer can slice a 20-foot by 40-foot rectangle of wheat dough into 0.5-cm strips in 1.2 seconds, which will later become packaged noodles someone can buy for lunch in a grocery store.<\/li>\n \t<li>A loan officer can lead a customer through the process of securing a loan, enabling the customer to start a small business.<\/li>\n \t<li>A pet food distributor can regularly ship nutritionally balanced cat food to stores around the country.<\/li>\n \t<li>The software can make a video file compatible with mobile devices.<\/li>\n<\/ul>\nOne implication of being focused on business capabilities is that each microservice can have its own [pb_glossary id=\"877\"]tech stack[\/pb_glossary] (including its own database).\n<h2>5.2.4 \u201cDecentralized Data Management\u201d<\/h2>\nIn a microservice architecture, <strong>each service<\/strong> <strong>typically has its own database<\/strong> instead of sharing a centralized database. This is part of decoupling the software\u2019s components, which has many benefits including <strong>failure containment<\/strong>. A disadvantage is that if two microservices need to share data, the two copies of that data can become inconsistent (e.g., because one database has not yet received the update). Microservice databases are said to have [pb_glossary id=\"878\"]eventual consistency[\/pb_glossary], which means that, with time, each microservice will have the most up-to-date information, but meanwhile, there could be a mismatch (perhaps one that will annoy or mislead human users).\n<h2>5.2.5 \u201cDecentralized Governance\u201d<\/h2>\nMicroservices need only be compatible at their interfaces (communication pipe), leaving <strong>flexibility in how each is implemented<\/strong>. For example, each service can be written in a different language, reducing the weight of tech stack decisions and decreasing the need to compromise on those decisions. For each service, teams can choose the optimal programming language, framework, architecture, and more. The technologies of each microservice can be independently changed. Conversely, in a monolith, teams might only need to maintain a small set of technologies (e.g., if there\u2019s only one framework, only one framework will need updates installed) and might not need as broad of expertise (e.g., having working knowledge of five programming languages). Also, when code is more or less part of the same codebase, it might be easier to maintain the same standards across the code.\n<h2>5.2.6 \u201cDesign for Failure\u201d<\/h2>\nWhen services run in different processes on different machines and were created by different teams using different technologies and standards, that <strong>can change how developers think<\/strong>. Instead of keeping the whole ship afloat, thinking can shift toward service-specific <strong>monitoring, logging<\/strong>, and design decisions about <strong>what to do when a service fails<\/strong>\u2014including what to tell the user. In contrast, with a monolith, more thought might be put into how to revert quickly if a deployment fails (because failure might mean no part of the monolith works). Monoliths can also be designed for failure, but that\u2019s not as natural a tendency as with microservices.\n<h1>5.3 Monolith Compared to Microservices<\/h1>\nThis section recaps and expands upon differences between monolith and microservice architectures (Fowler, <span class=\"citation\">[pb_glossary id=\"680\"]2015[\/pb_glossary]<\/span>; Lewis &amp; Fowler, <span class=\"citation\">[pb_glossary id=\"683\"]2014[\/pb_glossary]<\/span>).\n<h2>5.3.1 How Does Communication Happen within a Monolith versus between Microservices?<\/h2>\nIn a monolith, communication (e.g., between classes and components) can happen in many ways, including through direct calls and over a network. With microservices, communication typically happens over a network such as through HTTP requests\/responses, through \u201cdumb,\u201d standardized communication pipes. While microservices communication pipes are less complex, that means the end points need to be smarter. Also, communication over a network can be less reliable and less secure.\n<h2>5.3.2 How Is a Monolith Deployed versus Microservices?<\/h2>\nMonolithic software often needs to be deployed all at once. Microservices can be independently deployed and can potentially be stopped without stopping connected services.\n<h2>5.3.3 How Is a Monolith Scaled versus Microservices?<\/h2>\nIf your monolithic software needs more resources to be able to support how much it\u2019s being used, it can be copied onto multiple machines. Each machine must have enough space, memory, processing speed, and the like to support the entire monolith.\n\nIf your microservices software needs more resources, you have more options. For example, the services that are used more can be replicated more times.\n<h2>5.3.4 How Is a Monolith Tested versus Microservices?<\/h2>\nIn microservice software, each service can be independently tested. In a monolith, the way you test is influenced by dependencies within the code, which could reach broadly across the software (and make for slow tests).\n<h2>5.3.5 How Is a Monolith Upgraded versus Microservices?<\/h2>\nEach microservice can be written in a different language (e.g., one in Python, another in Java, another in C++, etc.) and can run in different contexts (e.g., machines with different operating systems, libraries, versions of libraries, and so on). In theory, this means they can be independently upgraded.\n\nWith a monolith, upgrading may require more care. Each component must be compatible with the new context (but this is also sometimes true with microservices).\n<h2>5.3.6 How Is the Database Used in a Monolith versus Microservices?<\/h2>\nMonolithic software might have just one database, potentially a very large one. This can create a bottleneck if multiple parts of the software need to access the database in parallel and can make for slow database backups\/restores, among other drawbacks. If you only have one database, however, that\u2019s just one place for managing database access accounts and one database to maintain\/back up\/restore\/etcetera. In contrast, each microservice typically has its own data storage.\n<h1>5.4 Summary<\/h1>\nMonolith and microservice architectures have different advantages and disadvantages. In a microservice architecture, each service is its own application and can be independently managed. Communication mechanisms between modules can be standardized. In a monolith, however, the codebase can be deployed all at once and components can communicate directly, which can be more reliable, less expensive, and provide better consistency than communicating between multiple applications over a network.\n<h1>5.5 Case Study: Microservice Architecture<\/h1>\nThe Oregon State University (OSU) <a href=\"https:\/\/cass.oregonstate.edu\/\">Center for Applied Systems and Software (CASS)<\/a> is a nonprofit that gives students real-world software development experience through its work with clients such as the Oregon Department of Transportation (ODOT).\n\nCASS and ODOT decided to convert ODOT\u2019s statewide computer-aided dispatch software, Transportation Operation Center System (TOCS), from a monolith to microservices. TOCS helps dispatchers share road emergency information with responders and the public. The part of TOCS that CASS started with was the outdated home screen.\n\nFrom a user perspective, the main problem with the TOCS home screen was inflexibility. Dispatcher centers in different parts of Oregon had different needs (e.g., some centers dealt with more icy roads, others withs more fender-benders) but had to use the same home screen, which could not be easily configured.\n\nFrom a developer perspective, the monolith had multiple technological drawbacks that made it difficult to respond to TOCS users\u2019 needs:\n<ul>\n \t<li>It was <strong>difficult to keep software components decoupled<\/strong>, especially since many different developers worked on the software. They were building up [pb_glossary id=\"880\"]technical debt[\/pb_glossary], which meant that developers might need to focus on clearing that debt instead of implementing new TOCS features.<\/li>\n \t<li>CASS <strong>could only deploy TOCS a few times a year<\/strong> because the software had to be tested and deployed in its entirety (a long process) and it was essential for the software to remain stable, especially during times of year with more weather and road hazards. This meant dispatch centers had to wait a long time for new features (e.g., individualized home screens).<\/li>\n \t<li>There was a lot of <strong>pressure on the database<\/strong> because the TOCS software at all the dispatch centers was transacting with the same database and causing performance issues.<\/li>\n \t<li><strong>Technology choices were limited<\/strong> because every part of the software had to be compatible with the .NET Framework. Even worse, their <strong>technology stack was becoming deprecated<\/strong> because Microsoft stopped releasing updates to the .NET Framework after version 4.8. CASS chose the microservice architecture as a solution to all these problems.<\/li>\n<\/ul>\nFigure 5.1 depicts the new architecture of the TOCS homepage, which integrates with the monolith. The WinGui Gateway application is responsible for preparing data from the services so it can be used by the New Home Screen UI. It uses the .NET 6 stack, which gives developers access to modern features. The Message Broker (Apache ActiveMQ) application talks to the services and the Gateway. Because the Message Broker uses a standard protocol, AMQP, it would be feasible to change the Message Broker technology in the future. Each service is also a separate application and has its own database. CASS found that one advantage of a dedicated database was that they could use [pb_glossary id=\"879\"]JSON[\/pb_glossary] for the Profile Service, which was more appropriate than the relational database used within the monolith.\n\n[caption id=\"attachment_91\" align=\"aligncenter\" width=\"1384\"]<a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/Fig06.01.png\"><img class=\"size-full wp-image-55\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01.png\" alt=\"Flowchart\" width=\"1384\" height=\"1168\"><\/a> <strong>Figure 5.1<\/strong>\u00a0Microservice Architecture of ODOT\u2019s TOCS Home Screen[\/caption]\n\nFor more information about this project, see Fern (<span class=\"citation\">[pb_glossary id=\"679\"]2022[\/pb_glossary]<\/span>) for a video that describes it in detail.\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Fern, A. (2022). <em>Tech Talk Tuesday: Lessons in real-world software: going from monolith to microservices<\/em>. OSU MediaSpace. <a href=\"https:\/\/media.oregonstate.edu\/media\/t\/1_ls3xsa6r\">https:\/\/media.oregonstate.edu\/media\/t\/1_ls3xsa6r<\/a><\/p>\n<p class=\"hanging-indent\">Fowler, M. (2015, July 1). <em>Microservice trade-offs<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/articles\/microservice-trade-offs.html\">https:\/\/martinfowler.com\/articles\/microservice-trade-offs.html<\/a><\/p>\n<p class=\"hanging-indent\">Fowler, M. (2019, August 21). <em>Microservices guide<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/microservices\/\">https:\/\/martinfowler.com\/microservices\/<\/a><\/p>\n<p class=\"hanging-indent\">Lewis, J., &amp; Fowler, M. (2014, March 25). <em>Microservices<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/articles\/microservices.html\">https:\/\/martinfowler.com\/articles\/microservices.html<\/a><\/p>\n<p class=\"hanging-indent\">Michell, V. (2011). A focused approach to business capability. In B. Shishkov (Ed.), <em>Proceedings of the First International Symposium on Business Modeling and Software Design<\/em>, 105\u2013113. Springer. <a href=\"https:\/\/doi.org\/10.5220\/0004459101050113\">https:\/\/doi.org\/10.5220\/0004459101050113<\/a><\/p>","rendered":"<div class=\"imgbleed\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter06.png\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-54\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\" srcset=\"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06.png 2550w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-300x155.png 300w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-1024x530.png 1024w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-768x398.png 768w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-1536x795.png 1536w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-2048x1060.png 2048w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-65x34.png 65w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-225x116.png 225w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter06-350x181.png 350w\" sizes=\"(max-width: 2550px) 100vw, 2550px\" \/><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 5<br \/>\nMonolith <span class=\"chtitlesmall\">versus<\/span> Microservice Architectures<\/h2>\n<p>High-level architecture is the software\u2019s all-encompassing code design. When described with a diagram, a high-level architecture usually looks like a few to dozens of interconnected shapes with short labels, an abstraction that usually represents the entire codebase. In this chapter, we\u2019ll use \u201carchitecture\u201d interchangeably with \u201chigh-level architecture\u201d (in other contexts, software architecture can refer to code design at lower levels).<\/p>\n<p>In this chapter, <strong>I won\u2019t be covering every high-level architecture<\/strong>. Instead, I\u2019ll concentrate on two distinct high-level architectures: monolith and microservices. Talking about the ways they\u2019re different will lead us through concepts applicable to high-level architecture in general.<\/p>\n<h1>5.1 Monolith Architecture<\/h1>\n<p>Monolith software is one interconnected codebase that <strong>cannot easily be divided<\/strong> into multiple independent components that run separately and are individually useful.<\/p>\n<p>If you\u2019re trying to think of an example of a monolith and nothing is coming to mind, that\u2019s probably because this architecture is so common that it can arise without having to plan. Your first computer program was probably a small monolith. If you keep adding more code\/files\/classes\/components, the software becomes a bigger monolith\u2014unless you change the architecture.<\/p>\n<h1>5.2 Microservice Architecture<\/h1>\n<p>Microservices are <strong>separate applications<\/strong>, each of which runs in a <strong>separate process<\/strong> and could be <strong>individually useful<\/strong>. This section describes core characteristics of software that uses the microservice architecture. The subheadings are borrowed from Lewis &amp; Fowler (<span class=\"citation\">2014<\/span>). <a href=\"https:\/\/martinfowler.com\/microservices\/\">Martin Fowler\u2019s Microservices Guide<\/a> (Fowler, <span class=\"citation\">2019<\/span>) provides additional discussion.<\/p>\n<h2>5.2.1 \u201cSmart End Points and Dumb Pipes\u201d<\/h2>\n<div class=\"textbox textbox--sidebar\">\u201cDumb pipes\u201d does not imply simple message contents.<\/div>\n<p>The communication pipe within a microservice architecture is <strong>simple,<\/strong> and the services themselves take care of translating and otherwise processing messages. For example, microservices commonly communicate through a REST API, which allows these kinds of messages: GET, POST (create), PUT (update), or DELETE. The contents of the messages can be complex, but it\u2019s the job of the services to deal with that.<\/p>\n<h2>5.2.2 \u201cComponentization via Services\u201d<\/h2>\n<div class=\"textbox textbox--sidebar\">Even though it provides a service, a library is not a service if you\u2019re including its code in your code.<\/div>\n<p>In a microservice architecture, <strong>components are services<\/strong>. The Lewis and Fowler (<span class=\"citation\">2014<\/span>) definition of a component is \u201ca unit of software that is independently replaceable and upgradeable.\u201d A service provides functionality while running in its own process. A monolith typically has code with tight coupling and components that run in the same process.<\/p>\n<p class=\"page-break-before\"><strong>Advantages of splitting components into services:<\/strong><\/p>\n<ul>\n<li><strong>Independence<\/strong>: Each individual service can be updated, tested, launched, and stopped without requiring the same from other components of the software. In contrast, with some monolithic software, all tests must be run each time a developer commits to a change, which can make for a long wait. If a service fails, any software depending on it will be without that service, but the rest of the software needn\u2019t be affected.<\/li>\n<li><strong>Standardized component communication<\/strong>: Service communication pipes can be simple and the same each time. This can make for less thinking, fewer mistakes, and less violation of encapsulation when connecting two components\u2014just use the pipe.<\/li>\n<\/ul>\n<p><strong>Disadvantages of splitting components into services:<\/strong><\/p>\n<ul>\n<li><strong>More expensive communication<\/strong>: Components in a monolith can communicate via direct calls (fast, lightweight); in contrast, microservices <strong>often communicate over a network<\/strong>. Microservice requests typically need to include request metadata, and because the pipes are \u201cdumb,\u201d responses might contain extra data (slower, heavier).<\/li>\n<li><strong>Potentially less secure communication<\/strong>: Communication over a network can be more prone to interception and alteration.<\/li>\n<\/ul>\n<h2>5.2.3 \u201cOrganized around Business Capabilities\u201d<\/h2>\n<p>You may have heard of the client-server architecture, in which multiple instances of client-side software communicate with server-side software, which communicates with a database. That architecture is organized around technology. Another way to put that: someone unfamiliar with the differences between client-side software, server-side software, and a database would not get much out of seeing a diagram of this architecture.<\/p>\n<p class=\"page-break-after\">In contrast, microservices are organized around business capabilities. This term has multiple definitions. Michell\u2019s (<span class=\"citation\">2011<\/span>) integrated definition of a business capability fits what we\u2019re talking about: \u201cthe potential of a business resource (or groups of resources) to produce customer value by acting on their environment via a process using other tangible and intangible resources.\u201d<\/p>\n<p><strong>Examples of business capabilities:<\/strong><\/p>\n<ul>\n<li>The manufacturer can slice a 20-foot by 40-foot rectangle of wheat dough into 0.5-cm strips in 1.2 seconds, which will later become packaged noodles someone can buy for lunch in a grocery store.<\/li>\n<li>A loan officer can lead a customer through the process of securing a loan, enabling the customer to start a small business.<\/li>\n<li>A pet food distributor can regularly ship nutritionally balanced cat food to stores around the country.<\/li>\n<li>The software can make a video file compatible with mobile devices.<\/li>\n<\/ul>\n<p>One implication of being focused on business capabilities is that each microservice can have its own tech stack (including its own database).<\/p>\n<h2>5.2.4 \u201cDecentralized Data Management\u201d<\/h2>\n<p>In a microservice architecture, <strong>each service<\/strong> <strong>typically has its own database<\/strong> instead of sharing a centralized database. This is part of decoupling the software\u2019s components, which has many benefits including <strong>failure containment<\/strong>. A disadvantage is that if two microservices need to share data, the two copies of that data can become inconsistent (e.g., because one database has not yet received the update). Microservice databases are said to have eventual consistency, which means that, with time, each microservice will have the most up-to-date information, but meanwhile, there could be a mismatch (perhaps one that will annoy or mislead human users).<\/p>\n<h2>5.2.5 \u201cDecentralized Governance\u201d<\/h2>\n<p>Microservices need only be compatible at their interfaces (communication pipe), leaving <strong>flexibility in how each is implemented<\/strong>. For example, each service can be written in a different language, reducing the weight of tech stack decisions and decreasing the need to compromise on those decisions. For each service, teams can choose the optimal programming language, framework, architecture, and more. The technologies of each microservice can be independently changed. Conversely, in a monolith, teams might only need to maintain a small set of technologies (e.g., if there\u2019s only one framework, only one framework will need updates installed) and might not need as broad of expertise (e.g., having working knowledge of five programming languages). Also, when code is more or less part of the same codebase, it might be easier to maintain the same standards across the code.<\/p>\n<h2>5.2.6 \u201cDesign for Failure\u201d<\/h2>\n<p>When services run in different processes on different machines and were created by different teams using different technologies and standards, that <strong>can change how developers think<\/strong>. Instead of keeping the whole ship afloat, thinking can shift toward service-specific <strong>monitoring, logging<\/strong>, and design decisions about <strong>what to do when a service fails<\/strong>\u2014including what to tell the user. In contrast, with a monolith, more thought might be put into how to revert quickly if a deployment fails (because failure might mean no part of the monolith works). Monoliths can also be designed for failure, but that\u2019s not as natural a tendency as with microservices.<\/p>\n<h1>5.3 Monolith Compared to Microservices<\/h1>\n<p>This section recaps and expands upon differences between monolith and microservice architectures (Fowler, <span class=\"citation\">2015<\/span>; Lewis &amp; Fowler, <span class=\"citation\">2014<\/span>).<\/p>\n<h2>5.3.1 How Does Communication Happen within a Monolith versus between Microservices?<\/h2>\n<p>In a monolith, communication (e.g., between classes and components) can happen in many ways, including through direct calls and over a network. With microservices, communication typically happens over a network such as through HTTP requests\/responses, through \u201cdumb,\u201d standardized communication pipes. While microservices communication pipes are less complex, that means the end points need to be smarter. Also, communication over a network can be less reliable and less secure.<\/p>\n<h2>5.3.2 How Is a Monolith Deployed versus Microservices?<\/h2>\n<p>Monolithic software often needs to be deployed all at once. Microservices can be independently deployed and can potentially be stopped without stopping connected services.<\/p>\n<h2>5.3.3 How Is a Monolith Scaled versus Microservices?<\/h2>\n<p>If your monolithic software needs more resources to be able to support how much it\u2019s being used, it can be copied onto multiple machines. Each machine must have enough space, memory, processing speed, and the like to support the entire monolith.<\/p>\n<p>If your microservices software needs more resources, you have more options. For example, the services that are used more can be replicated more times.<\/p>\n<h2>5.3.4 How Is a Monolith Tested versus Microservices?<\/h2>\n<p>In microservice software, each service can be independently tested. In a monolith, the way you test is influenced by dependencies within the code, which could reach broadly across the software (and make for slow tests).<\/p>\n<h2>5.3.5 How Is a Monolith Upgraded versus Microservices?<\/h2>\n<p>Each microservice can be written in a different language (e.g., one in Python, another in Java, another in C++, etc.) and can run in different contexts (e.g., machines with different operating systems, libraries, versions of libraries, and so on). In theory, this means they can be independently upgraded.<\/p>\n<p>With a monolith, upgrading may require more care. Each component must be compatible with the new context (but this is also sometimes true with microservices).<\/p>\n<h2>5.3.6 How Is the Database Used in a Monolith versus Microservices?<\/h2>\n<p>Monolithic software might have just one database, potentially a very large one. This can create a bottleneck if multiple parts of the software need to access the database in parallel and can make for slow database backups\/restores, among other drawbacks. If you only have one database, however, that\u2019s just one place for managing database access accounts and one database to maintain\/back up\/restore\/etcetera. In contrast, each microservice typically has its own data storage.<\/p>\n<h1>5.4 Summary<\/h1>\n<p>Monolith and microservice architectures have different advantages and disadvantages. In a microservice architecture, each service is its own application and can be independently managed. Communication mechanisms between modules can be standardized. In a monolith, however, the codebase can be deployed all at once and components can communicate directly, which can be more reliable, less expensive, and provide better consistency than communicating between multiple applications over a network.<\/p>\n<h1>5.5 Case Study: Microservice Architecture<\/h1>\n<p>The Oregon State University (OSU) <a href=\"https:\/\/cass.oregonstate.edu\/\">Center for Applied Systems and Software (CASS)<\/a> is a nonprofit that gives students real-world software development experience through its work with clients such as the Oregon Department of Transportation (ODOT).<\/p>\n<p>CASS and ODOT decided to convert ODOT\u2019s statewide computer-aided dispatch software, Transportation Operation Center System (TOCS), from a monolith to microservices. TOCS helps dispatchers share road emergency information with responders and the public. The part of TOCS that CASS started with was the outdated home screen.<\/p>\n<p>From a user perspective, the main problem with the TOCS home screen was inflexibility. Dispatcher centers in different parts of Oregon had different needs (e.g., some centers dealt with more icy roads, others withs more fender-benders) but had to use the same home screen, which could not be easily configured.<\/p>\n<p>From a developer perspective, the monolith had multiple technological drawbacks that made it difficult to respond to TOCS users\u2019 needs:<\/p>\n<ul>\n<li>It was <strong>difficult to keep software components decoupled<\/strong>, especially since many different developers worked on the software. They were building up technical debt, which meant that developers might need to focus on clearing that debt instead of implementing new TOCS features.<\/li>\n<li>CASS <strong>could only deploy TOCS a few times a year<\/strong> because the software had to be tested and deployed in its entirety (a long process) and it was essential for the software to remain stable, especially during times of year with more weather and road hazards. This meant dispatch centers had to wait a long time for new features (e.g., individualized home screens).<\/li>\n<li>There was a lot of <strong>pressure on the database<\/strong> because the TOCS software at all the dispatch centers was transacting with the same database and causing performance issues.<\/li>\n<li><strong>Technology choices were limited<\/strong> because every part of the software had to be compatible with the .NET Framework. Even worse, their <strong>technology stack was becoming deprecated<\/strong> because Microsoft stopped releasing updates to the .NET Framework after version 4.8. CASS chose the microservice architecture as a solution to all these problems.<\/li>\n<\/ul>\n<p>Figure 5.1 depicts the new architecture of the TOCS homepage, which integrates with the monolith. The WinGui Gateway application is responsible for preparing data from the services so it can be used by the New Home Screen UI. It uses the .NET 6 stack, which gives developers access to modern features. The Message Broker (Apache ActiveMQ) application talks to the services and the Gateway. Because the Message Broker uses a standard protocol, AMQP, it would be feasible to change the Message Broker technology in the future. Each service is also a separate application and has its own database. CASS found that one advantage of a dedicated database was that they could use JSON for the Profile Service, which was more appropriate than the relational database used within the monolith.<\/p>\n<figure id=\"attachment_91\" aria-describedby=\"caption-attachment-91\" style=\"width: 1384px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/Fig06.01.png\"><img decoding=\"async\" class=\"size-full wp-image-55\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01.png\" alt=\"Flowchart\" width=\"1384\" height=\"1168\" srcset=\"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01.png 1384w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-300x253.png 300w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-1024x864.png 1024w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-768x648.png 768w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-65x55.png 65w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-225x190.png 225w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2026\/03\/Fig06.01-350x295.png 350w\" sizes=\"(max-width: 1384px) 100vw, 1384px\" \/><\/a><figcaption id=\"caption-attachment-91\" class=\"wp-caption-text\"><strong>Figure 5.1<\/strong>\u00a0Microservice Architecture of ODOT\u2019s TOCS Home Screen<\/figcaption><\/figure>\n<p>For more information about this project, see Fern (<span class=\"citation\">2022<\/span>) for a video that describes it in detail.<\/p>\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Fern, A. (2022). <em>Tech Talk Tuesday: Lessons in real-world software: going from monolith to microservices<\/em>. OSU MediaSpace. <a href=\"https:\/\/media.oregonstate.edu\/media\/t\/1_ls3xsa6r\">https:\/\/media.oregonstate.edu\/media\/t\/1_ls3xsa6r<\/a><\/p>\n<p class=\"hanging-indent\">Fowler, M. (2015, July 1). <em>Microservice trade-offs<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/articles\/microservice-trade-offs.html\">https:\/\/martinfowler.com\/articles\/microservice-trade-offs.html<\/a><\/p>\n<p class=\"hanging-indent\">Fowler, M. (2019, August 21). <em>Microservices guide<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/microservices\/\">https:\/\/martinfowler.com\/microservices\/<\/a><\/p>\n<p class=\"hanging-indent\">Lewis, J., &amp; Fowler, M. (2014, March 25). <em>Microservices<\/em>. martinfowler.com. <a href=\"https:\/\/martinfowler.com\/articles\/microservices.html\">https:\/\/martinfowler.com\/articles\/microservices.html<\/a><\/p>\n<p class=\"hanging-indent\">Michell, V. (2011). A focused approach to business capability. In B. Shishkov (Ed.), <em>Proceedings of the First International Symposium on Business Modeling and Software Design<\/em>, 105\u2013113. Springer. <a href=\"https:\/\/doi.org\/10.5220\/0004459101050113\">https:\/\/doi.org\/10.5220\/0004459101050113<\/a><\/p>\n<div class=\"glossary\"><span class=\"screen-reader-text\" id=\"definition\">definition<\/span><template id=\"term_56_866\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_866\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_867\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_867\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_868\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_868\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_869\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_869\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_683\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_683\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_681\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_681\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_871\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_871\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_870\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_870\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_872\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_872\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_873\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_873\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_874\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_874\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_875\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_875\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_684\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_684\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_876\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_876\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_877\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_877\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_878\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_878\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_680\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_680\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_880\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_880\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_879\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_879\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_56_679\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_56_679\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><\/div>","protected":false},"author":1,"menu_order":5,"template":"","meta":{"pb_show_title":"","pb_short_title":"Architectures","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[48],"contributor":[],"license":[],"class_list":["post-56","chapter","type-chapter","status-publish","hentry","chapter-type-standard"],"part":19,"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/56","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/56\/revisions"}],"predecessor-version":[{"id":57,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/56\/revisions\/57"}],"part":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/parts\/19"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/56\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/media?parent=56"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapter-type?post=56"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/contributor?post=56"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/license?post=56"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}