Microservices as a Future Proof, and Reslient Architecture

Development velocity is highly impacted by technology advancements. Cloud infrastructure, operating systems, coding languages, frameworks and packages can be force multipliers for engineering teams, enabling them to compete in this high-paced era where "software is eating the world"1. An architectural choice can be critical when it cements how things are going to be done for a long period of time.

When you start a new project, you usually use the most modern and cutting-edge technology stack, however, technology can get old very fast, and without having the option to leverage future technology advancements does not only inhibit software development velocity but more inadvertently, makes room for competition to pass sweef and "eat your lunch"2.

The more complex systems get, the more vulnerable they are to failures. The fear of failure causes a set of decisions that can further reduce the development velocity. Microservices are built for resilience, limiting the failure impact allowing service continuance while remediate is in force.

Microservices as a Future Proof Architecture

Monolith

Poor

Microservices

Excellent

Definition

The ability to leverage future technology advancements when they arrive

Monolith

Architecture decisions and choices (e.g. languages, operating systems, protocols, etc.) are critical for a Monolithic architecture. As a Monolith usually includes a single code base that runs on a certain operating system, changing the aforementioned decisions is very challenging.

While small upgrades (e.g. newer versions of libraries that are being used as part of the code base and newer versions of the operating systems) are sometimes possible, more radical changes can be challenging or even impossible to implement. Sometimes even these small updates can become challenging. For example, you can get stuck at a certain version of Redhat Linux because one of the components you are using isn’t supported by a newer version, leaving you on an older version of the operating system.

When you can’t leverage new technology advancements, development velocity slows down and engineering teams usually consider refactoring which is a very expensive operation, especially at the later stages of the SDLC.

Microservices

Microservices are future proof. The nature of the architecture includes loosely coupled small elements, which allows for architectural decisions in the scope of the microservice and upgrade of each microservice individually which is less costly than upgrading the entire system. For example, refactoring a microservice is a decision at the size of the microservices which is likely to be considerably smaller than the entire system. You can gradually upgrade your entire system, service by service, as long as you keep the API contract with other microservices intact.

Microservices as a Resilient Architecture

Monolith

Poor

Microservices

Excellent

Definition

The ability of a system to "provide and maintain an acceptable level of service in the face of faults and challenges to normal operation."3

Monolith

A failure in a Monolith can be very expensive, as an unresolved failure in a Monolith is likely to fail the entire application and trigger resilience strategies that are expensive (e.g. a different availability zone or high availability mechanism).

Microservices

A failure in a Microservice architecture is likely to occur in one of it’s microservices causing it to fail. Even without an orchestration mechanism like Kubernetes, the blast radius is contained arround the failed microservice, allowing the rest of the system to potentially continue operation.

Modern microservice orchestration systems (e.g. Kubernetes, Docker, ECS) are built to deal with failure patterns. Comparatively speaking, the cost of failure in a Microservice architecture is so low vs. Monolith, that developers care far less about failures today. It is more acceptable today to let a microservice fail and allow the orchestration system to re-launch the service.

As an example, in the past we used to spend a lot of time avoiding memory leakage, today there is a higher tolerance to memory leaks as when the service fails the orchestration module will re-start the service.

Conclusion

Technology moves very fast. Not having a future proof architecture can adversely impact business results very soon as technology becomes obsolete and gives room to competition.

Due to the fragmented nature of a microservice architecture, the risk of a local failure impacting the entire system is reduced and can be managed easier.

Advice #1: Avoid marrying a single techstach in order to maintain control and be able to react and adopt new technologies when they arrive.

Advice #2: While it’s tempting to invest less in stability and maturity and more in resilience, don’t exchange software stability and maturity with resilience.

About UP9

UP9 provides an out-of-the-box test automation for microservices, Kubernetes and cloud-native, replacing the need for developers to constantly build and maintain tests, while providing comprehensive service test-coverage.

Features:

  • Automatic generation and maintenance of CI-ready test-code, based on service traffic
  • Observability into API-contracts, business-logic and service architecture
  • Automatic reliability, test-coverage and root-cause analysis
  • Machine generated tests include functional, regression, performance and edge-case test-cases, covering all services and all service-endpoints

UP9 offloads the microservice testing workload from developers giving them precious time back.