It appears to be an all in one, preconfigured/partially-or-completely assembled rack server for on-prem hosting, complete with pre-configured software.
Just my perception given the front page. I agree it's a bit vague.
Every "cloud" computer is on-prem for someone, and "private cloud" has been a term for at least a decade to refer to "API-based provisioning of resources like with a cloud but in your own data centre/office" that may not be "technically" a cloud but carries the meaning clearly for anyone in the business.
What they're selling is building blocks for private/hybrid/public clusters that may or may not fit your definition of cloud depending on where they happen to be located but where what the term signifies is that it is built to be a building block of a cloud setup that includes features above and beyond a "regular" server to provide what most people tend to associate with a cloud. That is, you're getting APIs to spawn virtualized compute and storage, rather than having to install a hypervisor and management APIs etc. and combine the resources into a cohesive whole yourself.
My guess is that most of them will end up being sold to either hosting providers to provide cloud services to their customers or companies large enough to operate their own data centres where the IT department will use them to offer cloud services to other parts of the business, where the term really is not misleading anyone.
It's too big even for most "private clouds" in smaller companies, because they tend to be too small to be able to order by the rack even when there are APIs etc. offered to developers to provision compute and storage (e.g. years ago I used to operate a hybrid cloud setup with a ~1000 or so VM instances across several countries, and while we had several racks worth of gear we physically owned in aggregate, we didn't have any full racks in any individual location).
Absolutely. The point of cloud computing is that I don't have to care where something is running and that I (theoretically) have infinite elasticity and can scale in and out as fast and much as I need to.
This server is for cloud operators - i.e. for organizations that are building their own cloud infrastructure. That's why Oxide is drawing comparisons to hyperscalers.
"Private cloud" has been a term for at least a decade to refer to situations where people are building their own cloud infrastructure to provide a "cloud feature set" even though the servers are self hosted.
You may not like it, but it's been a long time since "cloud" has exclusively referred to "someone in another organisation entirely runs the computers" as opposed to virtualised allocation of resources.
"Private cloud" as a term still kinda makes me itch, but I don't recall encountering an alternative that was more obvious and it's clearly the usual term of art at this point.
I suspect that while I do appreciate how some posters upthread find the website a tad on the vague side, the target customers-in-potentia will understand it fine.
There are many “you”s in most enterprises. If your platform engineering team builds their own cloud, and offers an experience similar to other cloud providers (or even better and more targeted), this could be a clear win.
I understand that’s your definition and I’m saying that there are many companies where the cloud experience (of not worrying about physical infrastructure but having flexibility and elasticity) is offered to product teams by an internal platform team. That gives you an articulation point where you could migrate from AWS to Oxide racks, and yes, lose some functionality and some guarantees, but also gain more control and potentially make huge savings.
Actually, the definition of cloud is "a visible mass of particles of condensed vapor (such as water or ice) suspended in the atmosphere of a planet (such as the earth) or moon".
Nonsense. The operative bit of "cloud" is "provision and de-provision instantly via an API, without much concern for what's going on inderneath", not "lives in someone else's datacenter".
But that is literally not possible with hardware you purchase yourself.
Sure, you can buy X amount of hardware, and provision up to X amount of virtual hardware via an API, but then what? You can't provision any more until you go and buy more hardware. This is why "cloud, but local" is a contradiction IMO. You can only be "cloud-like" if you're under-provisioning. The moment you want to actually use all of the capacity you already paid for, you're not a cloud any more, because you've provisioned all of it.
> But that is literally not possible with hardware you purchase yourself.
Sure it is. I think TFA is talking about a company selling you exactly that capability.
> You can't provision any more until you go and buy more hardware.
But this is also true of AWS etc. When their estate gets full, they need to go buy more hardware. Regardless of who owns the tin, someone's doing a capacity plan and buying hardware to meet demand.
The point of 'cloud' is that you move that function out of the domain who are actually using resources to solve business problems, which is where it traditionally sat. Historically, if you wanted to run a service, you had to go buy some hardware and hire someone to manage it for you.
A cloud-like model means that the application engineers no longer care about servers, disks and switches. Instead, they just use some APIs to request some resources and then deploy a workload onto them. The details of what hardware, where and how is fuzzy and abstracted. Or cloud-like.
> You can only be "cloud-like" if you're under-provisioning
Everyone under-provisions. Nobody runs at 100% utilisation.
It’s called cloud because it’s not in your own data center. Usually cloud symbols were used in network diagrams to depict systems/networks outside of our concern.
Also you could don’t really get elasticity with a system like this. If anything, that would be the operative bit for me.
With apologies to everyone who has a "The cloud is someone else's computer" T-shirt, things have changed, and the language as evolved as it is wont to do.
I've spent the last decade building on-premises systems very like what Oxide is doing, but I've had to build them out of stacks of servers, switches, storage appliances and VMWare licenses. And the network cabling, and fan noise, and the number of power cables, and.. oh man, I can't wait to install one of these things myself. Having a single point of responsibility for the whole thing shouldn't be underestimated either - I've spent far too long trying to resolve problems with vendors on both sides blaming each other.
It's worth mentioning too that building something equivalent to this would be across more than one rack, and easily cost in excess of $1M.
That was the case ~15+ years ago. Private cloud has been a term for the majority of that time to evoke the elasticity and virtualisation without the "not in your own data center" bit, because to most users of a cloud the operative bit is that they don't have to worry about where the computer is or talk to someone to provision one, not whether it sits in the corporate data centre or off at Amazon.
Hybrid clouds even means devs might not know whether it sits in the corporate data centre or a public cloud, because it could be either/or depending on current capacity.
> Also you could don’t really get elasticity with a system like this. If anything, that would be the operative bit for me.
"You" as in "the organisation as a whole" don't get elasticity. "You" as in "your department" or "you as an individual" do get elasticity.
> "You" as in "the organisation as a whole" don't get elasticity. "You" as in "your department" or "you as an individual" do get elasticity.
Right, but to the degree that you get elasticity, it starts to look more and more like "someone else's computer", no? If multiple people/departments/etc are provisioning virtual instances on one shared cloud infra, with nobody who's using the provisioning API caring about the underlying capacity (and capacity is planned indirectly by forecasting, etc), then it really starts to sound like "someone else's computer" to me. That "someone else" just happens to be another org within the same company.
> It’s called cloud because it’s not in your own data center. Usually cloud symbols were used in network diagrams to depict systems/networks outside of our concern.
That might be true historically, because the only way you could get resources provisioned on-demand via an API from someone else who'd built it. You had to run in someone else's datacenter to get the capability which you actually wanted.
Times have changed. Now, businesses think about "Cloud compute" as being synonymous with "on-demand", "elastic" etc. Where the actual silicon lives is merely an after-thought.
> Also you could don’t really get elasticity with a system like this. If anything, that would be the operative bit for me.
> Where the actual silicon lives is merely an after-thought.
If you have to buy the silicon and plan capacity for it (as in the case with Oxide for example), then it cannot be an afterthought. Which is exactly why I would not consider it cloud computing.
The point is the application team doesn't have to do any of that.
Someone's always got to buy the tin and manage that. Some people are big enough that they might get a benefit from doing that themselves, rather than having Jeff Bezos do it for them.
From the application team's perspective, call API then container go whirr.
> you could don’t really get elasticity with a system like this
Of course you do, right up until the point where you’ve used all available capacity. Just like with public clouds (ask anyone using meaningful amounts of {G,T}PUs). Elasticity doesn’t imply infinitely elastic, that would be ridiculous.
> Absolutely. The point of cloud computing is that I don't have to care where something is running and that I (theoretically) have infinite elasticity and can scale in and out as fast and much as I need to.
Define "I"?
I-as-developer can call an VMware/OpenStack API with an on-prem/private cloud and get a new instance just as easily as calling an AWS API. I-as-developer does not have to worry about elasticity if the IT hardware folks have the capacity.
As an engineer, an Oxide system works like any other cloud provider. You’re just interacting with its API and tooling like you would with Google Cloud or AWS.
To someone on the IT/Operations side, obviously there are differences but theres SIGNIFICANTLY less labor required to build-out and operate an Oxide system vs a rack full of servers. The biggest difference for these people is that there’s actual hardware vs a Cloud Provider, but also costs are fixed so there’s likely no monthly or quarterly meetings with finance arguing over the cloud bill, tying people up to try and shave a few thousand off the bill every month.
In finance/accounting, Oxide is probably the most different: now compute is CapEx rather than OpEx. Depending on your company’s stage that can be a wonderful thing for the bean counters.
> To someone on the IT/Operations side, obviously there are differences but theres SIGNIFICANTLY less labor required to build-out and operate an Oxide system vs a rack full of servers.
But it’s also gonna be much more restricted. So I guess one could see as kind of “Apple for data centers”? Have a nice appliance and be happy as long as it runs as it should (but hope it never stops working as it should).
Just my perception given the front page. I agree it's a bit vague.