Turn off your staging environment at night

In most tech companies, applications are deployed on three environments : development, staging, production.

In most tech companies, applications are deployed on three environments :

• development
• staging
• production

In big companies, there are even more.

Most of the time, "development" means "on the developer laptop". Hence the infamous quote :

But we are digressing, that's not the topic of this article ☺️.

On the other side of the spectrum, the "production" environment is typically the most important one because that's where customers go when they type "app.company.com".

But that's not the topic of this post, neither.

So what are we talking about ? We're going to have a closer look at the "staging" environment.

Its objective is to give the opportunity to test the product "internally". The typical users are :

• Developers : they test a new feature in a real environment in addition to the development one (even if they have a great test coverage, it's important to do so)
• POs : when a feature is deployed, the Product Owner will typically go there to test the feature, to see if it fits with the business requirements
• QAs : the Quality Assurance team will perform their extensive tests on this environment to see if the feature works well
• C-level : some of them are really implied on what happens on the field so they can test new features as well
• Sales : in some companies, that's where the Sales team perform their demo to potential customers (some companies can have a dedicated environment for this)
• etc.

As you can see, this environment is really important. Therefore, it's crucial for it to be as close as possible to "production".

Whether it be in terms of infrastructure, data, or security.

If "production" consists of 100 AWS EC2 instances behind a load balancer - because you're super successful 🚀 -, to be efficient, your "staging" environment must be close to it.

Indeed, if you have only one server for "staging", you can miss some important bugs that would happen only in a "distributed" environment.

Now that we've showed the importance of "staging", let's talk about the associated cost.

Let's say you build your "staging" environment with 5 AWS EC2 t3.medium instances.

Based on estimations, this environment will cost you around $160/month.

Extrapolated yearly, the cost would be $1920/year.

Even if most companies can afford it, should we really continue paying this much ?

I'm pretty sure a lot of your employees would enjoy spending this money on some team event or anything else.

Here are the arguments that we can hear, here and there :

And the list can go on and on...

Some are pretty good arguments, to be fair.

But the issues they raise, can be easily addressed with the right tools.

Given the fact that some users are not technical, they need to have a simple tool to manage this.

That's why we developed RebootX.

The right tool for the job, right in their pocket !

Let's continue the example with AWS.

1. Your CTO/SysOps defines a super restrictive IAM policy to manage only the "staging" servers
2. Then, they can create an account for POs, QAs, etc. attached to this policy
3. Then, these people download RebootX from the AppStore and enter securely their AWS credentials (stored locally in their keychain)

Et voilà ! In one click, they can turn on and off the servers, on demand.

Your instances in RebootX

And it works not only with Amazon Web Services (AWS), but also with Clever Cloud, Google Cloud and OVHcloud (more providers to come : Microsoft Azure, Scaleway, Heroku, etc.)

Since people work 1/3 of a day, this can theoretically makes you save a lot of money that you can use for something else.

And without doing any green washing, just as we must stop the tap while we're brushing our teeth, I'm pretty sure the planet will thank us for stopping servers when they are not in use 🙏🏽.

PS : If you have any question, our DMs are open ☺️.

PS2 : Your cloud provider is not integrated yet ? Tell us more.

Want to give it a try ? Get the app on the stores.