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