Start your cloud journey in the right direction

As you move part of your organization’s operations into the cloud, make sure you pick the right part. That’s a lesson plenty of other fields have learned, and it’s a good one for information technology (IT). The best investors, for example, not only pick individual stocks wisely, but they also are expert at allocating their efforts among different sectors.

How does that apply in migration to the cloud? With the burgeoning market of cloud-denominated offerings, there are apparent opportunities to move nearly every part of IT to a cloud basis. They’re not equally good choices, though, as Stephen J. Bigelow’s “Storage and PaaS shine in cloud computing adoption spotlight” illustrates.

In reading this study, keep in mind that the data come from surveys, and are subject to the inaccuracies common with self-reports. Storage is a great place to start, not only for the reasons the article explains, but also for its business status: for nearly all of us, storage is only a commodity, one where technology can add little incremental value. We want bytes to persist, and to be able to reach them with predictable latency. Not only is that formula simple enough, but the costs for storage have been a glaring budget item for decades, and dealing with vendors has been relatively complex throughout that time. While I’m less sanguine than some of the respondents about price advantages the cloud provides, migration of a reductive resource in use by every IT department is a natural. This applies whatever combination of public and private cloud a particular organization chooses.

It makes sense that “nearline storage” lags in reported adoption, because that’s the area where network frailties are likeliest to cause problems. “Backup” and “collaboration/file sharing” are equally predictable as the leaders, for the opposite reason: those are storage types where latencies and short-term outages are easiest to accommodate. The article aptly call these “… [d]ata that changes frequently but is accessed infrequently …”

In organizational terms, then, cloud services look like this: if you start with collaboration or backup, your migration will be one that:

  • decision-makers understand;
  • the cloud handles well; and
  • has a budget impact that is easy to explain in terms of a straightforward shift from capital to operations.

At the same time, collaboration and backup differ in plenty of more localized ways, such as impact on training. The most dramatic has to do with validation: if there’s a problem with collaborative services, DevOps will hear quickly; with backups, in contrast, an appalling portion of organizations report they’ve never tested, let alone have good procedures in place to ensure backup services remain healthy.

The rest of the article, which covers SaaS and PaaS (Software- and Platform-as-a-Service) prospects, is also worth reading. As you study the different descriptions, keep in mind which ones can become winners for your particular situation. I’m particularly struck, for instance, by the report that “… more than 34% of respondents say SaaS applications can cause integration challenges with other cloud-based or on-premises apps. This echoes the concerns of application suitability and integration found in public cloud adoption.” The solution for this is clear, at least in principle: research application programming interfaces (APIs) beforehand, and make them part of your decision process. Cloud providers have improved their APIs a great deal in just the last few years, and good SaaS should have API as a competitive advantage when compared to many traditional, in-house alternatives.

Cloud adoption doesn’t automatically create success. Good planning of cloud adoption has the potential, though, to be one of the better investments you can make. Choose a path that’s likely to make you a winner.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>