5 ms·

Disclaimer: I work for Salesforce, Heroku’s parent company. When Fargate was released I was very curious about it as it seemed like AWS was moving up the ladde

Disclaimer: I work for Salesforce, Heroku’s parent company. When Fargate was released I was very curious about it as it seemed like AWS was moving up the ladder towards PaaS and I wanted to know how it compares to Elastic Beanstalk and also Heroku. I started going through this AWS written tutorial: https://aws.amazon.com/getting-started/projects/build-modern-app-fargate-lambda-dynamodb-python/module-two/ https://aws.amazon.com/getting-started/projects/build-modern... The app they use as an example is of course meant to demonstrate how a plethora of AWS services can work together. I still couldn’t help but be surprised at the sheer number of different things I had to learn and configure, sometimes involving editing yaml. For long time AWS users: is that tutorial representative of how you really build apps in AWS?

sudhirj 7y ago
Yes. The Heroku developer is still fantastic and pretty unique, and hasn’t been replicated (yet). If Heroku intends to maintain the lead, it’ll have to keep moving - the new offerings like Kafka and Redis before a pretty good - providing S3, SNS and SQS as addons would also be pretty great - right now one still needs to drop into AWS for these services. Heroku also really needs to wake up to the world outside the US and Europe. Just enabling the other regions (for general use, not the super expensive private spaces) would be a step on the right direction.
joncrane 7y ago
Yeah, seems about right for a tutorial. In real life things are never as simple or well suited to the underlying technology so it's lots of painful little missteps until you get it "just right" for your use case and the strange rules you're subject do because of your organization.
throwawayFCfan 7y ago
That is exactly it, except sometimes you're editing or copy-pastaing JSON instead of YAML. I've often assumed that no one's KPIs are tied to making things more usable or docs more readable, and everyone's KPIs are tied to shipping new features.
- NathanKP 7y ago
  As an AWS employee on the container services team one of my KPI's is definitely making things more usable. Have you seen the AWS Cloud Development Kit? (https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk) It is a more powerful infrastructure as code framework that can docker build, docker push, and run an AWS Fargate task with just a few lines of declarative TypeScript or Python code. You can see some examples here in the "ecs-patterns" module: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-ecs-patterns-readme.html https://docs.aws.amazon.com/cdk/api/latest/docs/aws-ecs-patt... In general I'd say that AWS takes the approach of offering a lot of configurability if you need to tweak things. You can go into that low level JSON or YAML if you want, but we are also providing higher level tools like AWS CDK which do the work for you, and let you just focus on building your app with just a few lines of code. I'd say that the referenced tutorial is aimed at being "mid level". It abstracts some things but still shows a lot of the lower level settings you can tweak directly. If you want a more abstracted, higher level getting started experience you should start with a tutorial for a higher level tool like AWS Cloud Development Kit, and use that to automatically setup and deploy to AWS Fargate under the hood. If you (or anyone else reading this) have any specific feedback on things you want to see made more usable, or docs that aren't readable feel free to email me using the address in my HN profile.
  - davidjnelson 7y ago
    Thanks for making the cdk! It’s awesome. Would love docs / examples on how to connect to aurora serverless from fargate with secrets in kms. Also, auto rotating certificates for the load balancer. And lastly, a fully functional ci/cd pipeline with staging/prod and backfilling aurora serverless from prod->staging, and also how to import data into aurora serverless from a postgres dump, and how to get aurora serverless data copied to a local postgres. Thanks!
    - NathanKP 7y ago
      Great suggestions! Thanks for the feedback!
peterwwillis 7y ago
I use Fargate because it's not a PaaS. I don't want to use a platform, I want something to schedule my containers for me. (Granted, AWS is a platform, but not how you mean, I guess) Most people don't write good tutorials. Often what they're trying to teach you is ambiguous, they don't clearly define what the dependencies are, and they don't provide clear steps. AWS's docs are not great, but same goes for everybody else.
syntheticcdo 7y ago
That tutorial is representative of if you want to go all in on AWS and have your developers live and breathe in AWS. Everything in the Architecture Diagram of Module 2C are definitely necessary pieces of modern software development, you could easily replace as follows: AWS Cloud9 --> VSCode AWS CodeCommit --> GitHub AWS CodePipeline + AWS CodeBuild --> CircleCI So in any case you are configuring _something_.
auslander 7y ago
> surprised at the sheer number of different things I had to learn and configure AWS is complex just enough for production infra requirements. They don't make some stuff up just for fun :) Heroku is more for prototyping or personal blogs, imho.
- crcastle 7y ago
  Disclaimer: I'm employed by Salesforce, and I work on Heroku. I agree Heroku has the perception of being only for prototyping projects or small projects. It does work great for those. But also, there are lots of large companies (with non-trivial and large scale deployments) using Heroku, such as Macy's and Toyota and many others I can't mention without their permission. https://www.heroku.com/customers/case-studies https://www.heroku.com/customers/case-studies
  - auslander 7y ago
    Those companies did not yet run price/performance analysis probably.
    - crcastle 7y ago
      Possibly, but heroku does not try to optimize for price/performance. It tries to optimize for price/shipping production software, which includes performance but also lots of other things like ability for application developers to iterate quickly and the human hours saved configuring and operating infrastructure.
013a 7y ago
AWS couldn't build a Heroku-like PaaS if their entire business depended on it. They're organizationally incapable of something so simple, beautiful, and productive. I legitimately believe there's a checklist at the bottom of every new AWS service launch, and among their internal requirements includes a line like "Is this product so amazingly incomprehensible that customers will take weeks to integrate with it and be forced to upgrade to a technical support plan?" The closest any major cloud player has gotten is App Engine. And its pretty close; it has issues, and some inherent complexity, but generally I recommend any new startups look to either App Engine or Heroku for hosting. Avoid AWS like the plague.
- auslander 7y ago
  > Avoid AWS like the plague Autoscaling: Heroku - 2017, AWS - 2009.
  - 013a 7y ago
    Fortunately, the current year is 2019. If you're having issues determining the current year, I would recommend running the "date" command, available on any UNIX terminal.
auslander 7y ago
"Heroku’s physical infrastructure is hosted and managed within Amazon’s secure data centers and utilize the Amazon Web Service (AWS) technology", I did not know that. https://www.heroku.com/policy/security https://www.heroku.com/policy/security

sudhirj 7y ago

Yes. The Heroku developer is still fantastic and pretty unique, and hasn’t been replicated (yet). If Heroku intends to maintain the lead, it’ll have to keep moving - the new offerings like Kafka and Redis before a pretty good - providing S3, SNS and SQS as addons would also be pretty great - right now one still needs to drop into AWS for these services. Heroku also really needs to wake up to the world outside the US and Europe. Just enabling the other regions (for general use, not the super expensive private spaces) would be a step on the right direction.

joncrane 7y ago

Yeah, seems about right for a tutorial. In real life things are never as simple or well suited to the underlying technology so it's lots of painful little missteps until you get it "just right" for your use case and the strange rules you're subject do because of your organization.

throwawayFCfan 7y ago

That is exactly it, except sometimes you're editing or copy-pastaing JSON instead of YAML. I've often assumed that no one's KPIs are tied to making things more usable or docs more readable, and everyone's KPIs are tied to shipping new features.

NathanKP 7y ago
As an AWS employee on the container services team one of my KPI's is definitely making things more usable. Have you seen the AWS Cloud Development Kit? (https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk) It is a more powerful infrastructure as code framework that can docker build, docker push, and run an AWS Fargate task with just a few lines of declarative TypeScript or Python code. You can see some examples here in the "ecs-patterns" module: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-ecs-patterns-readme.html https://docs.aws.amazon.com/cdk/api/latest/docs/aws-ecs-patt... In general I'd say that AWS takes the approach of offering a lot of configurability if you need to tweak things. You can go into that low level JSON or YAML if you want, but we are also providing higher level tools like AWS CDK which do the work for you, and let you just focus on building your app with just a few lines of code. I'd say that the referenced tutorial is aimed at being "mid level". It abstracts some things but still shows a lot of the lower level settings you can tweak directly. If you want a more abstracted, higher level getting started experience you should start with a tutorial for a higher level tool like AWS Cloud Development Kit, and use that to automatically setup and deploy to AWS Fargate under the hood. If you (or anyone else reading this) have any specific feedback on things you want to see made more usable, or docs that aren't readable feel free to email me using the address in my HN profile.
- davidjnelson 7y ago
  Thanks for making the cdk! It’s awesome. Would love docs / examples on how to connect to aurora serverless from fargate with secrets in kms. Also, auto rotating certificates for the load balancer. And lastly, a fully functional ci/cd pipeline with staging/prod and backfilling aurora serverless from prod->staging, and also how to import data into aurora serverless from a postgres dump, and how to get aurora serverless data copied to a local postgres. Thanks!
  - NathanKP 7y ago
    Great suggestions! Thanks for the feedback!

peterwwillis 7y ago

I use Fargate because it's not a PaaS. I don't want to use a platform, I want something to schedule my containers for me. (Granted, AWS is a platform, but not how you mean, I guess) Most people don't write good tutorials. Often what they're trying to teach you is ambiguous, they don't clearly define what the dependencies are, and they don't provide clear steps. AWS's docs are not great, but same goes for everybody else.

syntheticcdo 7y ago

That tutorial is representative of if you want to go all in on AWS and have your developers live and breathe in AWS. Everything in the Architecture Diagram of Module 2C are definitely necessary pieces of modern software development, you could easily replace as follows: AWS Cloud9 --> VSCode AWS CodeCommit --> GitHub AWS CodePipeline + AWS CodeBuild --> CircleCI So in any case you are configuring _something_.

auslander 7y ago

> surprised at the sheer number of different things I had to learn and configure AWS is complex just enough for production infra requirements. They don't make some stuff up just for fun :) Heroku is more for prototyping or personal blogs, imho.

crcastle 7y ago
Disclaimer: I'm employed by Salesforce, and I work on Heroku. I agree Heroku has the perception of being only for prototyping projects or small projects. It does work great for those. But also, there are lots of large companies (with non-trivial and large scale deployments) using Heroku, such as Macy's and Toyota and many others I can't mention without their permission. https://www.heroku.com/customers/case-studies https://www.heroku.com/customers/case-studies
- auslander 7y ago
  Those companies did not yet run price/performance analysis probably.
  - crcastle 7y ago
    Possibly, but heroku does not try to optimize for price/performance. It tries to optimize for price/shipping production software, which includes performance but also lots of other things like ability for application developers to iterate quickly and the human hours saved configuring and operating infrastructure.

013a 7y ago

AWS couldn't build a Heroku-like PaaS if their entire business depended on it. They're organizationally incapable of something so simple, beautiful, and productive. I legitimately believe there's a checklist at the bottom of every new AWS service launch, and among their internal requirements includes a line like "Is this product so amazingly incomprehensible that customers will take weeks to integrate with it and be forced to upgrade to a technical support plan?" The closest any major cloud player has gotten is App Engine. And its pretty close; it has issues, and some inherent complexity, but generally I recommend any new startups look to either App Engine or Heroku for hosting. Avoid AWS like the plague.

auslander 7y ago
> Avoid AWS like the plague Autoscaling: Heroku - 2017, AWS - 2009.
- 013a 7y ago
  Fortunately, the current year is 2019. If you're having issues determining the current year, I would recommend running the "date" command, available on any UNIX terminal.

auslander 7y ago

"Heroku’s physical infrastructure is hosted and managed within Amazon’s secure data centers and utilize the Amazon Web Service (AWS) technology", I did not know that. https://www.heroku.com/policy/security https://www.heroku.com/policy/security