It’s 8:00 p.m., and you’re looking to complete a sprint to push out a net new cloud-native application. You make the deadline, but sending the application to the testing group takes two more weeks to push first to deployment and then to ops. Considering the time it took to develop the damn thing from idea to ops, agile development just is not … well … agile.
What went wrong? The problem is today that not enough automation exists for testing and deployment of cloud-native applications, and thus those pesky people must get involved in the testing process, which slows things down and brings in the likelihood of more errors. Moreover, there are not enough testers who understand what cloud-native applications testing should be, thus the latency is figuring out the approaches and mechanism for testing.
For example, the ability to determine the stability of an application using a cloud-native identity and access management system, or native encryption. Or, the ability to determine if scaling up six server instances is enough to scale, using an autoscaling cloud-native service. These are specific to a particular cloud provider.
Many expertscall for those testing cloud-native applications to learn much more about what cloud-native is and does, what the best practices are, and what’s a good cloud-native application and what’s not.
But the best advice that I have is to remove them all together, and instead put the burden back on the cloud-native application developers to add test planning, including scripts to automate testing, as well as infrastructure as code (IAC), that will tell the cloud computing provider how to configure the platform where the application will run.
The approach I’m outlining has worked great in the PowerPoint presentations at devops conferences, but it’s not getting the real-world adoption it needs. It continues to be the missing link at most enterprises that are using devops and cloud computing. Indeed, I suspect that testing processes for cloud-native applications continue to be largely a set of manual processes, assisted by some automation for most enterprises.
That’s not where we need to be. Cloud-native application test automation can be pretty much void of people, with the majority of the testing automated in ways that are defined by the people who built the thing: the developers.
Moreover, this will reduce the latency that we’re seeing with devops today, and even make the applications better tested before deployment. That in turn will make ops and the users much happier.
