7 ways South African enterprise cloud projects fail

7 ways South African enterprise cloud projects fail
Thomas Lee, CEO of Wingu.

7 ways South African enterprise cloud projects fail
Thomas Lee, CEO of Wingu.

South African organisations are really beginning to board the cloud train but they’re running into a number of issues and it’s causing them frustration, costing them time, and resulting in undue expense. Being aware of seven of the most common issues can help them quickly and cost-effectively develop the right cloud solutions for their business needs and let their human resources focus on the business issues that will make them more competitive.

1. Any workload will run in the cloud

One of the biggest mistakes we see is customers think any workload run in the enterprise today will run in the cloud. We see that they try to move everything to the cloud without conducting feasibility checks to ensure the applications will work. We’ve seen issues with financial systems, monolithic applications, input/output heavy database systems and more. In 95% of cases applications have to be rebuilt for the cloud environment. The data is portable but the applications are not. There is no automagic way of simply porting a system to public cloud platforms. What companies need is a process to check and ensure that applications will port into cloud environments, which may include checking vendor documentation, operate test sites running copies of operational data, mapping application architectures and so on.

2. Implications of shared resources

We also see often that customers sometimes don’t grasp the implications of the fact that resources are shared in the cloud. There’s a common misconception that a virtual machine in the cloud will perform just like a physical piece of on-premise tin. Some cloud service providers advertise enormous systems, such as those with 512GB of RAM. But that doesn’t necessarily mean you can port your critical application straight into the cloud and expect to get all the benefits of cloud with the same performance as you squeezed out of your on-premise kit. The truth is that you’re using a shared resource, as opposed to dedicated server hardware. Sharing the infrastructure resource with other users and systems could have an impact on system performance.

3. Disk demands

Linked to shared resource performance is disk performance. Many organisations neglect to consider the impact of high disk usage where their data is stored. Operations that put big input-output (IO) loads on disks will suffer degraded performance when you move them to the cloud. Performance will degrade unless you specifically request high IO disks from the cloud service provider (presuming they can provide them) in which case you can expect to pay a lot more for the service. Shared systems offer no guarantees that you’ll get the kind of performance more demanding applications require so you’ll have to specify and incorporate the additional costs into your ROI calculations. In some instances you’ll discover that it’s more cost-effective to run certain operations on-premise but it’s a discussion worth engaging the cloud service provider on before you dive in. It’s one of the biggest complaints from customers in the industry because few cloud service providers make the consulting effort upfront to advise clients properly. Keep in mind that for high performance disks there may be a charge not only for the size of the storage, but also for the input/output operations per second and any service level agreed storage performance.

4. Calculating ROI

Calculating ROI properly is another area that can let customers down. Some cloud virtual machines (VM) can seem more expensive than on-premise, owned equipment written down over 36 months, but we’ve always found that to be the case when the true costs of running onsite equipment are incorrectly calculated. It’s important to consider the costs of electricity to power servers and data centre equipment such as power-hungry cooling, as well as administrator salaries, networking equipment, and more.

5. One provider for all

Another common point of failure is that many customers think they’ll appoint a cloud provider that will take care of all their needs. But that results in trying to hammer square pegs into round holes. Not all cloud service providers will meet your architectural requirements for all of your systems. They need to be fit-for-purpose so it’s important to select the provider based on precise needs. And, considering the requirement for interoperability, it’s important to architect the solutions holistically. The reality is that customers will use more than one cloud provider, placing workloads in fit-for-purpose platforms.

6. Cloud applications are automatically failure proof

Considering architecture, there’s a train of thought that applications and data in the cloud are automatically failure proof. If hardware fails under the VM you can expect some downtime while a copy or new definition gets moved to a new host system that is restarted and reconnected. For true resiliency you need applications built for web scale, with resiliency at the application, not infrastructure, layer. The common mistake is thinking that traditional enterprise applications built before cloud will somehow scale and be fault tolerant in cloud environments. That’s a big misconception. Things do fail in the cloud. That’s why organisations like Netflix, Facebook and others have thousands of servers in the cloud and you have a single interface into that served up by thousands of machines. You need to build resiliency into the application layer, which is something that often lets customers down. They neglect to consider the additional cost and resources of making systems cloud ready.

7. Cloud computing is enterprise virtualisation

Another major misconception is that many organisations believe that cloud computing is just like enterprise virtualisation. They are used to running VMWare or Hyper-V and they expect the cloud to operate the same way with the same functionality. But that is not how it works. And that’s why we internally distinguish between enterprise hosting and cloud provisioning. Cloud is a 24×7, self-service platform with infrastructure provided on demand and charged on a consumption basis. You can view financial data and make changes on the fly. Enterprise hosting is where you run traditional virtualisation technology, the same as you would in your own data centre, but on someone else’s infrastructure. We get a lot of requests for physical interconnects, redundancy, bandwidth, virtual LANs (VLAN) and so on, which is all traditional Internet service provider (ISP) stuff and distinct from cloud at a technical level. And that’s an issue that many enterprise architects don’t always grasp today that undermines rollouts. This is why a move to cloud requires fresh thinking and a new system architecture.

There are many nuanced issues associated with adopting cloud that have to be assessed on a per-enterprise basis. However, knowing to query these seven top issues upfront will get the ball rolling quickly so you can make informed decisions about what to place in the cloud, how to architect it, what benefits to expect, and how to maximise your budgets.

By Thomas Lee, CEO of Wingu