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.
The ability to leverage future technology advancements when they arrive
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 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.
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
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).
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.
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.
Try microservices contract testing for free with UP9. Sign up now.
UP9 is a microservice testing platform for Cloud Native systems that can scale across any number of services. UP9 helps developers prevent software regressions and increase engineering productivity through effortless testing and instant virtualization.
- Understand how services interact with each other with automatic contract discovery.
- Ensure system-wide contract adherence with tests that write themselves.
- Start testing early with test environments as code, automatically mocking all service dependencies.
UP9 offloads the microservice testing workload from developers, giving them precious time back.
You can sign up now for free!
Join our webinar about contract testing:
"How Contract Testing Helped Cycode Prevent Software Regressions in their Kubernetes and Kafka Environments". Feb. 17th 11:30 ET / 18:30 Israel.
Sign up now.