{"id":22697,"date":"2021-03-22T03:53:00","date_gmt":"2021-03-22T03:53:00","guid":{"rendered":"https:\/\/www.experfy.com\/blog\/is-microservices-the-best-answer-for-all-software-problems-valid-in-post-covid-world\/"},"modified":"2023-08-29T12:11:25","modified_gmt":"2023-08-29T12:11:25","slug":"is-microservices-the-best-answer-for-all-software-problems-valid-in-post-covid-world","status":"publish","type":"post","link":"https:\/\/www.experfy.com\/blog\/software-ux-ui\/is-microservices-the-best-answer-for-all-software-problems-valid-in-post-covid-world\/","title":{"rendered":"Is Microservices The Best Answer For All Software Problems? Is It Still Valid In The Post-Covid World?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Mainframe Modernization entails the process of migrating or improving the IT operations to reduce IT spending efficiently.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Microservice Architecture has been a hot topic in the software world for a while now. It has been seen and rendered as a solution to issues arising from monolithic applications.  But does it hold true to this argument?<\/strong> What are the benefits and challenges of this architecture?  I will be debunking the same in this blog to understand the relevance of Microservice architecture in the post-COVID world. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\"Is<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What exactly is Microservices Architecture?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Gartner<\/a> defines a microservice as \u201c a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable.\u201d<\/p>\n

However, architecture could be defined as a collection of small, individual autonomous services that are self-contained, programmed to implement a single business capability<\/strong>.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\"Logical<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Microservices is a perspective to building a single application that essentially contains smaller and independent services that run their processes to achieve a predetermined business objective. <\/p>

Microservices is a way of solving problems and putting systems together. There is not a single piece of software or hardware you buy to get microservices<\/p><\/blockquote>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\"Is<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

According to IDC, by 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code<\/strong>; 35% of all production apps will be cloud-native. The digital economy\u2019s requirement to deliver high-quality applications at the speed of business drives the shift to \u201chyper agile apps\u201d \u2013 highly modular, distributed, continuously updated, and leveraging cloud-native technologies such as containers and serverless computing. Combined with agile\/DevOps approaches and methodologies, enterprises can dramatically accelerate their ability to push out digital innovation \u2013 at 50-100 times (or more) the frequency of traditional techniques.<\/p><\/blockquote>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Characteristics of Microservices Architecture<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
  1. Highly Cohesive Components \/ Tightly Scoped<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    It is essentially like using a Lego block to build something. Owing to its single responsibility principle, each component does one thing and does it well. Components are smaller, less complicated, and are autonomous so that:<\/p>\n

    a.) They can be changed\/upgraded\/replaced independently<\/p>\n

    b.) They have a simple interface that makes sense for their domain<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t
    1. Organized around business capabilities<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      Service should have a well-defined focus around the business domain and associated bounded context. Even the Development team (rather a Fullstack Pod) should be structured as per business domain context. Teams with business context should have a product mindset<\/em>and should be designed for the full lifecycle of the product (requirement gathering to production support)<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t
      \"Decomposition<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t
      \"Decomposition<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t
      1. Autonomous and Self Contained<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        Each autonomous service is self-contained<\/strong>, which means that they each have a business capability. Additionally, each service has a different codebase that makes it easier for it to be managed by a small team. <\/p>\n

        a.) Each microservices contain their own set of data.<\/p>\n

        b.) Each microservice should be independent and autonomous<\/p>\n

        c.) Each Microservice should support the ability to change, test, and release independently of the rest of the system<\/p>\n

        d.) Microservices follow Nothing Shared principle for their implementation. The only public\/shared asset they have is their API or published Event in Event-Driven Architecture<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        \"Is<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        \"Is<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        1. Design for Failure<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t

          Microservices must be designed to operate despite failure, maybe with Degraded Functionality or Default Functionality implementation. Some of the common patterns used to build Microservices for resiliency are:<\/strong><\/p>\n

          a.) Asynchronous <\/p>\n

          b.) Circuit Breakers <\/p>\n

          c.) Redundancy \u2013 load balancer or competing consumer<\/p>\n

          d.) Brokered communication<\/p>\n

          e.) Detect failure \u2013 observability and Monitoring<\/p>\n

          f.) Test traffic<\/p>\n

          g.) Validation and defensive programming techniques<\/p>\n

          5. Smart endpoints, dumb pipes<\/strong>

          a.) Microservice needs to own its interfaces with well-defined contracts.  <\/p>\n

          b.) Microservice knows what data they take in and where they send data. They know what to do with errors and poison messages<\/p>\n<\/strong><\/p>

          c.) Microservices utilize contracts to other services, not integrations <\/p>\n\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t
          1. Infrastructure Automation<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t

            Infrastructure automation is required to support scaling and rapid response (e.g., adding more compute, deploying code, etc.) and required Monitoring and configuration management.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t
            1. Independently Scalable \u2013 <\/strong>even if one microservice handles the majority of traffic, we don\u2019t need to scale the entire system but focus only on scaling the affected microservice instead.<\/li>
            2. Independently deployable \u2013 <\/strong> it can be deployed separately without having to compromise other microservices.<\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t

              Lastly, applications that rely on the microservices approach to communicate with one another using well-defined APIs or Event-Driven Architecture don\u2019t necessarily require the same framework, libraries, or technology stack.<\/strong> Microservices are advantageous and useful for large and complex applications that require high scalability and shorter release cycles. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t

              Guess what?  All this can be challenging as you need to determine the backward compatibility of your implementation continuously.<\/strong><\/p>\n

              Now, let\u2019s deep dive further into the benefits and challenges of Microservices Architecture.<\/strong><\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

              \n\t\t\t\t
              \n\t\t\t\t\t

              Benefits of Microservices Architecture<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t
              1. Independent feature delivery<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t

                In a microservice architecture, multiple teams work in separate services, making deployment time much quicker, easier and cheaper.<\/p>\n

                a.) You can release any service independently from the others<\/p>\n

                b.) You don\u2019t have need all teams for the massive release cycle<\/p>\n

                c.) Delayed releases don\u2019t affect every component<\/p>\n

                d.) Using techniques like \u2018Feature Flags\u2019 feature plug and play, rolling upgrade scenarios are also possible. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                \n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t
                1. Scalability <\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  In the microservices architecture, you can scale each service independently without having to scale the entire Application. Using Kubernetes\/Service Fabric orchestrators, you can deploy a larger bulk of services onto a single host. This ensures that the resources are better utilized. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t
                  1. Agility <\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t

                    Owing to microservices being deployed independently, any update or feature delivery can be deployed separately without affecting the Application. Additionally, even if a feature delivery goes wrong for a single service, it can easily be called off without hampering the operations of the Application. The same can be assured in any other traditional systems of applications. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                    \n\t\t\t\t
                    \n\t\t\t\t\t\t\t\t\t
                    1. Technology Diversity<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t

                      Microservices enables you to use the right technology for each service. By design, the Microservices architecture can support Diverse Technologies\u2019 use and thus sometimes allows teams to develop the functionality using the technology they feel most comfortable with. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t

                      Pro tip<\/strong> \u2013 While I agree that different requirements sometimes benefit from a different technology, I would not suggest using a diverse set of programming languages across Microservices projects in the given Business context.<\/p><\/blockquote>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                      \n\t\t\t\t
                      \n\t\t\t\t\t\t\t\t\t
                      1. Lower Cognitive Load for developers<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                        \n\t\t\t\t
                        \n\t\t\t\t\t\t\t\t\t
                        \"Architects<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                        \n\t\t\t\t
                        \n\t\t\t\t\t\t\t\t\t
                        1. Automated Testing<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                          \n\t\t\t\t
                          \n\t\t\t\t\t\t\t\t\t

                          As Service endpoints are abstracted, it makes testing easier. Automated Deployment can be combined with Automated Test tools such as Continuous Testing. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                          \n\t\t\t\t
                          \n\t\t\t\t\t\t\t\t\t
                          1. Small codebase<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t\t\t

                            In a monolithic architecture, there is a high chance of code dependencies becoming entangled. This isn\u2019t necessarily the case for microservice architecture as it does not allow for code sharing, therefore ensuring fewer dependencies overall. This architecture makes it easier to add in more features as well. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                            \n\t\t\t\t
                            \n\t\t\t\t\t\t\t\t\t
                            1. Integration of DevOps <\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t\t\t

                              Once automation runs through the DevOps pipeline, it requires consistent testing at every release to ensure high-quality performance. The microservice architecture enables development teams to test even when things are still in production. Parallelly, DevOps monitors and oversees anomalies if detected and additionally renders necessary systems to issue fixes and rollback to previous versions if required. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t\t\t

                              Both microservices and DevOps work towards achieving an agile environment for any organization. When you combine the two, you can see the following benefits:<\/p>

                              a.) It helps to empower small independent development teams <\/p>

                              b.) Improves test cycle times<\/p><\/blockquote>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                              \n\t\t\t\t
                              \n\t\t\t\t\t\t\t\t\t
                              1. Fault Isolation -> increased resilience<\/strong><\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                Microservices architecture ensures that your Application is entirely decentralized and decoupled. This means that there will be relatively minimal failures. Unlike monolithic architecture, wherein a code\u2019s failure affects more than one service, each service acts as a separate entity, making maintenance simpler. It has resilience patterns such as bulkheads, circuit breakers, etc., that make isolating faults and anomalies easier. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t
                                \n\t\t\t\t\t

                                Challenges of Microservices Architecture<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t
                                \"Is<\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                Microservice Architecture isn\u2019t necessarily free of shortcomings either. <\/strong>The process of developing a microservice architecture-based application is far more complicated than a monolithic one. It may seem more straightforward, but the execution and implementation may pose a challenge to companies. These include:<\/strong><\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t
                                1. Software Complexity<\/strong>: Microservices have multiple individual moving parts wherein each service may be more straightforward, but the whole architecture can be tricky. For instance, each service must be monitored, deployed, and orchestrated without affecting one another. It requires an able team that fully understands this broader architecture of the Application. It additionally requires a continuous verification process that oversees whether each microservice is working correctly or not. <\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                  \n\t\t\t\t
                                  \n\t\t\t\t\t\t\t\t\t

                                  Complexity is moved from the code to the environment.<\/strong> Developers don\u2019t have to pay the price. <\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                  \n\t\t\t\t
                                  \n\t\t\t\t\t\t\t\t\t

                                  Though today most of this complexity can be handled with Infrastructure as Code and Desired Configuration State toolset.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                  \n\t\t\t\t
                                  \n\t\t\t\t\t\t\t\t\t
                                  1. Interaction<\/strong>: With a microservices architecture, the applications are loosely coupled into independent microservices that communicate with each other. If Monolith, previously hidden dependencies were coded, now in the Microservice architecture, they would have to be reconfigured. This makes the overall infrastructure communication complex and challenging. You have to be careful about handling requests flowing between each service. In specific scenarios, developers may even have to write up a new and extra code to avoid disruption. Additionally, an in-memory call would now be a call that moves around different processes, adding potential latency and interrupt speed. Remote calling a microservice in a loop can effectively add latency to every loop iteration.  <\/li>
                                  2. Operation Complexities<\/strong>: In a microservice architecture, each microservice team has the autonomy to choose the right technology, the ways to deploy a service, etc., making the overall inter-operational processes and communication much more complicated. <\/li>
                                  3. What about large or small companies?<\/strong> : Microservices Architecture can be excellent for large organizations; however, it can be complicated for small enterprises. Small enterprises wouldn\u2019t want to get bogged down in complex orchestration if they intend to create simple applications.<\/li>
                                  4. Difficulties in debugging problem<\/strong>: We have previously addressed the benefit of Microservices Architecture compared to Monolithic Architecture. A node failure can be easily isolated in the Microservices Architecture rather than the monolithic one, making maintenance relatively simpler. However, each set of services has its own set of logs to go through. It has been noted that 27% <\/a>of the developers debug a problem using only logs, which in my opinion, is a bad idea. So, the question remains: is it straightforward with more logs?<\/strong><\/li>
                                  5. Extra Time Testing:<\/strong> In this heavily distributed architecture, testing service dependencies become a considerable challenge significantly when the Application is evolving quickly. <\/li>
                                  6. Mindset challenges of Eventual Consistency of Data: <\/strong>Owing to the architecture\u2019s decentralized data management, eventual inconsistency is inevitable. Business stakeholders and developers now have to get accustomed to the fact that inconsistencies may arise and that they\u2019d have to spend some time to detect when things go out of sync. Most of the time, the Application needs to develop an additional complexity level to avoid issues and data inconsistency in the Business process and transaction.<\/li>
                                  7. Versioning<\/strong> \u2013 Without a robust design, backward and forward compatibility may become an issue as multiple services could be updated at any time.<\/li><\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t

                                    9. More Complicated Security System \u2013 <\/strong>A higher number of components means a higher risk of hackers\u2019 attacks. The security team needs to handle various operating systems, languages, and frameworks to secure the whole system.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                    \n\t\t\t\t
                                    \n\t\t\t\t\t

                                    Some of the other notable challenges include:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t

                                    a.) Complexity moves to Deployment<\/p>\n

                                    b.) Higher Cognitive Load for Architects<\/p>\n

                                    c.) Increased need for Monitoring<\/p>\n

                                    d.) Too much agile can make you rigid<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t

                                    An enterprise should use Microservice Architecture for a solution if it\u2019s complex enough to outweigh the costs of maintaining and moving to a microservices-based architecture<\/strong>.<\/p><\/blockquote>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                    \n\t\t\t\t
                                    \n\t\t\t\t\t

                                    Is Microservices Architecture still relevant in the post-covid world?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t

                                    \u201cNo Silver Bullet \u2014 Essence and Accidents of Software Engineering\u201d<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t