Ubicloud – open, free and portable cloud
github.com
github.com
Wow, it is exciting to see what we are working on at HN. We only shared it with our professional circle so far, but it seems it found its way to HN .
Happy to answer any questions, but in summary we are building an open cloud, an alternative to existing hyperscalers, because we believe that you shouldn't have to give up power and lock yourself in to be able to have the ease of use of cloud.
You can use the managed version of Ubicloud or you can host it yourself. You can also use any bare metal provider such as Hetzner or OVH (currently we only support Hetzner because... well.. we are just starting , and support for other providers are on the way), thus benefit from their low prices and many available locations.
Unfortunately Ubisoft Cloud wasn't (likely still isn't) anything special; thus there's nothing really to open source
Ubisoft cloud itself is a combination of openstack, a deprecated array of vmware clusters and kubernetes (Named: UKS). When I was there the storage system of these components kept disconnecting because there was a core switch without redundancy. The director of infrastructure for Central IT (GNS) sent a strongly worded email to all the stakeholders stating that we should be implementing failure domains.. when pressed on what failure domains we had he said... "one".
Blows my mind.
Ubisoft IT (GNS) has weird incentives. They chronically underinvest in themselves, offer half-baked and ill-fitting solutions and then wonder why people don't want to use them.
It's peverse because the on-prem stuff Ubisoft has is consistently underinvested in yet we have 7 figure contracts with all three major cloud providers- paying well over 5x what we would have paid if we just invested properly.
Have you considered other licensing options, like BSL?
https://news.ycombinator.com/item?id=36998888
Eventually, we decided to go with more restrictive one as it is easier to make it more permissive without upsetting our users.
> Today, AWS offers about two hundred cloud services. Ultimately, we will implement 10% of the cloud services that make up 80% of that consumption.
> Example workloads and reasons to use Ubicloud today include:
> You have an ephemeral workload like a CI/CD pipeline (we're integrating with GitHub Actions), or you'd like to run compute/memory heavy tests. Our managed cloud is ~3x cheaper than AWS, so you save on costs.
> You want a portable and simple app deployment service like MRSK. We're moving Ubicloud's control plane from Heroku to MRSK; and we want to provide open and portable services for MRSK's dependencies in the process.
> You have bare metal machines sitting somewhere. You'd like to build your own cloud for portability, security, or compliance reasons.
This seems needlessly wordy. Instead you might assume that readers already have expertise or can look up terms themselves and simply list like this:
Currently Available Features
* CI/CD
* MRSK app deployment
* Etc.
Coming soon
* X
* Y
* Z
* Etc.
As for the "as a managed service" part, I believe Open Metal (https://news.ycombinator.com/item?id=35087879 ) is trying to fill in that gap with actual open source software
I cannot speak to the "6 key services in GA form in the next two years" aspiration since I don't know what the other 3 are that you're going after in order to know how impactful they'll be
To my mind, the biggest alteration is who does changes, and why: unless people show a lot (really, a surprising level) of code contribution interest, substantially, Ubicloud staff will make the changes and collect bugs from hosting the software in production. This, alone, is a big departure from how OpenStack has evolved. It was my experience that engineering staff assessing bugs in hosted software they had design responsibility for gave it much of its distinctness. OpenStack's main contributions seems to be consortia in the system integrator space. This distance between operation and design changes makes a big difference in how a project shakes out.
There are some ramifications: one, is that more administratively complex services, like databases, tend to be out of scope for OpenStack, but in-scope for us. Secondly, OpenStack has an interest in broadening the number of mechanisms to support one kind of functionality, to handle varied and complex enterprise installations (that purchase service contracts). We are probably much more cautious about doing this, instead preferring one implementation that covers our target platforms well...and as simply as possible.
Finally, there's era. It's somewhat unavoidable. For example, you would not design a system around IPv6 network underlays in 2010 (OpenStack's formative years), but you might in 2023 (as we did). This simplifies things. You couldn't use SPDK (established 2015, and you might have been brave to rely on it at inception) to have a gentler ramp to implement more advanced block device support and decide: "that's the implementation, unless we replace it totally." Many useful kernel features were developed between 2010 and 2023. Systemd is an obligate dependency of ours, and it has a lot of connections to the more advanced cgroups and namespace feature of Linux...and, brand new in 2010. Bare metal providers were not as advanced in 2010. And so on. Path dependency is inevitable, and we will have a different one, and that will make it a very different device.
So, I haven't written much about what the project "is," but perhaps allowing you to anticipate how it "will be." And why some people found it worth their while to start building it.
We’re not open source but trying to provide managed services for clouds that don’t have them.
I'd really love to hear any feedback you have (does the landing page miss some information you want? missing services you'd like to see?)
[0]: https://nimbusws.com
„ You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.“
it is not "open source"
but it certainly free software
But yeah I find this kind of comments always overly negative, when there’s an organization giving something away.
I have many OVH and Hetzner servers (cloud and dedicated) but not sure I’d find a use for this.
That's what you pay public cloud service providers for, but private clouds are considered to be a thing as well. https://aws.amazon.com/what-is/private-cloud/
Essentially, private cloud is for deep pocket organizations (some Fortune 500, governments, militaries, etc). No one is running a private cloud for a small startup. The closest you'd get to a "private cloud" is a bunch of servers running a kubernetes (or swarm) cluster.
The cloud is just “someone else’s computer”, not “someone else’s commercially available aws compatible api suite of service offerings that is operating against someone else’s computer”
Not really. "Far more" would be extremely dependent on each specific scenario. Managing your own hardware, if you have the skills and upfront capital for it, can be drastically cheaper, especially if you need lots of storage/compute/networking/GPUs.
If setting up a private cloud was as easy as running a couple of scripts making it easily accessible to a small business without a large dedicated IT dept why wouldn’t small businesses not want to save money with that private cloud?
Full disclosure the management plane is not open source but I've already got support for a couple services and am working on some more.
Mind if I reach out? I'd love to get you to kick the tires.
[0]: https://nimbusws.com
It’s hard to grasp what is really part of the package. Is it a control plane? A list of curated services integrated together? An abstraction layer over hetzner? I can’t really tell.
REPL, testing, a few key high quality libraries.
In turn:
The REPL: lets you have unified development and operation. Makes it easy to record and review methodology when taking administrative action.
Testing: both made more necessary by the dynamic typing of Ruby, but more importantly, without disturbing the program under test much you can inject any input, any fault, nearly anywhere. In this way you can accrete invariants guarding against a large class of bugs encountered in production into the test suite, a form of retained learning.
The libraries: Sequel, Roda, Rodauth, part of the Jeremy Evans universe. They're very good by any standard, not even as confined to the Ruby world. The maintenance level on those is something I aspire to, but have never been able to duplicate. I did copy the 100% line (and later, branch) coverage project practice from this, though, in Citus Cloud and later projects, and it seems like a good thing, though not for the reasons people might anticipate.
An anti-requirement: control planes often have fairly lax performance needs relative to operation value. A few crucial loops, like monitoring, may indicate something with more efficient machine code. But mostly it's a fancy SSH client with quite a few tests, and some carefully designed concurrency patterns. Of the above factors, I'd say the REPL is the most dispositive for why I tolerate the performance and parallelism ramifications of Ruby, though, they all add something to my decision to use it for this.
This design theory is the fourth in a progression for me, though there are other clades by now. Heroku Postgres was the first, Citus Cloud was the second, Crunchy Bridge is the third, this is the fourth.
There are some exceptions, but they're few.
That's good, but it's also table stakes. Drb (in the standard library) lets you remote access any Ruby object, so if you want a remote REPL, it's is simply a case of injecting a Drb server. Hence e.g. pry-remote which remotes the Pry REPL, but you can also then remote any already existing object in any running application.
Erlang, from day 1, was designed to be logged in to remotely. No other system is remotely close to the sophistication that Erlang (and as a result elixir) has in this regard
1. it's not compiled and evaluated at runtime, which make it harder to test. Pesky undefined variables in edge case code.. 2. deployment is tough when it's a ton of small files. Most things compile to a single executable binary 3. it's not concurrent or parallel easily. You're not going to easily use all your cores and also develop sane software.
Difficulties using all your cores with Ruby was a problem when I first started using it 18 years ago. It hasn't really been a problem for things like web serving for the last ~15 or so.
For example, Github, Shopify, and Hulu were written with Ruby on Rails and they seem to do alright.
Some of the work on Ruby and Rails that Shopify and Github have produced is available to the community as well.
For instance: https://github.blog/2022-08-25-introducing-trilogy-a-new-dat...
Facebook heavily use, or did use, PHP dont they?
IIRC the Threads backend is Python as well. Which seems to be doing OK!
> Public cloud providers like AWS, Azure, and Google Cloud made life easier for start-ups and enterprises. But they are closed source, have you rent computers at a huge premium, and lock you in. Ubicloud offers an open alternative, reduces your costs, and returns control of your infrastructure back to you. All without sacrificing the cloud's convenience.
especially when you say:
> Ubicloud is in public alpha. You can provide us your feedback, get help, or ask us to support your network environment in the Community Forum.
while I agree self-hosting at a philosophical level, please note that there are lots of good reasons to use public providers.
1. Writing a lot of code that runs in the kernel, which is too expensive to be viable, in my estimation.
2. Combining existing kernel features together and living without making medium-sized adjustment for quite a while This was actually my back-up proposal if our experience with SPDK was bad. e.g., get deep into lvmthin and importing/exporting snapshots, but not having a graceful way to add, say, demand paging from an external data store. At some point we'd have to exercise option #1 or jack-knife to something more-like SPDK, which inevitably would be something of a discontinuity in our experience level and the customer experience of the product. I decided we could try to avoid jack-knifing and try to have continuity on SPDK.
3. Paying for extra context switches from user space to kernel space to user space again, at least once, and, sometimes, even additional times, if you need to add a bit of functionality and then use some mature kernel routines. A series of sandwiches.
The polling is wasteful if the server is not doing much, and not bad at all if there's a lot of I/O going on. We'll probably enable and get into tweaking adaptive hybrid polling option in SPDK to quiet things down on machines not running full-bore I/O.
SPDK has a lot in there, getting the logical volume and encryption features, as well as the plumbing for vfio-user, is significant. There are not many options that have this programming, and a programming model to add more. I also found the code and changes to it fairly readable, and the size of the code, e.g. in lvol, approachable.
The incredibly low level of latency and high levels of iops preclude having it be based on software interrupts, I think even in scenarios where sr-iov is available to the hyper visor.
This is how the usual suspects get past software interrupts adjacent to the VMM, on the "client" side of things. Getting the driver stack integrated into Linux is no small task and letting it percolate into distributions in common use is necessarily a slow process. SPDK permits getting decent performance and gradual deepening of our functionality while still relying on virtio, which has already percolated.
As I understand it, on the storage side, these cards tend to expose an NVMe interface which is somewhat generic, so you don't see the same kind of driver siloing there. There's a related bit of SPDK and hypervisor functionality, vfio-user (vs vhost-user), but we elected not to use it at this time. They both use a similar shared-memory transport.
Azure is an interesting outlier, a large one, in that their reliance on Mellanox (a subsidiary of nvidia) drivers is documented, so they could be considered in a partnership to achieve the same aim. So you could read the mlx drivers in the same fashion as ena and gve.
I've been watching the technology "vdpa" with some interest to have a shot to also provide pass-through PCIe devices to the guest that do not add such a driver dependency so far outside our ability to influence: Microsoft is going to have a bit more equal a relationship with nvidia than we would as it comes to problematic changes in the Mellanox drivers. But I suspect it'll be some years before that can possibly happen, if it happens at all. It's not easy to get a Connect-X 6 DX card, for example. So, there are many problems for the foreseeable future trying to get into hardware, though I'd like to avoid precluding it.
I liked this blog post in getting a feel for this, but in brief, they're computers plugged into computers: https://www.servethehome.com/zfs-without-a-server-using-the-.... Our alternative is to carve off a core or two instead of plugging a computer into the computer.
Maybe at some future time...I suspect, no sooner than five years from now, but probably, should it come to pass, quite a bit later...there will be some commonality and availability in such PCIe cards and Ubicloud or something like it could consider a tangible development theory around them.
We use Postmark to send emails and we apparently ran out of our monthly email limit after hitting HN. We just upgraded our plan; and this should now work. If it doesn't, please feel to directly ping us at support @ ubicloud.com.
So... not open source?
But here, all is right, I don't see where anyone could base any complaint. Except for being entitled to instruct others about the license they should use for their own work, that is. I'd say they are walking the line with insisting on how "open" this solution is, but it doesn't really cross any line.
They are missing a very strong 4th line in "How is this different than OpenStack?" [1], though: OpenStack is Apache 2.0, aka. proper OSS, thus you can use or host it in whatever way you want, even use it to create an IaaS if you wanted. With UbiCloud, I didn't read the license, but probably not.
[1]: https://github.com/ubicloud/ubicloud#how-is-this-different-t...
EDIT: turns out they say "open source" not in the linked github repo, but in the project's homepage. Back to square one then: they are lying.
Indeed, just back to being another case of falsely claiming to provide the freedoms of usage that Open Source would actually grant but they don't.
Should be a very quick fix, though. It isn't called open source all across, but only mistakenly in a couple of places.
For clarification, we weren't planning to launch until we had a proper looking website. Yesterday, I shared our GitHub repo on LinkedIn to get feedback from friends. Then, we saw this on HN - and realized that we haven't looked at our website in quite a while.
We're also trying to formulate a better point of view on the license and its implications. We Ask HN'ed several days ago, but there wasn't much input: https://news.ycombinator.com/item?id=36998888
In the end, we picked a more restrictive license. An important reason for that is, we feel that we can move from a restrictive to a more liberal license easily. Doing the inverse would feel like not doing the right thing by our users.
OSS flies faster because people love the ability to use and reuse source code. But not everything must be OSS especially if the source code itself must be the source of income (thinking here of a mantra that's been repeated in HN several times, and which is very correct IMO: "Open Source is not a business model")
And yes you're right that it's better to go from restricted to open. The opposite direction has always been received with harsh criticism. Also you open yourself to the risk of a community forming around forking the project from the last commit that was OSS, and departing with their own thing form there. Unlikely, but technically possible.
> You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
> You may not provide the software to third parties as a hosted or managed service
What exactly is a third party?
Does this prohibit one department/team from managing it and offering it as a service to other departments/teams in the same company? Does it prohibit using it in a homelab I share with my friends and family?
> Any use of the licensor’s trademarks is subject to applicable law.
IANAL, but if any of the protected parts of the code use trademarks, which seems pretty likely, wouldn't any forks risk trademark infringement?
It is fair criticism. We don't claim to be "open source" rather we are open and free as in you can see the code and host it yourself if you want. The primary restriction is that license does not allow building a managed service out of it.
BTW, we don't have any license key, so that part of the Elastic License wouldn't apply. It is there, because we wanted to use a known license that fits the bill instead of creating our own obscure license.
At top: "An open source cloud that can run anywhere."
Near bottom: "Open-source or managed for you"
Image at bottom: https://unicorn-cdn.b-cdn.net/0c2bf736-3f08-4b11-a500-57e4e7...
At least Openstack doesn't lie about its complexity.
> Truly sorry that we missed these instances of "open-source" references. We scrubbed the use of open-source in most places, but forgot about our home page, which might sound weird as the home page is... well... home page. The truth is that our web site is not our primary focus at the moment. Rather we are putting almost all our effort for building the product (You can watch all of it in GitHub)
1. did that intentionally, intending to trick people into thinking UbiCloud is FOSS
2. did it unintentionally, somehow missing the obvious connection that people are going to make
either way, its a bad look. this is a solved problem, you can use the correct term for the situation:
> ... An open source cloud that can run anywhere.
> ... Open-source or managed for you. Available on GitHub under the Elastic v2 license.
Taken from here: https://ubicloud.com/
Truly sorry that we missed these instances of "open-source" references. We scrubbed the use of open-source in most places, but forgot about our home page, which might sound weird as the home page is... well... home page. The truth is that our web site is not our primary focus at the moment. Rather we are putting almost all our effort for building the product (You can watch all of it in GitHub).
We don't claim to be "open source" rather we are open and free as in you can see the code and host it yourself if you want. The restriction is that license does not allow building a managed service out of it.
Am I the only one getting a certificate error browsing there?