Anton Jacobsz l Tuesday, December 05, 2017
JOHANNESBURG, South Africa – Not every application belongs in the public cloud. “You may ask astounded: “Say What?’ Especially as most of what we hear today is about moving all your business into the cloud,” says Anton Jacobsz, managing director at value-added distributor, Networks Unlimited.
Performance, costs and the ability to build a quick and efficient foundation in the cloud are important consideration for every organisation, but why is it that not every application is suitable for the cloud?
Jacobsz refers to vendor partner Tintri’s white paper with the straightforward title, “Does my application belong in public cloud?” to answer this question. The paper says, “There are the obvious reasons like security and compliance requirements in certain industries. But there are also other less obvious considerations that are best identified upfront.”
These “less obvious considerations” are: rewrites, resource utilisation and data gravity. The white paper elaborates on rewrites, stating, “Many enterprise applications were not designed with public cloud in mind—before they can be migrated they must be recoded, retested and refactored. That can add significant time and cost to a migration effort.”
It points out that resource utilisation refers to applications, such as relational databases, that assume the close proximity of compute, network, and storage resources to deliver the latency and performance required. “If those applications are shifted to public cloud, resources like network bandwidth may become a bottleneck and certainly aren’t ‘free’ as they are on-premises. The result can be surprisingly high bills or, worse, outages that you have no control over.”
Lastly, data gravity, in a nutshell, concerns the moving of data and applications to the public cloud, which creates a centre of gravity that can result in lock-in, making it harder to reclaim those applications later on.
“Applications also come with varying characteristics. These too need to be examined before a decision is made to move them into the public cloud,” points out Jacobsz.
The two general types of applications are: traditional enterprise apps (including relational databases like SQL Server and Oracle, and the many other legacy applications that your business still relies on, whether commercial or developed in-house); and cloud-native apps (including web, mobile, and other applications that were designed from the ground up to run in the cloud.)
The white paper illustrates what this means for cloud planning, stating: “Enterprise applications require careful consideration before moving to cloud, since these applications often benefit from the greater control that on-premises infrastructure provides. If you simply ‘lift and shift’ these apps into the cloud, you may not be entirely happy with the results. It’s worth understanding why this is the case (and why it may not always be a fair assumption).”
The jargon “lift and shift” is described in the paper as the process of moving an enterprise application with minimal change to the cloud. “Ideally,” continues the paper, “you’d just move an application with no changes, but that is seldom, if ever, possible. At a minimum, you’ll need to implement new data protection and DR methods. In many cases, you’ll have to do some coding, and you may have to refactor the application to run on cloud infrastructure. You’ll certainly have to retest everything to make sure it continues to meet SLAs.
“Even after you accomplish this, most enterprise applications end up being expensive to run in the cloud. The problem is that they aren’t elastic. An application that needs four VMs and 2TB of storage may hold those resources 24 x 7 x 365 whether it’s busy or not. Multiply that by 10s or 100s of applications, and the costs add up quickly.”
“With cost being a major factor in almost every business, you do not want to get a nasty surprise when you receive an astronomical invoice for moving a traditional app into the cloud when it could have remained cost-free and productive on-premises. The point is,” concludes Jacobsz, “that you should first establish how important it is to rewrite your app for the cloud. If your case is not convincing enough, it is more advantageous for your business to keep it grounded.”
