From On-Premise to the Cloud

If you’re here, you likely have a server on site, and you are looking to move to that big fluffy thing in the sky. You’ve probably done a lot of homework and now you’re ready to make a plan.

What follows is how we help our clients create that plan.

• Choose Your Cloud Provider(s)
• Types of Cloud
• Decide if you really want to move to the cloud
  • Common challenges with solutions
  • Determine costs of not moving
• Prepare the application for migration
• Migrate
• So… need some help?

Choose Your Cloud Provider(s)

This goes a little deeper than comparing virtual server costs if you want to capture the most value from the migration.

Rather than just migrating your application from your server to someone else’s, we highly recommend taking the time to refactor the application to be cloud native.

Going cloud native gives you some incredible benefits:

• Infrastructure as code - No more manually spinning servers up. You define a template, and can spin up as many complete environments as you need for your developments flow.
• Scalability to the max - Containers will automatically be created to meet the demand of your application. Also important, they will wind down when your users do. Why pay for computing power if everyone is asleep?
• Focus on your core - Using cloud native serverless allows you to focus on business logic and stop worrying about updating your hardware.
• agility - Lowercased “a” on purpose. Respond to changes in your business faster and be the first to exploit potential opportunities.
• Stop repeating others - Most cloud providers have built in solutions for common use cases, meaning you can focus on what makes you different rather than what makes you the same.

You will need to evaluate different architectures for your application in these different cloud providers (or an architecture spanning multiple providers). As with anything, there will be tradeoffs in speed, costs, maintenance, and complexity with each architecture.

Types of Cloud

Next, we need to decide what types of cloud we will be using for the application in question. Typically, we will use a hybrid cloud approach:

1. Sensitive data will live inside of the Private Cloud.
2. Non-sensitive data and the bulk of the application logic will live inside of the Public Cloud.

Ultimately, we are balancing 2 things with the private and public clouds:

• Minimize costs - A good split between private and public clouds will help you maximize cost savings.
• Security - Encapsulating your sensitive data inside a private cloud grants peace of mind.

Place your focus on moving as much of your application onto the public cloud in order to capture a higher proportion of those benefits. A cloud migration is also a fantastic time to offload sensitive data and compliance to another party.

Decide if you really want to move to the cloud

Now that you’ve survived the first two steps, you may decide it’s not worth migrating to the cloud. And that’s totally fine - too many companies jump on any bandwagon.

Common challenges with solutions

In an effort to help make your decision clearer, here are some other common challenges when migrating to the cloud. However, we won’t leave you just with the challenge - we will also include how we deal with the challenges here at Aidia.

1. Cost overruns. This is probably the first one we see most frequently. It ends up being significantly more expensive than you expected. How we deal with it? We charge an upfront cost and hold ourselves to it. In other words, you won’t have cost overruns with us.
2. Unknown technology. Many companies have worked with third party consultants to migrate to the cloud and end up with a system they don’t understand written in a language they can’t read. We work directly with your developers to choose cloud native technologies that are easy to pick up, with the code base in their language.
3. New bugs. Anytime there is a big change, the chance for bugs to creep in goes through the roof. We use best practices to minimize introducing bugs, and we offer a bug-free guarantee for all of our development efforts - if you find a bug as a result of our changes, we fix it free of charge for up to a year after we have finished the migration.
4. Time overruns. Even if costs are fixed, waiting for the migration to be complete before you can use it can be a death sentence for companies that need changes now. Our solution? Perform the migration in vertical slices which are immediately usable. This ensures you can continue moving forward and upward.
5. Downtime. For some applications, every second literally counts. Either downtime needs to be on the order of milliseconds, or needs to happen at some horrible time in the middle of the night. We address this by using a blue / green deployment strategy.

Determine costs of not moving

If you are still on the fence, you need to determine the costs of not moving.

1. How much time and effort is spent on maintaining your current infrastructure?
2. What technologies are your competitors using?
3. What will your competitors technology look like ten years from now?

Moving to the cloud does not guarantee a competitive advantage. Being able to do more with less (leverage) does, hence the importance of the first 2 steps.

Prepare the application for migration

Finally, we get to dive into the code. Here’s a high level overview of what we do:

1. Separate code as much as possible into distinct, logically separated modules. This makes it significantly easier to deploy a single module to the cloud while leaving the other modules in your existing premises.
2. Wrap modules with interfaces that can be swapped at runtime with flags. This allows us to switch from the on-premise module to the cloud module when we want to, and maybe more importantly, switch back if the cloud module isn’t behaving as expected.
3. Evaluate if the module needs can be replaced with something off the shelf, retired, or if it truly is necessary. Use this time to help bring the focus back on the core of your software which should match the core of your business.

This can be done all upfront, but is not necessary. Once you have successfully extracted a module and provided a swappable interface with it, you can move onto the next step for that single module, then jump back here and repeat the process.

Migrate

And finally, we get to play in the cloud. Here’s our process:

1. Create the new module in the cloud. Ensure it is well tested.
2. Create an interface in the existing system matching the old module interface which calls the module in the cloud.
3. When ready, trigger the flag to swap using the old module to using the new module.
4. When 2 new modules are well tested and interface with each other in the old system, remove the old system bridge and move it to the cloud.

Repeating this process with each module will allow the system to remain online, well tested, and migrated a piece at a time to the new architecture.

So… need some help?

You still want to migrate? Saaaweeet!

Here’s how we can help:

1. Cloud Native Architectures - We love the cloud, and will work with you to create an architecture which matches your business.
2. Application Decompisition - We will get our hands dirty and work with your team to separate your application into distinct, logically separated boundaries to prepare for a migration.
3. Expert Guidance - Need someone to chat with? We can set up strategy calls, workshops, or even have you join our slack for all of your questions.

Reach on out and let’s fly to the cloud!