The need to speed up feedback loops, simplify dev/test processes and collaboration, and also save on infrastructure costs — have led many organizations to create an internal dev/test cloud to standardize their processes.
On Tuesday, I participated in an online panel on the subject of Creating an Internal Dev/Test Cloud as part of Continuous Discussions (#c9d9), a series of community panels about agile, continuous delivery and DevOps. Watch a recording of the panel:
Continuous Discussions is a community initiative by Electric Cloud, which powers continuous delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes.
Below are a few insights from my contribution to the panel:
Why Create a Dev/Test Cloud?
One of the things I often see whenever I go to a new customer is what I’d call something of an overextended disaster of a physical test lab. Everywhere you go, teams are queuing up to get access to these labs where they have this long tradition of a physical test lab.
With everything in agile and DevOps being about doing smaller and smaller things faster and faster, ideally everyone needs an environment in which to do your testing and you would like that environment to be as close to production as possible. But if it’s exactly like production, you’re talking about tremendous cost.
So you not only need environments, you need a range of environments. You need some simple ones and you need some very high-fidelity ones, and so you very quickly get into a problem where you just can’t do it with a physical lab. It’s just too expensive.
You need something virtual and that’s what we do at Skytap; we are a kind of cloud that looks like your data center. You create a virtual model of your production application and maybe arrange a fidelity of tests environments and then make those instantly available. For doing this new style of development that people are getting so much mileage out of, we are finding this to be tremendously useful.
In this age of DevOps, we’re building up these environments through infrastructure as code, instead of worrying about a server. Another feature that we really focus on a lot is something very much like Symantec Ghost. We take the entire environment, and we save it exactly with the in-memory state. Think of it like a snapshot for a single VM, except we do it for the whole environment. That’s another thing that makes it really usable, and something you can trust.
What are the challenges of creating a Dev/Test cloud?
I really like the idea of making this whole environment problem one of your DevOps initiatives, because I do think that the ownership thing is a huge issue. Test labs are hard, and in a lot of organizations, people want somebody else to own this. The importance of it is too high.
And so, let’s attach it to something sexy like DevOps and say we’ve solved a lot of the infrastructure building issues. I think moving on to whole environments and making those easily accessible, I think people have to understand how important that is.
What are the challenges you see people running into when they’re trying to create Dev/Test clouds
Suddenly, you need a large number of environments that look very much the same, and maybe you’re sharing resources that aren’t easily virtualized. One of the things that we deal with a lot is building the right connections back to on-premises systems or other systems that are necessary and secure.
A lot of times, when we’re building environments for people, it’s getting these VPN connections with the systems so there aren’t a lot of conflicts, making sure the security is right, and getting access to the internal systems that are there. I think that’s obviously one of the challenges.
Another challenge is the classic cloud issue of latency. I still run into customers that say, “Hey, the data center used to be in down the hall and now it’s in the cloud. Why does it feel different?”
The other part of that is that global development has become the norm. So having low latency in the right places where people need these dev clouds is really important. Even if you’re doing a private cloud you need to think about it being global. Those are the two biggest issues that we run into when replicating all that complexity.
What Are the Prerequisites for a Dev/Test Cloud?
What are your plans for environments, what is the level of fidelity you need, and what you can put together? Part of the appeal of containers is that it gives you a way to do a low-fidelity environment right on your laptop. That’s nirvana for developers, but it’s probably going to be low-fidelity. How many people can do everything on their laptop that they really want to do in full production?
We think about the prerequisites. What environments do you need? Maybe the lowest kind of fidelity thing that you’re going to do is a few containers on your laptop to try a few things. Maybe the highest fidelity thing you could possibly do is would be a production replica which almost nobody wants to do anymore because it is too expensive. It’s just too much.
Where we try to live with Skytap is kind of everything in between. What are the kinds of environments that you can build that have varying levels that get you all the way to something very close to production? VDI was mentioned earlier, and that’s one of the things that we really focus on a lot.
As a developer, I’m thankful that we’re back doing command line stuff than doing it in VDI. I personally don’t like them, but a lot of people do, and it’s one of the things that we provide that people like. We even provide the ability to access machines that aren’t network connected inside the cloud.
Maybe the network isn’t working, or they aren’t network-connected there. We still provide a way to access that via our system, because it’s another thing you have to be able to test. For me, it’s coming up with the plan of the environments that you need. Once again, this is a strategic thing for your whole dev organization. You need to figure out what environments you need and how you’re going to provide them.
How to do it?
There are different approaches. Containers are the big buzz word these days. But even with containers, while they simplify a lot of things, they also introduce their own set of complexities. There are a lot of competing frameworks around containers and you need to make a decision about what you want to adopt going forward.
The solution also needs to be adaptive, because you don’t want to be too tied to a particular solution. You want to minimize inertia, if possible because many of the solution industries are emerging and you can expect to make some changes along the way.
We want to thank our friends at Electric Cloud for having us on their Continuous Discussions online panel; we hope to have them join us on a future episode of The Skytap Podcast soon!
