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:
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.
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.
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.
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) 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-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.
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!
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:
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.
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.
"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.
> 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.
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.
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.
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...
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?