4 ms·

Less then a month migration period. If you factor in that not much work is getting done in many western countries until early January the actual migration time

Less then a month migration period. If you factor in that not much work is getting done in many western countries until early January the actual migration time is more like less than two weeks. Now I don't know how easy it is to move from hyper.sh to alternatives, but that is unprofessionally short regardless. I would have expected at least three months. Is it possible that they are that short on money that they need to shut it down immediately? Seems like it. Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic.

shawnz 8y ago
> Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic. We need SaaS: Services as a Service
- Spivak 8y ago
  You're basically describing Openshift.
ticmasta 8y ago
Maybe they don't have any customers for this product? If they do however, it's a dick move to pull out the rug with this much notice over a period when a lot of people are away for much of it...
- bartread 8y ago
  Well, they're not out of cash - at least not right now. It appears to be a pivot. I'd therefore have to agree with your assessment that it's a dick move.
- arcticfox 8y ago
  > Maybe they don't have any customers for this product? I don't think they have many, but I'm one of them. Not pleased at all w/ the migration time.
CrLf 8y ago
"Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic." Not disagreeing per se, but I believe it's much more important to design for migration between providers instead of designing for abstraction over providers. The difference is subtle, but trying to make predictions about what needs abstraction will most likely lead to the same (or bigger) costs when a migration actually happens. It's a bit like the general advice to design to avoid getting stuck in a hole as opposed to designing to getting out of future holes.
- gaius 8y ago
  I believe it's much more important to design for migration between providers instead of designing for abstraction over providers Right. If you design to be cloud agnostic that means only using the lowest common denominator of features, and while it’s doable it’s not cost effective. The price structure is designed to shepherd you into the managed services.
- bfirsh 8y ago
  The thing that drew me to Hyper.sh in the first place was the fact that it used the Docker Remote API. That gave me some confidence it would be provider agnostic. Unfortunately no other providers have done this, so that idea didn't pan out.
  - slackpad 8y ago
    I thought Joyent had a container service that used the Docker Remote API?
    - philipswood 8y ago
      Joyent Triton https://www.joyent.com/triton/compute https://www.joyent.com/triton/compute A few years ago (when I last checked} their container startup times were a lot slower than hyper.sh's
bfirsh 8y ago
Indeed. This is a headache for me. My service is entirely dependent on Hyper.sh and there seems to be no trivial migration path. I think I shall have to drop everything I was planning to do after the holidays and rearchitect for Kubernetes. :( A few years ago, I ran a similar company that I also shut down, so it would be hypocritical of me to complain much. Competing with AWS is hard. (We did give users 3 months to migrate though.)
chubot 8y ago
Could this be due to a fatal security issue? Running untrusted code side by side on native hardware doesn't give you a whole lot of room to patch vulnerabilities ... And the situation has gotten a lot worse in the last year.
- lima 8y ago
  But Hyper uses lightweight virtual machines for multi-tenancy - they were actually one the providers who got it right. It was one of their unique selling points.
colemickens 8y ago
Hm, "professionalism", to me, is a weird criticism to levy against a product or business that is presumably shutting down due to failure or lack of funding. Is it common, or expected, that startups allocate funds for clean shutdowns? I assume it's just burning through cash trying to make it work, until it becomes so unavoidable that you have to shutter suddenly. >Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic. Yeah, but no one that matters, cares - whether it's writing blog posts or putting your entire company brand/presence/blog on Medium (which harasses all of your readers), or relying on low-margin infra startups that often amount to a thin docs/marketing layer around Docker. Just like the same people that get hosed by their hosting/DNS providers with a history of screwing users... because they didn't think it would happen to them -- people are lazy, people think they're exceptional, and I think a bunch of people don't like learning infra and don't see it as important.
- the_duke 8y ago
  If they are actually out of money, they don't have any other option than to shut it down. You can't blame anyone for that. A lot of startups wouldn't have the option to budget for an orderly shutdown. But their email doesn't say anything about being out of money, just that they are focusing on a different technology. That's why I brought it up. If you have to shut down, own up to the real reason. If not, you are screwing your users to focus on something else. I'd bet that they just can't cover the bills anymore, though.
Novashi 8y ago
You’re still making a decision to slow feature development for the relatively small risk that your cloud provider goes under. Personally I’d rather just pick the most popular platform as a better decision to hedge against the risk.
- solarkraft 8y ago
  That way you'd be indirectly promoting a monopoly and raising their incentives to raise their prices ...
eeeeeeeeeeeee 8y ago
Ok, I wasn’t the only one. Plus, right during the holiday season!!! What were they thinking!?

shawnz 8y ago

> Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic. We need SaaS: Services as a Service

Spivak 8y ago
You're basically describing Openshift.

ticmasta 8y ago

Maybe they don't have any customers for this product? If they do however, it's a dick move to pull out the rug with this much notice over a period when a lot of people are away for much of it...

bartread 8y ago
Well, they're not out of cash - at least not right now. It appears to be a pivot. I'd therefore have to agree with your assessment that it's a dick move.
arcticfox 8y ago
> Maybe they don't have any customers for this product? I don't think they have many, but I'm one of them. Not pleased at all w/ the migration time.

CrLf 8y ago

"Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic." Not disagreeing per se, but I believe it's much more important to design for migration between providers instead of designing for abstraction over providers. The difference is subtle, but trying to make predictions about what needs abstraction will most likely lead to the same (or bigger) costs when a migration actually happens. It's a bit like the general advice to design to avoid getting stuck in a hole as opposed to designing to getting out of future holes.

gaius 8y ago
I believe it's much more important to design for migration between providers instead of designing for abstraction over providers Right. If you design to be cloud agnostic that means only using the lowest common denominator of features, and while it’s doable it’s not cost effective. The price structure is designed to shepherd you into the managed services.
bfirsh 8y ago
The thing that drew me to Hyper.sh in the first place was the fact that it used the Docker Remote API. That gave me some confidence it would be provider agnostic. Unfortunately no other providers have done this, so that idea didn't pan out.
- slackpad 8y ago
  I thought Joyent had a container service that used the Docker Remote API?
  - philipswood 8y ago
    Joyent Triton https://www.joyent.com/triton/compute https://www.joyent.com/triton/compute A few years ago (when I last checked} their container startup times were a lot slower than hyper.sh's

bfirsh 8y ago

Indeed. This is a headache for me. My service is entirely dependent on Hyper.sh and there seems to be no trivial migration path. I think I shall have to drop everything I was planning to do after the holidays and rearchitect for Kubernetes. :( A few years ago, I ran a similar company that I also shut down, so it would be hypocritical of me to complain much. Competing with AWS is hard. (We did give users 3 months to migrate though.)

chubot 8y ago

Could this be due to a fatal security issue? Running untrusted code side by side on native hardware doesn't give you a whole lot of room to patch vulnerabilities ... And the situation has gotten a lot worse in the last year.

lima 8y ago
But Hyper uses lightweight virtual machines for multi-tenancy - they were actually one the providers who got it right. It was one of their unique selling points.

colemickens 8y ago

Hm, "professionalism", to me, is a weird criticism to levy against a product or business that is presumably shutting down due to failure or lack of funding. Is it common, or expected, that startups allocate funds for clean shutdowns? I assume it's just burning through cash trying to make it work, until it becomes so unavoidable that you have to shutter suddenly. >Let that be a lesson to not rely on cloud infrastructure too much without designing your architecture to be somewhat cloud agnostic. Yeah, but no one that matters, cares - whether it's writing blog posts or putting your entire company brand/presence/blog on Medium (which harasses all of your readers), or relying on low-margin infra startups that often amount to a thin docs/marketing layer around Docker. Just like the same people that get hosed by their hosting/DNS providers with a history of screwing users... because they didn't think it would happen to them -- people are lazy, people think they're exceptional, and I think a bunch of people don't like learning infra and don't see it as important.

the_duke 8y ago
If they are actually out of money, they don't have any other option than to shut it down. You can't blame anyone for that. A lot of startups wouldn't have the option to budget for an orderly shutdown. But their email doesn't say anything about being out of money, just that they are focusing on a different technology. That's why I brought it up. If you have to shut down, own up to the real reason. If not, you are screwing your users to focus on something else. I'd bet that they just can't cover the bills anymore, though.

Novashi 8y ago

You’re still making a decision to slow feature development for the relatively small risk that your cloud provider goes under. Personally I’d rather just pick the most popular platform as a better decision to hedge against the risk.

solarkraft 8y ago
That way you'd be indirectly promoting a monopoly and raising their incentives to raise their prices ...

eeeeeeeeeeeee 8y ago

Ok, I wasn’t the only one. Plus, right during the holiday season!!! What were they thinking!?