Things to think about when moving to the Cloud

It’s now 2018, and more so than ever, Cloud Computing is still complete bollocks. For the most part, if you ask ten different people what it means, you’ll get ten different answers.

Are you simply renting Virtual Machine capacity on another providers cloud? Are you changing the legal, billing and provision aspects of how you manage your service? Are you moving services into SaaS and not worrying about infrastructure?

It’s a complex question and a complex scenario. The trick of course is to not worry about platforms – be it IaaS, PaaS, SaaS, Containers or any of the other wonderful technology out there, but to first look at the use case.

What’s a use case? How about prior to looking at platforms, tooling and software providers you get a crystal-clear view of what you’re trying to do. Don’t think about the way you want to get there, but where you want to be. It’d be better to aim for the moon and miss than aim for the gutter and succeed!

An example might be that you’ve got a complex line of business application which runs across physical hardware on site. That line of business application exists in one site, but is accessed by many internal users, customers and suppliers.

Fundamentally, any change to this shouldn’t be initially about technology, it should be about making that application or service better for the wider user base. For example; suppliers and customers might upload data to it, that might be slow at busy times. The development team might want to change the code, but the entire platform is governed in an ITIL model which is costly in terms of time and effort to make small changes.

If the use cases look like they’d stack up; the application could do with more flexibility, quicker changes and better access, you might then start to weigh up what you can do with the application.

First and foremost, you should have an idea, even at a basic level of the following;

How much does it cost to run today?

Think Power, Infrastructure, Support Costs, People Costs, Licensing, Bandwidth, Support Contracts etc – get as close as possible to the magic TCO number however mythical it might be.

How much would it cost to run in the Cloud?

Look at two or three target architectures, think Cloud Consumption Usage, Bandwidth (often by the GB outbound in Public Cloud), Support Contracts, People Costs (Clouds still need to be configured and supported!), Licensing Costs – the model might be opex, not capex.

How much effort might a migration entail?

This is in terms of people time. Can the application tolerate downtime? How much upfront planning might need to go into understanding the system? How much time might need to go into building the new system in the Cloud? Don’t think in terms of calendar days, but people days. So just because it takes 30 calendar days, it might burn through 150 days if five people work on the project. What could those 150 days be otherwise spent on?

How much of a priority is it with all the other stuff you have going on?

You’re likely in a world where several applications or services exist. Say your organisation has 20 applications, how high up the priority list is this one? Will moving it/changing it make a major difference to your customers or cost base? If so, how major? Using an example. A bank changing their backend infrastructure might make some efficiency savings and tidy up some technical debt. Launching mobile banking however has changed the way people bank day to day. In some cases, the changes to the back-end infrastructure might have been needed to enable mobile banking, but which is a higher priority? This needs to be understood and decided.

Compliance

Is there a compliance need against this? If so, how sure are you that migrating it to the Cloud will mitigate the risks you’ve highlighted? What additional controls does changing the platform give you? Simply moving platform might not be enough to get you into the right space.

With all of the use case stuff out of the way, you can then start to look at what a target platform looks like. This is something that again needs very careful consideration. Often platforms are picked based on Infrastructure Cost/Platform Cost.

It’d be wiser again to pull the full figures in. How much will a platform cost to support and operate in terms of people time and effort? If you get some of that time back through automation, could those people do things that are more useful for the business?

Important questions such as understanding what skillsets, you have in house? how technically mature you are? What vendors you’re used to working with are hugely important.

It’s also important from a business perspective to understand what your IT/Digital/Technology Departments will look like following change, how will they be organised, and will different team structures exist for the new technology needs?

Once you have this kind of information, you can then start getting into the technology. Go out, look at different vendors, look at different technologies and see what they have to offer. AWS and Azure tend to be the default platforms for a lot of use cases now. That’s not by accident, they’ve both developed an amazing range of features and services. Use correctly, they can be incredibly powerful and incredibly cost effective.

When used inefficiently however, they’ll give huge vendor lock-in and they’ll not be cost effective either. The trick when looking at your target platform is to worry more about the workload and automation where possible.

If you’re simply going to continue running virtual machines, moving to the cloud will be a very pointless exercise. It’s a great way to get started, and it’s hugely useful for the start of your cloud journey, however the bigger savings and efficiencies will arrive when moving to Micro-Services/Containers/Serverless Technology.

Of course, this brings us back to the start, some applications simply cannot easily or cost-effectively be converted to newer technology. In this world, it’s much more advantageous to use a traditional hosting environment which’ll be way more cost effective for that type of workload.It’s now 2018, and more so than ever, Cloud Computing is still complete bollocks. For the most part, if you ask ten different people what it means, you’ll get ten different answers.

Are you simply renting Virtual Machine capacity on another providers cloud? Are you changing the legal, billing and provision aspects of how you manage your service? Are you moving services into SaaS and not worrying about infrastructure?

It’s a complex question and a complex scenario. The trick of course is to not worry about platforms – be it IaaS, PaaS, SaaS, Containers or any of the other wonderful technology out there, but to first look at the use case.

What’s a use case? How about prior to looking at platforms, tooling and software providers you get a crystal-clear view of what you’re trying to do. Don’t think about the way you want to get there, but where you want to be. It’d be better to aim for the moon and miss than aim for the gutter and succeed!

An example might be that you’ve got a complex line of business application which runs across physical hardware on site. That line of business application exists in one site, but is accessed by many internal users, customers and suppliers.

Fundamentally, any change to this shouldn’t be initially about technology, it should be about making that application or service better for the wider user base. For example; suppliers and customers might upload data to it, that might be slow at busy times. The development team might want to change the code, but the entire platform is governed in an ITIL model which is costly in terms of time and effort to make small changes.

If the use cases look like they’d stack up; the application could do with more flexibility, quicker changes and better access, you might then start to weigh up what you can do with the application.

First and foremost, you should have an idea, even at a basic level of the following;

” How much does it cost to run today?

o Think Power, Infrastructure, Support Costs, People Costs, Licensing, Bandwidth, Support Contracts etc – get as close as possible to the magic TCO number however mythical it might be.

” How much would it cost to run in the Cloud?

o Look at two or three target architectures, think Cloud Consumption Usage, Bandwidth (often by the GB outbound in Public Cloud), Support Contracts, People Costs (Clouds still need to be configured and supported!), Licensing Costs – the model might be opex, not capex.

” How much effort might a migration entail?

o This is in terms of people time. Can the application tolerate downtime? How much upfront planning might need to go into understanding the system? How much time might need to go into building the new system in the Cloud? Don’t think in terms of calendar days, but people days. So just because it takes 30 calendar days, it might burn through 150 days if five people work on the project. What could those 150 days be otherwise spent on?

” How much of a priority is it with all the other stuff you have going on?

o You’re likely in a world where several applications or services exist. Say your organisation has 20 applications, how high up the priority list is this one? Will moving it/changing it make a major difference to your customers or cost base? If so, how major? Using an example. A bank changing their backend infrastructure might make some efficiency savings and tidy up some technical debt. Launching mobile banking however has changed the way people bank day to day. In some cases, the changes to the back-end infrastructure might have been needed to enable mobile banking, but which is a higher priority? This needs to be understood and decided.

” Compliance

o Is there a compliance need against this? If so, how sure are you that migrating it to the Cloud will mitigate the risks you’ve highlighted? What additional controls does changing the platform give you? Simply moving platform might not be enough to get you into the right space.

With all of the use case stuff out of the way, you can then start to look at what a target platform looks like. This is something that again needs very careful consideration. Often platforms are picked based on Infrastructure Cost/Platform Cost.

It’d be wiser again to pull the full figures in. How much will a platform cost to support and operate in terms of people time and effort? If you get some of that time back through automation, could those people do things that are more useful for the business?

Important questions such as understanding what skillsets, you have in house? how technically mature you are? What vendors you’re used to working with are hugely important.

It’s also important from a business perspective to understand what your IT/Digital/Technology Departments will look like following change, how will they be organised, and will different team structures exist for the new technology needs?

Once you have this kind of information, you can then start getting into the technology. Go out, look at different vendors, look at different technologies and see what they have to offer. AWS and Azure tend to be the default platforms for a lot of use cases now. That’s not by accident, they’ve both developed an amazing range of features and services. Use correctly, they can be incredibly powerful and incredibly cost effective.

When used inefficiently however, they’ll give huge vendor lock-in and they’ll not be cost effective either. The trick when looking at your target platform is to worry more about the workload and automation where possible.

If you’re simply going to continue running virtual machines, moving to the cloud will be a very pointless exercise. It’s a great way to get started, and it’s hugely useful for the start of your cloud journey, however the bigger savings and efficiencies will arrive when moving to Micro-Services/Containers/Serverless Technology.

Of course, this brings us back to the start, some applications simply cannot easily or cost-effectively be converted to newer technology. In this world, it’s much more advantageous to use a traditional hosting environment which’ll be way more cost effective for that type of workload.

The tricks we’ve found work best are if something runs well in a VM and it’s a pain to convert it to Cloud, keep it there until you replace/decommission the application, or you’ve passed a tipping point that means it’s no longer efficient/makes sense to run a traditional virtual environment.

Application delivery and migrations can be complex beasts. I’ve certainly found spending some time upfront and thinking about why you’re doing it before doing it can often lead to much better outcomes. If you’d like any help with migrations or platform moves, drop me a message.

The tricks we’ve found work best are if something runs well in a VM and it’s a pain to convert it to Cloud, keep it there until you replace/decommission the application, or you’ve passed a tipping point that means it’s no longer efficient/makes sense to run a traditional virtual environment.

Application delivery and migrations can be complex beasts. I’ve certainly found spending some time upfront and thinking about why you’re doing it before doing it can often lead to much better outcomes. If you’d like any help with migrations or platform moves, drop me a message.