The Need for Configuration Management in Microservice Testing
By: Tracy Ragan
With the shift to cloud native architecture comes the shift to microservices, and this shift will disrupt business as usual for all testing from development through pre-production. Microservices change many things about how we see the world from a testing perspective. From the loss of an ‘application version’ to managing continuous tests across multiple application teams, the testing world looks very different. If you have not started thinking about what a test environment will look like in a microservice architecture, a good place to start is understanding the relationship a single microservice has to multiple applications, or in other words microservice configuration management.
An Update to a Single Microservice Can Impact Multiple Applications
As we move away from monolithic practices and into a Kubernetes microservice environment, we lose the concept of an ‘application version.’ We also lose the careful configuration management that was completed during the compile/link process performed by the continuous integration build step. Instead we are faced with lots of loosely-coupled, independent functions that talk via RESTful APIs.
Think of the problem as a puzzle. In monolithic practices, we put the entire puzzle together through a continuous build step. A very smart build manager makes the decisions around the software configuration of the application, i.e. what code updates and libraries to include and statically link. The puzzle is then pushed through the continuous delivery pipeline as a complete solution.
With microservices, the puzzle is not put together until runtime. Instead, independent functions move through the CD Pipeline in their own workflow. This means each microservice is pushed through the Dev, Test, Prod stages alone.
Once deployed, the microservices pass data via RESTful APIs. In other words, we are shifting from a static application to a fully dynamic application. The trick is knowing what applications should be tested based on an update to a single microservice.
The Microservice Magic is in Their Reuse
A solid microservice implementation means that all microservices are designed around a domain driven structure to facilitate reuse. A single microservice may be consumed by multiple applications. Think of a ‘login’ service. Each project team would reuse the login services written and supported by the Security Project Team. If one of their ‘login’ services were updated, all applications consuming the service should be retested. This means that an update to a single microservice should initiate the continuous test workflows for all dependent applications.
While the concept of API contract testing applies at the unit testing level, we have work to do to pull together our functional testing harness when a single microservice can impact several consuming applications.
A New Kind of Release Candidate
Unit testing individual APIs or microservices does not validate the readiness of a full application release. For this reason, we can never eliminate the functional testing process in a microservice architecture. If we do, we risk missing situations where one microservice is using an older version of another microservice, and that causes an adverse impact. This level of anomaly can only be found when we perform functional testing on the application as a complete product.
In monolithic environments, the application version is our release candidate. A new release candidate initiates the work done by our functional test harness, which in many cases lags behind the development sprints that perform unit testing on the API contracts. While development teams may make incremental coding changes, functional testing is based on a full release candidate, and the release of that candidate causes the execution of an entirely different set of linked test cases.
When testing microservices, this level of functional testing is still required and critical. Ideally, we want to leave our functional testing in place even when our application is built on a set of loosely coupled services. To do this, we need visibility into the ”logical application” version. In order to remain efficient at the functional testing level, we need some insights into what has changed between two application versions, allowing the functional testing to be targeted. What we want to avoid is constantly retesting everything simply because we have no reference as to which microservice caused a new release of the application version.
Re-Imagining Continuous Test
In order to re-imagine the testing process, we must go back to our roots and remember the importance of software configuration management. SCM is the process of tracking the parts of an application, their changes and how they impact the application as an entire solution. In recent years configuration management has taken a back seat, but with microservices the SCM discipline will save us from missing critical updates in microservices that impact multiple ‘logical applications.’ Microservice configuration management is the process of tracking each version of a microservice and the relationship to the consuming applications. API gateways can help, but the configuration data must also include a view above the cluster level. Remember, there could be different versions of a single microservice running across multiple clusters resulting in different versions of the ‘logical’ application on each cluster.
Yes, microservices add complexity to the testing process. As we adapt to the new requirements, the complexity will eventually be normalized. It is just going to take us some time to get there.
Conclusion
Shifting to microservices requires us to re-imagine how we coordinate testing. The loss of a static monolithic application requires us to rethink how we are going to track and manage many microservices moving across the CD pipeline that could impact any number of dynamic “logical applications.” Configuration management will be key to tracking these changes even before they are ever installed into any cluster. Testing will need a process to track what impact a single service has across teams and across clusters. It is time to start understanding microservice configuration management in order for testing workflows to adapt to this new and exciting cloud native world.
A Pipeline with Automated Configuration Management
DeployHub and CircleCI have had discussions around solving this problem. You can view a demo of how it looks when you add automated configuration management to your CD Pipeline by viewing the CircleCI and DeployHub demo.
Click here to register for November 2020 SKILup Day: Continuous Testing
About the Author
Tracy is CEO and Co-Founder of DeployHub. DeployHub is the first microservice management platform designed to facilitate the sharing, relationship mapping and deployments of microservices. Tracy is expert in configuration management and pipeline life cycle practices with a hyper focus on microservices and cloud native architecture. She currently serves as a board member of the Continuous Delivery Foundation (CDF) where she is the elected General Member Representative. Tracy is also a DevOps Institute Ambassador.
Originally published at https://devopsinstitute.com on November 4, 2020.
