Cloud Parking

What is Cloud Parking?


The cloud’s model of operations lets you use resources on-demand, but ironically you’re paying for them even when you aren’t using them. This system of cloud services is a double-edged sword to the unprepared. Cloud Parking is a concept that enables you to leverage the ‘pay for what you consume’ philosophy for every cloud resource that you use. Turn on the resource when you’re using it, and park it when you’re not - but applicable across your entire cloud. 


What can be parked? 


The very paradigm of Cloud Parking rests on a resource’s ability to be turned on & off. Some resources have an inherent ability to be started at a certain time and be parked at a certain time - the best known would be EC2 & RDS instances. These can be parked out of the box in multiple ways that have been explored before. 

But your cloud has a multitude of other resources that are charged 24/7, but not used the same. Almost 80% of your cloud can be parked when not in use, barring a few functions like serverless. Why not extend the parking feature even to the ‘non-schedulable’ services - like RedShift Clusters, ECS, and EKS? ‘Start and Stop’ in their case involves a few additional actions like taking a backup/snapshot, deleting the resource & restoring it when needed from the backup. 


What are the current ways to park?


The current most widely practiced method of parking resources is to manually create lambda functions that start and stop them at a specified time. AWS has equipped users with the Instance Scheduler that provides a CloudFormation script, that they can use in conjunction with DynamoDB tables to set up schedules. There are a couple of third-party tools that solely provide the function of scheduling instances - in an automated fashion, and an easy-to-use UI. 



Pitfalls of the existing parking methods

Like Michael Wittig points out, EC2s have been around for 13 years. Despite this the existing parking methods haven’t prevented multiple businesses from incurring losses up to ‘000s of dollars from unnecessary uptime.


They only park EC2 & RDS instances 


The existing parking methods focus on just two out of the hundreds of resources that exist in your cloud. That hardly fulfils the paradigm of ‘Cloud Parking’. 


The most widely used method is hardly automated


The biggest parking method, the Instance Scheduler, is a manual of instructions to follow to achieve a schedule, it doesn’t put your cloud on auto-pilot. Consider a set of windscreen wipers. In the case of a slight drizzle, you might manually wipe it whenever needed. But as soon as the rain gets heavier, you trigger them to run automatically. Suppose the makers of the cars hadn’t inserted the automatic option - a heavy downpour would have you scrambling in chaos, your visibility is affected & you’re driving slower. As your cloud scales & becomes more intricate, human error & redundant repetition become your enemies.  

 

They only park based on time


The standard approach to parking is to set a start and stop time - based on usual business hours for your non-prod instances. But in a lot of scenarios, for larger companies, time doesn’t justify the scheduling needs. If you’re dealing with a complex or cross-continental infra, you need a smarter parking method that’s dynamic and based on actual usage. As soon as an idle resource is identified, it should power off, without the hassle of calculating the ideal time or worrying about timezones.  

I’m talking real-time power off & on-demand turn on (as easy as the flick of a switch, sticking with the metaphor). The duration where employees take breaks or their priority shifts between projects are all valid reasons to reduce uptime. 


They do not allow collaboration


DevOps teams that operate in a multi-geo setup require collaboration-friendly tools & platforms. You wouldn’t want team meetings being called on Slack just to park or unpark a resource. In a lot of cases, the creator and users of the resources are different, the intention is to give the actual user the required control to operate smoothly. 

Your engineers should be able to spin up a resource whenever they need without any hassle, through simple external URL triggers and integrations. This ability, synced with automated parking based on idleness, will be a well-oiled machine in a collaborative landscape.


 In conclusion


We’re always looking for ways to create a better version of our architecture, applications, and offering - the same applies to every cloud management function. In the case of Cloud Parking, although lambdas have been around for a while, it’s time we have something more scalable and dynamic - so that you don’t have to recreate it across resources, regions & accounts.


Cloud Parking

Smart Scheduling at your fingertips

Go from simple to smart, real-time AWS resource scheduling to save cost and increase team productivity.

Learn More
More Posts

You Might Also Like

AWS Use Case Files
Launch EC2 Instances with CloudFormation
CloudFormation is the gateway to Infrastructure-as-code for AWS users. Learn how you can deploy Cloudformation templates through Totalcloud workflows and increase your customization.
June 25, 2020
Hrishikesh
AWS Use Case Files
JIRA Triggered Cloud Management
What if cloud management were as easy as raising a JIRA ticket? Almost every DevOps team uses JIRA as a standard means of issue tracking & task management. It’s a given that it would be a seamless process if you could also integrate your cloud processes with it.
June 16, 2020
Hrishikesh
AWS Use Case Files
Totalcloud Launches New Temporary Rightsizing Feature
You can't always shut down your EC2 machine outside of business hours since some machines are needed up for longer periods. Totalcloud's new downgrade feature lets you optimize your costs by letting you downgrade your machines in a fixed schedule.
June 8, 2020
Hrishikesh
AWS Use Case Files
S3 Cost Saving: Archiving Compressed S3 Data into Glacier
We've devised a new workflow to cut your archiving costs. Simplify the storage, compression, and transfer of your S3 data into S3 Glacier with 1 workflow and 8 nodes.
June 8, 2020
Hrishikesh
AWS Use Case Files
Creating a 3-tier Application With Totalcloud’s Code-Free Workflows
As part of a new request by a customer, we've developed a workflow to deploy 3-tier applications much faster. Utilising merely 3 workflows to achieve a result that would have you scripting and troubleshooting for hours. This post gives you an idea of how this workflow functions, the services being used, and how you can benefit from it.
June 2, 2020
Hrishikesh
AWS Tips & Tricks
Componentized Cloud Management: The way ahead for Cloud Automation
When something gets complex, our primary approach is to break it down — even cloud management. If you’re a part of a growing company that uses the cloud, you can see your infrastructure becoming more…
May 29, 2020
Sayonee