Although a hybrid model using Azure Batch or HPC could crunch those numbers in miliseconds, spinning up the instances when required, reducing the need for on-premises hardware. Like most things virtualised, the answer is usually "It Depends".
Convince me Azure and/or SaaS are good ideas
- Thread starter glenimp617
- Start date
Although a hybrid model using Azure Batch or HPC could crunch those numbers in miliseconds, spinning up the instances when required, reducing the need for on-premises hardware. Like most things virtualised, the answer is usually "It Depends".
Firstly, when looking at costs, I find a lot of companies don't actually understand fully the cost of operating their current kit. They then often try and do an Azure/IaaS/SaaS price comparison by just layering their existing topology into Azure (other vendors are available). Both of these lead to a difficult business case.
YFirst, you really do need a solid understanding of your current real costs so that you know what you're comparing. Next, to look at the hosting there are typically two stages to examine - take on (or lift & shift as you've referred to it above) and then optimisation. People call it different things, transition and transformation for example.
You'll have an initial operational cost for 'taking on/lift & shift)' your existing platform, then some services to 'transform' or 'optimise' those platforms for those cloud services, and make them a better match to that - that'll often drive down the pricing *and* improve the service.
One other thing to consider is the accounting side. By paying for stuff monthly 'as a service' from an accounting perspective it becomes an operational cost, so you are therefore able to fully offset it against profits - so no Corporation Tax. With capital purchased stuff you can't - it's written down over the lifetime of the kit you've purchased. There's some complexity to this - I'm not an accountant - but that can also be a driver for moving to this model as well.
Don't forget there's a fair bit of flex in IaaS type setups too. Scale stuff down, scale it out etc. all as needed.
YFirst, you really do need a solid understanding of your current real costs so that you know what you're comparing. Next, to look at the hosting there are typically two stages to examine - take on (or lift & shift as you've referred to it above) and then optimisation. People call it different things, transition and transformation for example.
You'll have an initial operational cost for 'taking on/lift & shift)' your existing platform, then some services to 'transform' or 'optimise' those platforms for those cloud services, and make them a better match to that - that'll often drive down the pricing *and* improve the service.
One other thing to consider is the accounting side. By paying for stuff monthly 'as a service' from an accounting perspective it becomes an operational cost, so you are therefore able to fully offset it against profits - so no Corporation Tax. With capital purchased stuff you can't - it's written down over the lifetime of the kit you've purchased. There's some complexity to this - I'm not an accountant - but that can also be a driver for moving to this model as well.
Don't forget there's a fair bit of flex in IaaS type setups too. Scale stuff down, scale it out etc. all as needed.
Deleted member 138126
Deleted member 138126
Last week I interviewed a Linux guy that works for a big advertising company, and they are migrating to AWS for what seems like the perfect use-case. They run thousands of VMs and the vast majority (+90%) are for web hosting. Everything is scripted via a bunch of technologies (too many for me to remember) but things like Ansible and Chef, where you have a "recipe" for a particular type of VM, and you can very quickly spin up (and destroy) VMs on the fly. This means they pay only for what they currently use/need, instead of having giant datacentres full of depreciating tin. Think of them launching some new ad campaign, which needs a large number of web hosts for the initial surge, then as demand drops they can start destroying VMs and end up only paying for what they need. This also makes it dead easy to assign a cost to a particular project/campaign.
This is what I believe AWS/Azure/Google Cloud are perfect for. Running enterprise systems with dodgy software written 100 years ago, not so much. If you can afford to re-architect your entire enterprise stack (which is always heavily inter-dependent, so good luck sorting all that out), then by all means do it with the cloud in mind. But direct migrating in-house systems to the cloud is not going to be cheaper, and introduces a whole new set of problems and challenges.
This is what I believe AWS/Azure/Google Cloud are perfect for. Running enterprise systems with dodgy software written 100 years ago, not so much. If you can afford to re-architect your entire enterprise stack (which is always heavily inter-dependent, so good luck sorting all that out), then by all means do it with the cloud in mind. But direct migrating in-house systems to the cloud is not going to be cheaper, and introduces a whole new set of problems and challenges.
Deleted member 138126
Deleted member 138126
100% agree, but the reality is it is very hard to unpick systems that have been in place for years, and if you can't get rid of your big costs (like datacentres, inter-site links, network and server infra, support contracts, etc) then it's very unlikely you'll be able to make a significant dent in your underlying costs unless you literally burn everything to the ground.
There are other costs that will be higher, like storage and backups. For me, cloud makes sense when you can either make a complete cultural change in how you do everything, or when you are starting from scratch. Otherwise I find it impossible to justify from the pure cost point of view. There may be a desire to move to that new culture, in which case the up front cost while you adapt to the new way of doing things (probably over several years) *may* be justified, but even that I find pretty hard to believe (being a realist).