Ubicloud – open, free and portable cloud(github.com)
github.com
Ubicloud – open, free and portable cloud
https://github.com/ubicloud/ubicloud
102 comments
I work for Ubisoft and I initially thought we published our internal cloud platform which is named "Ubisoft Cloud".
I used to work for Ubisoft; thought the same thing when reading the name.
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.
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.
Congrats on the (soft-)launch!
Have you considered other licensing options, like BSL?
Have you considered other licensing options, like BSL?
Thanks. Indeed we did. Actually we asked HN crowd about this few days ago to get some input.
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.
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.
I think you could improve this section of the Readme to make this more accessible:
> 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.
> 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.
Thanks for the feedback. We iterated few times on our README already and we will iterate on it many more times. These will definitely come in handy.
https://github.com/ubicloud/ubicloud#how-is-this-different-t... was my immediate question, although they left off "and the license is different" but I guess that's implied
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
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
Thanks, came here for this question (difference from OpenStack).
I work on it. Quite a few differences. Different business theory, different development theory...and, unavoidably, different era, all which change the likely "feel" of the project as it matures.
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.
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.
I’m also doing something similar with Nimbus[0]!
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
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
I wanted to offer that I'm not the one downvoting you (I actually cannot, in the HN setup) but I wanted to bring to your attention that you are squatting on someone else's pseudo-Show-HN instead of having your own Show HN which can carry its own discussion, along with the feedback you were after. And you should brace yourself for some feedback, because your site, its messaging, and your product are ... well, just brace yourself
It’s not open source, AFAICS? It is under the Elastic License, which is not an open source license as it limits use?
„ 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.“
„ 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.“
This is what happens when teams/companies dont know AGPL-3.0 - it would solve this issue almost entirely. Anyone building a competing product that is better would have to agree to publish their improvements.
Even with if the third party provider makes no improvements, they can still provide it cheaper because ubicloud pays the development costs? This is a business threat that would not be mitigated by AGPL-3.0?
But if they develop it and are the only ones developing it (because the rest are freeloaders by definition, since they make no improvement) then they would have the better knowledge of the product and could provide the better support, that should grant the more juicy clients.
Evaluating the quality of support at the purchasing stage could be downright impossible. If you see two products that look the same (and you haven't used them yet so can't see the difference, if any), and one is 30% cheaper, many would pick the cheaper version.
Let's assume, Hetzner or OVH themself would just take Ubicloud and offer this as a service without paying any money to Ubicloud. In this case, many customers would just use the Hetzner/OVH offer (everything from the same vendor = more convenient) and Ubicloud has no way to make money. The AGPL license would not prevent IaaS providers from doing so. I think it's not easy to build a stable business as a company if everything is OpenSource. If Ubicloud would be a pure community project, that would be a different story.
That would work for 3 months, then they would start running into edge cases and issues that need fixing, patching or developing a new feature. So either providers start bringing in knowledge in terms of developers, or sign some kind of contract with Ubicloud to get those developments as needed.
Do most commercial PostgreSQL / MySQL / Redis / whatever hosting providers employ developers to work on these projects? No, they get a few sysadmins that know enough to keep it running and watch the money roll in. At best they might "sponsor" the project so they get slightly higher priority on their bug reports, but even that is just a handful of the big players. Most just apt-get install the official distribution and plug it into a billing system. And if your main source of development are developers paid by a SaaS company, this will kill you. This exact thing is, after all, why the Elastic license exists.
Thats valid. Ubicloud could potentially make money with SLAs (support)
oh boy.
it is not "open source"
but it certainly free software
it is not "open source"
but it certainly free software
Wasn’t “free software” the kind of “free, as in speech” thing? E.g. “free software foundation”.
But yeah I find this kind of comments always overly negative, when there’s an organization giving something away.
But yeah I find this kind of comments always overly negative, when there’s an organization giving something away.
Sort of, but this kind of giving away often means you cannot use it at all because using anything not unencumbered is blocked by default.
Also the name invokes "Ubiquity" the networking company.
Just to be clear, we are talking about Ubiquiti. I am not fancy enough to own it's hardware but I like the android and iPhone app for Wi-Fi man which is an easy to use Internet speed testing thing for Android and iPhone.
https://en.wikipedia.org/wiki/Ubiquiti
https://en.wikipedia.org/wiki/Ubiquiti
The thing you pay for with cloud servers is not having to do the up-keep of the host machine. They tend to have many more drives than you’d get with a bare metal server.
I have many OVH and Hetzner servers (cloud and dedicated) but not sure I’d find a use for this.
I have many OVH and Hetzner servers (cloud and dedicated) but not sure I’d find a use for this.
> The thing you pay for with cloud servers is not having to do the up-keep of the host machine.
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/
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/
But the reason you go with private cloud is because you want to give developers in your organization the ease of use and velocity of their peers using the public cloud, while footing the bill to pay far far more than you would have paid to any public 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.
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.
If I can open an app, spin up some VMs, pipeline a deployment to them and extend my operational footprint in 10 minutes, I'm not sure I care whether you want to call that cloud or not. I've seen that in some pretty small environments.
Yeah honestly some ipmi, cloudinit and (insert config management flavor of the week here) has been spinning up “private clouds” for decades with ease in large shops and in single server shops. We’ve had private clouds since the first person ran ssh commands against someone else’s dedicated metal in some dc.
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”
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”
> But the reason you go with private cloud is because you want to give developers in your organization the ease of use and velocity of their peers using the public cloud, while footing the bill to pay far far more than you would have paid to any public cloud.
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.
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.
Isn’t that the case now because setting up a private cloud is complicated and expensive?
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?
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?
If you’d be interested in cutting down on upkeep I’m actually running a service thats fully managed services on clouds like Hetzner[0].
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
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
We mainly run game servers - not sure how helpful that would be.
Ahh I thought there might be some auxiliary services you need to run — do you run anything like prometheus instances or analytics or anything like that?
How does this compare to kubernetes?
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.
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.
Elastic License
https://github.com/ubicloud/ubicloud/blob/main/LICENSE
https://github.com/ubicloud/ubicloud/blob/main/LICENSE
What makes you stand out from this list of other managed openstack providers?
https://www.openstack.org/marketplace/public-clouds/
Interesting choice on Ruby. Why Ruby in first place ?
I work on Ubicloud.
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.
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.
I'd have picked elixir... Much better concurrency and distribution support. SSH is built into the (erlang) standard lib, really fantastic support for templating via EEx (if you're using libvirt, e.g.). Easy to deploy as an on-metal or containerized platform using releases. Ruby deployment dependency management can be tricky unless you have a way to isolate from the host (containers e.g.) but that's not the best for being a hypervisor.
They're not a hypervisor, though. They provide a control plane that uses one via ssh. Choosing to deploy outside containers at this point in time should in my opinion be a last resort almost irrespective of what you're deploying; if the surface you interact with the host is so complex you can't grant access with granularity to a container without it becoming problematic (or at the very least via a tool providing similar levels of isolation using namespaces), chances are you have a bigger problem.
There are some exceptions, but they're few.
There are some exceptions, but they're few.
I've considered at various points (but not with deep seriousness I admit), typescript, julia, scala, swift. You might notice all of these have a REPL in common. Elixir might be a reasonable alternative, but not one I exercised here. In areas I wanted to take risk, I had some other stuff going on.
uh just fyi: Elixir's repl is the most powerful of all of them, as it gives you incredible introspection. With care you can attach a repl to a remote running program (in prod, if you take appropriate precautions) and be able to diagnose the running state of your program quite effectively -- like you can examine the tail call state of any given process.
> With care you can attach a repl to a remote running program
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.
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.
I mean the equivalent is also possible out of the box Erlang VM. Without having to install sidecar servers or monkey patching objects with potentially spooky action at a distance.
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
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
There are no "sidecar servers" or monkey patching or "potentially spooky action at a distance" involved in what I described.
[deleted]
Why not?
top three reasons to not use ruby for me are:
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.
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.
Ruby parallelism with request-based server apps probably works the same as other managed languages with single threaded runtimes (eg v8, Python) - you run multiple server processes. Requests are independent so its's an "embarassingly parallel" problem without need for communication between threads of execution.
If you deploy in a container (and if not, why?), the number of files is irrelevant.
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.
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.
If I'm not mistaken, the vast majority of web app backends are written in interpreted languages like Ruby, such as PHP, Python, JavaScript, and Perl.
For example, Github, Shopify, and Hulu were written with Ruby on Rails and they seem to do alright.
For example, Github, Shopify, and Hulu were written with Ruby on Rails and they seem to do alright.
"All right" is a stretch. Shopify employs a lot of amazing compiler engineers to constantly evolve the ruby compiler/VM to squeeze as much performance as possible without affecting the regular engineers, something most startups cannot do.
That's true of many companies at scale though. :-)
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!
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!
Being engaged in cost optimization engineering after you've "made it" doesn't mean failure, quite the opposite. And the parts before that are much harder bottlenecks, where other aspects of tech choices are rightfully weighed more.
Ruby web applications have a history of absurdly high resource usage and failure stories compared with something like Go. If the selling point of this is for individuals and small businesses to run this instead of AWS/GCP, it may not be any cheaper once you start running this control plane.
AWS/GCP is frequently 2x-3x as expensive as doing it yourself, depending on your usage patterns as some things are vastly more overpriced than others (e.g. egress), sometimes a bit lower, but if your control plane is more than a rounding error in your overall cost you're doing something very wrong.
love this.. we've in the process of leaving the traditional cloud powered by microk8s
Could you elaborate a bit on my you are leaving microk8s?
We're leaving AWS EKS to Microk8s. Our final setup will be microk8s + cloudflare tunnel acting as our cdn
I’m confused too, but perhaps they mean the move itself is powered by microk8s?
A sincere best of luck to you all. At the same time these sentences are unwarranted
> 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.
> 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.
spdk seems like an environmental unfriendly decision given the 100% cpu [0] that the user-space polling requires. For me a no go. Did you consider alternatives?
[0] https://spdk.io/doc/spdk_top.html
[0] https://spdk.io/doc/spdk_top.html
Well, I would have, except there weren't that many viable alternatives that don't involve one of:
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.
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.
Do you suppose the elastic block stores of the public cloud providers operate in a non polling manner?
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.
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.
Yes, SPDK for us sits on adjacent to the VM however, so our use of it for now can be best compared to an alternative to specialized PCIe hardware operating in pass-through mode directly to guests (e.g. AWS Nitro), with enough industry heft to (in the case of AWS especially, and GCP more recently via a probably-Intel collaboration) to get guests to have drivers for those cards. You can see this in action in the Linux drivers for ena (aws) and gve (google).
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.
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.
Is there a demo available?
You can check out our managed service to get a feel at https://console.ubicloud.com
I registered by never received account confirmation email.
Thanks for noting this.
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.
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.
what are you using under the hood for cloudifying?
>Available on GitHub under the Elastic v2 license.
So... not open source?
So... not open source?
For once, someone got it right and didn't claim with bold, uppercase letters that it's an Open Source project, like it usually happens with a lot of HN entries of that topic. Lately, the relicense of some Sentry product to a non-OSS license that was wrongly called "Open Source" just because the source was shared. As deserved, these kinds of usages tend to receive a good amount of backlash due to wrongly using the term.
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.
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.
They have an "open source" image right there on their front page
Oh. Just saw it. I had only opened the Github project page linked in this entry. I've added a mention in my comment.
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.
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.
Thanks for pointing this out. We updated our website.
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.
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.
For the record, I believe you did the right thing. It's your work so you should use whichever license you like, and have users use your product on your own terms. It's just that passing non-OSI approved licenses as "Open Source" does tend to trigger strong responses.
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.
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.
Yeah, these are terminological bugs. I have reported them. I work there.
[deleted]
I hate the trend of these freemium faux FOSS poser projects that keep popping up.
normally I give "open source" comments like this the label they deserve, which is "troll". however in this case it seems justified:
> 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.
https://elastic.co/licensing/elastic-license
> 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.
https://elastic.co/licensing/elastic-license
Also
> 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?
> 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?
I also commented this on their previous thread looking for input on licenses. I have no problem with monetising a managed service and preventing others from doing that on software you build, but disallowing ‘third parties’ is too broad. I wouldn’t be comfortable using this under that language.
I work on Ubicloud.
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.
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.
Pretty terrible look, given you're lying already with this "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. "
From https://ubicloud.com/
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.
From https://ubicloud.com/
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.
I replied this in another thread and didn't want to repeat myself here but that was probably oversight on my part.
> 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)
> 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)
using "free and open" is going to evoke the idea of FOSS. so you either:
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:
https://wikipedia.org/wiki/Source-available_software
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:
https://wikipedia.org/wiki/Source-available_software
Agree. Using "free and open" is still rather deceptive.
It doesn't even need to evoke the idea of FOSS. Software that includes licence management with keys and such should not be called "free and open"
elastic, who is the creator of the licence in the first place, refers to it as Free and Open. https://www.elastic.co/pricing/faq/licensing#
https://news.ycombinator.com/item?id=36998888 It seems they are still in the process of determining the most suitable license to truly make them an open-source project.
Looks like another fauxpen source, yes.
Do they pretend and mention it’s open source? If not, I don’t see a problem.
Yes.
> ... 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/
> ... 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/
I work on Ubicloud.
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.
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.
> Taken from here: https://ubicloud.com/
Am I the only one getting a certificate error browsing there?
Am I the only one getting a certificate error browsing there?
[deleted]
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.