Hello! I'm part of the Convox core team and happy to answer any questions.
Convox is an app deployment platform that you can install into your own AWS account. It uses ECS, ELB, Kinesis, and many other great AWS services under the hood but automates it all away to give you a deployment experience even easier than Heroku.
Convox uses Docker under the hood so if you want to customize anything (distro, dependencies, etc) you can simply add a Dockerfile to your project.
Is there likely to be support for other clouds in the future? Amazon is great and you're far cheaper than Heroku itself but I'd love to throw this on DigitalOcean or Vultr.
Vultr's website looks... interesting. And their control panel is also... interesting. BUT.
I've been very impressed by the performance of my nodes.
Tops DigitalOcean easily. I don't have any hard numbers (I can provide some if people would like) but with the performance and number of locations they provide it's hard to beat.
Vultr also offers a "dedicated cloud" which I think is just dedicated resources — similar to RunAbove (http://www.runabove.com)
Whenever I talk about hosting, I seem like I'm affiliated with the providers. I am not :) I am simply a vet, a student, and a product of the hosting space.
If anyone has any questions, see my profile and reach out. I love to talk hosting :)
I'm also a big fan of Vultr, hence why I mention them :)
When I've run tests, they beat DO on every metric on unixbench (for equivalently priced/RAM filled instances [0][1]) and they let you use whichever ISOs/images you want (including fun stuff like BSD), unlike DO.
This looks like a really great idea. Does Convox provide a convenient way to set up SSL for custom domains? The custom domains page (https://docs.convox.com/docs/custom-domains) didn't say much about it, but I may just be looking in the wrong place.
Sorry I downvoted by mistake... I was trying to upvote so quickly that I pressed the wrong button. I love what you have built! Definitely spending the rest of the weekend playing with this...
We're using CloudFormation and Lambda to create and update everything.
The "convox" stack the installer creates makes a VPC, ASG, ECS cluster and ELB, and registers an ECS task and service for the API and private registry.
It also creates DynamoDB table for recording every build and release. And creates a KMS key for encrypting all the environment variables before we save them to S3.
An app stack the "convox deploy" command creates makes ECS tasks and services and an ELB for all the containers in `docker-compose.yml`, and creates a Kinesis stream for app logs.
Take a look at the CloudFormation tools as a starting point:
We don't yet, unfortunately, but we will add one soon.
If you'd like to see for yourself you can install it and then check the Resources tab on your CloudFormation page in the AWS web console to inspect everything it created.
Is anybody working full-time on the project? Are there plans to commercialize any aspects of this? How confident are you that the project will get to "1.0".
Thanks! Yes right now we have a small team working on this full time. We do plan to commercialize it, but intend to always keep it open source.
We're super confident it will get to a more mature state. We have some resources to keep working on it ourselves, and we're seeing lots of interest and participation from the open source community as well.
Yes! We have formed a business behind convox and current have a small team working on it full time. We are very confident that it will hit 1.0. Thanks for your interest :)
ECS is working out great for us. We host all of our own internal infrastructure on Convox and have been very happy.
The minimum per-application cost would be for an ELB. Counting the slice of runtime cluster needed to run it I'd estimate around $20-25 per app as a minimum.
> We also have plans on our roadmap to integrate with internal (inside the VPC only) ELBs for internal APIs and things of that nature.
This is what I'm getting at. Also just saw the issue pertaining to HIPAA, which probably requires the same thing.
Apps deployed on Empire apparently are only available inside the VPC unless a domain name is added, it doesn't actually work like that (when I deployed the Empire stack all boxes had public IPs and a security group allowing ingress from the internet 😓), but the idea is a good one I think.
Oh, and thanks. Knowing you're behind it I'm sure Convox will be great. I'm looking forward to watching it develop and using it myself.
Hey! Creator of Empire here. The demo stack we provide isn't suitable for production use as you found out already. Empire can definitely be deployed in a production ready manor where you can have internal and external services, which is how we have it setup at Remind. The docs are a little lacking right now unfortunately, but we'll be improving this in the future.
@ddollar: This is Michael from Livecoding.tv
Do you want to demo Convox live on Livecoding.tv?
Would be cool to see this in action and ask questions
My email is michael@livecoding.tv
Cool product! This is fairly unrelated but since you've open-sourced your code (thanks!) I was just browsing around the 'cli' project and saw heaps of the following:
if err != nil {
stdcli.Error(err)
return
}
Is this idiomatic Go? It's just sprinkled everywhere and makes it hard to follow logic at a glance.
Not sure how much it applies here as I haven't looked at the code, but the Golang blog has a good article that talks about how to "Simplify repetitive error handling"[1].
I work with Go at my day job and that's idiomatic. It's not the most beautiful or readable language for sure. This does force devs to think about error handling. Although it's not that different from code littered with exceptions (like some Java codebases).
Yes, there is a business behind Convox. The founders are all ex-Heroku engineers and have we all have a great deal of experience building this type of tooling and automation.
For now we are focused on building a great open-source platform.
How is this a private cloud if it's running on AWS which is most certainly a public cloud? I don't mean to take away from the product but I find the messaging to be odd.
My guess is that it's them playing slightly loose with the AWS term VPC: Virtual Private Cloud. My guess is that this is the way most people that have done work with AWS will understand their statement this way.
You're right. It's technically a virtual private cloud. We've found that nowadays VPC works for most people. The days of on-premises platforms are numbered.
Days numbered or not (aside: take a look around Fortune 1000 and you'll see it's alive and well) the term private cloud has a definition. Someone should come up with a term for subnets inside a public cloud.
The fact that Amazon offers Direct Connect shows that on-premises platform growth are certainly numbered but not the mere existence of them. Plenty of companies are still forcibly keeping their data in their own datacenters due to regulatory reasons despite desperately wanting to use third party providers. So until these regulations change (I'd bet it'll happen for PCI-DSS level 2+ before several federal ones unless FedRAMP supersedes them all) the largest possible users for AWS (and sadly, the most likely to benefit from it the most) are likely to be stuck operating stupidly expensive datacenters for pretty much no good reason besides making last-generation tech jobs.
It is similar to Deis in goals but it differs substantially in implementation. Because Convox runs on AWS we can rely on stable and scalable services only available on that platform such as ELB and DynamoDB. Deis uses its own internal Postgres and implements a custom load balancer, scheduler, etc. We believe using the hosted services will help you keep your operational costs down over time.
Creator of Empire here. Empire and Convox are kinda like brothers and sisters, both really similar in implementation and philosophy. There's a couple of subtle differences, like how Empire expects that you've already built a Docker image somehow, whereas Convox can just take some code and do it for you (hosts it's own docker registry). Convox also supports streaming logs, which is pretty awesome (although, coming soon to Empire too :)). Convox is a little more reliant on AWS, whereas Empire was designed to be able to work with other backends like Kubernetes for example (not implemented yet). I would say, use which ever one best suites your needs, they're both great, and like David said, we talk a lot and share ideas back and forth.
To me, AWS VPC is a game-changer for privacy. The isolation and network configuration options satisfy every need of a "private cloud" or "behind the firewall install".
The HIPAA-compliance was a nice mention. "zero-knowledge" privacy resonates with me as well when it comes to privacy, though I realize that's out of your control with AWS.
You're quite welcome! All three of the Convox founders are huge proponents of open source. We've already seen the benefit from this as a user has mapped out the missing pieces to host HIPAA-compliant applications on Convox and has already started making the necessary changes.
I would like to use Convox to spawn several instances of a Java app in order to benchmark Java messaging lib within the VPC (no ELB needed). Is Convox suitable for such use case?
Haven't had a chance to take it for a trial spin yet, but I was wondering if there is anything in here for applications that have a limited lifespan? Working on a system right now that would have the need for a "central" application that would need to regularly launch subworker apps for a specific task (planning on running each sub app on it's own micro AWS instance) and then "kill it off" once the job was completed.
Could someone familiar with Convox give us a brief answer to the question "how is this different from the myriad DevOps tools that Amazon provides for AWS?"
We're most familiar with OpsWorks. The main difference is simplicity. Convox doesn't require you to think much about infrastructure or write big JSON config files. We want the developer experience to be very app-focused like Heroku.
One of the great things about stuff like Convox and Empire is that, because they're built on existing stable technologies and utilize AWS managed services, you're basically asking if ELB, EC2 and ECS can scale. The most unstable component in all of this is probably Docker. In our experience running it in production at scale, it's faults have been pretty minor (things like push/pull being agonizingly slow) and failure modes get taken care of by ECS managing desired state well.
Yes, we have people using this in production, including ourselves! Most of the scale right now is on the small-to-moderate end but once your application is up and running you're really only limited by how much AWS you want to pay for :)
There is a tremendous amount of awesome work happening in this space. Tsuru is one such great project, thanks for adding it to the thread.
One big difference is that Convox uses managed services over writing and running our own components. For example, we use DynamoDB for saving build and release records. And we use ELBs for load balancing and routing.
This approach ties us closely to AWS, but results in a stack of infrastructure that has minimal operational overhead (e.g. Amazon is keeping DynamoDB Available, you don't have to manage an etcd cluster), and great scaling potential (vs tuning and scaling individual HAProxy nodes).
How does this compare to Cloud Foundry? Do they solve different problems and therefore should not be compared directly?
I can (and will) google this myself in an effort to triangulate and understand but I figure it would be valuable to hear from people who are more informed and experienced.
This is really great! I'm interested in trying this out for our products in place of OpsWork.
The documentations says "by default provisions an Elastic Load Balancer and 3 t2.small instances", is it possible to change the number/size of servers dynamically?
You can update an existing cluster using something like `convox system scale --count 5 --type c4.xlarge` from the CLI. If you change the instance type your cluster will be rolled one at a time with no downtime.
That's great. Is it possible to add additional servers after installation? I looked into the CLI project but I haven't found anything yet, the scale option appears to be for processes not servers.
Correct. It does default to us-east-1. The main reason is that we are using some fairly new AWS services that aren't launched in all regions, but we do want to and expect to expand to more regions.
It may be possible but it would take a substantial amount of work and I wouldn't recommend it. Convox achieves much of its stability and scalability from relying on hosted a AWS services.
Great product - exactly what I'm looking for in infrastructure. Was able to get a bunch of esoteric services up and running on AWS without having to pull out my hair.
This project looks AMAZING. I love what you guys are doing at Convox. The title of this post immediately caught my attention, because I've already spent what I consider far too much time figuring out how to deploy our application and would face the same problem with AWS.
Convox looks to help developers focus on their platform as opposed to how exactly it should be deployed when there are many options, even though most platforms can run and scale with a very similar setup. Great work guys. Looking forward to Google Cloud support!
Thanks for the input. Google's offerings are really picking up steam. We've been in touch with Google and are excited about expanding onto their infrastructure in the future.
Unless it has changed since I last look Dokku only runs on a single server.
The other major difference is that software like Dokku is trying to run anywhere. Because we are only trying to run on AWS we do not need to build custom schedulers, load balancers, routers, etc. We believe this will reduce your operational costs over time.
As one of the dokku maintainers, I wholeheartedly agree with ddollar. Convox seems extremely interesting to me, since our goal is a single-server heroku experience. I personally would never be able use Dokku in production exactly because of this, but its quite good for throw-away sites, as a test-bed for side projects, etc.
Good work ddollar. I quickly looked at the github repos and once I saw your name attached, I knew it was going to be a quality project :)
Currently we only offer Convox the open-source platform :) In the future we are considering paid support and other monetization strategies but the base platform itself will always be open-source and available for you to do with as you please.
You could run Wordpress today, afaik. Anything that can run in a Docker container can run on on Convox. You'd just need to use some sort of hosted database service like Amazon RDS to persist your data.
edit: Just looked at Wordpress a little closer. I didn't realize it expects a persistent filesystem, which I guess is what you're asking about. Convox follows the 12factor.net philosophy of ephemeral filesystems, so you'd need to figure out a way to persist files to S3 or similar...
Convox is an app deployment platform that you can install into your own AWS account. It uses ECS, ELB, Kinesis, and many other great AWS services under the hood but automates it all away to give you a deployment experience even easier than Heroku.
Convox uses Docker under the hood so if you want to customize anything (distro, dependencies, etc) you can simply add a Dockerfile to your project.
Convox is entirely open source. Check it out at https://github.com/convox
To get started with our installer go to: http://docs.convox.com/docs/getting-started-with-convox