It’s clear that the cloud is the future of business for many organizations, but it’s not always clear how to get there. Many companies have existing investment in infrastructure and applications in their own data centers and colocation facilities (“edge computing”), and they want to know what strategies exist for using the cloud and what the trade-offs are.
There are many options on how to use the cloud, including:
- Partial cloud migrations or “hybrid cloud”
- Using cloud for on-demand capacity or “cloud bursting”
- Migrating to Software as a Service (SaaS)
- Using multiple public cloud providers or “multicloud”
We won’t focus on every possible option here; however, you should be aware that varied approaches exist and explore all options as you research the right solution for you.
In this article, we look at two different ways to take advantage of the cloud: performing a “cloud migration,” or rebuilding to have your technology be “cloud native” (sometimes called re-platforming). By the end of this article, you’ll understand the pros and cons of each of these two approaches, and when you should perform one over the other.
Cloud Migration
A cloud migration is a common approach for getting your existing infrastructure and services into a cloud provider. It involves as few changes to the existing systems as possible by re-creating the same resources, architecture, and services in the cloud provider.
Even within cloud migration there are different ways to solve the problem. As with any big infrastructure change, there will be some things that don’t map one to one—commonly, things like security, access management, and network topologies.
The minimal-impact cloud migration usually involves converting machine or virtual machine (VM) images from on-premises data centers into the cloud provider’s environment. Some cloud providers offer tools to do this for you (such as Amazon Web Services [AWS] Connector for vCenter), but others require manual export of VM images and importing those images into a cloud provider.
Other options might include migrating VMs but using a cloud provider’s service for things like database management or storage. In this situation, instead of migrating all of the infrastructure necessary to run your own DNS servers, you can use AWS’s Route53 or Google Cloud Platform’s Cloud DNS and move your DNS records into their hosted services.
There are still other ways in which you can move your current investments into the cloud. Rather than move entire VMs, it might make more sense to create duplicate infrastructure in AWS that looks like your current infrastructure and redeploy your applications to that infrastructure. Often, you can do this with automated tools such as Jenkins or Chef. This method will still move the service workloads you care about but maybe not all of the underlying infrastructure you are currently running.
Benefits of a Cloud Migration
In all of these scenarios the main motivation for the migration method is time. Cloud migrations are the fastest way to get your services in the cloud. They involve the least amount of staff retraining because the applications and architectures should be familiar. The main thing that changes is the interfaces for infrastructure management. Assuming that you have automation for your application deployments, the application engineers might not even realize anything changed with how or where the application runs. That’s a good thing.
Because a migration requires so little personnel training and almost no redesigning, it can save a lot of time in the migration process. Saving time in getting to the cloud can save a lot of money. Not wasting months or years planning your migration and instead cloning VM images is likely to be less disruptive than setting up brand-new machines and redeploying the applications.
The immediate money savings is a huge benefit for the business and probably for customers. Not only can the quarterly report show that you are now using the cloud, but it can show that you didn’t spend a lot of time moving there. This should be a win-win situation.
Drawbacks of Cloud Migrations
But the reality is that if you move all of your applications and infrastructure to a cloud provider, you haven’t solved any problems. You’ve likely only created new problems for yourself. The cloud doesn’t work the same way as your data center does. Just because cloud providers offer VMs and hosted services doesn’t mean you should treat them the same as buying a physical server and carefully nurturing that system for years to get the best return on investment (ROI).
Can you still manually create a VM and keep it nurtured and running just the way you want? Probably. I would imagine a good number of VMs running in cloud providers are run this way. But it will cost you. Your upfront costs to get into the cloud will be minimal, but your ongoing monthly costs will be the most expensive they could possibly be.
When running your own hardware and VM infrastructure, the cost per VM for computing, storage, and network was likely hidden behind complex licensing terms rated per server socket or similar esoteric pricing scheme. The VMs don’t appear to cost very much on their own because it’s difficult to figure out the usage costs for your backend storage and network utilization. Being able to run a single VM was hidden and fairly insignificant, so moving the VM should also be insignificant.
However, in a cloud environment, you will be charged for every reserved CPU core that is not utilized, and for every gigabyte of hard drive space that you thought you were using and aren’t. On a single VM, these costs could easily double your spending per month. Even though the cloud vendors often promise to be cheaper, it all depends on how you use their services, so make sure that you’re not provisioning resources you don’t need.
Cloud Native
On the opposite end of the spectrum from a cloud migration is cloud native. These are applications and infrastructure designed to run specifically in a cloud environment. In essence, they consume cloud services for as long as they are able. If the cloud provides a hosted version of MySQL, a cloud-native application will use it so long as it is technically able to.
Replatforming your current investments in technology involves taking a hard look at all of your infrastructure and applications to understand how they work now and how they would work best when running in a cloud environment. After you have done this, you can invest the time to create compatible systems in the cloud provider to provide the same functionality.
For example, if you have an application that uses Memcached, a Node.js application, and MySQL, you might want to create an architecture in AWS that uses Elasticache, Lambda, and RDS instead. These services no longer require that you run any VMs but still allow you to have the same functionality. By using the hosted services, your ongoing monthly costs will be significantly lower and depend on consumed resources instead of provisioned infrastructure.
Often, the hosted version of a product is limited in features or not able to meet the requirements of an application for one reason or another. In a cloud-native approach you can still use VM instances to host your own services, but you should use declarative APIs to automate the creation of the VMs and take advantage of immutable infrastructure patterns. This means that you would never create a VM and then modify it in place. Instead, you would use an automated deployment tool to create a new VM image with the changes you want and then delete the existing VM(s) to re-create them with your new image. This pattern of managing infrastructure is proven to work much better in a cloud environment and at massive scale. Managing declarative state is the cloud-native approach to infrastructure.
Benefits of Being Cloud Native
One of the biggest benefits of managing your infrastructure and applications this way is that you can take advantage of the many hours the cloud provider invests into their infrastructure and build on top of it just what you need. By making your applications and infrastructure cloud native it means that you can spend less time on managing the underlying infrastructure and more time on the business logic that is important for your success. This can enable faster time to market, greater ability to experiment, and making it easier to scale.
For example, the cloud is great at dynamically scaling VMs in autoscaling groups. Thus, when load on a service begins to rise too much, the cloud provider will automatically create more VMs and put them behind a load balancer. It is the traditional “scale out” approach to gaining resources that can happen automatically. If you performed a cloud migration and are not able to automatically clone a VM image to balance load, you are not taking advantage of one of the most fundamental benefits of running in the public cloud. If your service needs more resources, you’ll need to take the “scale up” approach and pay for a bigger VM or to scale out by having people manually create more systems to put behind a load balancer. Both of these scenarios will cost you more money to run your applications in the cloud.
Making your infrastructure and services cloud native will also give you the most optimized monthly bill possible. You’ll still pay for what you use, but it will be less expensive than cloning VMs. One of the less-obvious benefits is the amount of person-hours you’ll save over time by protecting your engineers from focusing on manually provisioning and maintaining as much infrastructure and instead enabling them to adopt new cloud services when they are available.
Drawbacks of Being Cloud Native
One of the biggest drawbacks to replatforming your current applications is the amount of time it takes. Not only do you need to understand your current technologies enough to re-create them, but you also need to take the time to do so. For companies that have a lot of existing investments in on-premises infrastructure and services, it can take months or years to complete a full replatforming.
To know how services should change, you’ll need to understand how the cloud environment works and which services you want to consume from the provider directly. You can begin with articles and books such as Migrating to Cloud-Native Application Architectures (O’Reilly, 2015) and Cloud Native Infrastructure (O’Reilly, 2017).
However, at some point you’re going to need more specific advice about your applications and your chosen cloud environment. Cloud providers have customer success groups to help you understand their platforms. I recommend reaching out to the provider or one of their consulting partners because every environment is unique and it’s beneficial to have experienced help.
Hiring outside help can accelerate your switch to becoming cloud native and will help you avoid costly mistakes through understanding the trade-offs and limitations of hosted services. Without previous experience, you likely will not know all of the services you’re able to consume or which you’ll need to run on your own until you have found limitations. By then it might be too late, and you’ll likely have an outage or need to do emergency work to migrate the application.
Other Considerations
There’s more than just technology to consider when deciding whether to perform a cloud migration or rebuild systems to be cloud native. Here, we discuss some of the nontechnical considerations when moving to the cloud: people, processes, and costs.
People
The most important of these is your engineers. The people that run the applications and infrastructure are an investment you make in your business. If they are not trained or don’t understand how the cloud is designed to work, they will likely create a system that looks identical to what you are currently running in your data center. This is not their fault, but you do need to factor in their experience, the communicated desired goal, the processes that exist for them to do their jobs, and the organizational structure when choosing your path forward.
Running applications is similar to riding a bike. Engineers will get used to how things are done and get a good feel for when something isn’t right. Seasoned engineers will intuitively know when a problem exists in slow storage or slow network connections. It’s something you learn the more you work with the technology.
Asking engineers who have run applications only in a data center to transition to the cloud is like giving them a bicycle with reversed handlebars—the technology is familiar, but how they drive is foreign. If you perform a cloud migration, you can help ease the transition by changing a little as possible, but your engineers will need to relearn how to successfully ride a bike. The best way to do that is to try to unlearn the existing habits and understand the benefits and strengths of the new environment.
Investing time to train your engineers on how they can be successful in the cloud will have a slower start but a much better result in the long run. No matter what, you should expect some failures. Everyone has to fall when learning to ride a bike. Don’t be put off by failures; take full advantage of learning from what happened and how you can do it better in the future.
Processes
While you train your people, you also need to have a hard look at the processes in place for engineers to do their jobs. What is the current process for an engineer to request resources such as computing, storage, and network? How is code deployed into production? Are there standard tests, monitoring, and logging? How are security updates applied and tested?
Even though you might not have answers for all of these, it’s important to think about how the tasks would be different in an on-premises data center compared to in the cloud. You might find that there are some processes you should keep but some do not apply when infrastructure can be created with a single cURL command. For example, a two-week process for procurement and PO approvals to buy a server don’t apply in the cloud, and it’s important you recognize that and adjust your policies and processes accordingly.
You should put processes in place that enable engineers to perform their jobs with minimal overhead, and encourage the highest rate of change that is acceptable for your environment and level of risk.
Unexpected Costs
Speaking of managing cost, make sure that you come to terms with surprises on your bill and give up on capacity planning. The massive resources and pricing model of the cloud do not cooperate with traditional capacity planning practices. The constraints of your data center might have stifled your existing technology capacity more than you assumed. When capacity is seemingly limitless and the time it takes to create new infrastructure and services is reduced, don’t be surprised if your business’s thirst for innovation exceeds previous expectations. You’ll need to ensure that you have processes in place to audit what’s running. Don’t expect your cloud bill to break this down for you, but you should provide freedom for engineers to experiment. Let them push boundaries and understand their new environment. Give them time and a safe place to fail so they can learn and become better.
Conclusion
Whether you choose to move your existing infrastructure or replatform to be cloud native, it’s important to understand how the cloud is different from your traditional data center. Although many of the technologies and terms are the same, working in the cloud requires a different approach, cost model, and infrastructure management than building a new data center. Make sure your processes change when you move to the cloud, too. Otherwise, you’ll end up with management overhead that no longer applies to how work is performed. Most important, invest in your people. Having people who understand the benefits and trade-offs of the cloud and having processes that are optimized for its strengths are the real signs of success, no matter how you get to the cloud.
