A Use Case for Cloud Migration: What to Expect

You may be considering migrating to a cloud infrastructure, but want to know what the process is actually like. Is it easy? What do you have to do? What applications is it suitable for?

In the first part of our two-article series , we’ll talk about a use case scenario for migrating to the cloud. We’ll also discuss the value of the 12 factor application methodology, how to approach a migration project, and what to expect during the process. Read part two here.

We’ll be going through:

• A Use Case Scenario

• 12 Factor Application Methodology

• The App’s Migration Journey

• How Long Does it take?

• Next Steps

• Takeaways

A Use Case Scenario

We’re going to examine a straightforward example. Say we have an application on a web server, and we want to move it to the cloud. Let’s say the reason behind this is that we currently only have a single web server. So if we have a failure, this could result in applications failing. Therefore, we want some redundancy. We also want some scalability for our traffic because we expect to grow. This is a fairly standard use case for migrating to the cloud.

In this scenario, we expect that in a year's time our traffic will be too high for the small server to handle. We definitely have to move. There are two possible solutions for this move. Option one: we can move to a bigger server and just postpone the issue. However, we still have to do a lot of work. Option two: we just directly move to a cloud setup. This would make it much easier to scale. In this use case, we’re going with option two. Here’s how we would go about it.

12 Factor Application Methodology

There are a couple of things to consider when migrating to the cloud. First of all, we have to check our application itself. How is it implemented? What are the architectural choices taken? Is there anything that would be an issue when horizontally scaling or duplicating resources in this application? To do this, you have to first figure out if your application is fit for it. There are a couple of things to take to look at.

At Divio, we always recommend taking a look at the 12 factor app methodology for this. These are 12 architectural guidelines that make it easier to be deployed into the cloud. For all of these, there are ways to circumvent them or workaround them if you have to. However, things can be much more difficult if you don't implement them correctly, so we don’t recommend using workarounds unless absolutely necessary. 

If you follow all 12 principles, it’ll make moving applications much easier later on. These principles include how to set up an application, how to talk to a database, how to end the persistency, and so on. The hardest part of migration is making sure you follow as many of these principles as possible. In this process, you will want to consider how you will handle later on any principles that you cannot follow right now.  

The App’s Migration Journey

How to Approach it

The first thing you should evaluate is how your application looks compared to the 12 app guidelines. What needs to be done? For instance, think about how you want to store data. If you want to scale horizontally, you don't want to scale data in a local container. So how about storing data externally? It’ll then be much easier to scale the containers. 

For example, let’s say you have three containers and store their data in a centralized location. You could have a central database for every one of those three containers, and you could have object storage to store data. The idea here is that not every container is storing stuff locally. Everything that is persistent is stored externally. 

In layman's terms, don't store on your local file system, and don't serve any information to a local file system. This is a very common issue when people are thinking about moving to the cloud. 

When moving to the cloud, you can still store stuff on your local file system. However, this can lead to issues scaling. For instance, this can result in having more instances of your container.

Or, you end up having to play around with hacks of mounting virtual file systems locally. You really don't want to get into that. It's complicated, but you can fake saving data locally and then store it on an external service. 

So your application looks like its being stored locally. But this gets into complicated non-stable territory. However, once you can assess this you can determine that you have a reasonable set up. Everything is implemented correctly. This is something you might already want to use in your current infrastructure.

The trick is to get your current infrastructure as cloud ready as possible. This means the switch later to the cloud is much smaller. You might want to break this whole journey into small parts. You can then complete each section individually. You don't do all 12 steps together in one go. We recommend that you complete each of these steps of the migration separately.

In the end when you do the migration, this means you’ll only have one thing to worry about. Not everything has to be working perfectly, as each of these steps has potential issues. If you want to move data around, this can bring up issues. But if you do all of the migration at once, you can have more things that can fail at the same time.

Taking Incremental Steps

It’s all about focusing on the 12 steps. If any of them aren’t already steps in your current application, you can rewrite it to include them. Do this one step at a time, by repeating this approach for each factor. By the end, it’ll reflect that your current application adheres to each of these factors. After some time, you’ll have a well-defined, re-factored application. And you will have achieved this using a process that wasn’t too daunting.

You don't have to do a big implementation task that takes two years. You could end up flipping one big switch and everything breaks apart. It's much simpler to break the steps up, into smaller pieces of work. Just make one change, test it properly, then put it live through the next change. Do this for all 12 factors. Take an incremental approach.

On our platform we enforce these 12 factors successfully. There are reasons and ways to circumvent most of them. A couple of them are particularly heavily enforced, but it's absolutely recommended to use all of the factors. This is the most technical and challenging part of the migration of applications. Specifically if you’re migrating from a single web server to the cloud. But once you have done it using this approach, you’ll have a very well structured application. 

Along with the 12 steps, there are some other pieces of work that you can split up before you do a full migration. These are from a technical perspective that's very encompassing. These will highly depend on your business logic. Use this to think about specific ways on how to do the switch properly.

What is Business Logic?

Business logic is the logic of your application. For example, you have a shop system. If the customer is able to put something in a shopping cart and click the checkout button, this is business logic. Everything that your application is is the logic of your application. A different example would be if you have a music app, somebody can press the play button and a song plays. Business logic is anything that adds value in code. Unit tests, on the other hand, aren’t business logic. These are part of your code and are important. They’re adding value but to developers, not necessarily to the customer.

How to Start

You’ll want to start with a test environment, so just deploy it. Deploy everything you want to. You want there with some dummy data – don't use customer data. Then, just try it out. Do some smoke tests, see if everything works fine, and test it as extensively as you can.

You’ll be fine with everything in your performance tests. Everything will still work the same. It should still be the same business logic because you already upgraded everything correctly. You can then move data. This heavily depends on your application and your use case. You can just take your application offline for an hour, move data, and then put it all online again. Put it on the new environment with the domain switch and you're done.

How Long Does it take?

Let’s recap the process so far. You have to make sure that you've gone through all of the different 12 factors and changed your app where you need to. You need to make sure it meets the methodology’s standards. After that is the time to go through anything specific and/or idiosyncratic. You can then put it into a test environment and do smoke tests. Once you've gone through this, the process of debugging begins.

After you have gone through debugging, you can make the application live. In some cases that's going to take an hour, in some cases much longer. How long it takes all depends heavily on the data that's used. It can be a massive undertaking. If you have a lot of data, you could move a large chunk of it in advance. This means later on you only have to move the difference. 

Let’s look at a hypothetical example. Let's say that you’re an insurance company. You’re going through this process, and you have a massive amount of data to move. How long this migration takes will heavily depend on the application and the integration of the other processes. It could be a yearlong process to get the application ready for everything to be tested.

These sorts of applications have tightly structured release windows for when they’re legally allowed to make changes. However, even in the worst case scenario, the last migration step section may only take an hour. It’s everything in advance of this that will add to the time frame. This is one of the many reasons why the 12 step methodology is beneficial.

Let’s go to another example. Let’s say you’re a startup founded by a developer. This particular developer loves the 12 factor methodology. All projects have worked this way. Their product is very popular, and they know that they need to grow. They want to migrate to the cloud.

They want to move from a very small setup to a much bigger, scalable setup. Say their product is really popular in Thailand. They want to be able to handle bursts of activity. However, when Thailand is asleep, the product isn't as popular in other locations. They want to start to grow in different locations. This is why they’re moving to the cloud. In this scenario, it’d take them about a week or two to go through this process.

Next Steps

When it comes to a cloud migration project, there are two main topics to think about. The first thing is getting everything ready for the 12 factor guideline. The second thing is moving the data. Moving data is surprisingly slow. Once you've got it all moved over and made live, there’s the aftercare. There's going to be maintenance, cleanup, and so on.

So, you've gone through this whole process. What do you need to think about next? Let's say our little startup example has moved over very quickly. What are the things they have to think about in the future, now that they're on a scalable cloud solution? 

The most important thing to remember is that things change. There are always software updates for everything, at any point, all the time. Your verification needs to be kept up to date. The underlying operating systems that you use have to be kept up to date. And this is very not forgiving. A very famous example is when AWS stopped supporting PostgreSQL 9.6.

This is an extreme example, but there are always going to be software updates. There will always be things that get deprecated. There's no way around it. This is the main work to just keep your application running. It includes things like making sure that you apply security patches, that you look at your log data, that there are no storage needs, and that things are not growing indefinitely or infinitely. These are the things that you need to watch out for. Not to mention, if you've got something set up wrong, cloud costs can get out of control. There should be safeguards in place for this, but if you ignore these – good luck.  

Takeaways

As we’ve seen in the scenarios shared in this article, cloud migration projects should always be approached on a case-by-case basis. Whilst there are actions you should definitely take – like the 12 factor guidelines – the project itself and how long it takes is all down to your application.

Using a methodology can create a solid foundation that’ll help make the migration as smooth as possible. Part two of this series provides a deeper dive into cloud migration and how Divio can help you.