Originally published at The New Stack

If you’re developing software in a growing company, there’s a good chance that your development and testing team isn’t huddled in one room, or at the same site, or on the same continent. There’s also a good chance that the teams are not in shouting distance from your DevOps or Ops team.

Globalization gives us the luxury to hire talent around the globe, allowing cost optimization and quicker expansion. But it also creates compounding challenges, especially when keeping DevOps processes in place is a priority.

One of the top five causes of DevOps initiatives is the failure to collaborate (Top 5 Causes of DevOps Failure and How to Avoid Them, Gartner, 22 June 2018). When your development, Ops/IT, and DevOps teams are spread across geographies–collaborating becomes even harder, and the risk of your organization becoming much slower than you would have liked increases.

The risk can be decreased by fighting isolation of remote teams and providing them with the processes and tools that they need for functioning as small, self-sufficient units that collaborate with each other.
Until someone invents time zone-defying teleportation, we need to rely on creating multiple communication paths and taking small steps to empower teams.

How To Provide Your Remote Teams With Development Environments

Looking for a good start? Don’t make teams sweat for development and test environments.
Provisioning and deployment of IT environments for remote teams easily turns into a bottleneck, and make your operation feel like the software version of ancient Babylon. A remote team that needs to get IT environments from another team can create frustration and slow you down. As one smart person told me recently, and it’s stuck in my head since – dependency in waterfall makes you waterfall.

So, how do you make provisioning and deployment of environments be NOT waterfall?
The concept is simple. You make them self-service. Luckily, technology is on your side. It’s much simpler to automate IT environments these days than it was a few years ago. Leveraging public cloud infrastructure and container technologies can make your life much easier. But, even if you’re doing neither, or still in the process, it’s still very doable.

Instead of providing environments by request, your IT or DevOps teams have to start offering environments as a service. Environments become their product and their API to the outer world. And your remote teams can start consuming this service the same way that they consume electricity and wi-fi and coffee at their remote location – whenever they need it, as much as they need to accomplish their tasks. In a reasonable manner, of course, we don’t want anyone to overdose on caffeine or accrue a 500K dollar bill from AWS.

Ready to enable self-service environments? Make sure you follow a few best practices.

6 Tips for Enabling Self-Service Environments

Reuse Automation

Reusing automation is where you get the ROI. Invest in defining and modeling the environments you want to offer, and their input parameters.  Environment blueprint design isn’t something everyone should do. You need to have one or a few people that do that, depending on your team size. The rest should enjoy the service.

Continuously Improve

Don’t expect to get it all right in one go. The first blueprints are likely to be the worst you will offer. Start small and keep improving them iteratively based on feedback, and your remote teams will thank you.

Empower Teams

Invest in the service, not just in the infrastructure automation and deployment. Think about the ease of consumption. Can a developer/automation engineer/tester from a remote team easily get access to environments? Will they need to ramp up or develop new skills to do that? Can it be done 24/7? What happens if there is a problem? The friendlier the service, the better. Friendlier can mean different things to different people, so make sure you cater for all stakeholders. Some will want a CLI or API interface. Others will not call it friendly if it doesn’t have nice pictures on it. If you have diverse teams, you may need to offer a few ways to consume the same environments.

Make It Easy To Troubleshoot

Make sure you can access environments you provision quickly in case of issues and troubleshoot. Troubleshooting and debugging shouldn’t turn into frustration.

Go for Immutable Infrastructure

If you can control it, make technology choices that will enable immutable infrastructure. Static environments are the worst and slowest thing in the world, but dynamic deployment on statically provisioned infrastructure is only slightly better and still brittle. Avoid configuration management if you can, and make your infrastructure cattle rather than pets.

Stay in Control

Make sure you have controls in place. Self-service doesn’t mean all-you-can-eat-buffet. You need to be able to track what environments are being consumed, and what they are used for. If this 5K per week performance testing environment in AWS isn’t something you want everyone to start whenever they like – you will need to make sure your solution includes mechanisms that would help you manage the service, like RBAC, policies on environments and cost control.

Have more tips to share on making DevOps scalable? Reach out to me at @mayaberlerner