Cloud applications in 2017: How long until full cloud takes over?

clouds-take-overWe 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?

How to Protect Your Production Servers (The “Never Park” Policy)

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.

Here’s how to create a policy for yourself. (If you don’t have an account yet, you can start a ParkMyCloud free trial and follow along.)

From the ParkMyCloud console:

  1. policy-engineGo to the left sidebar and select “Policies” and “Create Policy”.
  2. Name your policy – let’s call it ‘Never Park’
  3. Input the criteria to identify your production resources  – usually this will be by name or tag.
  4. Select “Restrict” as the action.
  5. 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!