Clouds' crazy kinks can spin your wheels and lead you to mistakes

You're probably cocking up the cloud, but clouds themselves are part of the reason why.

So says Kyle Hilgendorf, chief of research at Gartner for Technology Professionals, the branch of the analyst firm that talks to Reg-reading types instead of suits. Hilgendorf delivered a session titled “Top AWS and Azure IaaS mistakes you'll want to avoid” at this week's IT Infrastructure, Operations & Data Centre Summit. It was comfortably the best-attended session I witnessed outside of the keynotes and offered eleven mistakes that Hilgendorf sees his clients making.

His starting point is that some mistakes are acceptable, because the big clouds don't explain everything about their offerings. He therefore recommends Googling “[NameOfCloudService] limitations” as useful research before evaporating workloads, because there are lots of little limitations to cloud services that vendors hardly shout from the rooftops.

But plenty of you are also messing things up by yourselves. For example, the analyst's first beef was virtual networks, which he said users are whipping up anew for almost every workload they put in the cloud. The result is sprawl, inconsistency and messes when workloads on their own virtual networks can't talk because of configuration clashes. He therefore recommended standardising on some basic virtual network designs and making sure they're re-used whenever possible.

Wide area networks are also a problem, because many users build multiple peer-to-peer links from branch offices to headquarters and/or from branch offices to multiple clouds. Doing so means organisations end up with multiple leased lines and a messy network. He instead counselled connecting all offices to a cloud exchange, over one link, and letting the cloud exchange handle links to clouds. Users are also ignoring the fact that AWS Direct Connect and Azure ExpressRoute can be partitioned into multiple virtual interfaces. Doing so means they're ignoring the chance to specify different security policies for different connections and eschewing the opportunity to tie the costs of one virtual link to a particular app and therefore to charge business units for their own cloud consumption.

Another mistake Hilgendorf pointed out is an oldie and a baddie: server sprawl. The analyst said that organisations aren't tracking their fleets of cloud VMs, aren't scaling them down when they're over-powered and underutilised and are therefore wasting money. To make matters worse, Azure and AWS monitor instances and warn when they're not being used efficiently, but users ignore those warnings. He therefore recommends hiring a person or acquiring software to monitor your cloudy VM fleet to optimise it for the power and capacity you really need.

AWS and Azure even advise you about this stuff, he said, with weekly emails that are bizarrely often ignored. Hilgendorf 's advice was to pay attention, because the big clouds have come to realise that the better their advice the more likely you are to stick around. Those emails can even warn of things like unexpected use of previously-dormant network ports. Pay attention, people!

We're up to number six now, namely the fact that AWS doesn't do automatic DNS autoregistration and Azure DNS does not yet support private DNS zones. Organisations accustomed to having those services on tap will need to adjust their expectations when they head for the clouds.

Another service many will take for granted is Windows authentication, which doesn't apply to some cloud services. Instead, you may find a move to the cloud requires multiple overlapping authentication tools. For example, an on-premises Active Directory domain controller can't integrate with Amazon RDS or Azure SQL. Prepare for complexity!

Load balancing may also cause problems, because AWS Elastic Load Balancing can't be assigned a dedicated IP address. Azure's Load Balancer can, but Azure Traffic Manager can't. This can become a problem if either cloud decides to hand a load balancer a new IP address, workloads that look for the load balancer can't find it and things get messy not long afterwards.

Trusting clouds' native file transfer tools is also not advisable, as Hilgendorf said they're not particularly resilient. You'll need to wrap your heads around chunking files and multiple parallel uploads or downloads to get data moving into and out of the cloud at satisfying speed. If you don't make the effort, expect repeated frustration as small networking glitches disrupt file transfers. Hilgendorf's ninth point was to skill up for uploads, his tenth was the same advice for downloads.

His last point was backup, because cloud users are too trusting that clouds just save everything always. Failing to plan a proper backup regime is as dangerous in the cloud as it is anywhere else, he said. So just do it! ®