7 ms·

I definitely agree that better tutorials and/or a simpler interface would makes AWS more accessible and user friendly. A YC S15 startup, Convox (http://convox.

I definitely agree that better tutorials and/or a simpler interface would makes AWS more accessible and user friendly. A YC S15 startup, Convox (http://convox.com/ http://convox.com/), aims to "make AWS as easy as using Heroku." It looks really promising.

autotune 11y ago
There are also quite a few Ansible core modules for EC2 if you're looking for a uniform way to manage your resources outside of the AWS GUI, although to be honest I'm not sure if that's "easier" so much as more flexible. Still solves the problem with mistake #1.
- manojlds 11y ago
  Would recommend Terraform here - https://terraform.io/ https://terraform.io/
- obulpathi 11y ago
  Try Kubernetes may be?
  - paulddraper 11y ago
    That's for containers. It isn't used to, say, setup SQS.
jacques_chester 11y ago
As an alternative, Cloud Foundry already drives AWS, as well as Azure, vSphere and OpenStack. Those coming from Heroku will find most of what they want, including buildpacks. Those who want to skip buildpacks can use docker images instead. Disclaimer: I work for Pivotal, who donate the majority of the engineering effort to CF.
- nzoschke 11y ago
  Convox member here. CloudFoundry is a really solid platform, but there is a very important distinction between CloudFoundry and Convox. Convox is a very thin layer on top of "raw" AWS. It gives you a PaaS abstraction but behind the scenes is well configures VPC, ECS, Kinesis, Lambda, KMS, etc. For those of us with no need to run on multiple clouds, using pure AWS is simpler, cheaper and more reliable than a middleware like CloudFoundry or Deis. If you want to run a private platform without bringing in operation dependencies like etcd (Deis) or Lattice (CloudFoundry), give Convox a look.
  - querulous 11y ago
    how does convox scale when moving to non-trivial aws scenarios? if i have three autoscale groups running seven different apps with associated kinesis streams, s3 buckets, elasticache, rds and elasticsearch instances how cleanly does convox handle this? what about monitoring and reporting?
    - nzoschke 11y ago
      We are working to normalize the AWS scenario for all apps. Every Convox cluster is an autoscale group managed cluster of ECS instances. Every Convox app gets its own Kinesis stream for logs, ELB for load balancing, and S3 buckets for settings, build artifacts and encrypted environment. And the app processes are run via ECS. So I'm confident we could handle the 7 apps in a single cluster, scale the cluster instance size and count, scale any individual app process type, and handle any individual app load balancing or log throughput. You can provision some services like RDS with our tooling which make it really easy to link to apps. You can also bring your own services like elasticsearch or pre-existing RDS and set them in an app's environment to use it. There are a couple monitoring tools built in. We automatically monitor AWS events like ECS capacity problems and send Slack notifications. You can also use our tooling to forward all your logs to Papertrail and configure your searching and alerting there. More CloudWatch Logs and Metrics work is coming in the near future.
      - 11y ago
nzoschke 11y ago
Convox member here. Thanks for the shout out. This is definitely a goal of Convox: to remove as much AWS complexity as possible. Our approach matches this guide to a tee. We are using CloudFormation to set up a private app cluster, as well as to create and update (deploy) apps. We are also using ASGs. The instance utilization point is spot on too. The fist thing convox does to make this easy is a single command to resize your cluster safely (no app downtime). Coming next is monitoring if ECS and CloudWatch and Slack notifications if we detect over or under utilization. I strongly believe that these AWS best practices can and should be available for everyone. For anyone starting from scratch or migrating apps off a platform or EC2 Classic onto "modern" AWS.
- davidbarker 11y ago
  I hadn't heard of Convox before, but it sounds interesting. I'd like to use AWS more, but each time I tried to get into it I felt overwhelmed. I currently use PagodaBox a lot, which is great (most of the time) because it handles a lot of the complexity for me, but it can often be expensive. How does Convox compare to PagodaBox?
  - nzoschke 11y ago
    I've never used PagodaBox but it looks like a nice PaaS. Convox has the same goal of a PaaS: to give you and your team an easy way to focus on your code and never worry about your infrastructure. One big difference with Convox is that we accomplish this with single-tenant AWS things. You and your team's deployment target is an isolated VPC, ECS (EC2 container service), and ELB (load balancers). If you're asking for a cost comparison, we're building Convox to be extremely cost competitive by unlocking AWS resource costs for everyone. Its easiest to compare the cost of memory across platforms, though not always apples to apples... The base Convox recommendation is 3 t2.smalls which is 6 GB of memory which costs about $100 / month. If your app can be sliced up into 512 MB processes, you can easily run 10 processes, which could be 2 to 5 medium traffic PHP apps on the cluster. I'm finding PagodaBox pricing calculator a bit confusing but 6 512 MB processes, so 3 GB of memory, is $189.
    - 11y ago

autotune 11y ago

There are also quite a few Ansible core modules for EC2 if you're looking for a uniform way to manage your resources outside of the AWS GUI, although to be honest I'm not sure if that's "easier" so much as more flexible. Still solves the problem with mistake #1.

manojlds 11y ago
Would recommend Terraform here - https://terraform.io/ https://terraform.io/
obulpathi 11y ago
Try Kubernetes may be?
- paulddraper 11y ago
  That's for containers. It isn't used to, say, setup SQS.

jacques_chester 11y ago

As an alternative, Cloud Foundry already drives AWS, as well as Azure, vSphere and OpenStack. Those coming from Heroku will find most of what they want, including buildpacks. Those who want to skip buildpacks can use docker images instead. Disclaimer: I work for Pivotal, who donate the majority of the engineering effort to CF.

nzoschke 11y ago
Convox member here. CloudFoundry is a really solid platform, but there is a very important distinction between CloudFoundry and Convox. Convox is a very thin layer on top of "raw" AWS. It gives you a PaaS abstraction but behind the scenes is well configures VPC, ECS, Kinesis, Lambda, KMS, etc. For those of us with no need to run on multiple clouds, using pure AWS is simpler, cheaper and more reliable than a middleware like CloudFoundry or Deis. If you want to run a private platform without bringing in operation dependencies like etcd (Deis) or Lattice (CloudFoundry), give Convox a look.
- querulous 11y ago
  how does convox scale when moving to non-trivial aws scenarios? if i have three autoscale groups running seven different apps with associated kinesis streams, s3 buckets, elasticache, rds and elasticsearch instances how cleanly does convox handle this? what about monitoring and reporting?
  - nzoschke 11y ago
    We are working to normalize the AWS scenario for all apps. Every Convox cluster is an autoscale group managed cluster of ECS instances. Every Convox app gets its own Kinesis stream for logs, ELB for load balancing, and S3 buckets for settings, build artifacts and encrypted environment. And the app processes are run via ECS. So I'm confident we could handle the 7 apps in a single cluster, scale the cluster instance size and count, scale any individual app process type, and handle any individual app load balancing or log throughput. You can provision some services like RDS with our tooling which make it really easy to link to apps. You can also bring your own services like elasticsearch or pre-existing RDS and set them in an app's environment to use it. There are a couple monitoring tools built in. We automatically monitor AWS events like ECS capacity problems and send Slack notifications. You can also use our tooling to forward all your logs to Papertrail and configure your searching and alerting there. More CloudWatch Logs and Metrics work is coming in the near future.
    - 11y ago

nzoschke 11y ago

Convox member here. Thanks for the shout out. This is definitely a goal of Convox: to remove as much AWS complexity as possible. Our approach matches this guide to a tee. We are using CloudFormation to set up a private app cluster, as well as to create and update (deploy) apps. We are also using ASGs. The instance utilization point is spot on too. The fist thing convox does to make this easy is a single command to resize your cluster safely (no app downtime). Coming next is monitoring if ECS and CloudWatch and Slack notifications if we detect over or under utilization. I strongly believe that these AWS best practices can and should be available for everyone. For anyone starting from scratch or migrating apps off a platform or EC2 Classic onto "modern" AWS.

davidbarker 11y ago
I hadn't heard of Convox before, but it sounds interesting. I'd like to use AWS more, but each time I tried to get into it I felt overwhelmed. I currently use PagodaBox a lot, which is great (most of the time) because it handles a lot of the complexity for me, but it can often be expensive. How does Convox compare to PagodaBox?
- nzoschke 11y ago
  I've never used PagodaBox but it looks like a nice PaaS. Convox has the same goal of a PaaS: to give you and your team an easy way to focus on your code and never worry about your infrastructure. One big difference with Convox is that we accomplish this with single-tenant AWS things. You and your team's deployment target is an isolated VPC, ECS (EC2 container service), and ELB (load balancers). If you're asking for a cost comparison, we're building Convox to be extremely cost competitive by unlocking AWS resource costs for everyone. Its easiest to compare the cost of memory across platforms, though not always apples to apples... The base Convox recommendation is 3 t2.smalls which is 6 GB of memory which costs about $100 / month. If your app can be sliced up into 512 MB processes, you can easily run 10 processes, which could be 2 to 5 medium traffic PHP apps on the cluster. I'm finding PagodaBox pricing calculator a bit confusing but 6 512 MB processes, so 3 GB of memory, is $189.
  - 11y ago