A sandbox is an isolated and safe place to play and learn.

It’s easy to imagine that there are strong parallels between developers who are learning new skills and children playing in a physical sandbox.

But that is an unwise simplification, unless you want to factor in various toys that have been materialized from the void and then abandoned, random buried piles of cat poop, and occasional visits from a rabid dog.

In this article, I’ll go over some of the tricks we used to make our cloud sandbox safe, reliable, and low maintenance.

As always, if you have another approach that worked well for you (or you’ve encountered problems that I haven’t covered), then I’d love to compare notes with you.

What is a Sandbox?

In this context, a sandbox is a restricted place that developers can visit to learn, test ideas and theories, and experiment. They are free of the restrictions imposed by an entirely automated build and deployment system. In a way, they give developers back the opportunity to “Ops” for themselves.

This is different to the idea of running your own copy of production in isolation in order to test some new feature: in my mind, testing new features should be a standard part of the delivery pipeline. It’s also different to application sandboxes that run within a device. But you knew that already.

How Sandboxes Go Wrong

One of the definitions of entropy is a_ lack of order or predictability; a gradual decline into disorder_. Whereas things will typically start out well, there is a natural tendency for complex systems (including sandboxes) to eventually devolve into chaos. These can include:

• **Abandoned resources **where something was created, used for a while, and then discarded because it’s no longer needed;
• Oversized resources where a small tactical nuclear weapon has been used to crack a nut;
• Illicit access has been granted to environment or infrastructure, either as part of standard workflow, or in spite of it;
• Production servers provisioned in the sandbox by developers not willing to invest time in learning standard deployment models, and attempt to use the sandbox as a way to game the system. This typically works as well as those scavenged systems sitting by the side of someones desk with a post-it note labeled “payments system! do not turn off!”;
• Lost productivity in the case where developers are blocked waiting for access to new or novel resource types

So the big question in all of this is how can we create a space that empowers developers to explore and learn, but without undue effort required on the part of the maintainers in order to minimize the ravages of entropy?

#devops #devops-practice #sre #sandbox