Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Cloud Platforms vs. On-Prem: A Guide for the Rest of Us

DZone's Guide to

Cloud Platforms vs. On-Prem: A Guide for the Rest of Us

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

[This article was written by Tom Smit.]

cloud-platforms-vs-on-premise

Working for Cloud based businesses for the greater part of a decade now, one question invariably comes up:

“Why should I move my data to the cloud?”

There are always a few objections that come up as well. Following-up on a previous blog post where we discussed the business benefits of cloud computing, this will be a discussion on the most common objections and how to have a conversation around cloud and on-premise environments.

Dilbert

Objections to a Cloud Based Platform

Below are some of the common objections we’ve heard during calls and communications with customers. It’s by no means an extensive list and we welcome feedback or ideas on things to add.

Security

Without a doubt, the number one objection to deploying a cloud service over the years has been security.

On-premise applications and platforms have historically been more controllable and therefore perceived more secure.

Are they?

In actuality, security of both on-prem and cloud based infrastructures are as equally strong (or weak).

Increasingly, SaaS based companies have started to include publicly available security information online. As more and more enterprises and small businesses move to the cloud for delivery of business critical applications, security of applications and customer data is at the forefront of SaaS based companies’ minds.

The question always asked:

“If I don’t have physical access to the data or the machines I’m using, how could they possibly be secure?”

We’ve all heard the statistic that 66% of all security breaches occur from within the company – and typically that has been against on-premise solutions.  With the advent of entire platforms such as Amazon Web Services and Microsoft Azure to service cloud based applications, security has become a top priority – and allows enterprises and small businesses alike to deploy in a known secured environment with little to-no worry about deploying security measures on their own.

There are no longer needs to invest in expensive intrusion detection systems, vulnerability scanners, or other security applications. Now all security measures are put into place by the platform provider – and this allows business to focus on securing their application rather than the infrastructure.

Integration Points

A large amount of legacy products that are now being replaced by cloud platforms have tie-ins to other legacy products.

How many on-prem mail systems are tied into accounting systems? Or payroll systems tied into an active directory system? The objection here is one of productivity.

“How can I be expected to be as productive as I was yesterday with a whole new set of tools?”

With the ability of new cloud applications to open up their API and other integration points, this is becoming less of an issue as we progress through the cloud era. The problem arises when older legacy apps try to integrate with newer “cloud” applications. If you remember last week’s blog post about the business benefits of cloud computing, one of the capabilities of a true cloud platform is a controlled interface. This allows for an open, but controlled, access mechanism – such as an API.

Older applications are being re-written to integrate with cloud based applications – to make these partnerships quicker and easier. Newer cloud based applications have integrations with each other (e.g., Salesforce and Gmail, Zendesk and Jira). As larger enterprise companies retire legacy systems, this objection starts to become less of an issue.

Benefits of a Cloud Based Platform

While objections are often easy to dismiss with strong discussions – having benefits to couple with objection handling allows for a greater knowledge of the on-prem vs cloud discussion. Looking back at last week’s blog article on the benefits of cloud computing, we can already add rapid elasticity, ubiquitous access, and constant addressability to the list of benefits. However there are a few more worth discussing below.

Cost

A huge benefit of moving to a cloud based platform is not only low cost and affordability, but one predictable cost per user, no matter what.

As a Google Apps user, a company knows that anytime a new employee starts, there is a fixed cost for that users email access. Compare this to the antiquated on-prem mail systems of yesterday, Exchange and Notes. Not only did administrators have to increase disk capacity over time (no one I’ve ever met receives LESS email day-to-day), but included in increased usage was backup, bandwidth, administrator, etc.

One thing does jump out in the above paragraph. Bandwidth.

Bandwidth costs do increase with more cloud-based platforms being utilized.

But it’s all relative. Yes, my users are using more bandwidth by going to Google to get their mail – but at the end of the day, I didn’t need to download all the SPAM and annoying emails to my internal network just to have users delete it. Whether you’re a creator or a consumer – bandwidth costs are going to remain the same as you’ll shave inbound usage by using cloud based applications, but increase outbound consumption for the exact same reason.

One other aspect of cost that often gets overlooked is the cost of the full-time-employee (FTE) whose part to full time job it is to support and administer the on-premise application. I’ve talked to some companies who have 2 – 3 DevOps guys on staff just to run their on-premise log management solution. It never started out that way – these guys always have 14 other things that they’re responsible for. But as time went on and complexity of solutions grew, the management of the systems and platforms became more and more of a burden on the staff.

Implementation

Speaking of administration and management – I can setup a new Logentries account and have log data flowing to that account in under 30 minutes (here’s a quick start guide for those who haven’t done it yet!). Meanwhile I’ve talked to customers and prospects alike who have tried to roll their own ELK deployment, only to stop after 30-45 days of trying to get it up and running. Trevor Parsons, one of our Co-Founders, detailed the pros and cons of open source logging in an excellent blog post that I implore everyone to read.

If you take an average FTE at 100k a year (this is salary, benefits, etc.) – if that FTE spends just 4 hours a week working on management and administration of their environment, thats @10k dollars a year spent on just plain maintenance and management (check my math: 100k/52/40 = 48 dollars per hour – 48*4*52 = 9984).

Now, factor in the implementation time, integration work into other systems, and cost of deployment (Trevor’s blog covers this nicely, mentioning some ELK deployments costing 4k a month in Amazon). You’re now looking at 10k management a year, 48k cost of running it, and 2k to deploy it (average 40 hours at 48 dollars an employee). That’s 60k a year to deploy and run your own ELK environment.

IT Needs

Lastly, and quite possibly most importantly, is when you deploy a cloud solution, IT Expertise is no longer necessary to have on staff.

At Logentries, we use a cloud based email system, cloud based ERP, cloud based support, and cloud based phone system. We also don’t have an IT person on staff – this role is filled partly by myself and one of the DevOps guys. The point of all this is – with a cloud based platform, there’s no longer a need to have 15 email administrators, a database admin for the payroll and ERP system, a networking guru in place for phone and network drops. It all just disappears and becomes a very easy plug and play system.

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:

Published at DZone with permission of Trevor Parsons, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}