5 ms·
Why companies still want in-house data centres
- baz00 3y agoI still want an in house datacentre. Our move to cloud has a 5x cost increase. We need more staff to run it as well (!).
- dathinab 3y agoah yes -- you need less people -- is probably the biggest lie of modern cloud through technically it should be that way so I would argue the current cloud infrastructure is seriously messed up
- nikau 3y agoWith cloud you can have less staff, but you need to pay more per headcount as they need to know how to manage tens if not hundreds of different services. Traditional on-prem has silos where the DBA just knows databases and their salary is capped because of that. I guess in theory you could have a "cloud DBA", but in my experience every business unit wants to keep autonomy over their cloud account/project and do it all in house to get rid of the delays that occur with centralized resources.
- dathinab 3y ago> With cloud you can have less staff, but you need to pay more per headcount I would disagree in my experience this isn't the case at all through having less more experienced (and in turn well payed) personal is always a thing no matter weather you speak about on-prem or cloud and there really is no reason you need to do on-primise like the siloed "Traditional on-prem" as you describe. I would even say that especially for smaller companies they stopped doing on-prem that way even before the cloud became widely relevant. I mean it's just not feasible and there really isn't a fundamental reason why you have to silo yourself in that way just because you are on-prem.
- ipython 3y agohttp://archive.today/hrC9Z http://archive.today/hrC9Z
- deleted 3y ago[deleted]
- pm2222 3y agoSimply put: it makes sense. When you are big enough, why not?
- adaml_623 3y agoThat article is a bit of a mishmash of factors, pros, cons, and trends
- Nextgrid 3y agoIf the cloud was truly cost-effective then AWS and its competitors wouldn't be the cash cows that they are.
- andrewstuart2 3y agoThis is partly true. The reason AWS et al ever grew in the first place was also that managing data centers well and automatically used to be a lot harder, and was assumed to be a whole org's full-time mostly manual job. AWS, Google, et al showed how well this could be done with software, showed the benefits of making it easier to do even for app engineers, and incentives shifted. Tools have significantly improved, though, and we're getting back to the point where it can be done with OSS and a team or three of engineers who really know the stacks involved.
- Nextgrid 3y agoIn my opinion, the promised "simplicity" of the cloud never materialized. You've replaced physical hardware that's easy to reason about with opaque, unpleasant and eventually-consistent APIs along unnecessary complexity (VPCs, etc) only designed to vendor-lock you even more into the provider. The staff savings never materialized - every company I've been involved with had at least one "DevOps" engineer, but instead of fighting with hardware he's constantly messing with YAML/Terraform/CDK files.
- politelemon 3y agoThe alternative isn't that different however. A company running its own centre may choose to go OpenStack/k8s. It still requires lots of messing about with awful files. The 'cost' then shifts elsewhere, and merely satisfies bean counters. IMO the simplicity promised does exist, it's up to the company how it gets implemented. Like either toolstack, if it's misused, it will cost more than they thought (and then they'll blame the toolstack)
- SoftTalker 3y agoI've tried several times and never got an on-prem k8s working. I use proxmox now and never looked back.
- renewiltord 3y agoCan’t get high utilization modern cpu on cloud for cheap. Ryzen 7950x single core very fast and very cheap.
- trillic 3y agoYou want a consumer desktop chip in your server? Consider the I/O.
- Nextgrid 3y agoIf he can buy 2 (or more) consumer-grade chips for the price of one enterprise-grade one and split his workload across them then it still makes more sense to go for the consumer version. Consumer hardware gets undeserved bad rap despite being a good fit for many of today's "cloud-native" and fault-tolerant workloads. Don't run critical infra on it that can't be fault tolerant (conventional RDBMS), but for your cluster of queue workers? Go right ahead since the queue is designed to handle failure of any nodes gracefully.
- jrockway 3y agoI think it's a great choice for a lot of workloads, especially CI.
- renewiltord 3y agoSome places performance/price matters most. Some places raw performance. 7950x outperforms cloud processor and cheap. But use Epyc in other places. Just empirical optimum.
- technofiend 3y agoI literally built billions of dollars of equipment for my employer deploying new datacenters. Even with a mandate to pivot to cloud-first, that kind of investment still needs to be used. And predictably after suffering enough pain from cloud-preferred thinking, we're settling on a mix, in no small part due to both monetary and migration cost.
- candiddevmike 3y agoAre you doing show/charge back for both on premise and cloud? Do different teams manage each environment?
- technofiend 3y ago>Are you doing show/charge back for both on premise and cloud? Yes, you're billed in either case. But it's the difference between blue and green dollars: money that exits the firm is much more strictly budgeted. > Do different teams manage each environment? Sort of. Knowing how to deploy to AWS vs an internally-hosted kube farm vs managing a fleet of virtual machines are all different skills, not that you can't learn them all. At one time our org structure split those functions but now if you go far up enough the management chain is the same.
- dathinab 3y ago> deploy to AWS vs an internally-hosted kube This is IMHO one of the absurdities of current could technology. We have the technology and know-how to not make this different skills, to make it mostly uniform and abstract away all the compute hosting specific parts in the same way that compilers mostly abstract away most ISA/hardware details (at least for most languages and many use-cases, not all)
- technofiend 3y agoI was disappointed (not that I'm picking on them) to learn Hashicorp's terraform didn't do exactly the sort of abstraction you're talking about. You can cobble together layers of automation, but I share your disappointment that there's not a single solution. Although I will say rackn's digital rebar gets a lot of the way there. You can deploy workloads in a pretty technology-agnostic fashion for the things it does support, and it can be integrated/extended with ansible, terraform and other scripting tools (including plain old bash) or other languages as needed.
- xyst 3y agoarchive.org - https://web.archive.org/web/20231005135420/https://www.economist.com/business/2023/10/05/why-companies-still-want-in-house-data-centres https://web.archive.org/web/20231005135420/https://www.econo...
- hoofhearted 3y agoThe author of the article makes a claim about using 5g technology to send the data to the DC; which would mean that it can’t be far away. Author clearly does not understand wireless networking. Ubiquiti sells consumer grade wireless dishes that beams a signal between two dishes point-to-point at distances of a mile with speeds of 250mpbs or greater. I remember when they released there newest dish a few years ago and one of the IT YouTubers did a test of setting up the dish on a basic lan on two different college campus that were miles across town from each other. It was v1 of the dish, and he got near 1gbps file transfer speeds between the two dishes without much setup or tuning.
- dboreham 3y agoSuspect the author is way more confused than that. The 5G distance comment, if it means anything, presumably refers to the distance between the "field-deployed" servers and the 5G tower. That does have to be quite close typically. But the mention of 5G is probably paid content because as you note, anyone with a real purpose would just deploy a fixed wireless p2p link themselves.
- hoofhearted 3y agoIt’s not really a 5G tower.. It literally looks like a Wireless Access Point, and can double as one sometimes. You plug a network cable into a power supply for dedicated power over POE, and another network cable into your LAN. On the other side where you other dish is, you do the exact same. Plug the network cable into a LAN, and boom you will magically have the devices on both sides on the same network. The dishes just have to a clear line of sight, and you can get some insane distances. There is a community mesh WiFi network in New York City that uses these exact ubiquiti dishes to beam wireless high speed trunks across the water to the different burrows; and to uptown. For just $800, you can set up a pair of air fiber dishes, and be able to beam a 2gbps trunk up to 7 miles away. https://store.ui.com/us/en/pro/category/all-60ghz-wireless/products/airfiber-60-lr https://store.ui.com/us/en/pro/category/all-60ghz-wireless/p... A few years ago, we moved to a larger space down the street; but Verizon couldn’t get fiber installed in time of our move out date of our existing location. We set up dishes on each building as they had line of sight fortunately. We ran a VOIP network over it for a month without any hiccups. Even in the worst storms, we didn’t see any speed slow downs or packet loss. It was very impressive.
- Pannoniae 3y agoThe wording is certainly interesting. This article is written as if cloud was a holy grail, with companies still being stuck in the stone-age era of.... owning servers. They also pretend that the cloud is the future for everything, and that on-premise servers are legacy technology. The following paragraph is the most illuminating: "The decision to build or rent may depend on a user’s data intensity. Consider a firm in America with a medium-sized data centre which thinks its computing load will rise roughly four-fold over a decade. In that case, building its own breaks even in seven years or so, and ends up being 5% cheaper overall than leasing, according to data from Schneider Electric. If the load remains stable, renting is the less expensive option, by a similar amount (assuming a flat cost of capital)." This assumes that cloud costs are stagnant and reliable. This is a very naive assumption - it can be seen that if the cloud providers think they can get away with cost increases, they will. On-premises works out cheaper in the majority of cases, even including the cost of a sysadmin team.
- VirusNewbie 3y agoI’ve never worked at a small company when on-prem is cheaper, because having to provision for peak load is not cost effective.
- jeremyjh 3y agoA lot of small companies have very stable workloads for years. Unless you meant startups?
- johnklos 3y agoThat's a sales line. Or do you work exclusively for small companies that are selling high demand online services that're trying really hard to go viral? The only other time I can imagine is if a company isn't going to exist in six months, such as movie productions, or companies that have so little going on that they don't need more than a $10 a month plan. Otherwise, on premises or colocation are invariably cheaper when there's any kind of real usage.
- VirusNewbie 3y ago
- dathinab 3y agoIt's paywalled but... if someone says it's "unlikely" it either is a stylistic method to goat people or they don't understand much about the technology, because there is nothing unlikely about it
- nologic01 3y ago> The decision to build or rent may depend on a user’s data intensity. Think of brick-and-mortars real estate (e.g. office space) which for most companies is completely outside their core value proposition hence they would be most inclined to lease. Accurate statistics are surprisingly non-trivial to find but it seems like the company owned segment is circa 20% (versus 80% leasing their office space needs). Now when you think of the role data centers play in a growing digital economy, for many companies increasingly their value proposition is linked to their digital infrastructure. So that would push the fraction of "owned" versus "leased" substantially higher. This would leave still a eye-wateringly massive amount to be served by "hyperscalers". This is really what the "cloud revolution" (renting somebody elses linux server) is mostly about. There is a certain naturalness to this state of affairs. But there is the major catch. Imagine if practially all the real estate in the world is owned by just a handful of mega-corps and anybody needing office space needs to rent from them. Companies small and large will quickly realize what the term "rent-seeking" [1] means... when the seller holds all the cards and the buyer holds none. Rationally a hyperscaler oligopoly would attempt to keep the price of digital infrastructure at just below the ownership cost, though greed and various frictions in migrating back to in-house might temporarily allow milking higher rents. In any case its a most interesting parameter to observe in these rapidly changing times [1] https://en.wikipedia.org/wiki/Rent-seeking https://en.wikipedia.org/wiki/Rent-seeking
- jeffbee 3y agoThe main reason is a whole generation of IT executives who don’t want to look superfluous.
- johnklos 3y agoPeople say cloud is cheaper, but that's based on horrible assumptions such as the idea that companies don't have staff that know how to maintain a server, so cloud costs have to be compared with in-house plus the salary of a systems administrator. People forget that services in the cloud require technical know how, and that the lack of technical know how can easily result in wildly insane cloud bills. Really, though, any heavily used service will always cost more in the cloud. Transfer? Sure, bringing Internet to your location might cost an arm and a leg, but it's trivial to find colocation with transfer that's significantly cheaper than anything cloud. CPU? Definitely. Ancient Xeon cores are a dime a dozen, but they don't compare to even an inexpensive last generation Ryzen. Storage? Absolutely, and the price differences are absolutely ridiculous. Even GPU workloads are cheaper if you have to run them for more than a handful of months. "But you can scale in the cloud!" Right. You can scale in real life, too, AND you can scale in real life WITH the cloud, if you want, so that's a silly thing to say. It's not one or the other, exclusively. I have yet to find a single example of a company that isn't doing really silly things saving money by moving to the cloud.
- nullindividual 3y agoYou left out all of the other costs of running a datacenter. Cooling, fire suppression, electricity, DR site, etc.
- johnklos 3y agoNo, I didn't leave them out. They're just not a significant factor because those costs are proportional to need and demand. A company is either large enough to have enough that those things are aggregated across tons of servers, or they're likely colocating. Also, datacenters don't require all of that to be datacenters.
- nullindividual 3y agoYou did leave them out because most people _want_ electricity in their datacenter, or have DR, etc. These aren't free. And colocation is not free -- you pay for all of those things on top of the hardware you have to plan for peak cycles on. Nor what you were talking about in the OP, hence ignoring colo. Please don't move goal posts. This is HN, not reddit.
- sgt101 3y agoOn prem requires a capital investment and a cast iron workload prediction. If you have a stable business this works. But you may still want to go to cloud if IT is not your business. An on prem infrastructure requires capital and capital can be used to change your core business, which could bring you sufficient bottom line to make cloud costs irrelevant. If you are trying for growth then a cloud infrastructure enables that.
- sgt101 3y agoBusiness isn't just about managing costs.
- autoexec 3y agoAre data privacy and security really nowhere in the list of considerations? I find it hard to believe that cloud providers aren't mining data and pulling every possible metric they can from usage. AWS alone has been responsible* for countless breeches and data leaks. Wanting to keep your data out of the hands of third parties for the protection of your own data or that of your users seems like it ought to be a factor in there somewhere when deciding to keep your data in house. * You can argue that it's mostly been the customers who fail to configure the service correctly at fault, and you wouldn't be wrong, but any time that many people are "doing it wrong" the problem isn't just them, its the service they're using (bad defaults, hidden footguns, unclear documentation, etc).
- batshibstein 3y agoIt's not solely a total cost decision but it's also OpEx vs. CapEx, what can be depreciated based on that, etc.