devopsy.kinsta.cloud

Tag: microservices vs. monoliths

  • Why Boring Tech is Best to Avoid a Microservices Mess

    Why Boring Tech is Best to Avoid a Microservices Mess

    Microservices are all the rage. A Forrester study found that 76% of enterprises were rearchitecting applications for microservices.

    At the same time, microservices are definitely not a silver bullet. Among those already using microservices in production, one study found that 59% said each microservice added increased operational challenges such as data management. Even more concerning, the same report revealed that when asked to compare the difficulty of troubleshooting different environments, 73% said microservices were more difficult, and only 21% said they were easier than monoliths.

    But how did we end up like this? According to Matthew Sinclair, VP of engineering at BCG Digital Ventures, it is because that, as technologists, “we want to use the most modern tech, and sometimes we even want to do it with tech we’ve got no experience in. We see this with engineers, not because it’s the right thing to do but because they want to learn something new.”

    Sinclair, who was speaking as a part of an Indorse Engineering Leaders Online Panel, went on to point out how the problem becomes self-perpetuating: Customers hear about new tech—in this instance microservices—that will fix the problems they have with monoliths. They rave about microservices to software engineers, who also get excited about it and then go off and start adding microservices in software engineering projects.

    The problem is, there is just as much chance of getting into a tangle with microservices as there is with monoliths. That’s because people often start breaking things up into microservices too early—they’ve heard it will be a good idea and they’ve seen some of the benefits, so they try to apply it to everything. In doing so, they create what some might call a “micromess.”

    Avoiding the Micromess

    So, how do you avoid ending up in a micromess?

    You need to go back to the fundamentals. One way to look at it is understanding that microservices are distributed systems, something many people will have experience with. They should also be familiar with what another panelist, Oswaldo Hernandez Perez, engineering manager at Improbable, called the first law of distribution: “If you don’t need to do it, don’t do it.”

    So that means focusing on why you are building what you are building. What are you trying to achieve? This is a fundamental question that’s applicable to businesses of all sizes. What problem are you trying to solve, and how will your solution remove friction from its users’ lives?

    That’s what people care about. Even if you’re developing a niche app for a highly technical audience, they are unlikely to care too much about how it got to them, only that it did and it is fixing a problem for them.

    If the only way to achieve that is with microservices, then yes, you should definitely use them. If there is an alternative, then consider using that. Do not simply start breaking everything up into microservices just because that is what everyone is currently talking about.

    Don’t Stick Your Head in the Micromess

    Ultimately, microservices are an architectural pattern to reduce complexity. It does this, but it also adds complexity elsewhere. If used in isolation, then you’ll fix your complexity in one dimension and have it proliferate elsewhere. So, it is vital that you use the many other tools out there to minimize complexity across the entire organization.

    It goes back to the question: What problem are you trying to fix? The majority of businesses can do that with boring tech. Granted, the likes of Amazon and Google, which are cloud-native to their core, can use microservices, but even large enterprises should be asking themselves if it’s really the right choice for them.

    Established businesses are likely to have a significant legacy codebase, which needs integrating with. Again, microservices might not be appropriate in this situation—it might be worth saving them for cloud-native projects, and use boring tech to resolve the challenges within legacy IT.

    Do You Really Need Microservices?

    Time and time again, we come back to the fundamental question: What are you trying to fix with this product and/or technology? Not how, but what? What friction will you banish from the user’s life if they engage with your product? Only once you answer that question should you consider whether microservices is for you. Chances are, you may find you don’t need them by that point.

  • Microservices vs. Monoliths: Which is Right for Your Enterprise?

    Microservices vs. Monoliths: Which is Right for Your Enterprise?

    With microservices projected to grow globally at a 22.5% rate between 2019 and 2025, the choice between monolithic and microservices architectures needs to be carefully considered. If you are wondering what microservices are best suited for, or whether your business should stick to monolithic or switch to microservices, here are a few cardinal points to take into consideration.

    What Is Monolithic Architecture?

    A monolithic application is built on a single code base with a variable number of modules. The number of modules depends on the complexity of the business and its technical features. The whole application—and dependencies, when applicable—are built on a single system with a single executable binary for deployment.

    A monolithic architecture has distinct advantages and disadvantages that should be evaluated when deciding when selecting the optimal type of architecture for the application.

    Monolithic architecture pros:

    • Fewer cross-cutting concerns: The majority of applications typically have a large number of cross-cutting concerns. Running them all on a monolithic architecture facilitates hooking up components.
    • Less operational overheads: Avoids the additional costs stemming from microservices such as interservice communication, service discovery and registration, load balancing, decentralized data management or distributed logging, for example.
    • Complex testing: Testing for microservices is considerably more complex than for monoliths.
    • Better performance: As shared-memory access is faster than interprocess communication, a monolithic architecture typically has better throughput performance.

    Monolithic architecture cons:

    • Overly tight coupling: Entanglement increases the difficulty of isolating services for upgrades or independent scaling when the application evolves.
    • More difficult to understand: As the application grows and the number of layers and dependencies increases, understanding the system becomes increasingly difficult.
    • Slow build and test create releases: Upgrades imply recoding the entire application to factor in the dependencies and side effects.
    • Hard to distribute development: Tightly integrated applications are difficult to break into chunks, which complicates the creation of a distributed team effort.
    • Usually requires opting for a single programming language: Integrating more than one language in a monolithic application is fraught with challenges, typically preventing the integration of components written in a different language, which might limit the flexibility of adding features best suited to an external language.
    • Complicates the adoption of third-party tools: Adding self-contained third-party components, for example, cloud-native, to a single code base with multiple dependencies requires complicated hookups to different layers of the monolithic application.

    What Is Microservices Architecture?

    Microservices architecture is designed to accommodate the need for large application development by providing a suite of modular components and services.

    When considering what microservices are particularly well-suited for, the following advantages and disadvantages should be taken into account:

    Microservices pros:

    • Better organization: Microservices are organized around business and technological capabilities, in units that are independently deployable.
    • Decoupled: Each unit can be independently upgraded without requiring a complete overhaul of the application.
    • Performance: Flexibility in opting to privilege performance or flexibility as needed, including independently scaling heavily used services by isolating them from the remainder of the application.
    • Fewer mistakes: The hard-to-cross boundaries between microservice units limit the technical possibility of generating mistakes, notably cascading ones.
    • Easier onboarding of new developers: They only need to master the microservice unit they will work on instead of the entire application architecture.
    • Scalability: Each microservice can be scaled independently, while also adding new components.
    • Improved fault isolation: As modules work independently from each other, a failure in one module does not affect another.
    • Elimination of vendor or technology lock-in: As each microservice module can be operated independently, replacing underperforming modules with better ones from an alternate vendor is relatively easy.
    • Ease of understanding: As services are broken down into modules, understanding the functionality of a module is easy for developers.
    • Smaller and faster deployments: Each service can be scaled independently as needed, instead of scaling the entire application. This can lead to cost savings.

    Microservices cons:

    • Cross-cutting concerns: Microservices require handling cross-cutting concerns such as externalized configuration, logging, health checks, metrics, service registration and discovery and circuit breakers, as well as those specific to the technologies used by the microservices.
    • Higher operational overhead: Microservices deployment typically leads to an increase in the number of units and containers, increasing the management and operation cost overheads.
    • Security threats: Microservices architecture presents an expanded attack surface. Securing a containerized application requires managing privileged access at image, container, node, pod and namespace levels, ensuring encrypted tunneling from ingress to egress and other elements that require baking in security from the beginning.
    • Multiple complexities requiring management:
      • Communication between services on a technological level, and between teams on an operational level.
      • Selecting the optimal pattern from the several microservices patterns available.
      • Provisioning sufficient IPs.
      • Provisioning resources (memory, CPU, disk) to accommodate each cluster requirements.
      • Maintaining multiple programming languages and frameworks.
      • Handling the incompatibilities between existing tools and new service dependencies.
      • Accounting for automation tools for each service requiring individualized testing and monitoring.
      • Achieving data consistency between each service’s individual database and transaction management system.
      • Handling the number of processes that can grow exponentially when load balancing and messaging middleware are considered.
      • Provisioning for the increase in documentation overhead stemming from the need to keep schemas and interface documents up to date.
      • Refactoring of an application built on monolith architecture is a massive undertaking for large enterprise applications.
    • Complicated global testing: Global testing requires that each dependent service be tested first. This can be partly assuaged with automated testing.
    • Difficulty in debugging problems: Debugging requires inspecting each service log independently, increasing the workload.
    • Deployment challenges: Microservices are written in a variety of frameworks and languages and require distinct resources, scaling and monitoring, making orchestrating the deployment challenging.
    • Large versus small product companies: Though the benefits of microservices are invaluable for large companies, adopting a microservices architecture creates overwhelming complexities leading to slower implementation and unnecessary cost increases for small companies.
    • Higher costs: Without careful and strategic planning, cloud service bills may balloon due to the increase in data stemming from intraservices calls and the increase in resource requests to account for scalability and lack of friction.
    • Cultural changes: Microservices require the company to have an agile DevOps culture.

    As microservices architecture provides a better way to manage growing data sets, leverage cloud storage and automation and deploy solutions fast, microservices are usually preferable to monoliths. However, they might not always be the best choice for an organization. Before opting for microservices, a careful examination of your company culture and business objective is imperative.