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 fulfills 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.