Today we are announcing the general availability of the world’s first
commercial cloud computer — along with
our $44M Series A financing.

From the outset at Oxide, and as I outlined in
my 2020 Stanford talk,
we have had three core beliefs as a company:

Of these beliefs, the first is not at all controversial: the agility,
flexibility, and scalability of cloud computing have been indisputably
essential for many of the services that we depend on in the modern economy.

The degree that the second belief is controversial, however, depends on who you
are: for those that are already running on premises due to security,
regulatory, economic, or latency reasons, it is self-evident that computers
should be able to be purchased and not merely rented. But to others, this has
been more of a revelation — and since we started Oxide, we have found more and
more people realize that the rental-only model for the cloud is not
sustainable. Friends love to tag us on links to
VC thinkpieces,
CTO rants, or
analyst reports on
industry trends — and we love people thinking of us, of course (even when
being tagged for the dozenth time!) — but the only surprise is how surprising
it continues to be for some folks.

The third belief — that the development of a cloud computer necessitates
rack-scale design of both hardware and software — may seem iconoclastic to
those who think only in terms of software, but it is in fact not controversial
among technologists: as computing pioneer Alan Kay famously observed, “people
who are really serious about software should make their own hardware.” This is
especially true in cloud computing, where the large public cloud companies
have long ago come to the conclusion that they needed to be designing their
own holistic systems. But if this isn’t controversial, why hasn’t there been
a cloud computer before Oxide’s? First, because it’s big: to meaningfully
build a cloud computer, one must break out of the shackles of the 1U or 2U
server, and really think about the rack as the unit of design. Second,
it hasn’t been done because it’s hard: co-designing hardware and
software that spans compute, networking, and storage requires building an
extraordinary team across disparate disciplines, coupling deep expertise with
a strong sense of versatility, teamwork, and empathy. And the team isn’t
enough by itself: it also needs courage, resilience, and (especially) time.

So the biggest question when we set out was not “is the market there?” or “is
this the right way to do it?”, but rather could we pull this off?

We have ind