{"id":9230,"date":"2019-01-30T15:13:30","date_gmt":"2019-01-30T15:13:30","guid":{"rendered":"https:\/\/www.uruit.com\/blog\/?p=9230"},"modified":"2023-06-01T06:55:43","modified_gmt":"2023-06-01T09:55:43","slug":"microservices-architecture","status":"publish","type":"post","link":"https:\/\/uruit.com\/blog\/microservices-architecture\/","title":{"rendered":"Divide and Conquer: Microservices Challenges"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_17 counter-hierarchy counter-decimal ez-toc-grey\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\">Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" style=\"display: none;\"><i class=\"ez-toc-glyphicon ez-toc-icon-toggle\"><\/i><\/a><\/span><\/div>\n<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:\/\/uruit.com\/blog\/microservices-architecture\/#Microservices_challenges_and_how_its_changing_the_way_we_make_applications\" title=\"Microservices challenges and how it&#8217;s changing the way we make applications\">Microservices challenges and how it&#8217;s changing the way we make applications<\/a><ul class=\"ez-toc-list-level-4\"><li class=\"ez-toc-heading-level-4\"><ul class=\"ez-toc-list-level-4\"><li class=\"ez-toc-heading-level-4\"><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#In_this_post_I_want_to_give_a_brief_introduction_to_microservices_challenges_and_how_it_can_be_an_alternative_to_software_development\" title=\"In this post, I want to give a brief introduction to microservices challenges and how it can be an alternative to software development.\">In this post, I want to give a brief introduction to microservices challenges and how it can be an alternative to software development.<\/a><\/li><\/ul><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Lessons_learned_from_Rome\" title=\"Lessons learned from Rome\">Lessons learned from Rome<\/a><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Monolithic_applications_a_snowball\" title=\"Monolithic applications: a snowball\">Monolithic applications: a snowball<\/a><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#So_what_is_a_microservice\" title=\"So, what is a microservice?\">So, what is a microservice?<\/a><ul class=\"ez-toc-list-level-4\"><li class=\"ez-toc-heading-level-4\"><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Microservices_characteristics\" title=\"Microservices&#8217; characteristics:\">Microservices&#8217; characteristics:<\/a><\/li><\/ul><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Microservices_Challenges\" title=\"Microservices Challenges\">Microservices Challenges<\/a><ul class=\"ez-toc-list-level-4\"><li class=\"ez-toc-heading-level-4\"><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#What_happens_when_two_microservices_share_entities_or_relationships_with_other_entities\" title=\"What happens when two microservices share entities or relationships with other entities?\">What happens when two microservices share entities or relationships with other entities?<\/a><\/li><\/ul><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Why_should_you_try_microservices\" title=\"Why should you try microservices?\">Why should you try microservices?<\/a><ul class=\"ez-toc-list-level-4\"><li class=\"ez-toc-heading-level-4\"><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#At_the_moment_of_starting_the_monolithic_application_MA\" title=\"At the moment of starting the monolithic application (MA)\">At the moment of starting the monolithic application (MA)<\/a><\/li><\/ul><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#How_to_implement_microservices_without_dying_from_the_attempt\" title=\"How to implement microservices without dying from the attempt\">How to implement microservices without dying from the attempt<\/a><\/li><li class=\"ez-toc-page-1 ez-toc-heading-level-3\"><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/uruit.com\/blog\/microservices-architecture\/#Final_considerations_about_Microservices_challenges\" title=\"Final considerations about Microservices challenges\">Final considerations about Microservices challenges<\/a><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Microservices_challenges_and_how_its_changing_the_way_we_make_applications\"><\/span>Microservices challenges and how it&#8217;s changing the way we make applications<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The way to <a href=\"https:\/\/uruit.com\/product-development\">build software<\/a> has changed over time; there are now many paradigms, languages, architectures and methodologies. Building applications based on microservices does not guarantee that the application will be a success (there\u2019s no architecture nor methodology that guarantee that either), however <strong>it\u2019s an approach that will teach you to manage your logical resources, components or modules<\/strong>. As a result, you can replicate them in different projects throughout your career, optimize resources and scale your applications in an agile way. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">The beginning of my experience as a <a href=\"https:\/\/uruit.com\/blog\/software-developer-skills\/\" class=\"broken_link\" rel=\"nofollow\">software developer<\/a> was not easy; I had to change the paradigms I knew. I also had to read a lot, not only about technologies, but also about operating systems, volumes, and Unix sockets, among others things. In addition, I had to face challenges, and I am still facing them, because the implementations can be many, depending on the business requirements. This learning process didn\u2019t just last a few weeks, but over a year and I\u2019m still discovering new things! I had to learn to abstract a lot of business logic and divide it into reusable components, not only in one project, but also for use in other projects. Thinking about microservices definitely helped me to be a better programmer and take on new challenges, especially since the programming language takes a secondary role.<\/span><\/p>\n<h4><span class=\"ez-toc-section\" id=\"In_this_post_I_want_to_give_a_brief_introduction_to_microservices_challenges_and_how_it_can_be_an_alternative_to_software_development\"><\/span><b>In this post, I want to give a brief introduction to microservices challenges and how it can be an alternative to software development.<\/b><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p><span style=\"font-weight: 400;\">We won\u2019t focus on all the existing theory, such as design patterns, programming languages, frameworks, etc. Instead, this introduction will help us to understand many concepts (that we can go into more detail in future posts) about Backup as a Service (BaaS) and Disaster Recovery as a Service (DRaaS). If you want to explore more about microservices challenges, you can read the e-book, &#8220;Microservices from Design to Deployment,&#8221; published by NGINX; if you want to read about design patterns in microservices oriented architectures you can take a look at: https:\/\/microservices.io\/<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Lessons_learned_from_Rome\"><\/span><span style=\"font-weight: 400;\">Lessons learned from Rome<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">In software development, as in politics, (and certainly in many aspects of life) the decisions we make while planning our project will affect its continuity in a positive or negative way. Divide and conquer or divide and rule, is a political concept born in Rome from its need to control cities after defeating one of its greatest rivals: the Latin League, a confederation of more than 30 tribes. The concept is quite simple, instead of attacking 30 nations at the same time, they devised an adoption system in which each of the tribes could adhere to the empire and obtain its benefits. Other tribes had autonomy, but over time, gradually the independent tribes began adhering. Without much effort, they were able to control a large portion of land and people without having to use force.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This is a great example not only of conciliation, but optimal resource management as well, because trying to control the tribes would have triggered riots, the dissolution of powers, and an increased investment in its military to contain them. If we apply this to the framework of the general theory of systems, what Rome did is to <strong>divide a great system into several microsystems, thus diluting the entropy that can affect the great system by reducing it<\/strong>.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Monolithic_applications_a_snowball\"><\/span><span style=\"font-weight: 400;\">Monolithic applications: a snowball<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Generally, when we start a project, we use a code generator (such as SpringBoot, Cobuild, or Maven, among others) or simply clone a boilerplate, where the core of our application becomes the business logic implemented by modules that define services. Finally, around this, we create interfaces that serve as adapters for the outside.<\/span><\/p>\n<figure id=\"attachment_9231\" aria-describedby=\"caption-attachment-9231\" style=\"width: 3508px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" class=\"wp-image-9231 size-full\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/elmo1.jpg\" alt=\"\" width=\"3508\" height=\"2480\" \/><figcaption id=\"caption-attachment-9231\" class=\"wp-caption-text\">Image 1: Example of an application. (Image taken from Microservices: From Design to Deployment, a free e-book from NGINX)<\/figcaption><\/figure>\n<p><span style=\"font-weight: 400;\">Applications that implement this architecture are extremely common and easy to implement, \u00a0test and deploy. You can also easily scale them by simply duplicating the application and running it behind a load balancer. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Unfortunately, this approach has a serious limitation: <strong>the complexity of implementation and deployment grows at the same rate as the application itself, just as a snowball would grow<\/strong>. I have seen this when I talk with other friends who have worked in traditional financial companies, where one of their main complaints is the difficulty of learning about a project. Typically, the installation of the development environment isn\u2019t easy, so these applications take more than 10 minutes to compile and even start; imagine the effort required to make an emergency deployment! You could almost forget about your weekend if you have to deploy something on a Friday night. As you can see, it\u2019s difficult to follow agile development in that type of project.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Monolithic applications are difficult to scale since many of their modules are competing for the system\u2019s resources.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"So_what_is_a_microservice\"><\/span><span style=\"font-weight: 400;\">So, what is a microservice?<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><strong><a href=\"https:\/\/microservices.io\/index.html\" class=\"external\" rel=\"nofollow\">A microservice is an architecture<\/a><\/strong><span style=\"font-weight: 400;\"><strong>\u00a0in which each module, or piece of the application, is conceived as a unit<\/strong>; an isolated, separate service, but communicates\u2014through network interfaces\u2014with other isolated modules. Unlike monolithic applications, these microservices have their own scope, are independent and communicate with each other to obtain services, that is, a service requesting services. There are many technologies to implement them; Docker is the most famous along with Docker Compose and Kubernetes, which are dominating the container providers market. In this post, we will always talk about Docker, Docker Compose and Kubernetes. All these interactions and their set <\/span><span style=\"font-weight: 400;\">\u2014<\/span><span style=\"font-weight: 400;\">that is, the sum of all these microservices<\/span><span style=\"font-weight: 400;\">\u2014<\/span><span style=\"font-weight: 400;\"> make the application work.<\/span><\/p>\n<figure id=\"attachment_9232\" aria-describedby=\"caption-attachment-9232\" style=\"width: 3508px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" class=\"wp-image-9232 size-full\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/elmo2.jpg\" alt=\"\" width=\"3508\" height=\"2480\" \/><figcaption id=\"caption-attachment-9232\" class=\"wp-caption-text\">Image 2: The previous application decomposed in microservices. (Image taken from Microservices: From Design to Deployment, a free e-book from NGINX)<\/figcaption><\/figure>\n<p><span style=\"font-weight: 400;\">Unlike Image 1, Image 2 describes each module of the application implemented as a microservice. For example, if you need to make changes in the notification module, you would only have to deploy that specific microservice, independently of the other application components.<\/span><\/p>\n<h4><span class=\"ez-toc-section\" id=\"Microservices_characteristics\"><\/span><span style=\"font-weight: 400;\">Microservices&#8217; characteristics:<\/span><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Decentralization<\/strong>: the microservices are distributed through the system with decentralized data<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Independence<\/strong>: each microservice does not depend on another to operate<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>The principle of single responsibility<\/strong>: each microservice has a function, and it must do it well<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Being a polyglot<\/strong>: it does not matter the language in which the microservice was written (Node, Python, Java or any desired programming language)<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Black box<\/strong>: microservices do not expose the complexity of their implementation<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Communication protocols<\/strong>: every microservice has its communication protocol with other microservices; this can be via sockets, http, grpc, etc.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">The S.O.L.I.D (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency investment) principle is the theoretical concept behind microservices; but to execute it in practice poses many challenges.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Microservices_Challenges\"><\/span><span style=\"font-weight: 400;\">Microservices Challenges<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Although I had already worked with microservices in previous work experiences and in my personal projects, I faced a project which posed some difficulty. Even though I was told that the project was microservices-oriented, the dataflow and its implementation\u2014perhaps due to a lack of knowledge of microservices\u2019 characteristics or for convenience\u2014ignored the responsibility of each microservice. This may sound like a problem but it\u2019s not because the needs of the project should prevail over the theory. This is something common that happens in microservices projects; <strong>there is still no methodology for how to implement them successfully, nor is there a microservices market available where you can buy and reuse them in your projects<\/strong> to save time and money. In this project, each module was separated as its own microservice:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The &#8220;cars&#8221; module was separated as a microservice.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The &#8220;users&#8221; module was separated as a microservice.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The &#8220;invoices&#8221; module was separated as a microservice.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">And, there was a gateway microservice. Theoretically, this microservice serves as the entry point for a client (web, mobile, iot, etc &#8230;); its responsibility is to redirect each request to the appropriate microservice.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">Each microservice (except the gateway) had its own database.<\/span><\/p>\n<figure id=\"attachment_9244\" aria-describedby=\"caption-attachment-9244\" style=\"width: 300px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" class=\"wp-image-9244 size-medium\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/image-300x225.png\" alt=\"\" width=\"300\" height=\"225\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/image-300x225.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/image-20x15.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/image.png 552w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><figcaption id=\"caption-attachment-9244\" class=\"wp-caption-text\">Surely, you have already noticed one of the first challenges.<\/figcaption><\/figure>\n<h4><span class=\"ez-toc-section\" id=\"What_happens_when_two_microservices_share_entities_or_relationships_with_other_entities\"><\/span><b>What happens when two microservices share entities or relationships with other entities?<\/b><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p><span style=\"font-weight: 400;\">Normally, many of the models maintain a relationship with the &#8220;users&#8221; entity. In a monolithic application, each module shares its entities, since these are in the same directory (in the case of interpreted languages) or in the same memory space (in the case of compiled languages). In this particular case, they were in completely independent scopes, where these entities only know the interfaces that the other entities know. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">To solve this problem, depending on the complexity, you could choose one of these approaches:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">A microservice for the database of your application and a database for exclusive use of your microservice.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Using replicas, however, isn\u2019t a good idea; the spatial cost would be very large, unless you need very high availability.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Each microservice implementing an interface that allows other microservices to interact with it. Theoretically, this is good, however, we would be adding extra load to our microservices network. Although we would follow the theory literally, it\u2019s not convenient if we want to use ORMs.<\/span><\/li>\n<\/ol>\n<p><b>If the problem is to share code, <\/b><span style=\"font-weight: 400;\">you could consider separating the common code in libraries and storing them in repositories to be installed via Gitflow. Another common problem when developing microservices <\/span><b>is failing to identify responsibilities properly.<\/b><span style=\"font-weight: 400;\"> I have seen gateways that implement business logic and some cases where they make the monolithic application an entire microservice. This brings some inconveniences:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><b>What happens when 80% of the requests are directed to a small portion of this application?<\/b><span style=\"font-weight: 400;\"> Resources are wasted.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>What happens if an event occurs and the heavy microservice stops responding?<\/b><span style=\"font-weight: 400;\"> Two things might happen: raising this microservice will be expensive in terms of processing; if the lifetime periods are too short, you could replicate this heavy microservice. If you replicate it, you\u2019re wasting even more resources.<\/span><\/li>\n<\/ol>\n<h3><span class=\"ez-toc-section\" id=\"Why_should_you_try_microservices\"><\/span><span style=\"font-weight: 400;\">Why should you try microservices?<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\"><strong>The architecture of microservices brings several advantages<\/strong>. If you do it well, development will be less chaotic, deployment times will be shorter, a failure would not imply 0% availability, and you can integrate new features easily (scalability). In addition, you will be able to reuse them in most of your future projects. Last but not least, you will consume fewer resources in the cloud, meaning you\u2019ll save money. You don\u2019t have to believe me; instead, you could believe the authors of &#8220;Performance Evaluation of Microservices Architectures using Containers,&#8221; a project supported by IBM, where they concluded that:<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">Containers are gaining momentum because they offer lightweight OS virtualization capabilities. They are commonly used to host single processes in isolation on the system. While they offer clear advantages in terms of lightness and performance under several circumstances, they show limitations from the infrastructure management perspective. On the other hand, Server Virtualization has been widely adopted across sectors and industries because it provides simple mechanisms to manage the infrastructure, and group processes and applications. But it introduces several significant penalties in terms of deployment time, memory and processing overheads that vary with the nature of the applications that they host.<\/span><\/p>\n<p>Reference: Performance Evaluation of Microservices<br \/>\nArchitectures using Containers, link:https:\/\/core.ac.uk\/download\/pdf\/81578653.pdf<\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">This is so because, unlike the monolithic application, this app would run while being distributed in different threads. Besides, the operating system will be able to better dispense its resources according to the demand of each. Pay attention to this conversation of a monolithic application with the operating system:<\/span><\/p>\n<h4><span class=\"ez-toc-section\" id=\"At_the_moment_of_starting_the_monolithic_application_MA\"><\/span><span style=\"font-weight: 400;\">At the moment of starting the monolithic application (MA)<\/span><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p><img loading=\"lazy\" class=\"aligncenter wp-image-9233 size-medium\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-300x283.png\" alt=\"\" width=\"300\" height=\"283\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-300x283.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-1024x967.png 1024w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-768x726.png 768w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-1536x1451.png 1536w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-750x709.png 750w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-1140x1077.png 1140w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4-20x20.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat4.png 1682w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">Assuming that the application receives 500 requests per minute just for login, MA will be reserving memory for all application modules, no matter how much load they are receiving. In this conversation, perhaps the &#8220;users&#8221; module (assuming you&#8217;re using it for login) only occupies 80MB of RAM. The rest of the modules occupy 432 MB, and not only is RAM wasted, but also processing time. If you have handled a cloud provider, you\u2019ll notice that this will cost money and no one likes to lose money.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In the case of microservices, the conversation would be a little different, it would have more voices; from the &#8220;users&#8221; microservice (UM), to the &#8220;cars&#8221; microservice (CM), the gateway microservice (GM), and finally a microservice for the database (DB).<\/span><\/p>\n<p><img loading=\"lazy\" class=\"aligncenter size-medium wp-image-9236\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-300x283.png\" alt=\"\" width=\"300\" height=\"283\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-300x283.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-1024x967.png 1024w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-768x726.png 768w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-1536x1451.png 1536w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-750x709.png 750w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-1140x1077.png 1140w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3-20x20.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat3.png 1682w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><img loading=\"lazy\" class=\"aligncenter size-medium wp-image-9237\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-300x283.png\" alt=\"\" width=\"300\" height=\"283\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-300x283.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-1024x967.png 1024w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-768x726.png 768w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-1536x1451.png 1536w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-750x709.png 750w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-1140x1077.png 1140w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2-20x20.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat2.png 1682w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><img loading=\"lazy\" class=\"aligncenter size-medium wp-image-9238\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-300x283.png\" alt=\"\" width=\"300\" height=\"283\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-300x283.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-1024x967.png 1024w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-768x726.png 768w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-1536x1451.png 1536w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-750x709.png 750w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-1140x1077.png 1140w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1-20x20.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat1.png 1682w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><img loading=\"lazy\" class=\"aligncenter size-medium wp-image-9239\" src=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-300x283.png\" alt=\"\" width=\"300\" height=\"283\" srcset=\"https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-300x283.png 300w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-1024x967.png 1024w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-768x726.png 768w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-1536x1451.png 1536w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-750x709.png 750w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-1140x1077.png 1140w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5-20x20.png 20w, https:\/\/uruit.com\/blog\/wp-content\/uploads\/2019\/01\/chat5.png 1682w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">The gateway will receive all the requests and will redirect them to the corresponding microservices. This means that the OS will allocate more resources for itself, while reducing the resources (mostly processing and memory exchange) for the microservices of low use. This means that there will be better system resource management. In terms of cloud, you will not have to pay so much for what you barely use&#8230; Now that starts to make some \u201ccents\u201d\u2026 Right?<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"How_to_implement_microservices_without_dying_from_the_attempt\"><\/span><span style=\"font-weight: 400;\">How to implement microservices without dying from the attempt<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Implementing microservices is not an easy task. However, if you properly define the responsibilities, the communication protocols and the data flows, it can be a success. Here are some basic tips for implementing it properly and overcoming common microservices challenges:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Focus on making your microservice reusable regardless of the project<\/strong>. You could start building a gateway; without any business logic, (only the one you need to execute your task) which means, redirecting requests. In addition, the majority of applications will need authentication, access control or messaging services between them; you could use <\/span><a href=\"https:\/\/nats.io\/\" class=\"external\" rel=\"nofollow\"><span style=\"font-weight: 400;\">https:\/\/nats.io\/<\/span><\/a><span style=\"font-weight: 400;\"> to broadcast messages from one microservice to another.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">There\u2019s no need to be a purist; there is no rule to follow, so use what you need!<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Examine other microservices in public repositories.<\/strong>\u00a0Github or Docker hub are good options, as there are people who are doing it really well.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><strong>Use a container management platform<\/strong> for your microservices, for example, Kubernetes.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Stop if you realize that you are adding responsibilities from one microservice to another that has nothing to do with it.<\/span><\/li>\n<\/ol>\n<h3><span class=\"ez-toc-section\" id=\"Final_considerations_about_Microservices_challenges\"><\/span><span style=\"font-weight: 400;\">Final considerations about Microservices challenges<\/span><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Microservices are expensive; you need to invest time and effort to build quality microservices. However, this opens the door to a world of possibilities. My experience with microservices at previous projects has left me with some great lessons, not only about software development, but also about networks, operating systems, and methodologies. Generally, companies, due to a lack of resources, cannot devote a team only to the development of these components. However, during the execution of our clients&#8217; projects, we could (incrementally) start to create and refine our microservices. I developed microservices for pre-rendering pages in JavaScript, gateways, authentication, access control, SQLProxy of Gcloud, headless chrome, and bookstack for documentation. Also, I deployed Moodle as a microservice, and created a sandbox. I did not develop them overnight; on the contrary, we <\/span><b>defined a thorough methodology for building them:<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Choose a project to start. Preferably a new project, which allows you to create the structure to your liking.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Share the microservice with your colleagues.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Your colleagues can then create tickets for missing functionalities. Also, they can even implement them on their own: they create a branch, test it, and generate the tests. Finally, a PR is made to the microservice.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The team should make notification of the change and if there are side effects (there shouldn\u2019t be any, or at least none that are critical). <\/span><strong>Do remember that the key to microservices is simplicity<\/strong><i><span style=\"font-weight: 400;\">.<\/span><\/i><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The other developers who use the microservice decide whether to update or not. <\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">If we can reuse NPM libraries, <\/span><b>why couldn\u2019t we reuse microservices or even sell them?<\/b><span style=\"font-weight: 400;\"> We could have a microservice for functionalities such as:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Gateway<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Authentication<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Access control<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Caching<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Mailing and notifications<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Pre-rendering<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">In upcoming posts, we will talk more about Disaster Recovery as a Service (DRaaS) and Backup as a Service (BaaS), but before reaching those subjects, I had to give an introduction to microservices challenges because we will need many of these concepts for future reference. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Thank you for reading!<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Contents Microservices challenges and how it&#8217;s changing the way we make applicationsIn this post, I want to give a brief introduction to microservices challenges and how it can be an&#8230;<\/p>\n","protected":false},"author":30,"featured_media":9243,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[276],"tags":[],"_links":{"self":[{"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/posts\/9230"}],"collection":[{"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/comments?post=9230"}],"version-history":[{"count":5,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/posts\/9230\/revisions"}],"predecessor-version":[{"id":9891,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/posts\/9230\/revisions\/9891"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/media\/9243"}],"wp:attachment":[{"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/media?parent=9230"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/categories?post=9230"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/uruit.com\/blog\/wp-json\/wp\/v2\/tags?post=9230"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}