Last week, Dale (ParkMyCloud CTO) held a tutorial web session to share (1) how to get started with ParkMyCloud, (2) what’s new in the platform, and (3) the best ways to use ParkMyCloud in your environment, including best practices from several of our customers.
If you missed it, not to worry. Here’s a recording of the session, with links to points of interest below.
At the halfway mark of each year, CRN takes a look back at the previous six months in the channel and throughout the IT world. The Cloud Application Startups category seeks Software as a Service (SaaS) applications offering solutions that broaden notions of what can be achieved by deploying applications in the cloud while solving diverse real-world problems for all types of business users.
ParkMyCloud was selected for our ability to slash AWS bills by more than 60 percent, through our simple app with no up-front costs.
Amazon Web Services (AWS) has grown immensely and recently cracked a $10 billion annual run rate. This means AWS is growing 70 percent year-over-year, which is staggering for a company of their size. Moreover, AWS recently doubled their compute power and now boasts 10 times more power than their nearest 14 competitors combined.
Elastic Compute Cloud (EC2) makes up nearly 70 percent of AWS’s revenue. That is almost $7 billion, and it is growing at 88 percent year-over-year. A little over half of that compute power supports nonproduction workloads, such as development, testing, QA, staging, training and sandbox environments. Many of these environments run 24 x 7, even though they are not being used. It would be like you leaving your car running all the time, even when it’s at home in your garage, which is insane.
So how can companies unlock savings from these non-production environments? Here are four key ways…
We pushed out a release over the weekend – most notably including the ability to park Auto Scaling Groups! Here’s what’s new.
Parking Auto Scaling Groups
You now have the ability to park full Auto Scaling Groups. You can control Auto Scaling Groups in the same way that you can individual instances – with schedules and on/off toggles.
You will see these groups included on your dashboard:
When an Auto Scaling Group is scheduled to be parked, ParkMyCloud will store the existing settings for minimum, desired, and maximum number of instances. Then, it will change those settings to Min, Desired, Max = (0,0,0) in AWS (while keeping the original values in our system) for the scheduled parking duration. Note that this means the individual instances will be terminated. When the instances are scheduled to run, we’ll set the parameters back to their original values and new instances will be spun up.
By the way, if you are using spot instances in those Auto Scaling Groups, we will be able to park those as well.
Since you can now manage your Auto Scaling Groups in ParkMyCloud, your downloadable reports will now be based on “resources” rather than “instances” – instances and Auto Scaling Groups will be considered resources. You’ll now be able to see parking savings for your Auto Scaling groups.
Detailed Information on Your Resources
You now have a much more detailed amount of information about each of your resources – whether instances or Auto Scaling Groups. Just click the “i” information button on the right side of the dashboard, and you’ll see a modal screen like the following:
Plus, you now have access to our shiny new User Guide!
It is hard to believe that this week, ParkMyCloud is one year old. Wow! Time has flown by so quickly, perhaps it is more appropriate to measure it in dog years. Throughout the past year, we’ve been plugging away in our little corner of the cloud world. But how did we get here?
One Year Ago: The Pivot
Prior to ParkMyCloud, we were part of another company called Ostrato. There, we built a hybrid cloud governance and management platform, called cloudSM, which worked across several cloud providers (AWS, Azure, OpenStack, Vmware, SoftLayer, etc.).
At the time, any platforms offering “cloud analytics” seemed to get most of the attention and funding. I have, in the past, referred to these platforms as “Cloud Tattletales”: They tell customers a lot about what is wrong with their environments, but don’t actually do anything to help them to fix it. The platform we built, cloudSM, actually helped them do something about those problems. However, adoption was poor.
The fact that we were making little progress, despite our best efforts, begged the question: Were we early? Did we build something the market was just not ready for? Perhaps what we were witnessing was a “cloud analytics wave”. I figured that at some point, customers would wake up and realize that they needed to do something with all that wonderful analytics advice, like actually govern their hybrid cloud environments (the “cloud control wave”). If true, how long that would take was anyone’s guess, but 3-5 years or longer was not out of the question.
As with most startup founders we were impatient, and wanted to start making a difference. It was time for something new. But what?
Bridging the Gap Between Cloud Analytics and Cloud Control
New cloud analytics companies were popping up all over the place, so it would be hard to differentiate ourselves in that market. Both waves did have something in common: cost control. So, instead of spreading ourselves thin trying to control all aspects of cloud, we decided to have a laser focus on cost control.
One thing we repeatedly observed, especially in public cloud, was the tendency for people to leave stuff running all the time. Obviously, in production environments that made sense, but not in non-production environments. Those systems could be turned off when people went home at night. We decided to take our most popular cloudSM “global policy”, parking VMs and instances on a schedule, and use that as the vehicle to deliver immediate cost savings. We would allow people to turn their instances off when not in use, and power them on when needed, without scripting and without being a devops expert. We also set our sights on a single cloud provider (AWS), rather than boil the “digital ocean”, and decided to make a dedicated product out of it, in a new company. The cost savings we could deliver would fit right in with the other purchasing options AWS developed, helping customers save money and contributing to AWS’ ability to oversubscribe their infrastructure.
We modeled ourselves after Nest, the intelligent thermostat, seeking to become “Nest for the public cloud”. We wanted to change the default state for AWS non-production environments from ON to OFF. That was the genesis of ParkMyCloud and the rest, as they say, is history.
The Little Startup That Could … Save You Thousands
We launched our new company, ParkMyCloud, on July 1, 2015. We went live on our SaaS application, also called ParkMyCloud, in September of 2015. We had our first customer by the end of the month. Fast forward a year to today and we have built a compelling, very simple-to-use cost control product. We’re continuing to improve our application, adding new features all the time (e.g., parking entire auto scaling groups, which is almost done). Customers love the savings we provide ($3 to $7 for every dollar spent). Our customers are truly global with several in Europe, Asia, and even as far from our home base in the Washington, DC area as New Zealand. All like our clean user interface, which allows them to see all their instances across all AWS regions and accounts. In fact, some use our interface as a proxy to the EC2 portion of the AWS console, obviating the need to add a lot of users in their AWS accounts.
Over the weekend, we pushed out a new release of ParkMyCloud, with new features focusing on reporting and snooze support. Updates made in this release include:
Upgraded reporting, including 4 new reports: detailed costs by instance, cost summary by team, cost summary by credential, and roster of team members by team and by role. These reports can be pulled for any date range you select:
Updated the Dashboard, which now shows how much time is left on the snooze period for snoozed instances. The time remaining will display both on the parking menu and in a tooltip, as shown below:
There is a new default parking schedule called “Always Parked – Snooze to Use Instances”. Several of our customers are successfully using this “always parked” strategy to achieve maximum savings on their non-production instances.
We also did some very important behind the scenes work to streamline the DevOps process and improve database development.
Coming soon: the ability to park Auto Scaling groups!
As always, we welcome your feedback. If you have any questions, comments, or suggestions for the future, please let us know in the comments below.
Over the long weekend, we pushed out a new release of ParkMyCloud. This new release contains several feature improvements, and sets up the platform for more user-requested features to come. Let’s take a look.
When you next log in – or first log in, if you’re a new user – you will be greeted by a new dashboard. It has a new look and feel, with actions on the left, info on the right.
The old recommendations bar has been revamped into a Keywords tab, which alarms RED whenever there are instances recommended to be parked:
Also notice the “Metrics” and “Policies” tabs – coming soon!
“Always Parked” Schedule
You can now create a parking schedule that parks instances 24/7:
This is great news for users who prefer a parking approach that capitalizes on the “snooze” function.
In this approach, an organization may choose to set all non-production instances on an “always parked” schedule. When developers come in to work in the morning, they can “snooze” the parking schedule on their instances for the length of the workday, for which time they will run. Then, the instances will turn off at the end of the day, maximizing savings.Several of our customers have had great success with the schedule + snooze formula.
This release also improves the search logic functionality. You can now use negation logic in both the dashboard filtering and in the recommendations keywords. Just put a “-“ in front of a search term, and everything not including that term will show up:
Schedule Removal Behavior
We have also changed the behavior for schedule removal. When a schedule is removed, the instance will no longer automatically start. Now it will remain in the state it was in when the schedule was removed.
As always, we welcome your feedback on these updates – please comment below.