Microservices have recently attracted a lot of attention for being the architecture of choice for companies like Uber, Netflix, Spotify, and Amazon. Undoubtedly, this architectural approach has distinct impacts across the SDLC. Many of the core benefits associated with the adoption of microservices actually introduce significant quality challenges. For example:
- An increased number of dependencies
- Parallel development roadblocks
- Impacts to the traditional methods of testing
- More potential points of failure
An Increased Number of System Dependencies
By definition, a transition to microservices involves breaking a monolithic application or service into more logical, isolated components. Whereas this decomposition adds value in respect to scaling and flexibility for change, it also introduces more dependencies in conjunction with the entire system under test. This makes configuring and provisioning complete test environments exponentially more complex.
For example, assume that standing up a test environment before a microservices migration involved one application with 10 web services. For the sake of extreme simplicity, let’s say that each of these web services has 10 operations and a microservice will be developed for each operation (10 times 10). The original test environment needed access to the original 10 web services, but the new test environment will need to provide access to 100 microservices properly configured for all test scenarios.
Parallel Development Roadblocks
The increased number of system dependencies also complicates the coordination of parallel development among evolving microservices. The expansion of system dependencies tends to create two types of bottlenecks: teams waiting for other teams to complete parallel development on dependent microservices and/or teams waiting for properly-configured test environments (with all the correct versions of dependent microservices) to be aggregated, configured, and provisioned. The more microservices you have, the more moving targets are introduced…and the more challenging it becomes to develop and release new functionality in parallel.
Impacts to the Traditional Method of Testing
The traditional method of testing involves taking a requirement or user story and validating it through UI tests. Evolving to microservices will require a distinct change in your test strategy, which will directly impact this traditional method of testing. Although testing through the UI during later stages of the SDLC is certainly still necessary, microservices will require a more comprehensive approach at the message layer.
Validating each independent microservice is only the first step. It’s also critical to exercise all critical transaction paths through the now more-distributed microservices. Since one of the goals of microservices is the ability to enable rapid change, it’s imperative to understand:
- The material change associated with the service itself
- The impact of the change versus other service dependencies
- The impact of change on critical end-to-end transactions
- The impact of change on the end-user experience
- The new requirements for test data
- The impact to broader non-functional requirements such as performance, accessibility, reliability, resilience, etc.
More Potential Points of Failure
Another side effect of microservices migration is the introduction of multiple independent points of failure. Returning to our previous simple example, a failure in the single web service would impact all 10 operations. After the migration to 10 separate microservices, a failure in any single service might or might not impact the other 9. Although microservices offers isolation associated with multiple independent points of failure, DevTest must now contend with the complexity associated with having more moving parts.
In order to understand the business impact of change associated with evolving microservices, DevTest teams must now monitor a much broader array of test dependencies. Furthermore, DevTest teams must have access to test environments which encapsulate this highly-componentized, distributed architecture.