ParkMyCloud has built a SaaS platform that allows users to turn off AWS EC2 resources in non-production environments during off-hours. We call this “parking”.
In order for ParkMyCloud to automatically recommend instances to be parked – or to simply automate the parking process altogether – users should have a naming convention for their instances or some type of tag on the resources.
Of course, our application is not the only one which relies on you having some type of tagging strategy for your resources. In fact, I’ll wager that most cloud applications involved in some type of cloud analytics, DevOps automation or cloud management would also be in a better position to help you help yourself if you had a consistent approach to tagging.
Tagging can help you in all sorts of areas, from asset management, to automation, cost allocation and security.
While I was researching ideas for this blog, I came across a great resource on AWS Tagging Strategies, published by AWS in January of this year, which provides a comprehensive overview on the subject. In fact, I couldn’t have said it better. You can find it here.
One of the excerpts from this blog which caught my eye was the about Tagging Categories:
Organizations that are most effective in their use of tags typically create business-relevant tag groupings to organize their resources along technical, business, and security dimensions. Organizations that use automated processes to manage their infrastructure also include additional, automation-specific tags to aid in their automation efforts.
We take this concept to heart here at ParkMyCloud in our internal systems, by applying tags based on functional group (prod, dev, test, QA, etc.) and resource type. We also recommend this approach to our customers — many of whom do use category tagging to identify resources as “production” or “dev”, “test”, “QA”, and “staging” for example. This makes it very easy for us to identify and automate the process of “parking” instances and quickly save customers money.
In the coming weeks, we will release “Zero-Touch Parking”, which will take maximum advantage of tagging. Here’s how it will work.
Let’s say you have 100 instances, 50 of which are production instances, and therefore should never be parked. If those 50 instances are tagged “production app”, you will simply create a policy that says instances with that tag assigned will get routed to the Production group, it’s blocked from having a schedule assigned to it, and runs 24x7x365.
On the other hand, let’s say we have an instance tagged “test”. We could have a corresponding policy that assigns that instance(s) to the group “Test Team”, applies a “Test” schedule which turns the instance off at 6:00 p.m. every weekday, on at 8:00 a.m. every weekday, and off on weekends.
The strategies outlined in this helpful document are not limited to AWS, but should be applicable to environments in just about any cloud provider.
So, on behalf of other cloud applications, help us to help you — get out there and start tagging, if you haven’t already.
We just released a new version of ParkMyCloud that’s jam-packed with new capabilities and features! Here’s what’s new.
More than 70x Faster
Previously, ParkMyCloud ingested instances from AWS every 6 hours – which suited most purposes, but meant there was a lag in displaying new instances. Now, ParkMyCloud will auto-ingest from AWS every 5 minutes. This has a few benefits: parking is now more tightly enforced, instance state changes made outside of ParkMyCloud (e.g. directly changed in the AWS console) will be detected within 1 minute, and the entire orchestration engine is more stable and reliable.
Resource Groups for Sequenced Start/Stop
You can now combine your instances in what we call “Logical Groups” for ease of management. You can park a group as if it were a single instance.
Additionally, you can sequence the order in which you want instances in a group to start and stop, providing configurable delays.
This feature grew directly from user feedback, because of the challenges they have with some database and other legacy applications. We’re happy to deliver!
Fresh, Compact Dashboard
The dashboard has been redesigned, with new capabilities, including vastly improved search filtering (can now filter by schedules and schedule status, auto scaling groups, logical groups, and more).
I think most people can agree that eating your own dog food – or drinking your own champagne, to the glass-half-full crowd – is a hallmark of a business that has created a successful product. The opposite is clearly true: when Alan Mullaly was brought in to Ford, he knew there was a problem when he was picked up from the airport in a Land Rover rather than a Ford car – and when he couldn’t find a single Ford vehicle in the executive parking garage.
For those of us in the software world, there’s another piece to that picture. To tell you how we discovered this for ourselves, I’m going to tell you a story.
It was six weeks after ParkMyCloud’s founding. We had the very first beta version of the product at our fingertips – but before sending it out to beta testers, we gathered the ParkMyCloud team in a conference room to do a bit of usability testing for ourselves. I created a ParkMyCloud user account and hooked up our AWS account so there would be instances to display.
“Now try it out, and let me know if you see any problems,” I told the group.
Heads down, focused on laptops, everyone diligently began to click around, playing with the first generation dashboard and parking schedule interface. For a moment, the room was quiet. Then a chorus went around.
“Hey, what happened?”
“Is anyone else getting this error?”
All at once, everyone around the table lost access to the application. It was gone. For a minute, we were left scratching our heads.
“Okay, what was everyone doing just before it shut down? Did anyone park anything?”
Finally, a sheepish marketing contractor spoke up. “I may have parked an instance.”
As it turned out, he had parked a production server. In particular, the production server running the ParkMyCloud application. D’oh!
Apparently, we needed governance. And we needed it fast. We got to work, and soon after, we released a version of ParkMyCloud that allowed for multiple users and teams for each ParkMyCloud account, all governed with role-based access control (RBAC).
We still use those roles today (incidentally, the “demo” team does not have access to production servers).
The lesson here is that using your application for yourself uncovers important usability issues. Some of these can’t be discovered as quickly as the one above, but only over time – like awkward flows, and reports that skip over meaningful data.
But of course, we also get the same benefits that the product gives to our customers – like saving money. In fact, after the approach was suggested to us by one of our customers, we adopted an “always off” schedule for ourselves. All of our non-production servers are parked 24×7. When our developers need to use them, they log in to ParkMyCloud and “snooze” the schedules for the length of time they need to use them.
This eliminates the need for central schedules, which works especially well for our multi-time-zone development team. Using this schedule, we save about 81% on our non-production servers.
I would encourage anyone who creates products to lead by example and use your product internally — and I assure potential ParkMyCloud customers that we drink our own champagne every day.
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.