Hacker News Reader

Comment by nzoschke | Hacker News Reader

One of the maintainers of Convox/rack here...

A few important differences between Convox and other options in the space.

AWS only. We use lots of AWS services to piggy back on all the reliability AWS has baked in. For example we use DynamoDB to record all your builds because none of us want to manage a Postgres for record keeping.

Open source. The layer between you and your AWS account is open, transparent, and modifiable.

Simple. I want to remove as many moving parts as possible, not add a heavy middleware.

View on HN

Hey there, thanks for putting this out as open source.

Curious: what's your business model? I am starting to write a book about open source business models and I would be interested in hearing your thoughts. Thanks!

I asked the same question in a thread about Convox a few months ago (https://news.ycombinator.com/item?id=10796165). Their reply from that thread might help:

nzoschke 134 days ago

> Thanks for your question. A much more thorough pricing page is in the works.

> The most straightforward model, and where we are already making some money, is running a Convox as a managed service.

> In this setup you and your team get Convox API keys. Convox installs, runs and updates everything for you in our accounts. You get a monthly bill that's your AWS resource costs plus a percentage to Convox for management.

> We will be tweaking this model to sell packages so bills are really easy to understand.

> Some other experiments we're doing...

> We sell support packages and professional services for app setup, migration and custom feature development.

> We have a per-seat model for productivity features. Private GitHub repos and Slack integrations are $19 / user / month. There are more closed SaaS tools like this coming.

> Infra is trending to commodity prices industry wide.

> We'll be selling SLAs, support, productivity tools on top of that infra.

> You'll get a cutting edge private platform without hiring and managing your own devops team to build and maintain it.

> Open source users will help grow the user base and make the platform better without us running a freemium platform.

The business model is around a closed management console service: console.convox.com.

We sell features for teams like workflows and auditing as a monthly subscription.

We also sell some support plans all the way up to some hefty professional services around getting your team and apps migrated.

The usual model of 'platform companies' is to get their platform adopted by giving it away for free/opensource. They charge for support, migration etc.

Docker. Docker is working incredibly well in production and in development, particularly if you use only a subset of its features. We're relying on Docker as much as possible for building and deploying your apps.

Having built an entire app stack atop it, what's your opinion of ECS? Specifically on the scale of easy/works to painful/bend-to-will?

I recently wrote up a lot about this:

https://convox.com/blog/ecs-challenges/

TL:dr it works very well. It's very flexible. But Amazon is still very hard for a lot of reasons.

One piece of data to share is that with ECS we are effortlessly running hundreds of production clusters and thousands of test clusters.

I'm not sure we could do this if ECS didn't exist.

ECS is incredibly powerful but definitely a lower-level primitive. We look at it sort of like a Kubernetes that we don't have to run for ourselves.

Scale has been great. We have customers running hundreds of containers on a single app without breaking a sweat.

Workflow / app / developer focused. With convox you deal with `apps`, `certs`, `builds` and `logs`. All the low level details are hidden. I think most people dont want to or shouldn't worry about "containers".

The thing with "containers" is that they're portable. I want, ideally, to assemble and test my app build in a sort of local micro-copy of the production infrastructure, then push something bit-for-bit identical to that build to the real production infrastructure. Containers easily enable that; source-code-push services leave it an open question.

Though, really, if your app uses a lot of fancy IaaS service APIs, even the container-oriented approach still isn't a full answer to enabling dev-time local testability with production parity.

(Personally, I'm waiting for a "mock AWS in a box"—a single binary that presents itself as many IaaS service machines on a virtual network interface it creates, without actually doing any of the heavyweight computation required to run e.g. OpenStack's DevStack. So the VMs wouldn't be VMs but just network-IO-level mocks, etc. I'd love to plug that some application Docker containers into that.)

This is a really great point. So far our strategy for this has been to build containers that mock various AWS services locally. This approach is still a bit experimental but please feel free to check out these repos:

https://github.com/convox/aws-dynamodb

https://github.com/convox/aws-s3

Indeed that's the way to go, I bet it will also increase enterprise adoption too as it reduces tie in with AWS.

An 'AWS-to-go' would be fantastic. I will always use AWS in production, but would be nice to have a lightweight dev equivalent. Especially now that I use Lambda a lot.

Cloud Foundry can be run on a laptop, using PCF Dev[0].

And of course it runs on AWS, OpenStack, vSphere, Azure and GCP is underway.

Disclaimer: I work for Pivotal, the main donor of engineering effort to CF.

[0] http://pivotal.io/pcf-dev

I can tell CF is really great these days and making companies really successful.

My impression is that it is a killer enterprise platform but really heavy for a lot of use cases.

Do you see small teams adopting it and setting it up and maintaining an install?

Convox hits a real sweet spot here due to its simplicity.

I think the argument that Convox is a good fit for AWS-only shops has a lot of merit. Specialising comes with different benefits from generality.

I and many others have been saying for a long time that CF is hard to approach due to its completeness and the all-or-nothing power of BOSH. PCFDev is chipping away at some of it; the bosh-boatloader[0] project should take away a lot of the remaining "this is too hard to install" pain.

That said, yes, you can run very large installations of CF with small teams. The whole of Pivotal Web Services is run by 2 shifts of the Cloudops team, I think 2-4 pairs each. What makes that possible is BOSH, which solves the everliving daylights out of deploying and repairing software on an IaaS.

And we have some more cool stuff coming :)

[0] https://github.com/pivotal-cf-experimental/bosh-bootloader

Makes sense.

Convox uses containers and images everywhere behind the scenes. But containers are a means not an end.

In general people want automated and reliable deployments.

What are the other options in this space :-) ? I am only aware of empire.

Empire is great. That team really knows what they are doing too.

CloudFoundry and Deis are other open source PaaS projects.

Swarm, Mesos and Kubernetes are other open source schedulers on top of which you can build a deployment system.

Cloud Foundry is my own pet favourite, since I work for the company doing the biggest share of engineering. But people sometimes overlook that Red Hat have repackaged Kubernetes into OpenShift Origin.

Take a look at tsuru.io.

Reply on news.ycombinator.com