How do you create a private Dev/Test cloud to standardize processes, tooling and environments across teams? Recently, 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.

What are your thoughts on Dev/Test cloud?

It’s not a question of why—You don’t really have a choice. I don’t think that this is an optional thing. If you’re moving to this modern software delivery, you’re going to have to build this environment. If by chance you’re already doing some of the continuous integration continuous delivery (CICD) processes without it, it’s not going to last long. If I were to take a slightly different angle, I think the interesting question is where? So where is your Dev/Test cloud?

I think of Dev/Test as a conceptual thing; it’s your factory. If we talk about it from a singleton point of view—as one environment, for example, or one integration environment that it is not going to support microservices and some of the future architectures—that’s when you might add multiple Dev/Test clouds. For example, if you think you’re going to have your browser grid on-prem or intermingling with your other integration environments, that’s a lot of work, and that’s a lot of maintenance. It’s just not a good idea. But at the same time, it’s actually amazing if you’re doing anything with artifact repos. Even though some of these artifacts are really small—and Docker images can be very small, if those repositories are not on the same network as the rest of your Dev/Test—it could be really slow pulling assets down. So that’s what can be brought on-prem. I think the bottom line is that you’re going to have to get there no matter what. It’s just going to happen. I think how you set it up is the interesting question, since there are a lot of options as far as how to do that.

What are the challenges of creating a Dev/Test cloud?

I think the first challenge is parity between your Dev/Test environment and your production environment. Replication would be insane because you’re talking about data centers, a lot of overhead, and it reduces flexibility. And everything we talked about before—the ability of developers to spin out Dev/Test environment and integration environment on a whim. However, there are things that you can absolutely consider, which is consistency between all your configurations, making sure that all your frameworks are consistent because chasing down bugs that cross applications throughout the system are very hard to deal with. But there is always the need to address that.

And we’re even talking about agents sitting on your nodes. I mean, if you’re running some tooling on your servers, it’s good to know what the potential impact of having those, or not having those on your Dev/Test environment could actually be. I’d say that parity is probably one of the biggest challenges. And then the other challenge is just knowing who owns it, because I think that the best scenarios I’ve seen are when you have a steward of the Dev/Test environment. It could be DevOps, it could be somebody else who’s responsible for maintaining the strategy of what you do with those environments versus it being a wild west. So they don’t own it, but they facilitate making sure that parity exists, and facilitate making sure the automation and the provisioning and everything is as efficient as possible. Developers shouldn’t think about that. Dev/Test should be more of an offering. At the bigger organizations, that’s exactly what they do. They’ve created a shared services or cloud services division that is responsible for setting those up.

What are the challenges you see people running into when they’re trying to create a Dev/Test cloud?

It is a huge habit of developers to build locally, and I think that most developers I tell to stop doing that complain. It is a big problem, just from a pure pollution standpoint and the fact that you don’t really know the condition of each developer box, there is no consistency. Hopefully a Dev/Test Cloud is easy enough to utilize that they don’t see the need, and there is some training—I think it goes back to the idea that if you treat it as this singleton thing, you know that some Dev/Test environments live and die within an hour time period. They’re very short. That should be the idea, that you spin it up, put your code and test it quickly, get the IP address. You test it and kill it, and that’s it. You move on and continue coding, and as it moves downstream, you can have a more robust integration environment.

I do think that there are best-of-breed Dev/Test clouds. I think you have the Dev/Test clouds that are great for the spinning up and down a pole instances. And then I think you have past types environments, and I think you have load testing clouds, and you have functional testing clouds. There may be a reason to break them out into different types. The most important thing is that everything is tightly integrated and that there is a strategy. It’s not just off the cuff, because that’s equivalent to shadow IT. Even if everybody knows it’s happening, it’s the same difference.

What Are the Prerequisites for a Dev/Test Cloud?

I think you have to have a steward, somebody who owns it, standardization. You need to have full master scripts, snapshots, images, that represent the de facto Dev/Test environment, and somebody needs to make sure that those are up to date and current so you have consistency across all the locations where these have been spun up. The contradiction is if you are using a performance testing cloud for load testing, a functional testing cloud, where you don’t have control over that infrastructure. In those scenarios, if you’re running Selenium scripts, you’re going outside in, so it doesn’t really matter as much.

How to do it

If you’re starting bottom up, you could think about it all the way through before you develop it. But most organizations aren’t in that position; they’re slip-streaming that into something else, and chances are you’ve already had this concept and you’re already using virtualization, so part of it you probably already have, but maybe not in the most efficient way. Many of the organizations I’ve seen start with something small. For example, they start with a robust integration environment. Druva is an example of a company that’s made this transition. But in all the scenarios I’ve seen, there’s been another catalyst, it’s never just been Dev/Test cloud. There’s always been something else. An architecture change to microservices, changing your product from an on-premises solution to a cloud-based solution, which was the scenario with Druva. There always seems to be something else. I don’t think it has to be that way, but it seems like there are other driving factors that necessitate change and the opportunity to change your pipeline, and they’re driven by the application. I don’t think there’s an easy answer. I think you have to rely on automation, you have to rely on tooling. You can’t be afraid of tooling. Don’t let the tool dictate what you do. You should be telling the tool what to do. If eventually you are a Chef shop and Jenkins, and it dictates what you’re doing, then that’s all you’re going to do. And you’ll never be able to adopt a future tool, so think about that. Inertia is a powerful force.

I have very strong opinions about how Development environments should be set up. Stop building locally, and put it in the cloud.