This year has flown by – and it’s been a big one for ParkMyCloud. Working closely with our customers, we’ve added features and functionality throughout the year to keep you parking, saving and happy! Here are the highlights of what’s changed in ParkMyCloud this year.
The “snooze button” has the honor of being ParkMyCloud’s first “most requested feature”. This function allows users to suspend a schedule for a set period, so, for example, you can use an instance on the weekend when it’s scheduled to be parked.
In March, we expanded ParkMyCloud accounts to include multiple user accounts per organization, and introduced user/team structures. This was also the first time you could manage multiple AWS accounts in one ParkMyCloud account.
Auto scaling groups can be parked just like an individual instance – when parked, the minimum, desired, and maximum number of instances are set to 0, so you can “pause” their scale-up times.
In this release, we added the ability to create Logical Groups of resources, which can be parked and managed as a unit, and sequenced for start/stop. The platform was also improved to be 70x faster!
In October, we released the Policy Engine, which allows administrators to create policies to automatically attach or detach parking schedules, assign a “never park” rule to an instance, assign instances to teams, and more.
We changed the look and feel of ParkMyCloud’s interface to be more organized and intuitive – and so far the feedback has been positive!
Whew – try scripting all that! (Or don’t.)
We’re looking forward to 2017, which will have more improvements and expansions for ParkMyCloud. In January, we’ll add support for Microsoft Azure, and Google Compute Engine will come after that. We’ll also add the ability to park additional resources, like RDS in AWS. If you have other things you’d like to see ParkMyCloud do in 2017, let us know in the comments below!
Happy holidays and wishing you a joyous new year from the ParkMyCloud team!
We were recently asked about our vision for cloud applications in 2017: are we still seeing ported versions of legacy on-premises Software-as-a-Service (SaaS) applications? Or are most applications – even outside of pure-play startups – being built and hosted in the cloud? In other words, how long until full cloud takes over?
Actually, it already has.
Native cloud applications like ours – an 18-month-old startup – that have been built, tested, and run in the cloud are no longer the fringe innovators, but the norm. In fact, outside of a printer, we have no infrastructure at all – we are BYOD, and every application we use for development, marketing, sales and finance is a SaaS-based, cloud-hosted solution that we either use for free or rent and pay month-to-month or year-to-year.
This reliance on 100% cloud solutions has allowed us to rapidly scale our entire business – the cloud, and cloud-based SaaS solutions, have provided ParkMyCloud with the agility, speed, and cost control needed to manage to an OpEx model rather than a CapEx model.
We were able to rapidly prototype our technology, test it, iterate, and leverage “beta” communities in the cloud in a matter of months. We even outsource our development efforts, and seamlessly run agile remotely using the cloud and cloud-based tools. For a peek into the process, here’s a sampling of software development tools we use in a cloud-shrouded nutshell:
- Amazon Web Service (AWS) for development, test, QA and production
- VersionOne for agile management
- Skype for scrum and video communication
- GitHub for version control
- Zoho for customer support
- LogEntries for log integration
- Confluence for documentation
- Swagger for API management
And I could repeat the same for our Marketing, Sales, and Finance process and tools – the cloud has truly taken over.
We don’t know if these applications are built and run in the public cloud or the private cloud – that’s irrelevant to us, what’s important is they solve a problem, are easily accessible, and meet our price point. We do know that these are all cloud-based SaaS offerings – we don’t use any on premise, traditional software.
The net net is that many companies are just like ParkMyCloud. The question is no longer about how us newbies will enter the world – the question is, how fast will legacy enterprises migrate ALL their applications to cloud? And where will they strike the balance between public and private cloud?
The other day, we talked to a prospective ParkMyCloud customer about how to protect his production servers. He had just started a trial of ParkMyCloud, and before he added additional users to his account, he had an important question: How can I keep my production servers safe from my end users accidentally parking them?
It’s a great question! Before you start shutting down your non-production resources for cost savings, it’s a good idea to protect your mission-critical production resources from being parked, which could wreak havoc on your applications — while some resources can be stopped, or “parked”, during off-hours, there are, of course, others that need to run 24×7.
Luckily, with ParkMyCloud’s policy engine, it’s straightforward and easy to protect your production resources. All you need to do is apply a “never park” policy so those resources cannot be scheduled or manually started/stopped.
Only users with the SuperAdmin role can create and manage policies, so if you’re the primary account holder, you don’t have to worry about end users changing these policies once they’re set up. Your production resources will be safe from being parked, so you can start parking and saving away.
Here’s how to create a policy for yourself. (If you don’t have an account yet, you can start a ParkMyCloud free trial and follow along.)
From the ParkMyCloud console:
- Go to the left sidebar and select “Policies” and “Create Policy”.
- Name your policy – let’s call it ‘Never Park’
- Input the criteria to identify your production resources – usually this will be by name or tag.
- Select “Restrict” as the action.
- From the Restrict dropdown menu, select “Never Park”. For this option, users can neither attach schedules nor manually start/stop resources.
You can also use policies to assign instances to teams based on their tags or names. If you set up your teams in advance, this is a simple way to automatically control which users have access to which instances. So in this example you could set up a “Production Team” and have all your production instances sort directly to this team. And as an admin you are able to create the permissions for who has access to this team, adding another layer of protection.
Save your policy to protect your production resources from being parked and you’re all set!
There are a few other reasons you may want to use policies on your resources. For example, you can use policies to automatically attach or detach schedules to instances, again based on credential, location, name, type, or tag. So, for example, you could set all of your instances tagged “development” to have the “Up M-F, 8 am – 5 pm” schedule automatically applied.
You can also restrict resources with parking schedules to “snooze only”. That is, end users can only snooze the attached schedule, they cannot edit, detach or change it.
The policy engine is a powerful feature that can help you automate many of the common actions within ParkMyCloud, ensuring that you maximize your cost savings with the least amount of effort.
If you have any additional questions about using policies, please comment below or contact us!