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.
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:
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
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.“
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
[+] [-] pwmtr|2 years ago|reply
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.
[+] [-] amne|2 years ago|reply
[+] [-] notpushkin|2 years ago|reply
Have you considered other licensing options, like BSL?
[+] [-] alsjdfnasljfkh|2 years ago|reply
[deleted]
[+] [-] esperent|2 years ago|reply
> 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.
[+] [-] mdaniel|2 years ago|reply
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
[+] [-] stevage|2 years ago|reply
[+] [-] hardwaresofton|2 years ago|reply
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
[+] [-] jwildeboer|2 years ago|reply
„ 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.“
[+] [-] lionkor|2 years ago|reply
[+] [-] 2Gkashmiri|2 years ago|reply
it is not "open source"
but it certainly free software
[+] [-] hypercube33|2 years ago|reply
[+] [-] bashy|2 years ago|reply
I have many OVH and Hetzner servers (cloud and dedicated) but not sure I’d find a use for this.
[+] [-] CharlesW|2 years ago|reply
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/
[+] [-] hardwaresofton|2 years ago|reply
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
[+] [-] Too|2 years ago|reply
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.
[+] [-] iFire|2 years ago|reply
https://github.com/ubicloud/ubicloud/blob/main/LICENSE
[+] [-] ody4242|2 years ago|reply
[+] [-] revskill|2 years ago|reply
[+] [-] fdr|2 years ago|reply
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.
[+] [-] joshmn|2 years ago|reply
[+] [-] rafaelturk|2 years ago|reply
[+] [-] Cwizard|2 years ago|reply
[+] [-] vero2|2 years ago|reply
> 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.
[+] [-] smartbit|2 years ago|reply
[0] https://spdk.io/doc/spdk_top.html
[+] [-] fdr|2 years ago|reply
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.
[+] [-] FranGro78|2 years ago|reply
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.
[+] [-] elitan|2 years ago|reply
[+] [-] pwmtr|2 years ago|reply
[+] [-] BilalBudhani|2 years ago|reply
[+] [-] Cantinflas|2 years ago|reply
So... not open source?
[+] [-] j1elo|2 years ago|reply
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.
[+] [-] dal|2 years ago|reply
[+] [-] 38|2 years ago|reply
> 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
[+] [-] dxk_user|2 years ago|reply
[+] [-] zxwrt|2 years ago|reply
[+] [-] lifty|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]