Hacker News Reader

Comment by samcheng | Hacker News Reader

What about people who don't want Heroku (or Heroku-style) dynos as application servers and workers, because you pay excessively for RAM and CPU and wrestle with configuration constraints, but want to keep the rest of the PaaS ecosystem?

I'm comfortable maintaining a fleet of stateless application servers, but don't want to maintain my own database servers, or queue servers, or SSL endpoint, or logging aggregator, etc. etc.

Is this a feasible setup?

View on HN

At a previous company, we initially set everything up at Heroku. As things got cost prohibitive, we moved them one by one to AWS. Since Heroku is setup on AWS, it was easy enough to connect to our Heroku postgres instance from AWS web servers and it doesn't add any extra latency vs. running direct on Heroku. Over time, we slowly migrated everything off to our own infrastructure on AWS, but we were able to leverage Heroku to avoid all of that development effort until it was cost effective to do so. You'll need to deal with your own SSL endpoint if you run your web servers on AWS, but it's pretty trivial to do so with ELB.

Out of curiosity: does Heroku give you a better deal as you grow? I know for a fact Salesforce will discount their licenses more and more and you buy bigger quantities and sign up for longer contracts. It'd be surprising if Heroku doesn't do this at all...!

From my experience, no.

They have the opposite model: give it away to small players to hook them up, then rake it in from heavy users.

That's exactly the roadmap I had in mind. Glad to hear someone had success with this route!

Google or Amazon will both give you PaaS systems where you can run pretty much anything. I have more experience with kubernetes than AWS Container Engine.

Openshift and Cloudfoundry should give you alternative PaaS type systems which in arguably are less versatile but more complete.

Take a look at Convox, convox.com.

It's an open source "PaaS" that runs in your own AWS account.

It's a thin configuration layer for AWS. So you get easy access to ECS for running your app servers at resource cost, then simple tooling for adding an RDS database, adding a Heroku Postgres URL to you app env, or adding to Papertrail.

Full disclosure: I work on Convox full time.

It's certainly feasible. Your containers run on a public cloud, just as Heroku does, which enables access to things like logging-as-a-service. But you'll soon find that such services are just as horrifically marked up as Heroku, because they too are middlemen who need to make money. (I'm referring to services like Loggly or Logentries, to continue with the logging example.)

We've been really enjoying AWS's hosted ElasticSearch, PostgreSQL, Elastic Load Balancer, etc. Most of the benefits of a hosted service at the cost of an EC2 instance.

Definitely agree that the other services are marked-up too! The issue is one of leveraging developer time at a dynamic startup. At some scale, it becomes cost-effective to manage your own application cluster. At some (usually larger?) scale, it becomes a good idea to administrate your own database cluster. We're definitely not big enough to consider managing our own RabbitMQ or log aggregator or other ancillary services from a developer-time opportunity cost/benefit perspective, though!

FWIW Cloudwatch has logs service.

Read up on MSaaS or CaaSi: http://venturebeat.com/2015/05/09/goodbye-saas-hello-contain....

The promise of this stuff is that you run the servers and control what gets deployed, but the vendors manage the software for you, like they do with SaaS. Is that what you are asking for?

Database servers - AWS RDS

Queue servers - AWS SQS

SSL termination - AWS ELB

Logging aggregator - depends on how you're deploying. We're deploying our containers onto elastic container service and adding one of these: https://github.com/gliderlabs/logspout to each instance. Elastic beanstalk will do the log aggregation for you

Isn't this exactly what AWS offers?

Yes and no. Amazon is mostly IaaS in its outlook -- the closest they come to a "true" PaaS would be Lambda.

What you get from Amazon is a box full of building blocks, which you have to assemble yourself. For many people that is compelling. For others it is daunting. PaaSes are there for the second group -- an architecture-in-a-box.

I'd argue that Elastic Beanstalk, too, is Amazon's explicit attempt to package and present AWS as a PaaS.

Elastic Beanstalk is the Amazon PaaS offering. Lambda is much more like a BaaS provider - it abstracts away the concept of a server entirely, and instead just gives you an API to execute code on some cloud service.

You're right. I overlooked Beanstalk.

to a degree, i guess. On AWS there are a lot of services, which would qualify as PaaS offerings. Even on Rackspace, you get Databases (and HA Groups), Load-Balancers (w/ SSL termination), Queues (albeit the obscure, OpenStack one) and ElasticSearch for Logging (the latter is pretty hefty priced IMO, though).

So we're able to run quite a lot of stateless 12factor-like services on Rackspace (using kubernetes), RabbitMQ being the exception we have to manage ourselves (which sucks).

> Is this a feasible setup?

Yes, there are open source PaaSes you can install privately or on an IaaS provider.

I like Cloud Foundry, some people like OpenShift. There are others emerging as well.

It's not a matter of if you could, but of if you should. In OP's case, clearly not.

Right. In another time, we had racks of 1U servers, a NAS cluster with fast backplane, redundant switching fabric, a tape library, and fiber to the meetup room.

This time around, if we were worrying about anything like that, it would be a distraction from the product!

Reply on news.ycombinator.com