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 respects 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.