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.
> 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.
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.
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.
@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
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 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.
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:
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".
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 :)
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.
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.
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.
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 :)
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.
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 :)
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.
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.
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.
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!
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.
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.
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).
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].
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.
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".
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.
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.
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).
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...
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.
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.
117 comments
[ 5.0 ms ] story [ 178 ms ] threadConvox 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
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.
Currently the EC2 instances in your Convox installation all have public IP addresses but this is currently being addressed
https://github.com/convox/kernel/issues/92
We actually have a production ready example stack using our stack provisioning tool called stacker: https://github.com/remind101/stacker/pull/43.
And what's your minimum per-application cost for single-container Docker web app with SSL?
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.
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.
$50 credits for two months: http://vultr.com/freetrial
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 :)
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.
Their SATA storage nodes are really handy too.
You didn't post numbers but here are mine:
[0] Vultr benchmark: https://gist.github.com/bobobo1618/0972fc51f49d90fb37af
[1] DigitalOcean benchmark: https://gist.github.com/bobobo1618/81aa3f413b99aaab1f0d
SSL setup isn't in the product yet, but it's coming soon. For now you can set up SSL using the AWS cli: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
We're excited about it, too. Hit us up via the www.convox.com Intercom button or support@convox.com if you have any questions.
Do you perhaps have a writeup or something about the convox architecture? (Which AWS services it uses, how etc)
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.
https://docs.convox.com/docs/getting-started-with-convox
You can uninstall when you're done to avoid paying for the AWS resources if you're not ready to use it yet.
https://docs.convox.com/docs/uninstall-convox
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:
https://github.com/convox/kernel/blob/master/dist/kernel.jso... https://github.com/convox/app/blob/master/template/staging.t...
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".
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.
https://github.com/convox/kernel/issues/92
- http://deis.com/
- https://github.com/deis/deis
(Empire: https://github.com/remind101/empire, http://engineering.remind.com/introducing-empire/)
The primary difference is that Convox is backed by a company for which this is our product and has a full-time team dedicated to it.
+1 Check out Convox and Empire. See which one works best for you.
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.
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 :)
For now we are focused on building a great open-source platform.
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!
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?
https://github.com/convox/cli/pull/48
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.
[1]https://blog.golang.org/error-handling-and-go
The privacy of "?". Was waiting for this part since it was included in the title.
"The privacy of your own data center."
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".
https://en.wikipedia.org/wiki/Cloud_computing#Private_cloud
https://cloudron.io/
(Cofounder of cloudron.io here)
Cloudiron.io looks cool. I'll definitely check it out.
https://tsuru.io/
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).
https://github.com/roots/bedrock
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...
Can apps be launched in specific regions?
edit: Looks like it defaults to us-east-1. I'd much prefer to use Sydney due to the latency here in AU :)
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.