There’s a common misconception in the IT industry. This misconception stems from the premise that the premises of your infrastructure will either be more expensive or less expensive based on its location. Okay, that may sound like a lot of metaphorical jibber jabber and mixed-speak, but that’s how the industry talks when backed into a corner.
If you take one thing away from this article, it will be that you will have a far better fundamental understanding of the premise of your premises.
The title of this article is actually a playful take on the often misuse of the word “premise,” which means the basis of an argument or theory or undertaking, and the word “premises,” which effectively means a location, site, etc. As an educational undertaking, using these terms interchangeably is not only incorrect, it also drives home the argument that the use of Cloud technology, whether local, hybrid, or public can vary drastically according to your circumstances.
Clouds within Clouds within hybrids within local sites… Where is the right fit? Where does it work out wrong? What can I do when, where, and why? Here we are in 2015, where the words “Cloud first” are starting to escape the lips of CxOs. But not everyone is ready to move ALL of their applications to the Cloud. However, if you were to start dipping your toe into the cloudy waters of the industry, where do people start first?
Think back to the beginning days of VMware® and virtualization adoption. People often started in “Test Dev” or with “applications that we don’t care if they go down” is how people would phrase that. That is actually where more and more applications are starting to find their way into the Clouds.
Here are some of the areas people are finding good bang-for-their-buck packages as they adopt Cloud technologies:
- Email Platform in the Cloud: Office 365®, Google® Gmail™, Lots of other emails!
- Application/development, with platforms like Azure™, Google, and AWS®.
- Platform as a Service, with players like Cloud Foundry®, Pivotal®, and SalesForce™.
- Disaster Recovery as a Service, with vCloud® Air™, Azure, and Rackspace™ as destinations.
- Backup to the Cloud, with direct writes to Amazon’s S3 or Cloud backup providers like Datto®.
There are a lot of other areas where people are starting their initial forays into leveraging Cloud services, and there are no ‘right’ or ‘wrong’ answers. However, there are some factors to take into consideration when adopting any Cloud service or service provider. It all comes down to how and why you are using it, and how much it is going to cost you if you were to keep it on-premises or if you were to move it off-premises to a Cloud.
- How much does it cost to run our applications in the Cloud?
- How much does it cost to back up and restore our applications in the Cloud?
- How long will our application live out there?
- What are our bandwidth and data storage requirements?
- What are our CPU and memory cycle requirements?
And for those who are bound by regulatory constraints where contracts are written:
- Do we have any regulatory requirements?
- Do we have any security requirements?
- Do we have any data retention requirements?
- Do we have country-to-country boundary requirements for that data?
- Do we have to deal with the Right to Audit?
- Do we have any contractual requirements written with our customers?
As you start peeling back the layers of your infrastructure, applications, and business onion you may find that certain applications are a no-brainer and should absolutely be used to leverage within a Cloud-service, while other applications should absolutely never leave your premises and stay locked up. Sometimes this choice is security-awareness related. However, more often than not, it is driven by economies of scale that some applications or functions will never be able to be made cheap enough being driven by depreciation schedules within the business.
Not all Clouds are created equal, but every business can find some part of their applications that can truly benefit from the premise of running those services off-premises.
This blog post was previously published on the SolarWinds IT Resource community.