Do you have what it takes for hyper-agile software development? Startup Ravello Systems discusses the key principles for building the dev/test lab of your dreams by normalizing the cloud.
In a world where competitive advantage is synonymous with business agility, the reality is that the very software that drives the business typically takes inordinate amounts of time to develop and test.
Hyper-agility in software development requires infrastructure and automation that not only keeps pace with development processes but actually helps accelerate cycles and improve overall quality. It is arguably economically infeasible to build an ideal lab entirely on-premise due to the bursty and transient nature of dev/test workloads, but now with new technologies that normalize the clouds, hyper-agile development and test is increasingly within reach of most enterprises.
The 10 ingredients described here can make for dev/test lab nirvana. Until now this “dream lab” was nearly impossible to achieve without breaking the bank, but with the latest technologies it’s easy to build this ideal lab that not only improves application quality and accelerates time to market, but also reduces overall costs.
1. Agile dev/test has bursty patterns and requires practically infinite pool of infrastructure resources
Typical software builds and tests are automated but all tests cannot be run in parallel due to resource constraints. For any enterprise, having the dev/QA team waiting for test results is tremendously expensive – not just in terms of inefficiency but also in terms of losing business to more agile competitors. In the ideal scenario, engineers should have no wait time with access to a seemingly infinite pool of resources irrespective of whether it’s a public, private or hybrid cloud, so that any number of tests can be run instantly and in parallel.
2. Developers should have self-service access to infrastructure
To fully utilize the potential of seemingly infinite capacity, engineers need on-demand self-service access to the resource pool with predefined permissions rather than wait for IT to setup resources and grant access for each request.
3. Ability to test on replicas of production
According to a Ravello survey conducted with dev/test engineers, IT admins, automation engineers, and DevOps, as many as 75 percent of architects and IT admins noted that it’s too complex and time consuming to create dev/test environments and that they are not representative of production. While everybody recognizes the need for speed, let’s not forget that the quality of the app is equally important. Particularly in very dynamic environments, testing on replicas of production is challenging but essential in ensuring that the final result is consistently high quality. For example, if you have a VMware environment on-premise and want to test those applications in an Amazon AWS cloud, it should be absolutely seamless between environments.
4. Infrastructure should be automated at the application level
Manually replicating complex multi-VM apps from individual snapshots and clones is both cumbersome and error-prone, particularly when it involves complicated networking setups. In an ideal scenario the entire multi-VM app along with its networking should be replicated with a single click.
5. Continuous integration – from application to infrastructure
With continuous integration, the moment a developer checks in code, he should be able to spin up multiple instances (production replicas) of the application, and run a complete battery of integration tests all at the same time. The developer gets instant feedback on whether the functionality works well in a production like environment or whether issues arise and need to be fixed. A great, widely-used tool is Jenkins, which enables continuous integration. To be used successfully it should, however, be tightly integrated with the underlying infrastructure setup for seamless end-to-end automation – from code to hardware.
6. Easy collaboration between dev and test teams across locations
Imagine a QA finds a bug and without any disruption or delay in the other ongoing tests, invites developers to examine or debug the same instance of the application irrespective of where they are located. This type of instant access and sharing accelerates dev/test cycles and enhances team collaboration.
7. Ability to reproduce bugs
Reproducing bugs can be very difficult in a complex multi-VM application due to the dependencies and interactions across application elements. In the ideal setup, the entire complex app can be packaged as one environment so that reproducing bugs is simple, such as executing a replica of the test system where the bug was identified
8. Rapid prototyping
The use of standard pre-defined building blocks (e.g., a standard database cluster) to rapidly prototype applications can accelerate the dev/test cycle significantly. However, ideally the building blocks would not just be brand new or vanilla instances of standard app components but would actually be replicas of the same elements that exist in the production app.
9. Ability to monitor usage of resources
Ability to monitor usage of dev/test resources is critical in ensuring that resources are efficiently utilized and for reclaiming unused capacity considering that dev/test labs are very volatile in nature where VMs are frequently created and destroyed.
10. Cost efficiency
Last but certainly not the least, all of these capabilities should be delivered at a cost that’s viable for the business. In the survey previously mentioned, 80 percent of dev teams faced shortages of dev/test infrastructure, and 92 percent have needed to buy more hardware for new dev/test projects – but that is not always a cost effective approach. Particularly for workloads that burst, like dev/test, it’s nearly impossible to design on premise datacenters for peak capacity since it means letting expensive infrastructure resources sit idle most of the time. In the perfect lab, it would be easy to spin up dev/test instances and you would only “turn on” when required rather than keep all instances running 24/7 and you would pay per usage only for the resources consumed.
11. Bonus: Extreme Testing
Having the ability to check network failure scenarios or test high availability environments with a simple API call. This is somewhat similar in concept to the Chaos Monkey but with broader functionality, eliminating the need to manually pull wires, or having to stop tomcat, for complex tests that check failure scenarios.
Software is eating the world but the state of development and test infrastructure in enterprises is holding back enterprise developers from being truly agile. The rise of DevOps is a testament to this gap. The principles described here go a long way in bridging the gap between developers and infrastructure administrators, and, in creating a dream lab for enterprises.
About the Author
Rami Tamir has 15 years of experience in management of multidisciplinary software development. In 2011 Rami co-founded Ravello Systems and serves as its CEO. Earlier, Tamir was VP of engineering at Red Hat. He joined Red Hat through the acquisition of Qumranet (the company that developed the KVM hypervisor, now the standard virtualization technology in Linux) where he was the co-founder and president. Previously Tamir held senior key management positions at Cisco which he joined through the acquisition of Pentacom where he was co-founder and head of software.