4 ms·

https://github.com/ubicloud/ubicloud#how-is-this-different-than-openstack https://github.com/ubicloud/ubicloud#how-is-this-different-t... was my immediate quest

https://github.com/ubicloud/ubicloud#how-is-this-different-than-openstack 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 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 3y ago
Thanks, came here for this question (difference from OpenStack).
- fdr 3y ago
  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.
hardwaresofton 3y ago
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 https://nimbusws.com
- mdaniel 3y ago
  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

stevage 3y ago

Thanks, came here for this question (difference from OpenStack).

fdr 3y ago
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.

hardwaresofton 3y ago

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 https://nimbusws.com

mdaniel 3y ago
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