Here's a fun complete breakfast I prepared, photographed, ate and then wrote for the ServiceVirtualization.com community site sponsored by CA, ran Dec. 16, 2015. (See original post at http://servicevirtualization.com/247-complete-devtest-breakfasts-service-virtualization-in-cloud-environments/) - JE
It’s been a while since Service Virtualization (and this SV.com site, for that matter) came out, both as a practice and a technology. Since this site was launched back in 2010, it seems like another trend has occurred: fast food restaurants selling breakfast food 24/7. I don’t know about you, but breakfast is still by far my favorite meal. If everything you want is there, no meal beats breakfast. So why not have a complete breakfast there whenever you want it?
The invention of Service Virtualization in 2007 was huge for resolving dependencies in development and testing, so those teams could move forward without the “complete breakfast” available. At the same time, SV inadvertently resolved some of the primary constraints to serious enterprise adoption of public dev/test cloud environments. We used to describe this phenomenon of constrained components that you can’t simply import as “wires hanging out of your cloud.”
Take any system that you need to have ready for testing, but is not readily available. It could be a heavy mainframe that is too bulky to image as a VM, or a third party service you don’t have the access permission to copy. It would be much easier if you could realistically simulate just the behavior and data you need to run tests with those components.
So SV gave us a lightweight way to eliminate these constraints by replacing them with Virtual Services. This new technology is now a standard practice in large enterprises, with several major vendors offering solutions in the space. SV is proven to “cut the wires” of dependencies in dev/test environments.
That’s great for traditional on-premise environments, but it is especially useful in cloud dev/test scenarios, where dynamic availability – anywhere, anytime — is of the essence. Cloud infrastructure has come a long way in the last few years as well – offering increased capacity and performance at decreasing cost. We're seeing some huge environments running in cloud labs now at every phase of the lifecycle, including CA applications, SAP test regions, Oracle RAC servers, the list goes on. You can even invoke and specify these environments via API with a host of new IaC (Infrastructure as Code) and automated deployment solutions like CA’s Release Automation and CI/CD tools like Jenkins and many others. Containers have also now become a new, happy meal player in this complete SLDC breakfast.
Having the real thing in a 24/7 cloud is great, but who really wants a Coke with breakfast? In many cases, even if you could get the whole production-style application architecture imported, you may not always want the real thing in your dev/test cloud. Production systems may respond and perform unpredictably. If you are developing an application that will talk to production systems, you will likely need to suss out all the boundary conditions in your battery of tests. For instance, what if the mainframe responds in 30 seconds instead of 3 seconds, or .3 seconds? What if my partner’s service returns my form request with an unknown error, or a bunch of SQL hack statements?
It takes too much work and coordination to try and make every other team’s system respond exactly as you want. But you can easily make a virtual service learn the behavior, and get Test Data Management (TDM) to supply the exact right data, so that you can have it all dynamically provisioned in a cloud environment that does exactly what you want, on-demand. And other teams can get that same level of customization and on-demand environments that are separate so they can work in parallel, without having to become experts in how the whole application infrastructure and network is set up. Better to focus on the aspects of development testing, integration and performance testing that are in the scope of your requirements, and simulate the rest with SV.
The same concern applies to virtualizing test data. Unless you are getting close to production phases of your SDLC, you shouldn’t have to deal with extracting and loading huge volumes of production data into dev/test environments. When policy demands test data be scrubbed of sensitive info before being loaded, TDM provides another lightweight asset that can provide valid “virtual test data” and be spun up in a public dev/test cloud.
What’s cool is that all of these modern development and test technologies can be loaded into an environment in Skytap, along with all the pre-configured servers, network and domain settings, and management controls needed. Then you can instantly stamp out clones of the exact environments needed to advance development, test and release activities faster than we ever imagined.
Yes, SV and Environments-as-a-Service in cloud infrastructure are great technologies separately, but when pulled together, and given automation, they make up a complete breakfast of dev/test champions that is available 24/7. Don’t just settle for serial, or cereal breakfast just because it is late. Customers won’t wait for it. So why should you?