{"id":3644,"date":"2016-12-09T17:00:26","date_gmt":"2016-12-09T21:00:26","guid":{"rendered":"http:\/\/www.acarlstein.com\/?p=3644"},"modified":"2017-01-18T14:36:02","modified_gmt":"2017-01-18T18:36:02","slug":"microservices-design","status":"publish","type":"post","link":"http:\/\/blog.acarlstein.com\/?p=3644","title":{"rendered":"Microservices: Design"},"content":{"rendered":"<p><a href=\"http:\/\/www.acarlstein.com\/?p=3632\">\u00a0<i class=\"fa fa-angle-left\"><span style=\"color: transparent; display: none;\">icon-angle-left<\/span><\/i>\u00a0Micro-services: Design Principles Introduction<\/a>\u00a0|\u00a0<a href=\"http:\/\/www.acarlstein.com\/?p=3687\">Microservices: Technology<\/a>\u00a0<i class=\"fa fa-arrow-right\"><span style=\"color: transparent; display: none;\">icon-arrow-right<\/span><\/i>\u00a0<\/p>\n<p><strong>Summary of Principles to Implement<\/strong><\/p>\n<ul>\n<li>High Cohesion: Small micro-service focused and single functionality.\n<ul>\n<li>Single focus.<\/li>\n<li>Do a single thing and do it well done.<\/li>\n<\/ul>\n<\/li>\n<li>Autonomous: Allow upgrade of different part without risking other parts in the system.\n<ul>\n<li>Independently changeable.<\/li>\n<li>Independently deployable.<\/li>\n<\/ul>\n<\/li>\n<li>Business Domain Centric: aligned with the overall organization structure.\n<ul>\n<li>Represent a business function or domain.<\/li>\n<\/ul>\n<\/li>\n<li>Resilience:\n<ul>\n<li>Embrace failure.<\/li>\n<li>Degrade or default functionality when failure detected.<\/li>\n<\/ul>\n<\/li>\n<li>Observable: so we can have an overall view of the health of the system.;\n<ul>\n<li>Centralized Monitoring.<\/li>\n<li>Centralized Logging.<\/li>\n<\/ul>\n<\/li>\n<li>Automation: in order to administrate the complex system.\n<ul>\n<li>Tools:\n<ul>\n<li>Testing.<\/li>\n<li>Feedback.<\/li>\n<li>Deployment.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>High Cohesion Design Principle<\/strong><\/p>\n<p>In order to implement a micro-service with high cohesion, we need to:<\/p>\n<ol>\n<li>Identify a single focus.\n<ul>\n<li>It might be in a form of a business function.\n<ul>\n<li>e.: A function to generate invoice for the account system.\n<ul>\n<li>Notices that it has clear inputs and outputs.<\/li>\n<\/ul>\n<\/li>\n<li>It might be in a form of a business domain.\n<ul>\n<li>e. micro-service focus in creating, updating, retrieving, and deleting data related with a part of the organization such as the accounting deparment.<\/li>\n<\/ul>\n<\/li>\n<li>We should not crowd the micro-service with both types of focus.\n<ul>\n<li>Example of no high cohesion:<br \/>\n <a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3651\" rel=\"attachment wp-att-3651\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3651\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/No-high-cohesion.png\" alt=\"no-high-cohesion\" width=\"231\" height=\"272\" \/><\/a><\/li>\n<li>Example of high cohesion:<br \/>\n <a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3653\" rel=\"attachment wp-att-3653\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3653\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/high-cohesion.png\" alt=\"high-cohesion\" width=\"307\" height=\"254\" srcset=\"http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/high-cohesion.png 307w, http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/high-cohesion-300x248.png 300w\" sizes=\"auto, (max-width: 307px) 100vw, 307px\" \/><\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Split into more smaller services<br \/>\n<table style=\"height: 51px;\" width=\"384\">\n<tbody>\n<tr style=\"height: 31.1022px;\">\n<td style=\"height: 31.1022px; width: 402.386px;\">\n<p><a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3588\" rel=\"attachment wp-att-3588\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft wp-image-3588 size-full\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/11\/dialog-warning-2.png\" width=\"16\" height=\"16\" \/><\/a>Avoid the thinking of \u201cIt\u2019s kind of the same\u201d mentality and begin <br \/>\n coupling multiple business functions into one micro-service.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<ol>\n<li>We wish to avoid one business function breaking another business function.<\/li>\n<li>A micro-service should only have one reason to change.<\/li>\n<li>Don\u2019t be lazy. Even if it requires an extra effort, make sure to create an extra micro-service or split an existent micro-service.<\/li>\n<li>Remember the overall objective which is to have a system which is reliable, flexible and scalable.<\/li>\n<li>We want our system being in separate parts so we can deploy them as specific parts.<\/li>\n<li>Laziness will only lead us to a system which would be monolithic in nature; therefore, introducing all the disadvantage of such.<\/li>\n<li>As you create micro-services in an incremental way, you will be learning how to maintain them and monitor these micro-services.<\/li>\n<\/ol>\n<\/li>\n<li>Ensure your micro-services have high cohesion.\n<ol>\n<li>Continuously question the design of micro-services.\n<ol>\n<li>\u00a0i.e.: Is there a reason why a new micro-service has to change?<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<p><strong>Autonomous<\/strong><br \/>\n Our micro-services must be independently deployable and changeable.<\/p>\n<p>\n <strong>Autonomous: Loosely Couple<\/strong><\/p>\n<ul>\n<li>Each micro-services should depend on each other in the most minimal way possible.<\/li>\n<li>They should have the least amount of knowledge of each other.<\/li>\n<li>They shouldn\u2019t be connected physically to each other directly, but use a medium such as the network in order to talk to each other.\n<ul>\n<li>Communication can be synchronous.<br \/>\n <a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3661\" rel=\"attachment wp-att-3661\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter  wp-image-3661\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/Communication.png\" alt=\"\" width=\"538\" height=\"148\" srcset=\"http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/Communication.png 706w, http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/Communication-300x82.png 300w\" sizes=\"auto, (max-width: 538px) 100vw, 538px\" \/><\/a><\/p>\n<ul>\n<li>A micro-service calls another and waits for a reply.<\/li>\n<li>Advantage is to know that if our communication was successful or not due the status of response.<\/li>\n<li>In order to work, the micro-service receiving the request should respond right away even before it perform and completed its actual task for the request.\n<ul>\n<li>This allow the micro-service doing the request to carry out its own task while waiting.<\/li>\n<li>When the micro-service doing the work, finish, it will call back the micro-service requestor indicating that the task is completed.<\/li>\n<li>The original request should include a callback address.\n<ul>\n<li>In this way, the micro-service knows who to notify when the job is done.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Communication can be asynchronous.<br \/>\n <a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3665\" rel=\"attachment wp-att-3665\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3665\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/Asynchronic.png\" alt=\"\" width=\"275\" height=\"170\" \/><\/a><\/p>\n<ul>\n<li>Instead of having the micro-services making requests between each other, the micro-services public events in a form of messages.\n<ul>\n<li>These events are queue by a message broker such as RabbitMQ.<\/li>\n<li>All micro-services listen out for these events and carry out tasks if any of those event correspond to them.\n<ul>\n<li>If they are interested in the message they pick it up. Process them. Then send an event so the other micro-services interested pick the result.<\/li>\n<\/ul>\n<\/li>\n<li>Micro-services subscribe to events<\/li>\n<\/ul>\n<\/li>\n<li>Use open communication protocols in such way that we obtain a technology agnostic API.\n<ul>\n<li>Example of communication protocol: REST over HTTP and data in JSON<\/li>\n<li>This allow for micro-services to work on different technology stacks instead of forcing them to work on the same technology stack.\n<ul>\n<li>i.e.: Using REST JSON, we can have a .NET-based service communicate with a Java-based service.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Avoid the use of client libraries.\n<ul>\n<li>A consumer of your micro-services requires the implementation of a client library in order for the consumer to talk to your micro-service.<\/li>\n<li>Client libraries increase coupling because it force your micro-services and clients to change when its client library changes.<\/li>\n<li>It forces the use of a specific technology platform at the consuming end.<\/li>\n<\/ul>\n<\/li>\n<li>Micro-services should implement Order Shared Model which means that the micro-services should have a contract between them.\n<ul>\n<li>Fixed and agreed interfaces between the services.\n<ul>\n<li>Method signatures and the format of the data that is exchanged.<\/li>\n<\/ul>\n<\/li>\n<li>We always use Share models of the data that are unlikely to change when any of the micro-services is enhanced.\n<ul>\n<li>The shared models should be different from the internal representation of the data within the micro-service.<\/li>\n<li>Keep the internal representation of data separate from data that is going to be exchanges using the shared model.<\/li>\n<\/ul>\n<\/li>\n<li>These contracts and interfaces are important for multiple teams since it help to have a clear view of the known inputs and outputs of each micro-service.<\/li>\n<\/ul>\n<\/li>\n<li>Avoid chatty exchange between micro-services.<\/li>\n<li>The sharing of things like databases between two micro-services should avoided.\n<ul>\n<li>While it may seems like a good idea to share data such a database, but a change in the shared database will result in both micro-services having to change (i.e. new schema change)\n<ul>\n<li>This can lead to have to deploy both micro-services instead of one.<\/li>\n<\/ul>\n<\/li>\n<li>Force both micro-services to use the same database technology.<\/li>\n<\/ul>\n<\/li>\n<li>Minimize the use of shared libraries within the microservice.\n<ul>\n<li>i.e.: A bug fixed in a shared library would force us to deploy both micro-services.<\/li>\n<li>Perhaps that shared library should be a micro-service itself serving other micro-services.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Autonomous: Ownership and Versioning<\/strong><\/p>\n<p><a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3672\" rel=\"attachment wp-att-3672\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3672\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/Autonomous-team.png\" alt=\"\" width=\"535\" height=\"262\" srcset=\"http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/Autonomous-team.png 535w, http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/Autonomous-team-300x147.png 300w\" sizes=\"auto, (max-width: 535px) 100vw, 535px\" \/><\/a><\/p>\n<ul>\n<li>Each micro-service is owned by a team<\/li>\n<li>Small micro-services allow for small teams\n<ul>\n<li>Small teams will be better retention of knowledge about the micro-service.<\/li>\n<\/ul>\n<\/li>\n<li>It encourage small teams to build and maintain the micro-service autonomous.<\/li>\n<li>Teams are responsible to:\n<ul>\n<li>Design a micro-service that is independently changeable and deployable.<\/li>\n<li>Agreeing the contract between the micro-services.<\/li>\n<li>How the micro-services interact.<\/li>\n<li>Maintain the contract so future changes don&#8217;t break contracts with other micro-services.<\/li>\n<li>Long-term maintenance of the micro-service.<\/li>\n<\/ul>\n<\/li>\n<li>Ownership encourage to:\n<ul>\n<li>Collaborate with other teams.<\/li>\n<li>Communicate contract requirements.<\/li>\n<li>Communicate data requirements.<\/li>\n<li>Concurrent development.<\/li>\n<\/ul>\n<\/li>\n<li>Multiple teams can work on different micro-services at the same time plus agree in the interaction between these micro-services.<\/li>\n<li>When creating a new version of the micro-service, think about the versioning strategy for that micro-service.\n<ul>\n<li>Create a new version of the micro-service avoiding breaking other micro-services by changing the contract.<\/li>\n<\/ul>\n<\/li>\n<li>All new changes should be backwards compatible.\n<ul>\n<li>Other micro-services should be able to continue working without any change.<\/li>\n<li>Honor the original contract that was agreed.<\/li>\n<li>Ensure your new micro-services is not and will not break any existing contracts.<\/li>\n<\/ul>\n<\/li>\n<li>Use integration tests to test the change of the micro-service for inputs and outputs, plus shared models.\n<ul>\n<li>Test if the original contract is still intact.<\/li>\n<\/ul>\n<\/li>\n<li>If a new version of your micro-service includes breaking changes, then you have concurrent versions of your micro-service running.\n<ul>\n<li>An old and new version of your micro-service could be running at the same time.<\/li>\n<li>This allow a period of transition from the old micro-service and the new micro-service.<\/li>\n<\/ul>\n<\/li>\n<li>Use semantic versioning where the version number is made up of three numbers: Major.Minor.Patch\n<ul>\n<li>The major number increments if the new version of the micro-service is not backward compatible.<\/li>\n<li>The minor number increments while the new version of the micro-service is backward compatible.<\/li>\n<li>The path number increments if the new version of the micro-service have a defect fix\n<ul>\n<li>Plus, the overall micro-service is still backwards compatible.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>When you with to include both old and new code in the new version of the micro-service, we can have coexisting endpoints.\n<ul>\n<li>The original endpoint which points at the original code (old version), and have a new endpoint pointing at the new version.<\/li>\n<li>Consumer can slowly migrate from the old endpoint to the new endpoint.<\/li>\n<li>We can have a new version of a micro-service which has the old endpoint; however, the old endpoint can have a wrapper for the new endpoint.\n<ul>\n<li>In other words, you could have the old endpoint redirect the calls to the new endpoint.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Business Domain Centric<\/strong><\/p>\n<p>Micro-services should represent a business function or business domain.<\/p>\n<ul>\n<li>Define these business domains in a coarse manner.<\/li>\n<li>These business domains should represent departments or areas of the organization.<\/li>\n<li>Split each area into business functions or business areas.<\/li>\n<li>Have in consideration to review the benefits of splitting the micro-service further.<\/li>\n<li>Remember to have high cohesion.\n<ul>\n<li>A micro-service must\n<ul>\n<li>Do one thing and do it well.<\/li>\n<li>Have a single focus.<\/li>\n<li>Only one reason for it to change.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>See micro-services as components\n<ul>\n<li>Maps to different components.<\/li>\n<li>Functions within the organization.<\/li>\n<\/ul>\n<\/li>\n<li>When parts of the organization change, we know which specific micro-service should be affected.<\/li>\n<li>Agree to a common language.<\/li>\n<li>Fix incorrect boundaries.\n<ul>\n<li>Be ready to split a micro-service further.<\/li>\n<\/ul>\n<\/li>\n<li>Merge two or more micro-service into one if they are doing the same thing.<\/li>\n<li>Consider the inputs and outputs and the contracts existent between the micro-services.<\/li>\n<li>We can split the system by technical boundaries.\n<ul>\n<li>For example, we need a special micro-service for accessing data or improve performance.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Resilience<\/strong><\/p>\n<p>The entire system shouldn&#8217;t go down for one failure; therefore, we must design our micro-services for all known failures.<\/p>\n<ul>\n<li>Known Failures:\n<ul>\n<li>Downstream systems: Micro-services that carry our specific task\n<ul>\n<li>Internal and\/or external services.<\/li>\n<li>Network outages and network latencies.<\/li>\n<li>Timeouts.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Micro-service should degrade or default functionality on failure detection.<\/li>\n<li>Do not hang or delay a transaction. System should fail fast and recover fast.<\/li>\n<li>Use standard timeout length functionality between services communication.<\/li>\n<li>Our system should continuously monitor our timeouts and log our timeouts.\n<ul>\n<li>This can help to workout specific behaviors related.<\/li>\n<\/ul>\n<\/li>\n<li>Make issues transparent for health checks.<\/li>\n<\/ul>\n<p><strong>Observable: Centralized Monitor<\/strong><\/p>\n<p>Our system will consist of multiple micro-services and instances of micro-services; therefore, we must implement a centralized monitor system that allows us to see the system health.<\/p>\n<ul>\n<li>Monitor data in real time.<\/li>\n<li>Monitor health of the host\n<ul>\n<li>CPU usage, memory usage, and disk usage.<\/li>\n<li>Response times.<\/li>\n<li>Timeouts and number of timeout errors.<\/li>\n<li>Exceptions and errors.<\/li>\n<\/ul>\n<\/li>\n<li>Monitor service itself. Expose metrics within your service.<\/li>\n<li>Expand to include business data related metrics.\n<ul>\n<li>Number of orders.<\/li>\n<li>Average time from basket to checkout.<\/li>\n<\/ul>\n<\/li>\n<li>Collect and aggregate monitoring data.\n<ul>\n<li>From trends and history to details.<\/li>\n<li>Drill down options.<\/li>\n<\/ul>\n<\/li>\n<li>Visualize trends to spot patterns and potential problems.<\/li>\n<li>Compare data across servers.<\/li>\n<li>Trigger alerts\n<ul>\n<li>For example, trigger alarm when a measures exceeds a threshold.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Observable: Centralized Logging<\/strong><\/p>\n<p>We are recording detailed information about events. It is key for problem solving in a system of distributed transactions.<\/p>\n<ul>\n<li>Log when our micro-services start up and\/or shut down.<\/li>\n<li>Log code path milestones. For example:\n<ul>\n<li>Received a request<\/li>\n<li>Code decisions<\/li>\n<li>Give responses<\/li>\n<\/ul>\n<\/li>\n<li>Log timeouts, exceptions and errors<\/li>\n<li>Information logged should be structured and be consistent across the system.\n<ul>\n<li>A log may contain:\n<ul>\n<li>Level of information.<\/li>\n<li>Information state.<\/li>\n<li>Information regarding an error<\/li>\n<li>Debug information.<\/li>\n<li>Statistics that&#8217;s have being recorded.<\/li>\n<li>Date and time when event happened.<\/li>\n<li>Correlation ID so we can trace distributed transactions across our logs.\n<ul>\n<li>A unique ID which is assigned to every transactions.<\/li>\n<li>When the transaction becomes distributed, we can follow that transaction across our micro-services.<\/li>\n<\/ul>\n<\/li>\n<li>Host name so we know where the log entry came from.<\/li>\n<li>Service name and service instance so we know which micro-service made the log entry.<\/li>\n<li>A message which is the key information whic is associated with the event.\n<ul>\n<li>i.e.: Callstack details regarding the exception.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Keep structured logging format consistent.\n<ul>\n<li>This allows us to query the logging information.<\/li>\n<li>We can search for specific patterns and specific issues.<\/li>\n<\/ul>\n<\/li>\n<li>It allows to make transactions more traceable.<\/li>\n<\/ul>\n<p><strong>Automation: Continuous Integration Tools<\/strong><\/p>\n<p>The Continuous Integration tools provide an automatic way to do testing and feedback of your software changes.<\/p>\n<ul>\n<li>These tools work with the source control.<\/li>\n<li>Test software after check-in and change into the source control.<\/li>\n<li>Run unit tests and integration tests that have begin written.\n<ul>\n<li>Unit test and integration test are designed to test our production code.<\/li>\n<li>They test that a change or enhancement in the code hasn&#8217;t break the existing and new requirements.<\/li>\n<\/ul>\n<\/li>\n<li>Provide quick feedback.\n<ul>\n<li>If a micro-services breaks (itself or anything else that may use any of those micro-services), we will receive a quick feedback so we can fix it.<\/li>\n<\/ul>\n<\/li>\n<li>Provide useful Information on the quality of integration.<\/li>\n<li>Prevent issues to pile up.\n<ul>\n<li>Automatic feedback is sent to its respective teams so they can quickly fix the issue.<\/li>\n<\/ul>\n<\/li>\n<li>Culture Note: All teams should stop development until all the issues reported have being fixed.<\/li>\n<li>Integration tools can be use to build our software\u00a0\n<ul>\n<li>Test Driven Development<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Automation: Continuous Deployment Tools<\/strong><\/p>\n<p>These tools automate the software deployment.<\/p>\n<p><a href=\"http:\/\/www.acarlstein.com\/?attachment_id=3684\" rel=\"attachment wp-att-3684\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-3684\" src=\"http:\/\/www.elblender.com\/wordpress\/wp-content\/uploads\/2016\/12\/CD-deployment.png\" alt=\"\" width=\"492\" height=\"218\" srcset=\"http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/CD-deployment.png 492w, http:\/\/blog.acarlstein.com\/wp-content\/uploads\/2016\/12\/CD-deployment-300x133.png 300w\" sizes=\"auto, (max-width: 492px) 100vw, 492px\" \/><\/a><\/p>\n<ul>\n<li>The Continuous Integration tool creates the build that the Continuous Deployment tool will deploy.<\/li>\n<li>There could be multiple micro-services and multiple instances of those micro-services on different servers.\n<ul>\n<li>Each server could be running a different technology stack (i.e. Microsoft, Linux, Unix, etc)<\/li>\n<\/ul>\n<\/li>\n<li>It is time consuming to configure this tool; however, it is done once. In the long run, this tools saves a ton of time.\n<ul>\n<li>When a new version of a micro-service is available, the same configuration is used to re-deploy automatically.<\/li>\n<\/ul>\n<\/li>\n<li>As long as all the continuous integration test pass, the new version will be deployed.<\/li>\n<li>This tools provide the ability to release anytime upgrades.<\/li>\n<li>It allows to deploy new version of your software to the market in a quick and reliable way.\n<ul>\n<li>This improve customer experience.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n<script>\nvar zbPregResult = '0';\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>\u00a0icon-angle-left\u00a0Micro-services: Design Principles Introduction\u00a0|\u00a0Microservices: Technology\u00a0icon-arrow-right\u00a0 Summary of Principles to Implement High Cohesion: Small micro-service focused and single functionality. Single focus. Do a single thing and do it well done. Autonomous: Allow upgrade of different part without risking other parts in the system. Independently changeable. Independently deployable. Business Domain Centric: aligned with the overall organization structure. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[19,1472,1480],"tags":[1531,1522,1526,1529,1528,1532,1530,1311,1521,1523,1482,1479,1462,1524,1527,1525],"class_list":["post-3644","post","type-post","status-publish","format-standard","hentry","category-programming","category-architecture","category-microservices","tag-automation","tag-autonomous","tag-business-domain-centric","tag-centralized-logging","tag-centralized-monitor","tag-continuous-deployment-tools","tag-continuous-integration-tools","tag-design","tag-high-cohesion","tag-loosely-couple","tag-micro-services","tag-microservices","tag-observable","tag-ownership","tag-resilience","tag-versionship"],"_links":{"self":[{"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/posts\/3644","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3644"}],"version-history":[{"count":35,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/posts\/3644\/revisions"}],"predecessor-version":[{"id":3804,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=\/wp\/v2\/posts\/3644\/revisions\/3804"}],"wp:attachment":[{"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3644"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3644"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.acarlstein.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3644"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}