back
99 comments
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.

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.)

"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.

> 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

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.

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.

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...

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.

Ok, I wasn’t the only one. Plus, right during the holiday season!!! What were they thinking!?
Weird, no statement or anything that I can find, just a banner at the top of the page. As well, they're shutting off service in less than a month during a time in the year when at least many western countries have limited staff/availability due to holidays. While I understand that once they decide they will no longer be operating, they don't have a legitimate business reason to help (former) customers ease through the transition, it really seems like they went out of their way to be as customer-hostile as they could.

EDIT: Looks like an email went out (copied in a comment below) and that they are not shutting down as an organization, just this product. Even more curious as to why they'd offer such a short migration window to former customers. I would, especially in an organization, be truly hesitant to rely on any of their other technologies if this is the pattern being set.

Here's a copy of the email I received:

We are writing to let you know that we decided to pursue a new direction in 2019, and will be closing down the Hyper.sh cloud platform on January 15, 2019.

Over three years ago, we set out to create an open secure container-native platform. We believed that containers represented a sea change in how software would be developed, deployed, and maintained.

Along the way, we created one of the first container-native cloud offerings, the Hyper.sh platform, which utilized our open source technology, called runV, which last year was merged with Intel’s Clear Containers project to become Kata Containers. We’re proud of the platform we built, and the influence we have had on the overall container industry. We are even more grateful to you, our customers, who have deployed hundreds of thousands of containers and built out new business on our platform.

The Hyper.sh platform, while trailblazing, is not where Hyper’s future efforts lie. Moving forward, Hyper is focusing all our attention and efforts towards the upstream Kata Containers project and in developing our Enterprise Kata stack for deployment in the major public clouds.

As of today, it is no longer possible to create a new account on Hyper.sh, and on January 15, 2019, the Hyper.sh cloud service will be shut down. Per section 11 of our terms of service, we wanted to provide you time to migrate off the platform and for the next month, our priority is to help your transition to other cloud services. If you need assistance, please feel free to reach out to us via Slack or your account dashboard. On January 15, 2019 any remaining user data and accounts will be deleted from the platform.

Please start now migrating your containers and data volumes off the platform. Directions on how to migrate your container volumes can be followed here. Please note, you will not be charged for either the container or the FIP in performing the migration.

Thank you for your business and support of our platform. It has been a privilege to serve you.

Sincerely,

The Hyper Crew

This is somewhat common. They've probably emailed all their customers with more details. One of them can post a screenshot of their email and link it here.
Wow! Just checked my email and got this. I was considering using this, but KNEW I couldn’t have built parts of my infra around this, because of one thing: the pricing. I even sent a message on their website asking what their roadmap was. After not getting a response for days, I figured the end was nigh.

It was far too low to build a sustainable business around, and so I decided to write my own stack. What I needed they served very well ( ability to run one-shot docker containers as an HTTP rpc ) — similar to AWS Fargate but much much simpler.

Fargates’ RunTask is close but requires way too much configuration of roles and permissions and “provisioning” just to run a container. And even at the scale AWS is providing fargate, their pricing was still higher! I remember the AWS pricing being something like 5c / hr priced out in seconds, but with a minimum charge of 1 minute, but hyper.sh was 1c/hr with a min charge of only 10s! So, roughly here’s why they’re going out of business: the business requires very scaley things ( think dinosaur not lizard ) in order to make very small amounts of money. And it’s making 1/5th of the market dominant service.

What would be good pricing in your point of view?
Woa... I was evaluating this service a couple of months ago. The conclusion was, even if it looks nice the major downside was that the company hadn't been around long enough and we didn't know if they were profitable. These kinds of moves with sub-30 days during major holidays is really scary. I feel for everyone out there having to work during the holidays. I hope the CEO did this out of financial necessities. Otherwise he should be put on some type of do-not-purchase-from-these-founders-blacklist.
> Otherwise he should be put on some type of do-not-purchase-from-these-founders-blacklist.

Does such a blacklist exist? Given the short notice I expected that Hyper.sh would be gone (and thus free of commercial backlash) but it appears the company will continue in new areas, which makes this decision even more surprising.

I'd definitely be interested in having such a list and an easy way to determine if they are involved in new companies, which doesn't sound trivial. "Foo Co was terrible to their customers" doesn't tell me Bob made the decisions, nor does that tell me that Bar Co is also run by Bob.

Hah I did the exact same thing. Neat product that I wanted to build something new on, but I didn’t trust that this company would be around in a year.
> The Hyper.sh platform, while trailblazing, is not where Hyper’s future efforts lie. Moving forward, Hyper is focusing all our attention and efforts towards the upstream Kata Containers project and in developing our Enterprise Kata stack for deployment in the major public clouds.

(From the shutdown email users received)

I was not aware of these products. Interesting.

kata (Intel clear containers + hypers runv) is big in the nested virtualization space but is still a tiny project (contributor wise) consisting of mostly Redhat. It's unlikely you'd run into these projects if you're not at an IAAS or dealing with containers accessing custom hardware (fpgas, gpus, etc). They're really cool, along with gvisor, kubevirt, nemu, etc. The really exciting part is everyone is using these projects for extremely different reasons. IAAS, rendering farms, android emulators, it's a really fun project to watch.

I think in the future there will be a big shift off of runc (docker) as the k8s default runtime now that CRIO has made them pluggable.

This really sucks for those that have invested in the platform and now have less than a month of warning.

If anyone needs help migrating off hyper.sh I am pretty free over the holiday period. I have extensive DevOps experience. I'm happy to help (gratis).

My email is on my profile.

Over the past 5 years I’ve seen too mans PaaS provider shutdown. Every time those affected ask why and my answer is the same: PaaS is a great tool but an awful business. We studied many PaaS providers and their business model and I believe there are fundamental business issues with a PaaS provider that provides infrastructure as well as the platform. The only way to survive the market is to have a rich owner (like Heroku / Salesforce), be a cloud provider (GoogleApps), run it yourself (DIY Kubernetes like solutions) or use a service that manages a PaaS on your own servers (Cloud 66).
Wow, a two week notice for an infrastructure provider is borderline criminal. I'm out for the holiday during this period... Guess it's going to be a scramble to get back on reliable 'ole Heroku for me. What a nightmare.
The promise of "Speed of containers and security of VMs" is enticing, but is there a simple 101/quickstart for somebody that just wants to run one container in this way?

as in no Kubernetes, OpenStack, Multi-tenancy, nothing.....

Just one bare-metal server, configured as KVM host, and how can I [run/start/stop] one Kata container?

I feel like everyone just assumes you're a Kubernetes Pro and runs infrastructure at the scale of Google/FB/Amazon these days... :-(

k8s is really just the scheduler and gives you a uniform way to deploy the "vm" containers in the usual scenario. With k8s you can have workloads run on different runtimes like trusted=runc, untrusted=kata, etc and this is even easier now with RuntimeClass which you can write right inside of a regular k8s deployment yaml.

Kata is actually just several binaries that talk via grpc (kata-agent, shim, proxy, runtime) and interface with QEMU/NEMU. For instance kata-proxy proxies commands over virtios serial interface that's exposed via QEMU.

You could install the binaries and qemu-lite and have a similar system but I'm not really sure how you'd benefit as it's the management through k8s that really won me over. I think in your scenario you'd just be making very complicated QEMU vms. I've linked this to the contribs, maybe they have some thoughts.

The documentation for kata seems fairly straightforward for a single host install. Install the kata packages, modify docker daemon to change the run time, then use Docker the usual way.

https://github.com/kata-containers/documentation/blob/master...

That is where serverless is really awesome as it give you scale and flexibility, and the providers behind are using containers
Sad to see this. What happened to the "serverless containers", especially startups working on the idea? Months ago, Zeit.co gave up the idea of hosting containers and changed their direction to FaaS . Wondering if there is a technical reason (e.g. cost effective and scalable) behind both changes. On the other hand, big cloud vendors are all providing the serverless containers while the experience may not be as smooth as the startups provide.
AWS employee here. Serverless containers are hard, and there are a lot of technical challenges along the way.

For context when we launched ECS years ago the goal was always to build a serverless container platform. But first we had to build out our own container orchestration platform capable of keeping track of all the containers at the scale that AWS requires, and build out a lot of underlying tech that didn't exist yet. Recently we open sourced Firecracker (https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...) which is one of the pieces we built along the way to enable the data plane. It took us a few years to get to this point, which is a really long time in startup lifetime.

The major cloud providers have the resources to spend a lot of time building the technical depth required to offer full featured serverless container platforms that can truly scale up and out. In my view the smaller providers like hyper.sh really nailed the initial developer experience but they are missing the depth behind the scenes that allows serverless containers to be scaled out cost effectively.

In time these two ends of the spectrum will hopefully converge. By open sourcing tech like Firecracker AWS enables small providers to have access to tech that we built because we needed it, and now its available for them to use. Conversely AWS learns how to improve our developer experience by seeing how these small startups create a great developer experience.

I used Hyper.sh for my side project 2 years ago during the initial development phase. It was really easy to start with but I wouldn't say it was stable. Every month or so there would be downtimes or the container would run but for example networks wouldn't work. Or storage volumes wouldn't mount/unmount.. :)

After several downtimes I switched to Google's GKE and never looked back. Hyper is easy to start with but impossible to finish. There was no managed database at that time (not sure whether they had it now) and using Postgres with their persistent volumes (which are backed by Ceph I think) performance was really sad.

All in all, it was a great service for trying out ideas or running small & less important applications, but if you really want it to always be available, then probably it's not the right tool.

In fact, I felt this coming since quite a long time. One day, they abrubtly shut down their Pi (serverless K8s) without a notification. Their forum was deserted. A little activity in Slack. Nothing but these.
This seems like a sudden shut down, only giving users a few weeks to migrate.
less confusion for https://hyper.is/
Exactly what I thought the link referred to initially.
Sad to see them go. They were easy to use and cost effective (for my use cases at least).

They have some really cool underlying tech.

I can't say I'm surprised though - there have been signs that this was coming.

I note that their Twitter account has had no activity for a few months. This seems to be a common thing with services that shut down or products that get discontinued.

Makes me wonder.. maybe it's worth building a tool that monitors the Twitter accounts of common services and products and raises a bat signal if they don't tweet for a month or two. It seems to be where budget gets tightened first.

I've been looking for a service like this for a while, and the first I find out about it is that it's shutting down. Does anyone know of similar offerings that are as simple? I know AWS, GCP and the likes offer container clusters, but I would like to just run a single container (for cheap) and not worry about it.
Just found out about this service. It looks like a solid concept. Any alternatives out there?
Zeit is dropping the support for containers for their v2 and now Hyper is shutting down their services. Any other one sentence deploy ("now" or "hyper run") for containers available out there?
They had a cron feature which was really good. I've switched to running a Kubernetes cluster for my side projects but Hyper.sh cron was really easy to get started with.
I was just considering using this service for a side project that needed isolated containers to run jobs in. Anyone have suggestions for similar alternative services?
You say another, which other products are shutting down ?
Well I guess that is one valuable lesson to not choose no name company as your cloud provider. Big buddy is your friend.
I was planning on using this for my side project. I thought it looked great for MVPs and small projects. What happened?
Interesting to see one of these happen. Put me down for this happening to Mongo's Stitch product next.
I thought it was a brilliant idea for builds. Not many customers?
I JUST signed up for their service this week. :(.
It's a shame. It was one of the most innovative cloud provider and my personal favourite.
What is hyper.sh ?