Hacker News new | comments | show | ask | jobs | submit login
Ep.io is closing down, recommending Heroku (ep.io)
157 points by goblin89 1649 days ago | hide | past | web | 68 comments | favorite

I think you'll see a slew of these closures.

- The PaaS space is getting squeezed on all directions; from the bottom by CloudFoundry and from the top from people like Heroku, Amazon and from startups like Parse chopping off verticals. Building a proper PaaS platform is a lot of work - tons of little edge cases, security concerns, scale concerns. All of it is very non-trivial and you can't just focus on one little scenario and hope to get away with it.

I suspect you'll see more people going the Phpfog->AppFog route, give up the general PaaS platform to CloudFoundry/Amazon/Heroku and try and move up the stack to provide value on top. I have no idea how DotCloud is doing but I'll be very surprised if they're doing well. I I love the team but I think they are in a tough spot.

(I'm one of the two Epio founders)

Obviously, we have an interesting view on this whole problem. I'm personally of the opinion that PaaS is still not quite the right solution - there's certainly some progress, but there's such an murky boundary between what a platform and an app provides that it's hard to make something that doesn't surprise people in some way.

It's interesting to note that as a PaaS platform you do get an advantage over IaaS - you can share resources and box-pack apps a lot more efficiently when you control memory and disk access at that higher level, so it's not like IaaS is certain to win either.

I probably need to compose my thoughts into something more intelligible and write a full blog post about how I think deployment should evolve, but I have a migration to shepherd first.

Please do. I'd be interested in your thoughts.

As a (sad to see you go) ep.io user thanks for providing the migration tips.

Did you consider attempting to sell your business? What prevented you from doing that?

Yeah, indeed. I'd have thought the provisioning code and tools could be useful (IIRC was there some custom thing which ran pip installs in parallel)?. I'd certainly donate some money and dev time to help encourage an open source version of the provisioning and build tools which would run any VPS.

dotCloud founder here. I am confused by your comment.

We launched the first multi-language PaaS in 2010, when it was considered a stupid thing to do. We raised $10m from investors who agreed with us that you can't build a sustainable business by only focusing on one stack - you have to focus on solving the hard problems that are the same for everyone and that people pay to solve: scale, security, change management, support for future components, customization. We have 24+ months of runway and already make more money than Heroku did when they were acquired. Now single-stack platforms are running for high ground, as we correctly predicted.

How exactly does this put us in a bad spot?

And by the way, we happen to be a python shop and encourage all ep.io refugees to give dotCloud a try!

I'm a Ep.io user, hosting a bunch of apps about half on the free plan and a half on a paid plan. Note that my apps on Ep.io are all pretty low traffic apps in general but traffic comes in bursts. On Ep.io I'm paying around $15 a month for the paid apps (when there's low traffic). Your pricing plans seem very ill suited for my needs. As I understand your pricing table, you would charge me $99 per each two apps (they all use databases), both those I get free and the paid apps on Ep.io. This is obviously way too much, is there anything that I'm misinterpreting?

I can guarantee that you can run your apps on dotCloud on roughly the same budget as Heroku, if not cheaper. Our pricing page is tragically bad, we know it, and we are fixing it. For now a large proportion of our sales process is custom, in mostly 2 ways: 1) "I have several tiny apps, help me pay less"! and 2) "I need VIP support and features, help me pay more". This will soon make its way into official pricing. For now you should email support@dotcloud.com and mention you come from ep.io :)

This may sound unglamorous, but that is how our discovery process works, and it's allowing us to build a real business. And in the long run you need a business in order to avoid selling out and letting your customers down.

This is what I found too. Yeah, there's a free tier, but if you want an app runner, database and cache it doesn't fit below $99.

The pricing model seems to be slightly different than both epio and heroku and it seems free apps can't have custom domains - also, you only get one free app + db, as opposed to heroku where you can start for free as a developer and then scale (and pay for) the apps that goes live.

On top of that, epio seemed to be much easier to get started with for a basic django project, than both dot cloud and heroku, possibly because of the multiple platform issue.

He clearly said, "I have no idea how dotCloud is doing.", making his comment simple speculation.

interesting situation, the whole thing (i'm saying this as someone standing completely outside, looking in)

He also said "I think they are in a rough spot", when we see exactly the opposite happening.

"I love the team" -> we love you too! :)

NodeSocket founder here.

Indeed PaaS is an extremely tough market with tons of external competitive pressures. Right now there are two major strategies. The first is the notion of a 'polyglot' platform (Heroku, DotCloud, CloudFoundry) which is multiple languages/databases. The second, and our strategy, is focusing exclusively on a stack (node for us) and building tools and systems which work exclusively for the stack. Essentially, I believe it comes down to company resources which strategy to choose. When Heroku started they focused exclusively on Rails, and did it really well. Not until recently after growing the team and dominating the rails hosting market, did they make the huge shift to polyglot.

Finally, recently, there is a new emerging strategy which I am really excited about, which is even more focused. Real-time javascript frameworks, with hosting bundled into the platform. Examples of this are Meteor and FireBase. Certainly there is some preliminary evidence, that these may be the future.

Not to knock on your service/business-plan, but I can't imagine how focusing on a particular stack gives you any advantage. To me, the bare PaaS offering includes not only the bits that run the app (nodejs workers in your case) but a datastore (minimum one choice each from RDBMs or kv-stores), a backend cache, and a front-end cache or load-balancer. At this point, I imagine your PaaS infrastructure is already plenty 'polyglot', and it seems to me that adding additional tool support wouldn't complicate the backend more. Of course, I do grant that manpower can be a limiting factor. (I do also grant that I may be a naive armchair theorist spouting hot air)

I'm interested to hear what you feel your business advantage is. Is it branding (e.g., someone wanting to host a nodejs project is more likely to head your way), or does the focus really give you a lead in the arms race against the 'polyglot'-er services.

I wonder if PaaS is just an intermediate step towards frameworks that abstract away the whole serverside logic and database.

At Gondor, we've had some success offering app-level consulting in addition to hosting as a way of differentiating ourselves from the bigger players. For example, not just hosting but helping the customer to get their site ready for production.

Totally agree on the PaaS squeeze. It's a very tough problem space and consolidation is already on the horizon.

These days everyone wants a streamlined, Heroku-style workflow. And yet it's interesting that despite the benefits of PaaS, many engineers just aren't willing to give up control of underlying infrastructure.

IaaS orchestration offers a different approach that provides many of the benefits of PaaS (auto-scaling, streamlined deployment workflow, etc) using raw IaaS building blocks. IaaS orchestration is also a challenging problem, but the space is less crowded.

Disclaimer: I'm the CTO of OpDemand and IaaS orchestration is what we do.

The reason we're not running on *aaS isn't actually becuase we don't want to - we'd love to.

Yet we keep having to roll our own mini cloud on root servers because our clients fear for data security (and rightly so) when putting stuff on servers of US-based companies because of the Patriot Act.

There are plenty of non-US based cloud providers who will be happy to take your money.

Where are you based?

Is there a packaged solution for abstracting your resources, ep.io style?


People drastically underestimate the effort required to make a PaaS platform and drastically overestimate people's willingness to pay. It's a dogfight of a market with brutal economics.

Not to mention the fact that you have to have a really wide range of knowledge to cover that full stack of management and security - from raw networking to database management and everything in between. We're fortunate that our skillset just about covered it, but throw in support for all the popular web languages and it's unlikely you'll pull it off without 3 or 4 people, minimum.

I think part of "drastically overestimate people's willingness to pay" is that the customers also "drastically underestimate the effort required", so they tend to compare PaaS pricing against what it'd cost to roll-their-own on a VPS or on EC2, which really puts a squeeze on pricing.

To be fair, customers should be comparing PaaS pricing to their own fully loaded cost to roll-their-own.

If a PaaS can't beat the internal price (including time, hiring ops people,etc), they're fighting a losing battle.

Sure, as long as the internal price doesn't "drastically underestimate the effort required". Which it rarely fails to do.

Even worse, most internal measurements drastically underestimate the competence required.

yep, number one thing I hear is "why wouldn't I just use my own VPS?"

I didn't really understand how hard it is to run a VPS until I started doing it. It seems so easy when you look at it. Also, I run my own web stack on my dev machine anyway.

I went VPS because:

1. I'm more familiar with configuring my own web apps then trying to use someone else's admin console. (Low opinion of said consoles that I've seen in the past, but haven't tried Heroku or other new services.)

2. I need to run Node.js, PHP, and Ruby all on the same server. (Actually, just PHP and Node.js, which are in the same web app and so need access to a shared database. Ruby could be elsewhere at the moment.)

I'm still on VPS because:

1. Already paying for it, hasn't been a year yet

2. I still don't understand the new PaaS thing

3. PHP + Node.js PaaS host? Preferably with name recognition on par with Heroku, but at least lots of good reviews.

Complications of VPS are numerous, so I won't enumerate them. Lots of things to configure, update, and keep alive. Also it isn't the same OS as my dev machine plus I have to manage security for a public server but not for my desktop machine.

EDIT: just thought of one more reason I use VPS, I actually like ssh shell access. Ability to edit files and run arbitrary commands, many innumerable uses of this.

https://www.dotcloud.com/ does all three (Node, PHP and Ruby) along with many others. You can set up different instances, have them access the same database as well.

When I was in their beta program when they first started out they also gave you shell access to the machine so you could see what was being deployed, and run arbitrary commands (perfect for having an Python app that required running paste for upgrading the DB to the latest version).

In my experience with them I had absolutely no issues, it was fast to configure and set up and their command line tools were fantastic. It used git if you wanted it to, or could use any arbitrary directory and upload the contents.

Not only that but you could modify the nginx config file to change redirects and set static directories that shouldn't be handled by WSGI so that you could take a load off the Python app from serving up requests for static content.

I haven't used dotCloud in over 8+ months now, if not longer, their pricing just didn't make sense for me, and I found it cheaper with all the sites I host to just go with a single dedicated server rather than use their services so maybe a lot has changed, but they sound like what you need.

dotCloud (not affiliated) might fit your needs. You can run various mixed stacks on one platform and as far as I remember from testing it they leave you more freedom than e.g. Heroku. Only drawback is the pricing which in your case would be at least 99 USD pm.

That's a pity. Ben and Andrew are two of the cleverest (and funniest) devs I've ever met.

They're not dying or anything...

Boo. Such a shame. Of all the PaaS offerings Ep.io was the one I was really rooting for. There was a real personal feel to the service - support email repies from Andrew directly, and an always active IRC channel.

PaaS sounds like it could make my life so much simpler. I've tried out Ep.io, Heroku and DotCloud, and have test apps continuing to run in all of them but none of them are quite right yet for me to trust a client's production site in, so I'm yet another person replicating using Linode VPSs and a custom build and provisioning script.

Best of luck to all involved with Ep.io, and it's commendable to see their dignified plan including working with helping their customers move away to other services.

I'm very curious what's not right with the mentioned services? Why don't you trust them yet?

Kindof worrisome that you can't seem to rely on these interesting hosting services because they're liable to go out of business in a few months. That said, it's nice that these guys give over a month to migrate, and instructions.

That's a risk you run using services provided for by anyone other than yourself. My bank could suddenly go under and I would have to switch banks... It's not just in the software world, that's anything.

I believe they were one of the best hosting providers for no-frill Python Django web apps. A lot of Python web app developers like me would appreciate a dedicated, easy migrate Django hosting website. Alas! :-(

Agree. Heroku appears inferior to Ep.io in terms of how easy you can get a Django website up and running, and less flexible.

In our case, we use Brunch (node.js-based tool) to build client-side code. With Ep.io, we'd just build the code locally and then do `epio upload`. While Heroku requires everything to go through repository. Since it's impossible, I think, to run a Node.js tool directly on Heroku, we'd need to `git push` compiled code. It is not nice.

You can basically do anything you want on heroku because they allow custom buildpacks. You could make your own buildpack that vendors in node.js and your tool and builds at deploy time. Here's a heroku doc article all about it: https://devcenter.heroku.com/articles/buildpacks

Thanks for the correction, I didn't read the docs carefully. Buildpack's a better idea than building stuff locally. This makes slightly steeper learning curve the only weakness of Heroku compared to Ep.io.

No problem. They don't actually talk about buildpacks all that much but I see it as the major differentiating feature on Heroku.

One thing you may be interested in is heroku-buildpack-multi[1] which lets you run multiple buildpacks. You could theoretically use this to include the standard Python and Node.js buildpacks plus a small custom one that just installs and runs Brunch.

[1]: https://github.com/ddollar/heroku-buildpack-multi

dotCloud has a comparable system called custom services. In addition to a custom build script you can also allocate arbitrary custom network ports (tcp/udp/http/websockets), as well as custom system packages.

I definitely agree with other comments in this thread that paas and orchestrated-iaas are on a collision course. Exciting times!

Either of the two workflows you mention are easily doable with dotCloud. Building locally (as you do today) should be fine: the dotCloud command line client uses git or hg (whichever you're using) by default, but can fall back to rsync if you want to push untracked changes[1].

In the long run, though, it's probably better to include the Brunch step as part of your build. With the new version of the dotCloud Python service[2], you can hack the build script[3] to do whatever you want. For simple build tasks, there's one version of Node already installed, but you could also poach part of the Node build script[4] to install another version, if you need it.


[1]: http://docs.dotcloud.com/guides/git-hg/#pushing-uncomitted-c...

[2]: https://github.com/dotcloud/python-on-dotcloud

[3]: https://github.com/dotcloud/python-on-dotcloud/blob/master/p...

[4]: https://github.com/dotcloud/node-on-dotcloud/blob/master/nod...

Sad to see them go. We were hosted with them and really liked their service. Good luck to Andrew and Ben.

When you guys say that you're going to make servers not suck, can you share a bit more about what you mean? Are you referring to dedicated hosting?

I'm sad to see epio go, it was/is a great tool and I always got stellar service from Andrew and Ben.

I've been using Ep.io for a number of apps, but one of them is http://laserey.es, which uses openCV. Andrew installed it on epio without a hitch, but I haven't found any other cloud hosting that offers it. Does anyone have suggestions where I could migrate it to?

You might find this comment suggests a way to do it on heroku. (Wishy-washy language because I have no direct experience with buildpacks.)


Too bad! Still no django-focused hosting options :-(

Trust me, you really don't want a Django-specific hosting environment. Django's a WSGI framework like the rest of the Python world (even moreso as of 1.4). Supporting any WSGI app is in some ways easier than just supporting Django, so I can't see any good reason why a platform provider wouldn't support any WSGI app. Further, why would you want to choose a platform that locks you into a particular tool? Django's far from the only good choice in the Python web world; don't pick a tool that forces you to put on blinders.

This is such a wonderfully respectable statement coming from Mr. Django.

What would you recommend as a WSGI-specific hosting environment, then?

I've been happy with Heroku, Dotcloud, and Webfaction. Of the three, Webfaction's the only one that's Python-specific (although not really), but both Heroku and Dotcloud have Pythonistas on staff and take Python support really seriously.

We run Django on Heroku and have zero issues. Absolutely love the service.

Did you hit any issues deploying?

This seems like a legitimate question to me, how about commenting about why you disagree with me instead of downvoting?

static/media files are served from CDN so if you have anything that breaks because of CORS you need to add some code to serve static files through gunicorn.

sorry, * for europe

Last time i checked it was in beta as well and we could't migrate media and database to and from the apps there - might be fixed now, maybe time to review them again (and checking if they finally got some servers in europe).

Gondor launched in September and we provide a load command for data but can also work with you to load existing data and media. Unfortunately we do not have any European data centers yet, but it's something we've planned. If you email support@gondor.io we'll be glad to answer any questions.

does Gondor offer PostGIS on the shared plan?

Heroku's doing Django fine now

It may not be focused, but I've had good luck with webfaction.

use wsgi

I smiled, because such caring about clients knowing the company goes down is simply good stuff. Kudos!

Does anyone have any feedback about OpenShift by Red Hat?

They were at PyCon and it sounded interesting. I tried openshift and heroku, and heroku was easier for me to get up and running with, but I am still interested in OpenShift.

Kind of surprised you didn't do a sale to Heroku or DotCloud (or another PaaS or an IaaS), maybe as an aqui-hire. If nothing else, convert income into capital gains.

Sad to see you go. http://zipf.ep.io got me my first dev internship.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact