{"id":17635,"date":"2020-01-20T10:08:09","date_gmt":"2020-01-20T09:08:09","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=17635"},"modified":"2022-11-21T16:11:34","modified_gmt":"2022-11-21T15:11:34","slug":"microservices-in-the-wild-part-1","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/","title":{"rendered":"Hype Meets Harsh Reality: Microservices in the Wild Part 1"},"content":{"rendered":"<p>Microservice architecture is one of the buzzwords that has notably influenced software development in recent years. This influence went as far as basically branding the term \u2018monolith\u2019 as a bad practice. Monoliths seemingly have to be avoided at all costs and microservices, therefore, appear to be inevitable. That&#8217;s why many projects start with this architecture from the very beginning if they have the possibility. Some longer living systems are being <a href=\"https:\/\/www.inovex.de\/de\/leistungen\/replatforming\/\">rebuilt or restructured<\/a> to follow this approach as well. But this process is often more difficult by quite a lot.<\/p>\n<p>At inovex we obviously talk about this approach to building systems quite often, and we did so during this exemplary project: The following article is about whether, when, why and how we moved a pre-existing monolithic system towards a microservice structure. Our intention is to help you better understand the implications and possible risks of such an introduction with empirical values, i.e. real-world experiences.<!--more--><\/p>\n<p>&nbsp;<\/p>\n<figure id=\"attachment_17642\" aria-describedby=\"caption-attachment-17642\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-17642 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-1024x724.jpg\" alt=\"monoliths vs. microservices\" width=\"1024\" height=\"724\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-1024x724.jpg 1024w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-300x212.jpg 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-768x543.jpg 768w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-1536x1086.jpg 1536w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-2048x1448.jpg 2048w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-1920x1358.jpg 1920w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-400x283.jpg 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/buildings-360x255.jpg 360w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-17642\" class=\"wp-caption-text\">monoliths vs. microservices<\/figcaption><\/figure>\n<p>This article covers the migration of a non-greenfield project. Our project revolves around a pre-existing system, which has to continue running during the migration process. In addition, we have some technical and organisational constraints. We will not cover the basics of what microservices are and presume at least a rudimentary understanding of the implications of this architectural type. There are plenty of sources out there that explain this concept in-depth very well and cover the (dis)advantages of building microservice systems.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_79_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#This-is-a-Series-of-Blog-Posts\" >This is a Series of Blog Posts<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Why-is-There-a-Monolith-at-All\" >Why is There a Monolith at All?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Other-Projects\" >Other Projects<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Status-Quo-%E2%80%9Cin-between%E2%80%9C\" >Status Quo: \u201cin-between\u201c<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Why-we-needed-a-change\" >Why we needed a change<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Team-Constellation\" >Team Constellation<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Team-Growth\" >Team Growth<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#What-Made-it-Easier\" >What Made it Easier<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#The-New-Stuff\" >The New Stuff<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#New-Features\" >New Features<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#New-Tech\" >New Tech<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#What-Could-go-Wrong\" >What Could go Wrong?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Right-before-the-migration\" >Right before the migration<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#Coming-up-next\" >Coming up next<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"This-is-a-Series-of-Blog-Posts\"><\/span>This is a Series of Blog Posts<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>This article is the result of a project that started more than three years ago and is still ongoing. As you can imagine a lot happens in such a timeframe, which is why we have divided the article into several parts:<\/p>\n<ol>\n<li>This is the part you are currently reading. We&#8217;ll give you an introduction to the reasons that caused us to consider a change. We also show the status quo that existed before our migration towards a more microservice-oriented architecture.<\/li>\n<li>The second part contains the description of everything that changed and parts of the setup that did not change (yet). This includes some of the reasons for the specific actions we took and those we skipped.<\/li>\n<li>The final part sums up the whole project: We draw conclusions about what changed for the better or worse and whether we recommend anyone else to follow the path we took during the past year.<\/li>\n<\/ol>\n<h2><span class=\"ez-toc-section\" id=\"Why-is-There-a-Monolith-at-All\"><\/span>Why is There a Monolith at All?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Clearly, the initial decision for the architecture of this project was to go with a monolithic application. To better understand this choice, we want to have a look at our goals for many projects that start on a greenfield. Most of these projects start out as MVPs or POCs with very limited time and budget frames. Additionally, the requirements for those systems rarely contain the expectancy of a big number of users (&gt;=10.000) once the platform goes live at some point. The expected long term scaling of such systems is rather small as well.<\/p>\n<p>Especially at the beginning, we try to keep the complexity of those products as low as possible. Often, a project is implemented according to startup ideas: reach a result with a minimal set of initial features in as little as possible time spent. As a result of this, there may even be <em>quick &amp; dirty<\/em> solutions that are sustainable for the moment but will have to be replaced one day.<\/p>\n<p>Yet you keep asking yourself whether it might be worth following the microservice pattern. This is also the case in this project. We discussed the question explicitly in the team at the beginning of the project (size: 2\u20133 developers in the first 18 months for backend, frontend and mobile). We decided against it because we had to expect disadvantages in operations, error analysis and stability due to the increased complexity and the distributed architecture.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Other-Projects\"><\/span>Other Projects<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>In other projects, however, we try to make big decisions about design and technology for the coming years right at the beginning. Over-engineering usually plays a major role here and in the first few months, you are often more occupied with the technological side of things than with functional features anyway. Experience shows time and again that it is completely sufficient to make decisions based on the most pressing current challenges and problems. It is not necessary to design each action completely decoupled and asynchronously right from the beginning. Asynchronicity itself causes complexity in many aspects.<\/p>\n<p>One example of this is the delivery of emails. If we were to send important emails asynchronously, e.g. those confirming the registration, we would at least have to implement a simple retry and queuing mechanism. We opted for the synchronous variant because the implementation effort was significantly lower. In addition, we did not need a highly available, error-tolerant and highly scalable solution.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Status-Quo-%E2%80%9Cin-between%E2%80%9C\"><\/span>Status Quo: \u201cin-between\u201c<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>During the first year, our setup turned out to work very well. The service was easily maintainable and we didn&#8217;t run into serious problems with the monolith solution. Only singular, very small parts were built into additional separate applications. Those parts treated very different issues and also needed to be deployed independently to additional hosts and\/or regions. Many of those services shared a single database which still meant an extensive degree of coupling.<\/p>\n<p>Another aspect that was very straight forward in the context of a monolithic system was testing. Integration testing did only require dependencies like a database to be executed with the tested application. End-to-end testing was quite easy as well since backend and frontend were packaged into one build file and distributed together. So, if everything was marvellous, why did we think about changing the existing system?<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Why-we-needed-a-change\"><\/span>Why we needed a change<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>In time we met changes and therefore new requirements for the system that demanded some form of change.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Team-Constellation\"><\/span>Team Constellation<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>One of those changes interestingly concerned the team, which grew considerably over time. This obviously meant that more people were working on the project simultaneously. They were mostly distributed over different features and parts of the application (such as a split between backend, frontend and mobile applications). Having more people on the team means more changes to the system coming in at any given time. This includes various side effects on other parts of the system caused by a change. That way some initially seemingly small features can become quite complicated since they have an impact on existing features. This requires further changes to the existing codebase which again might interfere with the work of a colleague being done at the same time.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Team-Growth\"><\/span>Team Growth<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<figure id=\"attachment_17638\" aria-describedby=\"caption-attachment-17638\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-17638 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-1024x648.jpeg\" alt=\"horde of developers\" width=\"1024\" height=\"648\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-1024x648.jpeg 1024w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-300x190.jpeg 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-768x486.jpeg 768w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-1536x972.jpeg 1536w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-400x253.jpeg 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af-360x228.jpeg 360w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/11\/photo-1504329779896-a7e131ac23af.jpeg 1691w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-17638\" class=\"wp-caption-text\">Team grows up<\/figcaption><\/figure>\n<p>The growth of the team also meant that we had to address the issue of distribution of knowledge among the team members in two ways, the first of which is sharing knowledge. New members of the team did not have the same deep knowledge of the application as the old team did. Yet one of the obvious goals that come with building a bigger team is to share as much knowledge as possible with your team members. Especially the goal to make the team itself and their development progress more tolerant to single developers being unavailable at any given time. Learning about the existing code base, all its features and system-internal dependencies was made a lot more difficult by the huge scope of the single monolithic application, especially with only very little and somewhat blurred separation of features.<\/p>\n<p>Of course, the opposite of this would have been cleanly cut microservices where each service caters to a singular functional concern. Implementing new features or extending existing ones included an extensive amount of explaining or looking for code that would be affected by side effects. The result of all this was an increased risk of failure with every deployment of the big monolithic application.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"What-Made-it-Easier\"><\/span>What Made it Easier<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>What actually helped a lot to notice side effects was a good test coverage of the application. This includes integration testing and end-to-end tests. The automatic test pipelines are able to discover most of breaking changes before they were deployed anywhere. From time to time some mistakes made it into the productive system anyway of course. The search for bugs was also hampered by the big monolithic application and the tight coupling of components. Extensive logging of both successful actions and errors was of essence in this scenario.<\/p>\n<p>The second issue connected to team growth was knowledge lying with single developers instead of being distributed across multiple members of the team. This again would lead to the team at least being held back in their capacity to react to bugs or to continue development on specific features. More so if the one person holding this specific knowledge would be temporarily or permanently unavailable.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The-New-Stuff\"><\/span>The New Stuff<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"New-Features\"><\/span>New Features<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>With the progress of the project, two types of new features came along. One of those could be matched with the then-present application. The extensions of the existing application alone made up a considerable amount of required additions to the monolith. This implied the risk of necessary changes becoming too big due to an already huge codebase. At this point, some version upgrades were already assessed as being too risky or too big to address for the time being. The second type of new features belonged to a new domain that was well separable from the then-present application. Both of these circumstances together strongly indicated the benefits of new services. Services with their own functional domains instead of the continued extension of the already quite big application.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"New-Tech\"><\/span>New Tech<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Another factor for the decision to start moving towards microservices was the developers&#8216; interest in newer technologies and the eagerness to keep the product up-to-date with recent updates. The upgrade to new major versions of essential technologies like Spring Boot turned out to be both quite difficult and risky. By separating the system into multiple services, major version updates were expected to become easier. Experience on how to set up the new major versions could be gathered within newly set up services as well.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"What-Could-go-Wrong\"><\/span>What Could go Wrong?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>From the beginning we expected some aspects like testing that were quite easy before to become more complex. Since we also knew about the benefits mentioned before this could not stop us from moving towards a microservice architecture.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Right-before-the-migration\"><\/span>Right before the migration<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Before we took the first steps of the migration, we had four services. Four of those are very small and only contain small singular technical features. Additionally, we have one monolithic application that encompasses all remaining functional features. On top of that we have the following architecture:<\/p>\n<ul>\n<li>There are four applications\/services in total\n<ul>\n<li>The main application in its monolithic form<\/li>\n<li><i>mqtt-http-auth-service: <\/i>handles the authentication for the message broker<\/li>\n<li><i>mqtt-service: <\/i>listens to a subset of special messages on the message broker and writes those to a database<\/li>\n<li><i>vnc-service: <\/i>small independent service that had little to do with the rest of the application and served a purely technical purpose<\/li>\n<\/ul>\n<\/li>\n<li>Services do not need to communicate with each other, but there is some data that is read from or written to the database by multiple services<\/li>\n<li>Our DBMS is built with multiple tables inside one single database that is shared between all the services<\/li>\n<li>The static (SPA) frontend lies within the main application\u2019s WAR-file and is therefore deployed alongside the monolithic backend. The other services do not depend on the frontend.<\/li>\n<li>There are integration tests on the API endpoints and end-to-end tests with the frontend. Both can be executed on the single applications&#8216; build output from within the CI pipeline<\/li>\n<li>An MQTT Broker for messages between our services and a number of external IoT devices<\/li>\n<\/ul>\n<figure id=\"attachment_17903\" aria-describedby=\"caption-attachment-17903\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-17903 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-1024x724.jpg\" alt=\"diagram of application before migration\" width=\"1024\" height=\"724\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-1024x724.jpg 1024w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-300x212.jpg 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-768x543.jpg 768w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-1536x1086.jpg 1536w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-2048x1448.jpg 2048w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-1920x1358.jpg 1920w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-400x283.jpg 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2019\/12\/microservicemigration_diagram-1-360x255.jpg 360w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-17903\" class=\"wp-caption-text\">The architecture of our application before the migration.<\/figcaption><\/figure>\n<h2><span class=\"ez-toc-section\" id=\"Coming-up-next\"><\/span>Coming up next<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>This is it for now. You should know about our reasons to go for the microservice architecture and also our expectations for this change.<\/p>\n<p>In <a href=\"https:\/\/www.inovex.de\/blog\/microservices-in-the-wild-part-2\/\">part 2 of the series<\/a> we will talk about the actual changes that have been made. But we will also shed light on the steps we intentionally did not take when leaving our monolithic system behind.<\/p>\n<p><span style=\"font-size: 8pt;\">All pictures except title are taken from Unsplash.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Microservice architecture is one of the buzzwords that has notably influenced software development in recent years. This influence went as far as basically branding the term \u2018monolith\u2019 as a bad practice. Monoliths seemingly have to be avoided at all costs and microservices, therefore, appear to be inevitable. That&#8217;s why many projects start with this architecture [&hellip;]<\/p>\n","protected":false},"author":138,"featured_media":18029,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[508,68,298,79],"service":[424,425],"coauthors":[{"id":138,"display_name":"Daniel Schreier","user_nicename":"dschreier"}],"class_list":["post-17635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-agile-2","tag-backend","tag-microservices","tag-replatforming","service-agile","service-backend"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2020-01-20T09:08:09+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-21T15:11:34+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Daniel Schreier\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1-1024x576.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Schreier\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"10\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Daniel Schreier\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\"},\"author\":{\"name\":\"Daniel Schreier\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/3dcec5277d616c22a8bcd132e05266d5\"},\"headline\":\"Hype Meets Harsh Reality: Microservices in the Wild Part 1\",\"datePublished\":\"2020-01-20T09:08:09+00:00\",\"dateModified\":\"2022-11-21T15:11:34+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\"},\"wordCount\":2057,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png\",\"keywords\":[\"Agile\",\"Backend\",\"Microservices\",\"Replatforming\"],\"articleSection\":[\"Applications\",\"English Content\",\"General\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\",\"url\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\",\"name\":\"Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png\",\"datePublished\":\"2020-01-20T09:08:09+00:00\",\"dateModified\":\"2022-11-21T15:11:34+00:00\",\"description\":\"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage\",\"url\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png\",\"contentUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png\",\"width\":1920,\"height\":1080,\"caption\":\"A monolith being broken up into microservices\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.inovex.de\/de\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Hype Meets Harsh Reality: Microservices in the Wild Part 1\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.inovex.de\/de\/#website\",\"url\":\"https:\/\/www.inovex.de\/de\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.inovex.de\/de\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\/\/www.inovex.de\/de\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/inovexde\",\"https:\/\/x.com\/inovexgmbh\",\"https:\/\/www.instagram.com\/inovexlife\/\",\"https:\/\/www.linkedin.com\/company\/inovex\",\"https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/3dcec5277d616c22a8bcd132e05266d5\",\"name\":\"Daniel Schreier\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/image\/a11a42c606092f7ee403db62eade98be\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c528335d505d7f130b20e35aaf89128199bd030768fffdda98423a4ddc19877c?s=96&d=retro&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c528335d505d7f130b20e35aaf89128199bd030768fffdda98423a4ddc19877c?s=96&d=retro&r=g\",\"caption\":\"Daniel Schreier\"},\"url\":\"https:\/\/www.inovex.de\/de\/blog\/author\/dschreier\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH","description":"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/","og_locale":"de_DE","og_type":"article","og_title":"Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH","og_description":"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.","og_url":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2020-01-20T09:08:09+00:00","article_modified_time":"2022-11-21T15:11:34+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png","type":"image\/png"}],"author":"Daniel Schreier","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1-1024x576.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Daniel Schreier","Gesch\u00e4tzte Lesezeit":"10\u00a0Minuten","Written by":"Daniel Schreier"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/"},"author":{"name":"Daniel Schreier","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/3dcec5277d616c22a8bcd132e05266d5"},"headline":"Hype Meets Harsh Reality: Microservices in the Wild Part 1","datePublished":"2020-01-20T09:08:09+00:00","dateModified":"2022-11-21T15:11:34+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/"},"wordCount":2057,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png","keywords":["Agile","Backend","Microservices","Replatforming"],"articleSection":["Applications","English Content","General"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/","url":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/","name":"Hype Meets Harsh Reality: Microservices in the Wild Part 1 - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png","datePublished":"2020-01-20T09:08:09+00:00","dateModified":"2022-11-21T15:11:34+00:00","description":"Everyone wants to leave monoliths behind for new and shiny microservices these days. We have a look at the implications this had for our real-world project and why you would (not) want to go down that road.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/01\/monoliths-microservices-1.png","width":1920,"height":1080,"caption":"A monolith being broken up into microservices"},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/microservices-in-the-wild-part-1\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Hype Meets Harsh Reality: Microservices in the Wild Part 1"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/3dcec5277d616c22a8bcd132e05266d5","name":"Daniel Schreier","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/image\/a11a42c606092f7ee403db62eade98be","url":"https:\/\/secure.gravatar.com\/avatar\/c528335d505d7f130b20e35aaf89128199bd030768fffdda98423a4ddc19877c?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c528335d505d7f130b20e35aaf89128199bd030768fffdda98423a4ddc19877c?s=96&d=retro&r=g","caption":"Daniel Schreier"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/dschreier\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/17635","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/138"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=17635"}],"version-history":[{"count":1,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/17635\/revisions"}],"predecessor-version":[{"id":39480,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/17635\/revisions\/39480"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/18029"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=17635"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=17635"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=17635"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=17635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}