Software Testing in the Era of Cloud Native Microservices
A defining characteristic of the new ‘Cloud Native’ era is the use of a microservices approach to software architecture. In simple terms, this means operating lots of small, autonomous units of code rather than one overall ‘monolith’.
For large scale adopters such as the ultimate poster boy Netflix, this can mean vast software environments executing hundreds and thousands of them across a global platform. In his 2016 presentation, Director of Platform Engineering Ruslan Meshenberg explored the challenges of managing such a complex system.
The Cloud Foundry Comic Relief case study is another great tutorial, in this case, an ideal use case demonstrating both the power of the Cloud and a microservices architecture. They experience a massive demand for web resources and e-commerce transactions, but only on one day of the year.
A traditional data centre approach would see an expensive infrastructure sitting idle for 364 days of the year, whereas the Cloud provides them with the cost-effective, elastic scalability to meet this one-off large spike, and the use of a distributed microservices architecture the business system that can autonomously expand itself across multiple Cloud providers to ensure the resilience of the absolutely critical e-commerce processing.
Accelerating digital innovation
It’s not just this scalability that makes microservices such a powerful approach for enterprise organisations, it also enables faster development of new software too.
In the Netflix presentation Ruslan describes that their organizational priorities are ranked 1) velocity of innovation, 2) reliability and 3) efficiency, as their core goals. Microservices software architecture is combined with a DevOps team model where developers take full life-cycle ownership of their services, a loosely coupled approach that enables each to release new features much faster, increasing the velocity of innovation.
Simply pushing through lots of new code faster, without an adequate testing strategy, will only create a log jam of defects that prevents the core goal of releasing functional code.
For organisations seeking to emulate this transformation a number of methods and tools can be considered, including of course the components Netflix has open-sourced.
Cloud guru David Linthicum makes the point that Cloud Native efforts won’t succeed without a suitable test automation capability like this. The Cloud Native QA guide repeats the Netflix philosophy, notably “It is important to not only design for failure but test for recovery”.
They recommend a series of QA practices for adopting the same type of culture as Netflix, various ways to test for failure and recovery as they do, and using tools such as OpenTracing.
Fernando Mayo explores the modernisation of testing for this new microservices world, highlighting practices like property-based testing, fuzz testing, and mutation testing, that can help detect a wider range of defects in an automated way.
To understand how testing can be adapted to this new paradigm, Martin Fowler, a renowned guru on the topic, offers this excellent presentation resource, a primer on microservices software testing, where he explains in detail how practices like Unit, Integration and Component testing are applied to this new architecture.
2i can help organisations transition to this new, high-velocity approach to software engineering, through team support and help to adopt the right tools for the job.
For example, a fundamental characteristic of microservices is their inter-communication through APIs, which can be tested using tools like Postman, which can manage APIs available via a browser, making it easier to share and inspect APIs. Previously, Postman required DevOps teams to download a desktop application to access the Postman platform.
Writing on DevOps.com Mike Vizard says:
“Now that more organizations have adopted an API-first approach to building and deploying applications in the age of microservices, those APIs need to be managed as discrete projects. Postman provides a means of achieving that goal now through a browser interface that can be accessed more easily by members of DevOps teams working remotely.”
Postman themselves offer this article, explaining their own in-house journey to a microservices architecture. This is highly informative, exploring the challenges of DevOps team dynamics, as well as adapting their CI pipeline.