Is it possible to Stop Your Cloud Environment Breaking Down?  Yes, of course it is.  For that, you’re going to need your developers to write every line of code by hand, themselves.  No shared libraries, and no dependencies on other systems.  Your cloud is going to have to be a private one, so you can control that plane too.

That’s going to be hugely costly, for no great benefit.  Don’t do that.  Instead, learn to make mistakes and have failures in the right place.  The right place is anywhere that doesn’t affect your customers.

Environments
What we’re basically talking about is having different environments for different groups of people to use.

Production Environment
A production environment can be thought of like a production line in a biscuit factory.  The production line can’t stop.  You’ve got a biscuit order to fill by the end of the week, which is achievable, if you’re making biscuits from now until Friday.  But if the line stops or fails, you’re going to miss that order, and affect your customer.

You know there are improvements to be made, and efficiencies can be had, but you just can’t risk changing things on the line that directly makes your biscuit factory money.  So you leave it alone, and you make the same number of biscuits you made last week, and you’ll make the same number of biscuits next week.  Your business can’t grow, and it can’t expand because you can’t risk interrupting the production line.

Development Environment
But what if you had another line that made biscuits but those biscuits weren’t ever sold.  So you don’t need to worry about making a change that makes things worse, or breaks things completely, because the output of the line isn’t important.  The important bit is working out the problems, and coming up with changes which will have a positive impact if you were to implement those changes on the real production line.

Yes, a development line is an expense.  You need the equipment itself, the staff to run it, and the ingredients to make biscuits that you’re never going to sell.  But It’s just development, so maybe you don’t actually need the bake the biscuits, because you’re not making any changes to the ovens, or the way they’re used.  Now you can make a huge saving by either not having ovens on the development line, or having them, and only run them when you want to test out changes to how you use them in production.

You don’t care whether the development line is working or not at any specific point in time – all that matters is that you test and record the results of experiments.

But if the development line doesn’t have to have all the same parts and processes as the production line, how do you know your experiments will have the same affect on the production line, with it’s exact setup?  That’s where a Staging environment comes in.

Staging Environment
A Staging environment should be as close to production as you can get it.  All the same machinery as you have on the production line.  The same number of staff with the same training.  Equipment should be running to the same standard as the production line, and ingredients should be just the same.  The biscuits coming off the end of the Staging line should be exactly the quality expected for the real customer.  Quality Assurance tests, or QA, should be just the same in Staging as it is in Production.

So the process goes, think of an update or a fix to something that’s going a bit wrong on the production line.
Think of a solution.
Design and build that solution quickly.
Try it out on a subset of the equipment in the development environment, without fear of breaking something else.
If the test goes well, come up with a plan for getting that change into the real production environment.
Test that exact plan by migrating, or pushing, your new fix or feature into the Staging line.  Staging should be just the same as production, so if it works in staging and it passes QA, we know it’s good enough to go into Production.
Execute that exact plan to move the change in Production.

Breakdowns
So you can see in this process flow, we still have plenty of scope for things to go wrong.  The original idea for an improvement might be bad, and might go wrong.
The plan we came up with for migrating the change into the next environment might go wrong.
But neither of those two things would affect our real customers.  To our customers, our platform never went wrong, and that’s the important thing!

So if your environment is constantly having problems, but you’re too scared to touch or change anything for fear of breaking everything, maybe it’s time for the tried and tested 3 environment setup.  Dev -> Staging -> Production.

To talk to us about getting towards this approach for your business, get in touch today!