Here at Glisser, we’ve migrated over several different cloud providers in the course of two years (AWS, Rackspace, IBM Softlayer and then Azure). The process was a proper pain at first, since we provide a live presentation service and simply cannot afford any downtime when our clients are on stage. But we’ve learnt a lot doing it – reworking some of our plumbing as we go, resulting in a leaner platform and a better product. Here are our top cloud migration tips.
Do I need to move into the cloud?
It’s a hotly debated topic. The short answer is no, you absolutely don’t need to. It really depends on the nature of your business and your own requirements; there can’t be a simple answer.
Spotify, for example, have only recently moved away from a hybrid on-premise / cloud architecture to a full cloud hosted platform. As even the big guys are still profiling both scenarios, it goes to show that this isn’t a binary answer, and that the choice should be tailored by your needs.
Requirement Analysis: How big is your stack?
Ultimately that’s the big question that will define how long your migration is going to take.
I debated the subject with CTOs from many other startups at the Microsoft Accelerator program. One of them explained how challenging this was for him – he said he had about twenty servers with complex service replication and data segregation. What might be a quick sprint to others must have been more like an Ironman for him!
The general advice here is to keep things light and lean. The quicker it will be to transition and the easier it will be to maintain on the long run.
- Draw the whole stack on your office wall. I know this sounds overly basic, but it will give you a good idea of the scale of the job and the amount of time it will take you. It will also get everyone in your team to understand your architecture better.
- Start separating your public facing from your back end components. You can use this exercise as an opportunity to improve security on your infrastructure with very simple practices.
- As some of your components might need a few tweaks to work in a new environment, run an ‘exploratory’ sprint to identify what will need to be addressed. Use this opportunity to simplify the various interfaces of your components.
- If you’re not doing it already, enforce a proper inversion of control solution to make your code as agnostic as possible to its surroundings. You will make it much looser and more flexible to changes throughout your project lifetime.
- Use this migration as an opportunity to refactor your code footprint. You probably have a good number of architectural impediments sitting in your backlog. It’s the perfect time to size and address those with a bit of refactoring. Your code can never be too light!
- Automate your processes. Yes it sounds very common sense, but it will save you time. Loads of various tools out there to use depending on the tech you use. The aim is to turn this fastidious process from long manual tasks to a single click operation.
How much is it going to cost me?
Cloud hosting doesn’t come for free. Although a lot of providers have free plans to give you a taster and get you on board. Ultimately, however, you’ll have to pay the bill.
And the answer is again dead simple: you’ll keep it cheap if you keep it lean. Badly designed architecture is going to cost you a lot on the long run, and spotting problems early will help you keep your architecture as light and cost effective as possible.
Don’t over architect it!
I recently attended a talk about cloud migration. It was interesting to learn about a ton of infrastructure tools (and there are a lot around) but frankly this was overwhelming. Generally, try to keep it simple. There’s no need to come up with a hugely complex infrastructure until your product requires it. Over-architecting will have an immediate impact on your bill for no real benefit. Of course you can try things out, but a good practice is to keep it as lightweight as possible.
Heavy bikes don’t make olympic champions, and neither will heavy code!
You can start identifying what in your stack would need to be streamlined instead before adding on extra services. This will ultimately make the switch in the future much faster.
Watch your specs
Since most of your bill will be based on server uptime, it’s a good idea to understand how many you’ll need, what specs, bare servers vs virtual and so on… My advice again, is to keep it simple with relatively low specs and this should be plenty for you to start with.
Don’t learn to drive in a Formula One car.
As part of our last migration, I chose a well overpowered park of servers for our live platform, although based on actual metrics, our service would run just fine on lower spec machines without any impact. You are going to find that most of the problems come from code implementation rather than hardware (virtualised or not). So it’s best to get going with the most restrictive hardware to get the most out of your code.
Monitor, monitor, monitor
When choosing your cloud provider, I suggest you do your research, and really understand what monitoring solution they offer. Most of them come with a bare minimum, but it’s good to check beforehand.
You will benefit greatly from a monitoring solution that can inform you in real time about the state of your platform. I might be teaching my grandmother to suck eggs here, but start setting up some basic monitoring: CPU consumption and network activity to begin with. Set up in seconds usually, they will give you a good indication of how well your engine is performing and will help you drive your DevOps decisions in the long run: choosing higher specs, scaling up and so on…
I hope this was helpful. Get in touch if you have any questions, and if you like what you read, speak to me about working at Glisser. We always need great developers!