Why cloud costs get out of control: Too much lift and shift, and pricing that is 'screwy and broken' Spinning up services on public clouds is dead easy, but what about staying in control of the bill? Organisations are "over budget for cloud spend by an average of 23 per cent, and expect cloud spend to increase by 47 per cent next year," according to a "State of the cloud 2020" report by Flexera, based on a survey of 750 …
There are discounts to be had if you're willing to commit to usage, although the system used to be a lot simpler to use. If you were willing to pay in advance, you could send Microsoft £5000 and they would credit your account by £7000 (which would last 12 months).
Now you have to say what kind of VM you're going to use (although you can trade for others without any penalty). Then there's software licensing... we knocked a massive chunk off our costs by actually buying some Windows Server licenses, rather than using the PAYG Azure pricing. Both of those things took our "per VM" cost down from £250 down to £80!
"organizations 'make a lot of compromises' "
Oh do they now ? Funny, five years ago going into The Cloud (TM) was accompanied by a chorus of angels playing their harps and chanting "bonus, bonus, 100% uptime and no hassle anymore, bonus".
At least, that's how the marketing played it out.
Now, when The Cloud (TM) is firmly entrenched, we discover that no, it is not easy to manage, yes, it is easy to lose customer data and have data breaches and no, your costs are your problem and, if you don't pay attention all the time, those costs will go up.
In other words, you have to have a Cloud Admin who is overseeing all the company activity and reacting accordingly.
The only difference with a SysAdmin is that a SysAdmin had direct control, knew what was happening where and had the means to shut things down if it came to that.
So we've basically replaced SysAdmins who were in control by CloudAdmins who have to continually check to see if they are in control.
Yay progress.
We're currently dipping our toes in AWS. I'm a sys admin and for on-prem I know exactly what's what. So when we get audited I can prove who has access to what, and what they can do. So far so good.
For the AWS stuff? Well that's a different kettle of fish. Whilst I should be able to prove who can do what based on SSH access, there's still the sticky point of people who can gain (console) access via Session Manager. And, of course, I have no visibility etc of the polices surrounding Session Manager.
Plus we're still seeing far too much of "put it in the cloud, because" type stuff where people think it's the solution to everything. And to top it all off so far the main project that was slated for the primary/best use of AWS has so far pretty much ignored what we've set up for them and spunked a rather large amount of money on some on-prem servers...
Because it's a closed source, remotely managed, remotely run, piece of software on someone elses hardware. The fact you have set a policy saying only these people can connect to the session manager and these systems doesn't mean the AWS admins can't, or some compromised admin account in AWS can't.
On premise, secured, session manager software, you have far better assurances.
BTW, different AC
Take a look at this article on how to audit...
https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging-auditing.html
--------------------
In addition to providing information about current and completed sessions in the Systems Manager console, Session Manager provides you with options for auditing and logging session activity in your AWS account. This allows you to do the following:
Create and store session logs for archival purposes.
Generate a report showing details of every connection made to your instances using Session Manager over the past 30 days.
Generate notifications of session activity in your AWS account, such as Amazon Simple Notification Service (Amazon SNS) notifications.
Automatically initiate another action on an AWS resource as the result of session activity, such as running an AWS Lambda function, starting an AWS CodePipeline pipeline, or running an AWS Systems Manager Run Command document.
The Cloud Providers certify their services using industry-wide programs that are then verified by third party auditors - think the big five... This is the same for all providers, GCP, AWS, Azure. These audit reports are available for customers to read and make interesting reading. They will help with your audits, on top of the built-in audit and logging capabilities they provide.
At a global level, AWS has certifications against PCI, SOC1 - 3, a bunch of ISO and CSA. They have a bunch more at a Europe level such as GDPR. Then they certify individual services and I can see that Systems Manager, that includes Session Manager, is covered. This should give you confidence that the Cloud Providers are doing things in the correct way and you can see this in the audit reports. You can see what systems that have and how they monitor access to these systems.
On Top of this, have confidence that some of the most heavily regulated customers on the globe running on them, including Nasdaq, DBS, Starling Bank, HSBC, Standard Chartered Bank, National Australia Bank, Commerz Bank. These are just the public-facing case studies.
Personally, I would worry less about CLoud Providers securing their services, and worry more about how you configure your accounts, systems running in the Cloud.
Yeah, I work at a company that is audited by PCI (DSS, CP), various ISO certifications, Military clearance (which I also have TS clearance and others CTS).
The audits of course depend upon the auditor, but are mostly worthless in terms of actual security and following what rules they do require. The auditors either have specialised knowledge which they really like to look into and nothing else or know very little and will just take your word that all is good.
I have even been in an audit where when we brought up the command line to provide information on the system, it was, all is good, no need to show anything.
To be fair, most of the same issues of overspend and under-utilisation were there when moving to VMs started to be a thing. And when the move to network PCs happened. When fundamentally changing an architecture, it takes a while for all the parts to catch up, and some legacy applications never do. And having hybrid architectures is cost-inefficient. And working with a new architecture you initially don't have the kno to optimally use it.
I don't think any of that is specific to the cloud
This post has been deleted by its author
There are very few good reasons for using the cloud (aka other peoples computers)
1) Short term peak (3 months or under)
2) Providing a web service when a firms own internet connection is inadequate for the load
3) Keeping development staff well away from production systems
4) Temporary production run while own servers are out of action
For almost all other use cases, it will be cheaper to use own hardware. Try pricing the cost of a cloud service vs the cost of on site hardware before using any cloud service - you may be surprised at how few months it takes before the on site hardware is cheaper.
Other reasons for NOT using the cloud
1) Most cloud systems are owned by US companies - the US Cloud act allows the US government to access any data on the at will without notifying the data owner. For any company in the EU (and also in the UK if it continues to follow GPDR) this can lead to it being exposed to heavy penalties if personal data is exposed.
2) As all too many companies have shown it is far to easy to configure cloud storage security incorrectly leading to release of confidential information. This can again lead to GDPR penalties along with the other costs from the leaked data.
Icon for cloud users =========================>
It is rather sad that the Beancounters and the PHB's don't see it that way.
Like offshoring, it can work BUT...
it often doesn't.
Far too often those seemingly running the show think that the latest trend/fad/buzzword is the path to untold riches.
Act in haste repent at leisure.
Not that I condone this or agree with it in any way, but the big point is the move from Capital expenditure to Operational expenditure. To buy and run your own hardware is a big hit of Capex, which re-occurs every three to five years as you refresh.
Beancounters don't like Capex.
Moving stuff to the cloud is an ongoing Opex which makes the beancounters feel all fuzzy and warm.
The fact that the total Opex expressed over a number of years is way more than the equivalent re-occuring Capex doesn't seem to bother them...
Cloud is just like outsourcing 15 years ago. Everybody went all in and found out that 100% outsourcing was not so great.
The cloud migration trend is just another IT fad. People will over do it to the cloud and bring some stuff back on-prem. We will end up in a Hybrid cloud model that make sense for each business.
It's years since I had this explained to me. But the way it goes is that capital expenditure needs write offs, so there is an annual depreciation cost. Operational expenditure is just an agreed budget,and they can control it.
I'm sure my ageing memory has oversimplified this.
FYI the Cloud Act applies in the UK only because the US/UK signed an agreement last year. Otherwise it would have broken GDPR. https://www.insideprivacy.com/surveillance-law-enforcement-access/10167/#:~:text=It%20obligates%20each%20Party%20to,jurisdiction%20of%20the%20other%20Party.
The issue with the 'Cloud' is not that it could be a viable solution for many organizations for at least part of their workload but the adoption is often not thought out. Every organization has a different balance between on prem and cloud they should be using. Surprisingly it is often weighted in favor of on prem for numerous technical and legal reasons. So the cloud use should reflect not what the sales person says but what a cold, hard look of the organization's needs are.
The 'Cloud' has been touted too often as the solution for all problems to non-technical types who do not appreciate the complexities of running a server farm of any type. The problem is the decision is made without consulting the people who will be implementing and running it.
Completely agree - the push towards 'migration of everything on prem to the cloud' is not something I'm uncomfortable with. IMHO the technical and legal reasons can often be mitigated, but are real concerns sometimes..
Regardless, I'm unconvinced that shifting a bunch of production VMs running applications not designed for the cloud from infrastructure that's already bought, in place and stable will really offer a sensible return on investment unless that infrastructure is unusually expensive for some reason (which is sometimes the case). Doing the migration generally involves good people if it's done well, and people are expensive. If it's not done well, it risks service stability.
But for many new services, cloud can be great.
Totally agree, if you have a very spiky load, think ticket sellers (in normal times), or video streaming platforms it makes perfect sense.
Just scale up when you need it and then scale down. It might be you need x resource on a normal day but 100x on a peak load. Then the cloud makes sense. If you just need x all the time then I can’t see why you wouldn’t just do a local resource, as it is fixed, controllable and easy to manage.
If you haven’t got your own data centre just rent a cabinet off a hosting or co-lo site
I recall the claim from the last century, before dumb terminals were beginning to sprout up in offices everywhere, that the world would only need 5 computers. I had a holiday job with a large hight street store that had its own computer (and a well-staffed building to support it) that leased time to the local authority. Then, how we chuckled at the notion of only 5, as each corporation was getting its own. We howled with laughter as the PC took over - every person had his or her own; not 5, but millions! The laughter began to die down as organisations realised they could use VMs for centralised services - PCs were becoming terminals (albeit not-so-dumb). Granted we all carry our own computer or three around in our pocket or on our wrist but, for business management, If we consider each cloud supplier (AWS, Azure, etc) as a computing unit (that is, the modern iteration of last century's computer), 5 might seem excessive...
The Cloud is just like any other business procurement. The purchasing manager has a budget. Once that's spent there is no more unless said manager goes crawling to the grown-ups asking for more pocket money. Managers should keep within their budgets.
I understand that some Cloud providers require a credit card or other grab-my-cash authority but they also provide tools that allow you to monitor spending very carefully. The culprit here is poor monitoring of Cloud resource consumption. I'd happily bet that most Cloud overspends aren't down to poor estimation of workloads but are due to resources that were spun up for a test or migration and never shut down, or multiple versions of test/backup data that is no longer required.
It's much, much easier with the Cloud to make such mistakes but they are due to carelessness. A glance at my personal Dogital Ocean account would prove that. But it's still down, largely, to poor management of the resources, not the technology nor the billing and business models of the providers.
They don't provide decent cost monitoring.
You don't get cost breakdowns, which means the beancounters can't assign the consumed budget to each project, or even business unit.
And thus there is no incentive for each individual project to spend any effort trying to account for their usage.
Thus, they do not. They spin it up and leave it going.
And thus costs spiral out of control, until someone screams that the entire business risks failing unless Something Is Done.
That wasn't an issue when only one or two projects were "cloudy" (eg CDN), but as soon as it's tens...
That's just completely inaccurate. You can absolutely use and automatically enforce tagging to track resource costs and report costs back to teams/projects/cost centres etc. at a really granular level. Similarly you can control who is allowed to spin up resources. E.g. for AWS there is https://docs.aws.amazon.com/whitepapers/latest/cost-management/introduction.html . It's one of only five AWS Well Architected pillars - https://aws.amazon.com/architecture/well-architected/. I'm pretty sure the other big clouds have equivalents.
You have to set it up right, of course, but frankly if you don't, it's a governance failure on the enterprise side, not something inherent to cloud. I'm not saying businesses don't frequently get themselves in a pickle, but when it does it's often more to do with traditional infrastructure and operations sticking their head in the sand, refusing to engage and bring their expertise to the table to make sure it works.
" You can absolutely use and automatically enforce tagging to track resource costs and report costs back to teams/projects/cost centres etc. at a really granular level."
Sure. And how much you have to pay for that capability? More than the project otherwise costs, as already observed.
Because in the cloud *nothing* is free.
Your time is the only significant cost, actually. The basics you get in the same way as most people get itemised phone bills for free. Tagging doesn't cost anything. Everything's so automated and integrated it will likely cost very much less than any cost allocation you're trying to do for on-prem services. Remember, cloud services are built from the ground up to be metered at a granular level for the cloud provider - all they've done is extend this out to customers.
From a technical perspective, there are storage charges if you want to retain for a long time, bandwidth charges to download info etc., but those are really really *tiny*. If you choose to use cloud BI services (e.g. AWS QuickSight) to do your reporting rather than desktop-based/on-prem server based analysis, of course you pay for those, but not much - think $18/mo for a dashboard author ranging down to $.30/30 min session for infrequent dashboard viewers.
"I understand that some Cloud providers require a credit card or other grab-my-cash authority but they also provide tools that allow you to monitor spending very carefully. "
This is blatant BS. Some provide tools to "monitor spending" but unless you are spending millions per year the tools cost *more than the item they monitor*.
This is *not* an accident: The idea of the cloud is to steal *everything you have*. First data and then money: Once you go into cloud, any, getting out *costs a lot of money*.
Also: No backups you could put on tape and sit on. Not without *huge* amount of money. Basically disaster recovery capability is literal 0.
Sorry, I think the BS is yours.
There are specialist third-party (not provided by the clouds themselves - that would make no sense as no-one would trust them) cloud spend monitoring and optimisation tools. Some of them are expensive and indeed only make any kind of sense for very large cloud estates. But you can do a great deal with the standard, built-in, essentially free ones.
On reversing out of the cloud: if you generate truly epic quantities of data, that generates some lock-in, but not irreversible. Case in point: Dropbox exited 4 petabytes of data from AWS S3 when they decided they had the scale and capability to build and run their own private storage cloud.
More importantly, and similar to any proprietary vendor including any on-prem ones, there is substantial lock-in if you go for proprietary high-level services as opposed to lower level standards-based ones. There are things you can do to mitigate that a bit (Kubernetes is often one aspect of this), but these tend to increase complexity and unpick a number of benefits of going to the cloud. Essentially, you end up trading potential long term costs of lock-in against short term increased build costs. It's not a new problem, nor is it cloud-specific. The right answer usually depends on how fast you have to get to market.
I've spend a fair amount of time looking at DR for both on-prem and cloud-based services in a fair number of companies, and from a practical perspective DR for cloud based services tends to be way ahead in my experience, because the clouds make it really easy to implement setups that provide (largely) automated resilience to outages affecting a smallish geographical area (e.g. tens of miles). On-prem DR is often a shitshow on very many levels. And the clouds do effectively provide tape or equivalents - S3 Glacier is backed by it, at least the last time I checked. They won't, of course, be tapes in your possession though, which is I suspect what you're fulminating about.
The one type of disaster that many people building on cloud do not address is wholesale failure of the cloud provider for either technical or business viability reasons. You have to take a view on how likely that is - the really big cloud providers seem to isolate availability zones pretty well nowadays (much better than enterprises - one I reviewed forgot to implement DR for their DHCP servers FFS, and it took a power outage for them to notice). The top three providers are probably too big to fail. If they got into trouble as businesses, the government would probably backstop, not least because they don't want their own stuff falling over. But if you want to mitigate - just sync your data back to base. There are lots of patterns for doing so.
Beware who you give a corporate credit card to and check the bills to ensure cloud providers are not cropping up. This especially applies across countries.
Set up your cloud governance before you move anything and rigidly control it. Requiring Devops pipelines and build templates can help a lot.
Beware customer contracts that say "you will get your own dedicated hardware/server" because auto-scaling 10 web servers across 10 customers won't be possible and you won't get cost savings.
Trying to combine security uplift with a migration will cause delays and cost over-runs. Be sensible about it but don't go to either extreme. Asking security will cause them to list everything in the toy box as a minimal requirement. Similarly I've seen too much *.* just to get stuff going because the IAM was too hard.
Kubernetes (the latest must-have) can in fact cause utilisation to go down rather up (against VMs) when everybody wants their own dedicated cluster, for reliability, contractual or other reasons.
Microsoft aggressively target boardrooms with the Azure products, promising better up time, lower cost and significantly reduced costs on prem.
Much of this was supported with fancy PowerPoint presentations showing how many staff were needed to support x TB or storage and y number of servers. IT staff in these roles were classed by Microsoft as "highly paid janitors that offer no value to your business" We can do everything they do for a fraction of the cost.
C-Suite's lapped this up and got hooked on the cloud bandwagon, ignoring any advice from IT Teams. All the believed IT had to do was manage the contract and SLA. Microsoft magically made everything happen. Developers could do undreamed of work more efficiently and faster than before. Everything would be perfect.
Now, unsurprisingly, Cloud is not cheap, easy to manage or always available. The bills start rolling in but companies are screwed because it is now so difficult to undo the rush into the Cloud.
Cloud services do have their place however this mantra of "Cloud First" is benefiting nobody other than a few mega-corporations. The monthly subscription model that started with the mobile communications has been hugely successful in making everyone believe it is cheaper.
I don't think that's it. If they just kept increasing the prices for the same thing, that might apply, but they don't seem to do that very often. Instead, they have so many products, each of which has sixteen variants, and each variant of each product has a different price depending on where you host it, so nobody can really keep track of the price differences. Also, they don't bring people's attention to the things where they make the most revenue, meaning they can slip in a slightly higher than expected bandwidth price and people only notice if they do a lot of research. It's not quite extortion based on lock-in, but instead a morass of complexity.
For example, just look at bandwidth charges. I wanted to do a simple comparison to demonstrate how quickly those could run away on you. So I tried to find the prices. I found Azure's quickly. Google's took longer but was still in my first set of search results. Amazon's was tricky to find via DuckDuckGo. I found unrelated AWS pages, third-party blog posts purporting to explain it, outdated information of all kinds, and increasingly shrill requests by Amazon to let them do the math for me (only about 58 steps). If you scroll down a lot on this page, there are transfer prices for EC2 VMs, and for all I know there are different charges for every other product but I got bored. Now we can begin to actually compare the prices for bandwidth. Microsoft's seems cheaper, but Google's is a little unclear how a public-facing one will work, and each one offers different prices based on the selected region, includes exceptions for certain types of traffic, and doesn't show you the full set of numbers in one chart. I think this illustrates the problem. I could figure this out, do some calculations, and actually estimate the bill for each system. Except these prices are for one aspect of one product and there are a hundred more products and price lists to consider. The more chaotic the set of systems, the harder estimating a price will be even for routine usage and the easier to quickly find out that something was overlooked.
"When you've got them by the balls their hearts and minds will follow" Charles Wendell Colson
Equally, their wallets.
Once you're committed to a "cloud provider" it's remarkably difficult to extricate yourself, or even to change provider. it's not just a matter of contractual tie-ins - it's about actually recovering your data and ensuring your processes continue to operate.
Lift and shift has so much to answer for.
The economics, the operational controls and the observability between on prem and in cloud are so different that any project is planning to do a lift and shift for economic reasons really needs questioning on their planning and decision making.
Once you have done a lift and shift, you are locked into paying for peak capacity, paying for rewriting all of the operational controls and observability layers just to keep your existing customers happy. Then you find that you have peak capacity issues, and the only way to solve them quickly enough is upscale (burn money on the amazon fire). Getting the time and resources to then do the actual engineering to turn an on-prem product into a cloud product doesnt suddenly get funded properly - its budget gets swallowed up to keep the illusion of this great cloud product there in the customers eyes. All of the cloud features that are needed in the MVP product are all support tickets, for someone to do manually, because they were features that could be done by the customer when they had the software in their own office network.
I have noticed a tendency for programmers to come up with less efficient solutions when building them for the cloud. The most extreme example of this that I'm aware of is one company that performed a particular task with about 100 times the computing demand as compared to a virtually identical on-premises server solution by another company. The reason seems to have been choices the architects and developers made to use methods that were familiar to them and that they didn't have to think too much about the cloud computing bucks that this would burn. But somehow spinning up thousands of computing instances could not possibly be an acceptable solution in the long run.
In my company we use the cloud primarily for the outward facing tasks, but do all processing and such with internal server farms. It's far more economical compared to all the cloud options that we have looked at over the years.
I'd say it's actually a bit more about cloud programming and architecture models encouraging less efficient programming. I'd point out first - it's not necessarily bad programming, but more focused on redundancy.
In our main cloud system we took a process that was previously a long running DB task, mostly synchronous single thread. We put it into a clustered environment (Service Fabric, though K8s would have been no different) and moved the processing into C#. We then had to cope with the new programming issue that services may stop at any point, and nodes can go down (and definitely do), so we needed to introduce persistent storage points throughout processing. Now that it's not running in the DB then there's an overhead to processing data that was previously done through table joins, so to counter this cost we split the processing out and allowed it to parallelise, but in doing so (as well as running multiple instances of the service) we needed to reproduce what would previously have been single in-process caches with a distributed cache, which then required that cached data to be further held in each process memory locally to reduce load on the distributed cache. Then we find the instability of the environment means we need to scale this to multi-region, which at the completely redundant level means running 2 versions of the system one in each Azure region we use. This meant 2 express routes, double the infrastructure costs generally, and for the system itself x2 every component.
So we went from 1 process in a DB to a 5 node cluster with multiple persistent storage points and complete redundant processing, we had to put (and pay for) load balancers in front of the new clustered services and tie into app insights for logging. We then had to double that cost to go multi-region. This is a better system, it never goes down and it is highly redundant and scalable. We haven't written inefficient code, but there are implicit cost overheads (both in code efficiency and in infrastructure) to performance and stability scale outs that mean this system is getting noticed as being significantly more expensive that the previous DB process.
Yours is a perfect example of how flawed cost comparisons can be, specially if you go from a multi-hour long process running in 5 year old hardware to something that resolves in minutes. People complaining about the cost difference conveniently "forget" the already amortized on prem hardware and the different run times. If they compared the cloud version with a similar on premises version, amortized over a 5 year period, with similar performance, reliability and monitoring I'm sure the costs would not look so skewed
Moving to the cloud fully is much more expensive is it? Going with GSuite is much more expensive and less feature rich than 365 is it? Going with 365 would of actually been cheaper and they'd have done the migration for free instead of GMail giving no benefit for migration and insisting you still pay £30k for that migration did they?
Oh so you lied to the councillors then did you? So they sign off on it. Oh and the councillors now can't admit the fuck up as they want to be re-elected.
Interesting.
Can we please start calling the cloud what is really is, just old mainframe mentality and yes it has its uses but unless you are forced into leasing/renting most people are much better off just getting a small server in house, But nope all the small businesses seem to think they now need to be in the cloud... Sorry, rant over I just can't take much more of this software as a service stuff.
Indeed, Cloud is Just updated computer Bureau Services model from the 60s and 70s.
...and of course, virtualisation at compute, storage and network levels, also all hails from the mainframe. But “Cloud is good, Mainframe is bad” repeat mantra at C level until someone signs up.
In my company (A/C obvs) we have been moving systems to the cloud: costs have skyrocketed, reliability has gone right down.
Many of our systems are very CPU intensive so putting our processes onto VMs running on seriously over-committed hardware (one big way the CloudCos make their money) just doesn't work. So we need dedicated hardware for our VMs (costs++), dedicated support (costs++) and guaranteed uptime (costs++). Getting issues resolved has got way slower - because our cloud provider doesn't have to answer to us in the same way our on-site teams did - they have many customers and they know the costs of us moving to another cloud would be crippling.
Costs were much lower when we had our own data centre. But bigly win for our head of IT who has now decided, after this great partial success, to ply his epic skills elsewhere, presumably for more cash.
Lift and shift to the cloud is professionally irresponsible, cloud services have to be designed to be cloud services - the hardware they run on is never guaranteed to still be there and available one minute from now, you need to design for that.
As part of the design you attribute costs and as part of the operational tasks you add monitoring, not only of health but of idleness and uselessness.
Therefore, over time, as you monitor your services, they *should* become cheaper as you strip away the useless and idle parts (or redesign the useless and idle parts to become useful).
In non-cloud based organisations the infrastructure teams are often seen a wastrels always asking for more money for more storage and compute to support ever increasing requirements. The application teams have no link to those cost and no motivation to limit systems, system growth or dispose of old systems in a timely manner. Infrastructure teams a pretty bad at managing those teams, they techies so no real surprise.
Moving to cloud means systems have an ongoing cost which is easy to apply to a team, Finance can then see who are the real wastrels, if they can understand what is actually being used by whom. This is especially useful for unstructured data where individual departments can be charged for the storage and these teams then have a motivation to managee this. However if Finance do not take the opportunity to change thier charging model and just charge the Infrastructure team they miss out any real benefits of cloud and cost will just escalate with no real restrictions.
Big Cloud (Azure, AWS) is a Rolls Royce - High End Data Centres, lots of bells and whistles you can live without (Brollies in the doors, drinks cabs...). Most companies only need a Ford or VW, But in practice the accountants only want to pay enough for 45 year poorly maintained Austin Marina.
I think we can also manage ship based comparisons, the Titanic for example –the unsinkable, the entire ‘It’s too big to sink’ mentality. Eggs nicely lined up in one big basket; backups (if someone paid for them) stored on the same cloud provider just in case nothing goes wrong, no ability to switch supplier, no meaningful contingency plan…. It is so lucky that the cloud has no physical presence or some organisations would really need to really worry about how exposed they actually are.
There do seem to be costs that just get neglected or are avoided because they are a bit inconvenient to the nonspecific dream cloud implementation that incorporates large volumes of hope and magic beans - and because any problem can be attributed the 'the cloud' rather than a person.
In our specific case, it's turned out cheaper in total cost. We grow/shrink as needed, embrace monitoring, patching agents and I am able to wear infrastructure wonk hat along with others in a small company. Not having on-prem tin makes ISO27001 cheaper to maintain and I've not need to visit an office since February. It was jarring having to learn all the new nomenclature (oh! security groups ARE virtual firewalls etc), they change the service underneath (although that did happen with software updates for on-prem too), you might accidentally configure something that's expensive and I find cost tracking a necessary tedium. Your mileage might vary.
I think cloud-ing also assumes that an application can, in some cases, be rewritten to work "better" in a cloud environment. If it can't, then lift-and-shift becomes a bit pot luck. And I'd argue that a lot of COTS applications can't be, or at least can't be in a timely and cost effective manner. Having tried it, we ended up with IOPS being the killer, to the extent that an AWS bill for one application would have cost approx. £30K per month (due to IO requirements), whereas the hardware and licensing to put on an internal VM hosting environment (with capacity for other VMs) cost...about the same. It's a complete no-brainer.
This whole OpEx/CapEx thing also confuses me... I've worked at the same company for 2 decades with 3 CFOs, and all of them have pushed hard for capitalising as much as possible - moving anything to OpEx is really hard to justify, to the extent that even if we do manage to do so, the initial move is run as a capital project so at least first year spend can be capitalised. I don't understand the (financial) reasons for this, but it's clearly not just one person's idea that this is "a good thing".
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
