Ahead of the Cloud

Considering the cloud? It helps to "know before you go".

Migrating to the cloud is inevitable-at some point. The benefits it offers are real and compelling, the economics will get more favorable, and the cost to keep up with cloud-powered competitors will become unsustainable.

However, the industry is still not there yet.

That being said, this is the right time to be thinking about cloud services, and to be testing the cloud to determine when it makes sense for your company. A full commitment to the cloud - especially a single vendor - at this point puts a lot of faith in the major cloud providers without guarantees that they'll meet your needs.

With that in mind, here are the key areas I'd look at if I was considering a move to the cloud.

1: Portability

Making the transition to depend on a new infrastructure carries innate risk, but under the right circumstances it is worthwhile, and it is sometimes necessary for survival. One way to mitigate that risk is to make your components extremely portable: If you can create a VM image for your mission-critical service that can be run in your own data center, on AWS, and on Azure, then you are in a great position:

• You can experiment with all three environments without having to maintain code or build forks, and perform apples-to-apples comparisons to determine which environment delivers the best customer experience.

• You are free to pack up and leave any of the environments if it no longer provides the features you need at a price you're willing to pay.

The more vendor-specific features you use, the more difficult switching will be. Your Windows VM should work equally well on Azure as it will on-prem, but the Java or JS code you wrote for AWS Lambda will be useless on any other platform. This "lock-in" benefits the cloud vendor, but increases the risk of project failure for you.

2: Developer Productivity

Up to a point, the PaaS cloud outshines other models in convenience and developer productivity. Consider the case of a developer who needs a niche service for a one-off job, or some code to glue together two other systems, or any of a dozen other small tasks. In the past, the cost of deploying such a small component would outweigh the time spent developing that component. In the past, this would lead to some unpleasant outcomes:

• Shadow IT - a small but mission-critical service running off a box under a dev's desk

• Functionality riders - bolting unrelated components into existing services to piggyback on the larger service's deployment. Over time the dependencies and complexity from all the riders can slow down and complicate deployments for the truly important components.

• Increased dev costs - dev teams would have to add time to their estimates to account for sorting out the deployment with the ops team. For workloads where a rewrite is not a big deal (and performance is not essential), PaaS is an absolute dream. There's a reason many PaaS demos center around a single dev's work being deployed and running in minutes - that was impossible for many years, and is a legitimate boon to dev productivity.

Problems arise when the developer's needs outgrow the environment. In on-prem environments, this typically only happens when running out of hardware, and therefore requires scaling up (bigger boxes) or scaling out (more boxes), with the associated buying cycle and deployment delay. In cloud, there are more ways for the developer to hit the limits of the environment. IaaS and PaaS each impose limitations beyond those of the underlying machines (with PaaS being more restrictive than IaaS). For a CIO/CTO, any major cloud move is a bet of several hundred thousand dollars that the devs will encounter no such insurmountable obstacles. Those bets can be hedged by ensuring portability, as outlined in section 1 above.

This issue of needs outgrowing the environment leads to the third consideration:

3: Control

Beyond control of the underlying hardware or OS, "control" here refers to stewardship of the platform by the provider. For on-prem, the provider is the ops team, and thus the CIO has full control over the ops team. For IaaS, the cloud vendor is in full control and is generally not beholden to the CIO, but the expectations of IaaS are fairly well-understood, are standard across cloud vendors, and are unlikely to change over time.

PaaS is the riskiest option from a control perspective. In addition to handing the most control to an external organization, PaaS tools and philosophies are often under active development by the cloud vendor. This increases the need for regression testing within your own organization, unless you're comfortable having mission critical services down for 12 hours because of a bug that is completely out of your control.

4: Performance

Many have observed a decrease in performance and an increase in performance variability when using cloud vs. an on-prem deployment. This can sometimes be tolerated - the jobs described in item 2 above are great examples of cases where performance variability is wholly acceptable - but Nielsen and others have written at length about the damaging impact of load times on customer conversions.

Conclusion

Were I in an IT department with workloads that could be moved to cloud right now, here's a rough sketch of how I'd approach the project.

1. Begin running some pilot programs in your cloud of choice, to get a sense for their performance and ease-of-use. It may be that one is easier than the other for the company. Services that don't talk directly to customers are great for this because they can be indirectly monitored by other components in the organization.

2. Create a base image that can be consistently deployed across the on-prem data center and at least the cloud provider of choice, if not both cloud providers. This needs to be approved by both the dev team and the ops team.

3. Start writing more important services on the base image, having the dev team adhere to cloud ideals of largely-stateless, easily-replaced individual VM instances. This is often called "cattle, not pets" and will make it easier to scale deployments both on-prem and in cloud.

4. Perf-test and stability-test the cloud provider(s) with shadowed traffic from the on-prem data center. As the code running in each environment is the same, it should be straightforward to compare the results.

5. Begin diverting a portion of production traffic to cloud, while performing ongoing testing. This is an area where monitoring will be absolutely critical, especially if the cloud provider is talking directly to customers.

6. Very gradually, begin to scale down the on-prem deployment in favor of a solution that straddles Azure and AWS. Both promise high availability, and the odds that both are down at once are vanishingly small. Some services may remain on-prem for a while (stateful services that need to coordinate across the cloud environments, for example), but the company's in-house data center complexity should be substantially reduced.

Of course, ExtraHop has visibility for IaaS today. With a comprehensive view of everything in your environment, we help you assess which portions of your network to shift while delivering the control to mitigate risk and ensure a seamless migration.