7 Reasons Cloud Adoption Fails

While cloud can lead to key benefits, make sure you avoid these costly mistakes.

According to Gartner, a company with a corporate ‘no-cloud’ policy in 2020 would be as rare as a company today operating without Internet. In a 2016 Study by IDG, they estimate that 70% of enterprises are running at least one application in the cloud today and that number is projected to reach 90% in the next 12 months. In other words, in a couple of years a company not in the cloud will be unfathomable.

While an efficiently deployed cloud environment can lead to agility and cost savings, for every benefit cloud can bring, a poorly deployed environment has a matching drawback. That’s why you need to proceed with caution when outlining your cloud strategy, and avoid these top seven reasons cloud environments fail:

1. Security Blindness

According to a 2015 Survey by Wikibon, security consistently tops the list of issues companies will face as they move to the cloud, and it needs to be built into the migration from the first step. As the workforce becomes more connected, organizations need to take every possible step to ensure their company data is protected. This means IT has both the training and the tools needed to fight security threats from day one. It is a shared security strategy in the cloud. The organization needs to understand what security they are responsible for and what the cloud vendor is responsible for. It should be noted that moving to the cloud usually brings a better overall security solution, as the entire model will be scrutinized during the transition.

2. Outdated Toolkit

For many IT professionals, the shift to the cloud means learning a new set of skills, which requires an investment in training and time across the board. First and foremost, IT professionals need to understand the business objectives and requirements to discuss the right cloud service to procure, deploy and manage. Now, more than ever, IT professionals will need to understand the cloud services available to them and how these services can benefit their organization.

3. Not considering all options

Choosing a major cloud player for your migration has its benefits, but many companies find themselves making decisions before they’ve had a chance to fully explore their cloud options. It is increasingly difficult to move between vendors once you’ve made your initial cloud choice. For this reason, you need to be extremely thorough when vetting cloud options, and you need to carefully consider how your environment will evolve in the coming years. This is especially important given the industry is trending towards the multi-cloud approach.

4. Internal miscommunication

Cloud decisions are increasingly being up-leveled to executive teams and the boardroom. This trend can cause gaps in communication between the decision makers and IT, thus resulting in operations procuring their own cloud resources as ‘Shadow IT’ budgets are increased. Many organizations struggle to help IT teams meet in the middle and communicate proactively about their cloud strategy. Executives need to create a clear line of communication where operations can bring their business goals to the table, and IT can assess the resources needed to realistically meet those goals with the entire organization in mind.

5. Migrating too quickly

Moving to the cloud needs to happen slowly, one area of the business at a time, so the entire team feels confident in the migration at each step of the way. Organizations should start the migration with your least critical business units, so the team can familiarize themselves with the deployment process before diving into the more high-stakes Enterprise Applications. Cloud migrations take time and need to be built to scale. Organizations that push their teams into the cloud too quickly will put their entire cloud infrastructure at risk.

6. Poor cost optimization

Many organizations struggle to navigate cloud pricing models, and according to Right Scale an estimated 25 to 45% of cloud spending is ultimately wasted. It’s very common for companies to under utilize their VMs, paying for instances that are no longer in use. This can cause the cost of cloud maintenance to skyrocket. Migrating to the cloud doesn’t have to break the bank, but if you’re not careful when laying out your cloud maintenance strategy, you will have a difficult time justifying your budget to the executive team.

7. Unwilling to adopt new technologies

New technology brings exciting opportunities for innovation. Right now, many IT departments are looking into the possibilities that automation, machine learning, software-defined data centers (SDDCs), etc. can bring their business. Companies that fail to take advantage of the full range of opportunities the cloud can bring will find themselves left behind in the next chapter of the cloud revolution.

At Smart Panda, we have been working with organizations since the days of mainframe computers. Technology is changing every day and the growth is crazy, as Amazon just posted a profit of $2.5 billion for the past quarter and it has posted positive gains for the past 14 straight quarters. This trend is not going to slow down. Organizations need a plan to migrate to the cloud, and the best way to get a plan is to get a trusted advisor that can work with your organization to build the best road map to the cloud and the future.

Moving to the cloud, doesn’t mean everything moves to the cloud, some times it makes sense to be on-premise, some times it makes sense to be in the cloud, some times neither option makes sense. Newer and better technologies are constantly becoming available, and integrating these new technologies may be the best direction for your organization.

Start planning today by contacting your new trusted Advisor at Smart Panda.

AWS Mount Data Disk

Smart Panda - AWSAWS Mount Data Disk (Linux)

Amazon Web Services allows you to create EBS (Elastic Block Storage) instances which can be mounted to your EC2 Server instances. This allows an administrator to be able to size the storage solution effectively. These instructions should work on most Linux Flavours.

Use the lsblk command to view your available disk devices and their mount points (if applicable) to help you determine the correct device name to use.

[root ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvdf 202:80 0 100G 0 disk
xvda1 202:1 0 8G 0 disk /

The output of lsblk removes the /dev prefix from full device paths. In this example, /dev/xvda1 is mounted as the root device (note the MOUNTPOINT is listed as /, the root of the Linux file system hierarchy), and /dev/xvdf is attached, but it has not been mounted yet.

Determine whether you need to create a file system on the volume. New volumes are raw block devices, and you need to create a file system on them before you can mount and use them. Volumes that have been restored from snapshots likely have a file system on them already; if you create a new file system on top of an existing file system, the operation overwrites your data. Use the file -s device command to list special information, such as file system type.

[root ~]$ file -s /dev/xvdf
/dev/xvdf: data

If the output of the previous command shows simply “data” for the device, then there is no file system on the device and you need to create one. If you run this command on a device that contains a file system, then your output will be different.

[root ~]$ file -s /dev/xvda1
/dev/xvda1: Linux rev 1.0 ext4 filesystem data, UUID=1xxxxxx-exxx-4xxx-axxx-8xxxxxxxxxxxx (needs journal recovery) (extents) (large files) (huge files)

Use the following command to create an ext4 file system on the volume. Substitute the device name (such as /dev/xvdf) for device_name.

NOTE: This step assumes that you’re mounting an empty volume. If you’re mounting a volume that already has data on it (for example, a volume that was restored from a snapshot), don’t use mkfs before mounting the volume. Otherwise, you’ll format the volume and delete the existing data.

[root ~]$ mkfs -t ext4 device_name

To create a mount point directory for the volume. The mount point is where the volume is located in the file system tree and where you read and write files to after you mount the volume. Substitute a location for mount_point, such as /data.

[root ~]$ mkdir mount_point

To mount the volume at the location you just created.

[root ~]$ mount device_name mount_point

(Optional) To mount this EBS volume on every system reboot, add an entry for the device to the /etc/fstab file.

Format: device_name mount_point file_system_type fs_mntops fs_freq fs_passno

The last three fields on this line are the file system mount options, the dump frequency of the file system, and the order of file system checks done at boot time. If you don’t know what these values should be, then use the values in the following example for them (defaults,nofail 0 2). For more information on /etc/fstab entries, see the fstab manual page (by entering man fstab on the command line). use the UUID from the file -s device_name for the device_name. So for this example the entry would be:

[root ~]$ file -s /dev/xvdf
/dev/xvdf: Linux rev 1.0 ext4 filesystem data, UUID=2xxxxxx-5xxx-3xxx-1xxx-exxxxxxxxxxxx (needs journal recovery) (extents) (large files) (huge files)

[root ~]$ vi /etc/fstab

UUID=2xxxxxx-5xxx-3xxx-1xxx-exxxxxxxxxxxx /data ext4 default,nofail 0 2