As we launch into 2017, we’re looking to bring our public cloud users even more ways to save on their cloud spend. Here’s a preview of some of the more impactful features and functionality we’ll be releasing throughout the year.
New Cloud Service Providers
Thus far, ParkMyCloud has supported customers of Amazon Web Services (AWS) alone. (No small fries here; about 30% of public cloud infrastructure is in AWS). However, in two weeks, we’re expanding by releasing support for Microsoft Azure.You will be able to manage AWS and Azure resources side-by-side in a single dashboard.
In the following months, Google Compute Engine support will follow.
New Ways to Save
In addition to the new cloud service providers, we’re also adding support for additional services and new ways to save on your cloud infrastructure.
We’ll start the expansion from compute services by parking databases (Amazon RDS and others). We will also offer resource rightsizing, so you can ensure that you’re not wasting money on resources that are larger than you need them to be.
Adding to the ParkMyCloud Experience
We’ll also be enhancing the ParkMyCloud experience with surrounding features, starting with single sign-on (SSO) using SAML 2.0 coming in February.
Following that, we’ll add external notifications leveraging AWS SNS. And for the quants out there we’ll be adding a data analytics layer. We’re also excited to share that we’ll have native mobile support for iOS and Androidby the summer.
Of course, as a small and agile company, this list is not complete! We’re happy to hear your thoughts and suggestions about what you’d like to see in ParkMyCloud this year – so what’s at the top of your list?
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.
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!