The Shakespearian question of our age: To cloud or not to cloud On-prem or not on-prem, that is the question. Hamlet, musing on something similar, decried the slings and arrows of outrageous fortune, dramatically foreshadowing the outrageous fortunes many report spending on the sea of troubles more commonly known as the public cloud. There is no shortage of evidence. Are you a mid-sized …
Great article and nuanced argument for where to place 'your' infrastructure.
Ecclesiastes 3:1 "To every thing there is a season, and a time to every purpose under the heaven"
We started off in the cloud and are building our software stack so it can be moved on to our own dedicated infrastructure at a point of our choosing.
That time is not yet, but likely to be in the next 12-24 months.
It takes deliberate preparation and decisions to stay out of or disentangle yourself from the snares of the cloud providers.
I kind of went off her (and her two good songs) after she and Neil Young threw their toys out of the pram for Spotify platforming Joe Rogan.
Love him or hate him, he asks interesting questions of some super interesting people. I might not agree with everything (or much) that some of those people say, but I still defend their right to say those things.
They paved paradise, and put up a huge AWS Data Centre with massive tax incentives. What's not to like? |-)
"At least have the guts to thumbs down and follow up with a reason why you're giving it."
I can generally summarize their reasons. Any time you see a thumbs down, it means "I don't agree with something in this". That's their reason. Why do they need to spam the forums with lots of copies of "I disagree with you"? When I disagree, I tend to post a response, but that's usually when I have counterarguments to your arguments that I feel are worth talking about. For the same reason that they don't have to post lots of "This!" comments when they agree with you and can just push that upvote button, the downvote button is the way to express disapproval without necessarily having to post a lengthy response.
I didn't vote either way on your comment or any other comment in this thread. However, I can probably explain why some of the people downvoted and didn't leave a comment. They might disagree with the idea that someone is bad for disagreeing with a company's decision to give a platform to someone else. They might agree with the disapproval of the person concerned, or they might think it's irrelevant. That is not a comment that needs a lot of explanation; one person says they care about this detail, and other people either don't care or feel the opposite way. Comments saying "I feel the opposite way" are content-free, so they use the button instead. Presumably some people avoided posting "I feel the same way", and they pushed the upvote button.
If you disagree with my explanation and you want me to understand why you think I'm wrong, post a reply. If you just think my approach is wrong, but it's a subjective thing that can't be defended either way, here are some quick vote buttons.
All I'm saying is that, as it appears, they are divisive. As hollow and vapid as the Facebook "Like" function is, they haven't implemented the complimentary negative aspect of it. If you don't like what was posted and disagree, then you have to post something yourself.
Reddit suffers from this same flaw.
Again, I view it as divisive, and it serves very little value. So, in turn, it also makes the thumbs up also be somewhat questionable. It all starts to feel too much like an echo chamber one way or the other.
We're not being charged by the character here.
I don't vote very often (I still haven't on your posts or anything in the thread), but I think the buttons make sense. There are many cases in which I disapprove of something but can't really argue against it. Here's a simple one. When a security event happens, there are often people who will post a comment like "They deserved it". I don't agree with this, but what should I say in response? If the person who said they deserved it didn't post reasons, I don't have anything to rebut. I could post "They didn't deserve it and I disapprove of your blaming them", but the downvote just shortens that. It will be equally divisive whether I post that message or press the button, because I'm still disagreeing. Instead of twenty copies of that useless rejoinder, we can see a simpler count and leave the wording of the response to anyone who feels they can respond to such a statement in a more useful way. This is why I don't mind the system as it exists today, but it's a subjective opinion so I don't expect you will agree with my reasons.
In principle your response is agreeable. However, where I disagree is that having the upvote to add weight to your disagreement has value because it limits the need for everyone post the same disagreement. However, the downvote just allows the "torches & pitchforks" type model where people just gang up and do so because it's just too easy to do that. They need to state a reason for their downvote nor do they need to have a post that states their reason they can upvote. They just downvote because they either disagree or they just want to pile on.
I've seen that all of this appears to lead to things like karma farmers on Reddit (both up and down) and generally stifles conversation. If every time someone posts a dissenting opinion, and they get downvoted to the extreme we don't gain anything good. The foundation of free speech is based on hearing not only what you want but also those things you may not agree with. The voting system in these forums harms that in my opinion.
"If you don't like what was posted and disagree, then you have to post something yourself."
<fights urge to mention the Nazis and fails> No-one *has* to do anything on here.
Not everyone who reads, votes or even posts replies on here is as confident or eloquent as you clearly believe you are. Some readers will just be too busy, others will just have a general sense of disagreement. Some may have posted contradictory replies before, been flamed and found the process uncomfortable or worse. There are a myriad of reasons why people may down vote and they are all valid to the down voter. The alternative is to live in the "only positive feedback" world of Facebook and similar, which would be a real echo chamber.
It might not have any bearing on the quality, but as I don't own any of her albums and I mostly use Spotify, it means I can no longer easily listen to the two songs of hers that I like. As it happens I did listen to the a whole album of hers on Spotify before it was taken down, and I really don't feel I'm missing much. However, I still like Big Yellow Taxi, and I would listen to it. There are probably hundreds of thousands or millions like me, however as she's decided to take her entire back catalog off Spotify, she's now lost that source of income. She's cut off her nose to spite her face. Hopefully her PRS money brings in enough to make it a worthy sacrifice.
You SHOULD listen to Rogan, he interviews some very interesting people. (if you are selective), although Lex Fridman is even more interesting. If you like long form podcasts.
Maybe the downvotes are for your implied hypocrisy?
You "Kind of" went off of Joni Mitchell after she "Kind of" went off of Spotify? It may not have been your intent but the implication is that while you can choose not to listen to her music because of her choices, she cannot exercise her right to withdraw from Spotify because of their choice.
I could be misinterpreting but that's my view. As for downvotes & upvotes, I tend to hit either one only when its a strong agree/disagree, otherwise 'meh'.
> You "Kind of" went off of Joni Mitchell after she "Kind of" went off of Spotify? It may not have been your intent but the implication is that while you can choose not to listen to her music because of her choices, she cannot exercise her right to withdraw from Spotify because of their choice.
Spot on. Or as I would put it "the hypocrisy is strong with this one".
The fact they don't see the irony in their own statement is rather telling.
You got my meaning completely the wrong way round. I'm saying it's a shame that she's not on Spotify any more, as that's the only place I'm likely to hear her music. I don't agree with her choice, but I'd still like to be able to listen. I can separate the art from the artist.
Now the guy's got Microsoft as a partner. Any problems, he goes to Microsoft. Trouble with the bill? He can go to Microsoft. Trouble with the cops, deliveries, he can call Microsoft. But now the guy's gotta come up with Microsoft's money every month. Business bad, screw you, pay me. You had a fire, screw you, pay me. Place hit by lightning, screw you, pay me!
"The less well you fit that description, the greater the chances that you’ll do well to look at on-prem to run some, maybe a lot, of your tasks"
The problem is that VERY FEW workloads actually fit into that description. Having worked in IT for 30+ years, I can anecdotally tell you that the vast majority of traditional workloads have needed far greater availability during the day OR during the night (not using the same hardware). You simply can't do that easily with on prem hardware. I guess you could spin down VMs during the night, or move everything to containers and kubernetes, but that's a really huge pain-in-the-ass, which the huge cloud providers give you an oven ready solution for.
Also, what about patching the OS? Patching firmware and routers? Negotiating deals with comms providers? Economies of scale?
I've worked for companies who have a couple of 3 x football pitch sized data centres, and even for them cloud makes sense because of the flexibility and the speed of provisioning. Once you've got a budget approved it could take many months to get all the hardware ordered, racked, provisioned and then get the OS installed and the applications put on top of that. With cloud you can get all that on the same day.
Also, flexibility. If your company decides to change direction you can shelve a project after 6 months and just stop paying. Or perhaps it's just half as popular as you expected? Simple, just pay for half the hardware. What happens if it's all on-prem? You're left paying for lots of spinning servers. Likewise, if some campaign blows up and works out 10x better than expected, you can fairly easily spin up 10x on cloud.
I guess if you are a truly massive company, and you've got a decent internal billing system sorted it might make sense to go on-prem. But I've never met a large company yet, that's managed to sort out their internal billing, and everything typically goes to "IT" and somehow gets split up among projects or divisions. Cloud makes it much easier for a division to pay for that they use.
Which is why it's growing so fast, compared to on-prem.
This is a well reasoned article to a very simple question.
If a company can use the ability to grow 10x overnight, then Public Cloud is a great option. Most companies in the world don't fit this description. To the point of the article, a mid-sized Saas provider (I work at one) that has a relatively stable workload (we do) would pay far more using Public Cloud than on prem gear. We are a fine example. Our total costs are about 1/5 per workload to run on prem. We have some offerings that are in the cloud, and after seeing our eye watering cloud bills, we are looking at moving the most obvious ones on prem.
We already have an on prem environment we have to maintain, so all of the firmware upgrades etc mentioned are already going to need to be managed. I can say the same about having to have a well paid devops/SRE that understands and has experience with k8s or docker or all the esoteric services offered by AWS/Azure/Google that are not simple to understand, and those employees are paid very well, and when they leave they are hard to replace.
One thing mid and large companies are noticing is that the ability to just spin up machines in public cloud without any sort of budget oversight is that they blow up budgets. There is no one minding the til like they do with on prem gear, and while yes, getting through a requisition and the budget process can be slow and painful at some companies, if we have a customer contract that requires more hardware to fulfill, rest assure, the bean counters will move heaven and earth to get the gear to get the beans. Good planning would also allow for slack in storage and compute clusters to pick up an unexpected load.
And yes, systems can be turned off in the public cloud and the bill for them stops, but it doesn't stop for storage, and that were all the money is in most companies' AWS bills.
The problem with these sorts of analysis is that it always looks at raw compute and storage and ignores the hidden cost. Take some simple web app, its got frontend resources, a backend api, a cache, probably some file storage, some sort of message queue, background workers, and at least one database. If you look at the raw compute power to run this, no shit, its going to be bundles cheaper on prem.
But you now have other concerns. You need people who know how to run that database, back it up, restore it, resize it, make it HA, scale it. You need people who can operate a message broker service, keep it up, monitor it, replay events. Its the same for almost all parts of the stack. With cloud, you don't need those people, you can concentrate on your core business logic - the frontend, the api, the background workers - and have a cloud ops team who rely on the provided cloud resources for maintaining all those essential services that are not your core business.
It's the same with most IT SaaS solutions. You can run datadog, sentry, gitlab, grafana, etc self hosted and on prem if you want - most choose not to, most choose to use the managed services, because investing time and resources into running these services yourself is not what your business does - its just another cost centre. Same with cloud services.
Build it on the cloud, concentrate on providing what your business needs, and price the cloud costs in to your service. Hopefully if you are successful enough to grow to a point where your product is big enough that bringing it on-prem provides enough saving to pay for the expertise you need at that point.
> With cloud, you don't need these people [...] have a cloud ops team.
My experience is leading me to the realization that the "cloud ops team" is "these people".
Obviously every company is unique, but right now I'm going through fits with multiple product teams whose managers are basically doing the classic hand-wave of "all I need is a computer guy" when it comes to appropriately staffing and tasking the cloud team. Yes, we know we need a "cloud" person, but they can also manage the network devices, databases, and admin the Linux and Windows boxes, right? Instead of hiring cloud people, we're either lumping cloud work on our existing network/system admins, or expecting our admins to pick up cloud experience.
The end result is that managers aren't changing headcount at all, and the hope that all the complexities involved with building and maintaining systems which should get magically whisked away to be handled by someone else, which is the promise of The Cloud, are still necessary tasks which are done by the same people.
I'm coming around to the opinion that for most of our use cases, the idea of doing it in the cloud is a sham. A knee-jerk reaction to a keyword search done by program managers who have too much MBA and not enough MSci.
> You need people who know how to run that database, back it up, restore it, resize it, make it HA, scale it. You need people...
You need those people whether your DB is cloudy or on-prem.
If you think otherwise then you're probably drinking cloud marketing koolaid.
I agree with most of your points. You do have to be really careful with controlling that AWS bill, and it can come as a real shock.
Also, DevOps with K8s, Terraform and AWS are expensive. I should know, I am one.
But this bit "doesn't stop for storage, and that were all the money is in most companies' AWS bills" is simply not my experience in the least. Storage is usually super cheap out of the whole cloud bill. Also, if you completely ditch a project you can also ditch the storage or archive into even cheaper.
The whole premise seemed to be that it makes sense for SaaS, so perhaps it makes sense for many other people, which is the bit I didn't like.
YOUR experience doesn't mean everyone else's is incorrect, not worthy of taking into account, or should be ridiculed.
My experience with storage is that it can be FAR from cheap, depending on the way it is being used. And I mean it was costing hundreds of thousands per month just to provide a hot standby. C-Suite decisions to move to the cloud are, I would say. more geared towards moving cost from Capex to Opex - rarely is it going to be based on sound technical reasoning.
A former employer of mine, when I blatantly pointed out that Cloud was costing us 4x what on-prem did (we still had on-prem servers etc), with out a hint of a smile said....
Yeah, but that's CapEx - CapEx is bad...
yes, I know they operate differently so far as accounting but 3m (Cloud) vs 750K (on-prem) is a hell of cost to do OpEx!
One method of reducing cost in the cloud is to commit to using resources for a fixed period. Often 1 or 3 years. Same problem as on-premises - 1/2 as popular? Too bad, keep paying. Or, like on premises, use it for something else.
I would almost never migrate a VM, having seen the cost. Cloud native programs and services - now you're talking. But even after a while, bring them back to containers, on prem. If you're big enough, you can manage the capacity internally. It's the medium sized company with "just enough overworked, not redundant and permanently stressed IT" that will have some difficulty in de-clouding the expense.
(And yes, redundant is both meanings of the word).
"Or perhaps it's just half as popular as you expected? Simple, just pay for half the hardware...if some campaign blows up and works out 10x better than expected, you can fairly easily spin up 10x on cloud."
This relationship only approaches linear for cloud resellers. If you get half as many orders for your new, say, airframe, halving your server bill won't help much... if you get 10x more orders than expected, 10x more servers, should you need them, is barely the start of what you do need.
The comment was intended to discuss the benefits of cloud servers, so it wouldn't relate much to manufacturing unrelated things. If your product is software that runs on servers you operate, a website that handles a bunch of visitors, or anything where your need for servers is related to the demand you have, then you can benefit from cloud's ability to scale and could consider that as a potential option.
If your business is making airframes, then your servers are likely not that important to you, because only a few people want airframes, they only want a few of them, and they won't care all that much if your order form makes them wait thirty seconds to confirm their request has been submitted. If you make software that thousands of people use daily, then it won't be acceptable to make them wait like that, so that company would care a lot more about their ability to scale than the airframe company. The same applies to people who use servers to present content to users. For instance, if I had to wait a long time every time I clicked on an article or posted a comment with the possibility that I'd get HTTP errors half the time, I would be less happy with this site. They use CloudFlare to help with some of that scaling problem in case they get a lot more readers than typical.
This post has been deleted by its author
"So are you saying that you agree that it is pretty much only people reselling cloud services that can benefit from the cloud?"
No, because I would disagree with calling them "reselling cloud services". I would call it using the cloud services. If I run a website that scales with demand, I'm not reselling their services because, by using my website, you don't get to set up anything of yours in the cloud. I am, however, relying on those services to conduct my business. For the same reason, if I decide I can run my site off on prem servers, I'm not reselling those either. I'm using them. Depending on how I use them, I might benefit from the cloud or on prem more.
Since you're posting here, I assume you have a technical background meaning you're well aware that some companies need a lot of servers to conduct their business and other companies don't need that many. The ones that need a lot of them tend to benefit more from the cloud, but most crucially the ones that need a lot of them but don't need that many all of the time are most likely to benefit.
Cloud often works well at the small end of the scale as well. I have a few bespoke light-use web apps and web services hosted for customers on azure which cost from about 15 bucks a month for a web service, maybe rising to 50 bucks if you need RDB as well.
> I guess you could spin down VMs during the night, or move everything to containers and kubernetes, but that's a really huge pain-in-the-ass,
Why's that a pain in the arse? You use the same technology as the cloud providers, run your own on-prem clouds - OpenStack or whatever - and you get that same effect. I mean, the cloud architecture, K8s, dynamic workloads, micro-services, etc., there's nothing wrong with that. Makes perfect sense (for appropriate workloads) whether it's on someone else's cloud or your own.
> Also, what about patching the OS?
What about it? We patch OSes on thousands of servers automatically as it is now - after testing it to make sure it won't break current production systems.
> Patching firmware and routers?
We already do this on hundreds if not thousands of devices now.
> Negotiating deals with comms providers? Economies of scale?
My organisation has 20k employees, hundreds of millions of customers ranging from individuals to multi-nationals spread literally in every country in the world. We already have economies of scale and negotiate deals with comms providers. It's not that hard to negotiate deals with comms providers, if you have enough data flows that standard business plans don't cut it, then you are probably big enough to deal with that anyway.
> Once you've got a budget approved it could take many months to get all the hardware ordered, racked, provisioned and then get the OS installed and the applications put on top of that. With cloud you can get all that on the same day.
Right, and while you wait for those millions or hundreds of millions of dollars in hardware, you can begin your 2 or 3 year RnD process - and PoCs - in the cloud, and once finshed there move it onto the on-prem hardware. I mean, a project that requires millions of dollars of hardware usually has some RnD lead time - do that in the cloud.
> If your company decides to change direction you can shelve a project after 6 months and just stop paying.
Since the hardware has already been paid for, there isn't any ongoing payment that needs to be stopped. You just stop using the equipment, and shut it down if you want to save electiricity. And I'm sure that hardware can be re-tasked to the other project that was on a 6-month wait (though, as above, they should have been doing their RnD in the cloud while waiting, so shouldn't really have been waiting as they had stuff to go on with anyway and should have placed their orders well before they'd actually need that hardware since) but can now use this hardware instead and cancel the order they had placed for hardware.
> Likewise, if some campaign blows up and works out 10x better than expected, you can fairly easily spin up 10x on cloud.
Absolutely, and working on-prem doesn't preclude this, as if you use on-prem cloud architecture then moving workloads to cloud or back again once the campaign stabilises and you purchase the hardware to bring it on-prem after its temporary cloud residency is (relatively) easy as long as you planned that from the get-go (i.e. don't use cloud services that you don't have on-prem, if you use DB2 on-prem then use your own DB2 licenses in the cloud).
Also, sack your analysts, they aren't worth shit if that happens.
> Which is why it's growing so fast, compared to on-prem.
There are many reasons its gorwing fast, the biggest of which is it's the current C-suite buzzword, and we all know how the C-suite fad cycle works. It's aso great for short-term expenses shifting, so it can be used to make it look like a company is reducing it's IT overhead - thus gaining bonuses for the C-suite - then the C-suite can leave with their bonuses before the monthly Opex of cloud over a period of a few years exceeds what Capex of on-prem would have cost. The exact same reasons these companies who are making $10's billions in profit are panic sacking 10's of thousands of staff so they can look good to their shareholders and earn their bonuses rather than caring about the long-term future of their companies.
Also because it's perfeclty suited to startups and their unknown requirements (because they are startups) and so startups don't have to worry about dealing with physical infrastructure while they are still small - and still working out what the hell they are going to do.
It's great for RnD and PoCs before you commit to spending money on hardware.
IMO cloud is absolutely suited for any business (or other organisation) that doesn't have enough use of IT resources to justify having several full-time hardware/infrastructure IT people, e.g. DBA, network specialist, server iinfrastruture specialist, etc. If you can get by with one of your employees IT-nerd children helping out every now and then, then absolutely cloud is the way to go. And those types of small businesses still make up the most types of businesses.
Once you get to the size where - if it was on-prem - you'd have a dozen of so full-time IT staff to look after it, it's probably getting big enough that bringing it on-prem would probably start to look cheaper than cloud.
The topic not talked about was security.
When something is running on someone else's machine you need to worry about confidentiality of your data. For some orgs/applications this does not matter (much). This needs to be an up-front eyes-open decision after which the other things talked about can be discussed.
.. correct, which is exact reason we did not even bother evaluating anything cloudy, I agree.
Yes, we virtualise eveything and we have it all running on very expensive iron for resilience, but we have tight control over what goes in and out of our DCs and are now also working with upstream network providers to improve response time in case of DDoS attacks for the Internet VPN interfaces, but about the only thing we may consider cloudy things for are multihomed DNS and that's already in the works by our external DNS providers.
We have such a heavy compliance and audit model that the mere idea of letting something be controlled by a third party would be shot down by legal as well as internal culture..
You still need to worry about the confidentiality of your data when it's on prem.
Security is really hard.
Cloud makes it slightly easier, as they handle all of the physical side of things and the patching up to the hypervisor level.
Of course if you've got leaky VMs, that's a pretty big problem, which I've seen happen exactly once (and was patched PDQ)
"Cloud makes it slightly easier, as they handle all of the physical side of things and the patching up to the hypervisor level."
We saw how well that works with OMIGOD and ChaosDB.
https://www.theregister.com/2021/11/12/chaos_db_wiz_azure_cosmos_research_pwnage/
https://www.theregister.com/2021/09/17/microsoft_manual_omigod_fixes/
And these are just two examples of major security lapses by cloud providers.
If you think cloud is any more secure than on-prem then I have some bridges you might wanna buy. Because not only is cloud really any more secure than (properly maintained) on-prem, with cloud you've also given up any control over how secure your underlying environment is. And cloud SLAs are written in a way that cloud providers can't be held responsible for any security lapses.
It's the "(properly maintained)" part that I have an issue with. I've worked at many places where they patch monthly. Ish. Some that are really hot on it. Some that hardly bother.
Cloud providers live or die on security, so I'd like to believe that they are super hot on it. Perhaps I'm naïve? How much is the bridge?
Depends on your workload and what you are running?
I have customers who are running old crap in the cloud. Cloud providers live or die on the security of THEIR hardware and environment - they don't give a shit about the security of whatever crap someone decides to run in their cloud.
Now don't get me wrong - I fully agree that customers should patch regularly and promptly - but the reality is that they don't (despite how many risks are raised, how many meetings are had to emphasize the risks and issues etc etc). There are days I just sit there and shake my head at the insanity I see.
"Cloud providers live or die on security, so I'd like to believe that they are super hot on it."
I'd like to believe that too. I'd also like free drinks. It's fine to want things.
In short, regardless of whether you'd like to believe what cloud sales and marketing people tell you, their motivation is to sell you stuff -- not protect your operations after the sale.
Some of them might very well be "super hot" on security of some of their underlying infrastructure (which you have no access to as a customer) but the security of your cloudy VM's is on your remit, not theirs.
> Problem is, many C-suites think that Cloud is ...
Yes, that's the insidious peril of cloud: it's generally not the technology itself (which can be quite good in situations where it's fit for purpose), it's the perception of cloud capabilities.
And because the cloud vendors know it's usually the executives making big decisions about cloud purchasing (renting?), their marketing efforts reflect that. So what the CEO/CIO/COO believes about The Cloud may not be well grounded in reality. Security, stability, reliability, etc. all comes included "for free", right? And with no staff support required! Big bonuses all around for the boardroom!
To be fair, it's not just cloud vendors -- many IT and tech vendors shifted a while ago to wooing the big wheels instead of the techies and engineers. I'll try to be a bit gracious and say that most executives are too ... busy to have a firm grasp of the technical details that can make or break a proposed solution; but since the company techs don't typically play golf on the same courses as the executives, they aren't consulted on the deal, they merely get told to work it out afterwards, or catch the blame when the solution is found to not be fit for purpose.
The benefits of cloud, for me, is the ability to scale up/down, have better availability than on-prem, being to create new test environments, and have less dependence on other teams in our IT. There are also other cloudy features, such as feature flags and SignalR (with scaling up/down & being load-balanced) that could suit me very well.
Yes, these can be done on-prem, but it took our IT team a good few months to get another test environment up and running. They are busy AF, we are busy AF. Company does not want to hire more people, so cloud might be the way to get around it.
> Yes, these can be done on-prem, but it took our IT team a good few months to get another test environment up and running. They are busy AF, we are busy AF. Company does not want to hire more people, so cloud might be the way to get around it.
Well, yes, but that seems to be a work-around for shitty management, not necessarily a good technical decision...
"One upside of the cloud is that you don’t have to worry about the details of where and what is going on to provide the service you’re paying for."
True while it's running, but you do have to worry about whether it's going to be running this morning, as outages are on the increase. If everything you need for your business is at the other end of a service that's down, you're stuffed.
Seems like that would create more worry about those very things.
Since you're not in direct control anymore all you can do security audit the cloud services regularly and constantly hound your cloud provider upstream when you find them slipping or lagging behind
And then hope that they decide to fix it, in the meantime run mitigation strategies until they do.
And of course there's a possibility of getting in legal trouble for doing a security audit of a cloud provider You Don't own,. But if you don't then your business gets caught with its pants down and lacks the information to build a proper case to embarass them to competence a timely manner.
"If everything you need for your business is at the other end of a service that's down, you're stuffed."
That's true, but that's equally true with an on prem system. Unless the people are there to fix it whenever it breaks, you can have the same situation and it's just as bad. I've experienced this from the maintainer's and the user's sides. I maintain equipment for a charity that doesn't have a full-time person to do it. I have a full-time job as a developer at a different company, so my maintenance usually happens out of hours. When their on prem server (in my defense, not one I set up) failed during working hours, they had problems while they failed to get my attention because I was in meetings and then had to work with my instructions on what to do over the phone because I wasn't able to be there in person. Obviously, a company will probably have more than one part-time volunteer IT admin, but if the admins who know the system are unavailable, it can be broken.
The cloud can also be broken, but the admins are there to get it back up and generally do so quickly. I've used a cloud service that had an outage, and without having to do anything, it was back to normal in a matter of hours. Had we deployed services in multiple regions, we wouldn't have been affected anyway, but this was a test environment. That point is the most important one. If you can't withstand the service failure, you need to have redundant and backup systems, whether it's on the cloud or in the building. Neither one will prevent you having that dependency.
> I maintain equipment for a charity that doesn't have a full-time person to do it.
To me, that's a perfect use-case for cloud. Any organisation that doesn't have enough equipment that would warrant several full-time IT employees if it was on-prem anyway is a good fit for cloud. As long as they understand cloud. e.g. cloud doesn't automatically give you HA, backups, cross-site backups, multi-zone availability, multi-national availability zones. All of those are optional, paid-for extras. As long as they understand that and pay for those extras (backups for example) they are expecting, then go ahead.
> As long as they understand cloud ... doesn't automatically give you [good list of technical features and functions]
Well that's just it, isn't it? Many people (and executives, bosses, etc.) do not understand that. Sometimes due to (willful?) ignorance, but also from cloud sales and marketing pushing their story.
Look, pretty much all vendors spin their wares in the most positive possible light -- that's been true since the first bottles of miracle liquids were peddled from the back of horse-drawn wagons. But cloud has such a far reaching perception as a panacea, it's almost mind boggling.
Maybe it's things like social media making it easier to advertise, and spread perceptions and partial-truths, maybe today's executives and decision makers are less will-informed than their predecessors, I don't know.
It's gratifying to finally see some people and organizations slowing down and even exiting cloud, not so much because "Cloud = Bad", but because it's hopefully a sign that some of those folks are critically analyzing their needs and requirements, the costs of getting them, and evaluating cost vs. buying into hype. With one corollary hopefully being the folks who do adopt cloud as a tool, will do so with open eyes and better understanding.
Very large datasets coupled to highly pipelined compute are vital to AI/ML. They also generate monthly hosting bills you can see from Jupiter.
We ran the numbers a few years ago and came to the conclusion that it would be *five times* cheaper for us to buy a dozen 4U compute nodes and two petabytes of storage - because although the up front numbers were terrifying, the cost of running it in the cloud over the expected lifetime of the equipment would be insane, which we promptly did.
Fast forward to this year and we've grown a lot and need to massively expand our compute and storage, but we've run out of office to put it in. Now, me, I wanted to snaffle a couple of those meeting rooms we don't use any more since everyone's working remotely and have them re-fitted as machine rooms. Unfortunately CapEx has to be paid today, OpEx can be paid tomorrow, and comes out of someone else's budget, so off to the cloud we go...
...on a more serious note that's a genuine benefit of cloud vs on-prem. If you can't afford the couple of hundred grand it will take to purchase and install all that physical infrastructure based on your current operating profits, you can rent it until such times as you can afford it.
Which leads me to thinking about tomorrow. Our business has grown a lot since we made that initial assessment and we're looking at renting a new office that's literally 10x the size of the one we're currently in. It'll be a couple of years before that becomes a reality, what with all the site surveys and fit-out and everything else, so I'm inflating the numbers on the server room fit-out as hard as I can because it's only a matter of time before someone goes "Hey, this cloud compute bill is bonkers! We used to do all that ourselves, can we bring some of this back in house?"
What goes around, it comes around.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
