Managing policies …and your usage …and your costs …and how it all adds up sounds super dull, right? And it is.
That is, until it isn’t. Have you ever had to experienced the feeling of going to your boss or any other financial controller in your company with an unexpected bill? And that bill happened to be larger than you could have imagined? It’s a long walk to their office isn’t it? Well, we don’t want you to experience that, ever!
What managing your policies equates to is managing how long your environments run. How long your environments run affect your usage and your bottom line.
Think of it as thrift, as a gift, if you catch my drift
We created the self-service Environment Policy feature to empower you, the customer. This gives you the ability to say just how long you want the environment to exist, run and when to shut down when you’re not using it. All of these you can handle manually as well, but you need a starting point at least – just the basic framework.
Whether you’re a new CloudShare customer or have been with us for a while, you’ll have a way you like to work and will want to match your policies to your work habits. This is the best way to start when creating policies. Ask yourself this, how long do you and your team work on specific tasks.
This can typically be broken down into 3 basic sets – you will just want to match the tool to the job:
- a quick run, I just need to test something for a couple hours
- I’m working on an ongoing daily project, should take 1-2 months
- This is my master environment. I’ll need it for ever and ever and ever and ever and ever
Create your policy
This is your basic bughunt and testing policy. You only need it for a couple hours, likely won’t even leave your desk except to get coffee.
Note the short storage time. You can of course make this longer but the idea is that you found something or fixed something (yay!) and you immediately take a snapshot to keep a reference point for it. As you’re taking a snapshot right away you don’t really need to keep the active environment, so let that thing get auto-deleted.
Next up is your longer ongoing project-type of policy.
With a runtime of 30 days (remember, that’s 720hrs of actual running time, so quite a lot) and a 60-day storage time this should suit most requirements. It’s your go-to runtime. By the end of the project, you’ve reached the end of your storage time and the environment gets auto-deleted. Snapshot the environment to save a copy for future use or can it, because you’ve already delivered and moved on to your next project.
This next one is the one policy to rule them all. It’s used for environments that are your golden copy, master shared environment for VPN set-ups, or you just think of it as the daddy environment. Whatever your use case – you need this one to stick around for a while.
This is the fire and forget policy. It’ll keep running and won’t even suspend if you don’t want it to. You’ll come back to it in a year’s time to asses if it needs changes, snapshot the environment, relaunch it with a shorter policy or extend the policy for another year.
You have control
Don’t forget, as your projects progress, and as you continue working on CloudShare, you may want to make changes or adjustments to your policies to better suit your needs. Go for it! You can also change the active policy assigned to an environment by clicking
or extend the policy, which basically appends the same policy to the environment again.
Feel free to play with the suspend times as well. Our sensing is so good, we detect pretty quickly once you’ve stopped working on machines so your environment won’t run when you don’t need it to.