Rack: Open-Source PaaS on AWS
github.com
github.com
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.
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.)
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.
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.
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 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
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.
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.
Scale has been great. We have customers running hundreds of containers on a single app without breaking a sweat.
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!
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.
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.
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.
I'm happy to answer any questions you have about Rack or any of Convox's other offerings.
To join a discussion with our user community please join our Slack! https://invite.convox.com
Our other main offering is a web console for managing your team's access to rack(s) and integrations with 3rd party services. https://console.convox.com We charge a subscription fee for that and we also sell support and services packages.
I've looked through a couple of the previous threads and didn't find much on this.
This is a level of abstraction above ECS, which Beanstalk uses behind the scenes for multi-container installations.
If you think about it, it's like Heroku for docker, you handle "apps", and the rest is handled by Rack.
This is how I understand it.
* Simple
* Configures AWS resources uniformly run your app
* Uses Docker
Some advantages to using Convox instead of Elastic Beanstalk:
* More flexibility in the experience. Convox has a simpler API and CLI for end users.
* More flexibility in the infrastructure. We can pick and choose the best infrastructure components and constantly evolve.
* Less lock in. This is speculative but having a thin layer between you and AWS could help with portability.
AWS is awesome but their values might not exactly align with your organization.
There are general advantages to letting the Convox team and community guide you through your cloud journey.
We value developer experience where AWS simply doesn't. Our plans include things AWS will never add to EBS like automating dashboards, monitoring and alerts.
We are moving a lot faster. Convox has swap and CloudWatch Logs integration where ECS doesn't.
Does Convox continue to use hosted AWS services?
I like the idea of the App being containerised and that workflow, but I cannot convince myself that running DB/Cache in something like Convox is a good idea (vs Hosted in AWS).
Can you give your thoughts?
We do not run dbs as containers other than for dev or testing.
'convox services add postgres' and 'convox services add redis' provisions RDS and Elasticache respectively.
For example SNS. Would convox ever support terraform/cloudformation for an App, or would you add SQS service in convox, then create SNS outside of convox, and then join them together somewhere else?
Is a thing.
Automatic provisioning services should be easy.
Your rack and all your apps and services are CloudFormation stacks. We favor CloudFormation over terraform for the same reason, it's a managed service.
The dream is fully automated provisioning of everything you want inside a single AWS account and VPC.
Then you can peer this VPC with another to keep linking things.
The framework is open source so it's pretty easy for us or anyone to add more services when requested. SES would be a good one next.
I think rack is a pretty good name for something that is meant to be the infrastructure for running services. Not sure of the etymology for this project, but to me it conveys images of a server rack in a datacenter.
Next up a JavaScript framework called Rake because who uses Ruby anymore.
Thank you for commenting :)
More importantly, who cares? It was a common 4 letter word used to describe an item that holds stuff a hell of a long time before it was a Ruby thing.
Ruby programmers are a... dedicated bunch.
http://www.indeed.com/jobtrends/q-rails-q-ruby-q-javascript-...
Seems like this is likely to reflect something other than changes in language popularity. Frankly the data doesn't seem very interesting without correcting for other factors such as total volume of jobs.
Overall, Ruby looks pretty much as popular today as 3 years ago to me from that data, though perhaps with Rails in a downwards trend (awesome - I love Ruby, but finding Ruby work that doesn't imply Rails is harder, and I don't like Rails).
But it's besides the point anyway. I simply explained why someone mentioned Rack, I don't particularly care either way (probably because I don't really care about Convox Rack - I'd never use a single vendor solution like this, and haven't exactly hidden how overpriced I find AWS in past comments).
I don't see a problem with two items have the same name provided the functionality they provide is substantially different. Nobody is going to get confused over whether they are referring to the PaaS application or a Ruby library in everyday conversation.
The naming collision with the Ruby interface is unfortunate, but we figured it was pretty easy to tell them apart from context.
However, it will muddy the waters for people trying to solve problems in future. For example, this tag on StackOverflow: http://stackoverflow.com/questions/tagged/rack
Naming is hard.
"Convox" is the company and platform.
Rack is a project code name but it is a noun you come across when using the platform too. For example the 'convox rack update' command delivers API and infrastructure improvements.
https://github.com/ddollar/foreman (Convox employee)