Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Joyent Public Cloud EOL

docs.joyent.com

Post reply on HN
Print view View original

181–190 of 289 posts

Re: Joyent Public Cloud EOL

#181

Post by Annatar »

zzzcpan wrote: post #127
SwellJoe wrote: post #102

Earlier quoted context omitted.

Technically speaking, they were quite far ahead of the curve. While VMs were all the rage, they were shipping container-based products (their Sun refugees kept developing Solaris Zones and ZFS in this context). The technical abilities of the Joyent folks were well beyond just about anybody else for a long time. One could argue they were too early. For several years they had the technology to beat Amazon, until Amazon…

> Technically speaking, they were quite far ahead of the curve. While VMs were all the rage, they were shipping container-based products > The technical abilities of the Joyent folks were well beyond just about anybody else for a long time. None of that was ever true. Whether they had container-based or VM-based tech was a tiny unimportant detail for a cloud company. Although over engineering in this area certainly m…

Sun Microsystems literally invented the network is the computer. They were the first company ever to even begin to think in terms of distributed systems on a network scale (DEC had done some pioneering work on the hardware front prior to that with VMS, but not the network). The network file system, NFS, exists because Sun Microsystems engineers willed it so -- they wanted to multiply the computational power of smaller systems into a larger, distributed one.

They were a pioneer in distributed systems computing. Not many computer companies can claim that. Even fewer companies can claim engineers which hold patents which now power the InterNet, like Radia Perlman does for the spanning tree routing protocol. If that's not distributed, I don't know what is.

Re: Joyent Public Cloud EOL

#182

Post by unixhero »

SwellJoe wrote: post #168
pron wrote: post #131

Earlier quoted context omitted.

I don't know if it was the immediate cause of their lack of success, but they had also brought with them from Sun the Sun attitude of doing stuff that their engineers thought was cool (and it probably was) without paying attention to how much people are willing to pay for it and whether their focus is correct from a market perspective. For example, Bryan Cantrill, Joyent's CTO, liked blaming Oracle's Larry Ellison fo…

"perhaps it was Cantrill who was monomaniacal all along, not keeping his eyes on the market" Joyent made money and was acquired, all while producing metric shit tons of incredibly cool Open Source software. We should all be so "monomaniacal".

We have an art installation at the corporate campus where I work.

It's a parody of 1984, with inspirational quotes flowing over the entire building (300meters long). But they are not inspirational, rather artsy sometimes edgy and provocative.

The sentences change every day, and are controlled by an artist in California somewhere.

One of the sentences one day was: "Monomania creates success"

I keep a logbook of the strangest entries.

Re: Joyent Public Cloud EOL

#183

Post by insulanian »

kelp wrote: post #157
zzzcpan wrote: post #127

Earlier quoted context omitted.

> Technically speaking, they were quite far ahead of the curve. While VMs were all the rage, they were shipping container-based products > The technical abilities of the Joyent folks were well beyond just about anybody else for a long time. None of that was ever true. Whether they had container-based or VM-based tech was a tiny unimportant detail for a cloud company. Although over engineering in this area certainly m…

I'm reminded of something a smart engineer said at work today. "Our customers don't care how we implement the system, they just care that it works"

That's how you end up with unmaintainable solutions and code-bases which die under the cost of just trying to keep the system running, and because they lose the ability to evolve.

Re: Joyent Public Cloud EOL

#184

Post by insulanian »

Annatar wrote: post #177
SwellJoe wrote: post #102

Earlier quoted context omitted.

Technically speaking, they were quite far ahead of the curve. While VMs were all the rage, they were shipping container-based products (their Sun refugees kept developing Solaris Zones and ZFS in this context). The technical abilities of the Joyent folks were well beyond just about anybody else for a long time. One could argue they were too early. For several years they had the technology to beat Amazon, until Amazon…

"but it's kinda sad to see a technically visionary set of products reach a dead end" It's not a dead end since any company, public or private can use the code and the product (I for instance build my own modified SmartOS from source) to power their infrastructure. Technically there is nothing to prevent anyone from taking the product and the code and starting the next Amazon. I know of at least one internet service p…

What would you state as the top reason(s) to choose SmartOS vs Linux for those use-cases?

Re: Joyent Public Cloud EOL

#185

Post by Annatar »

insulanian wrote: post #184
Annatar wrote: post #177

Earlier quoted context omitted.

"but it's kinda sad to see a technically visionary set of products reach a dead end" It's not a dead end since any company, public or private can use the code and the product (I for instance build my own modified SmartOS from source) to power their infrastructure. Technically there is nothing to prevent anyone from taking the product and the code and starting the next Amazon. I know of at least one internet service p…

What would you state as the top reason(s) to choose SmartOS vs Linux for those use-cases?

1. full-blown virtual UNIX servers running at bare metal speeds (joyent-branded zones).

2. ability to run virtual Linux servers are bare metal speeds (and their applications).

3. simple and easy container management of 1. and 2. with imgadm and vmadm.

4. OpenZFS - easy capacity growth, checksummed data, silent data corruption detection and self healing.

5. lightning fast, faster than GNU/Linux performance on the same hardware.

6. same application portfolio as GNU/Linux (14,000 applications available with a simple pkgin command invocation).

7. ability to create virtual routers and switches out of thin air with dladm, join and partition physical links in terms of percentages, simplifying network topology in virtualized environments.

8. OS paranoid about protecting and self-healing itself and the data it hosts.

9. ability to pick between KVM (slower) or bhyve for paravirtualization of non-Linux OS's like Microsoft Windows, OpenBSD, FreeBSD et cetera (although this process is poorly documented).

10. NFS V3, V4, fiberchannel and iSCSI which work correctly.

There is one major downside (I don't consider it as such, but I know others do): one must pick the hardware compatible with SmartOS from the Joyent's hardware compatibility list, not the other way around: https://eng.joyent.com/manufacturing/bom.html.

But when it does fire up over the network and once one groks it, holy shit, it's like being taken into the future with a time machine.

Re: Joyent Public Cloud EOL

#186

Post by Annatar »

Chyzwar wrote: post #124
cookiecaper wrote: post #110

Earlier quoted context omitted.

Yes, for a very long time the Linux devs were emphatic that cgroups should be not be treated as an actual isolation/security barrier. This was flagrantly ignored and like most things in the Linux ecosystem, the functionality was eventually kinda-sorta backfilled based on the community's refusal to accept anything else. Meanwhile, FreeBSD and Solaris had quietly provided coherent tools to accomplish the same ends secu…

I disagree. Linux have 18 millions lines of code in drivers. It can run on almost any chip/architecture. Distributions are fully featured and most of the things you can imagine have first class support. I do not care how beautiful is architecture of BSD kernel if I cannot run my code on it.

Write the drivers for your hardware and bootstrap it and it will be able to run. Wait a minute, wasn't that THE one and only answer for "my hardware doesn't run Linux!" from the early '90's all the way to 2005?

Re: Joyent Public Cloud EOL

#187

Post by Annatar »

RantyDave wrote: post #116
jaytaylor wrote: post #79

Earlier quoted context omitted.

In this case, do clouds with physical bare-metal provisioning capabilities like EC2 / GCP / Azure / OCI kill the Joyent value proposition?

Joyent's value proposition was killed (for the most part) by the experience of using their public interface. It would've taken a great deal of bravery to try that and decide a local install would be better. The node thing also did a lot of damage - Joyent wrote a lot of the SmartOS/Triton command line tools in node so they were slow as hell. Triton itself is a very non-trivial install although quite probably less so…

"For a start it needs to do its first boot off a CD and subsequent boots off a USB drive-type-arrangement."

No it does not. I boot my SmartOS instances with PXE, DHCP and TFTP from the network. Served by a Solaris 10 intel server, no less. No CD's or USB images anywhere in sight.

In fact, I came up with a trifecta scheme where three SmartOS servers will all run TFTP and DHCP servers, thus being able to boot each other and all the other SmartOS servers over the network. In the event where all three would lose power simultaneously, THEN I reach for a USB stick with the emergency boot image. And I'll have two of those. But barring such catastrophic loss of power simultaneously, there won't be any CD's or USB sticks needed.

The network is the computer.

Re: Joyent Public Cloud EOL

#188

Post by Annatar »

jen20 wrote: post #125
RantyDave wrote: post #116

Earlier quoted context omitted.

Joyent's value proposition was killed (for the most part) by the experience of using their public interface. It would've taken a great deal of bravery to try that and decide a local install would be better. The node thing also did a lot of damage - Joyent wrote a lot of the SmartOS/Triton command line tools in node so they were slow as hell. Triton itself is a very non-trivial install although quite probably less so…

> Triton itself is a very non-trivial install Actually I'd say the Triton install is not only trivial, but should be a model for other similar systems. During my testing with Intel NUCs, I had a usable system deploying containers in under 20 minutes. Most managed Kubernetes systems cannot even provision in that time frame. > you just can't run SmartOS on the cloud. The installer may lead you to the USB and install pa…

How long did it take you to install Triton?

How many systems did you need to install Triton?

How much memory did(do) the individual systems running Triton have?

Which documentation did you follow to install Triton?

Re: Joyent Public Cloud EOL

#189

Post by dboreham »

nailer wrote: post #25
fragmede wrote: post #17

Earlier quoted context omitted.

Hindsight is 20/20. Linode (founded 16 years ago), and Digital Ocean (founded 8 years ago), are still alive and kicking, not to mention more traditional hosting companies like HostGator.

DigitalOcean have no serverless product and just spent a bunch of engineering resources on a new customer-managed Kubernetes setup. The amount of people who are unsatisfied with DO's VM product and would be satisfied with a k8s product is tiny. The amount of people who would like somewhere to run functions and not care at all about infrastructure is growing rapidly. If they're not skating to where the puck is moving…

Hmm...you can fairly easily (haha) layer functions/serverless over K8s, e.g. with projects like OpenFaas.

Re: Joyent Public Cloud EOL

#190

Post by kelp »

insulanian wrote: post #183
kelp wrote: post #157

Earlier quoted context omitted.

I'm reminded of something a smart engineer said at work today. "Our customers don't care how we implement the system, they just care that it works"

That's how you end up with unmaintainable solutions and code-bases which die under the cost of just trying to keep the system running, and because they lose the ability to evolve.

I guess I should have provided more context. It was in context of talking about a rewrite into another language to make something more maintainable and performant. To explain how hard that was to get right, and that if we messed it up, customers only really care that we messed it up.
Post reply on HN