Hacker News Reader

Comment by derefr | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com