Hacker News Reader

Comment by KaiserPro | Hacker News Reader

The problem with fargate is that like all AWS "compound tools" that are meant to be an answer to competitor x, is that they are painful to use if you don't have an infra team

take elastic beanstalk, its meant to be a competitor to heroku(thats how it was pitched to us in $big company), but my word it misses the mark.

Lambda and API gateway is a massive faff to setup manually, but serverless and zappa make it really really simple to do. That and its cheapness is why its caught on, its fast(to iterate), simple enough and super cheap.

Fargate is kinda aimed at people who have out grown lambda, but then you will be evaluation the whole hosting ecosystem. But if you are evaluating hosted K8s, I don't know why you wouldn't just plump for GKE.

Mind you, avoiding K8s and sticing with lambda + ECS for long running stuff is far simpler to understand, even if updating it with CF is a massive ball ache.

View on HN

> Mind you, avoiding K8s and sticing with lambda + ECS for long running stuff is far simpler to understand, even if updating it with CF is a massive ball ache.

actually with GKE you can run your "AppEngine" apps directly on GKE: https://cloud.google.com/appengine/docs/flexible/python/run-...

Better yet there is the "next gen" stuff from AppEngine (Cloud Run) which is like Fargate, but can ALSO run on your own GKE: https://cloud.google.com/run/

the only thing which I still think is way more expensive/worse than the aws counterpart is RDS. (Google has a hosted db service, but that feels worse than rds)

ECS & Fargate is probably closer to the Heroku experience than Beanstalk is these days. You've got the same primitives you would with Heroku, in the form of Fargate tasks, being orchestrated by an ECS service.

Its definitely more involved than just a git push, you'll have to deal with RDS for databases for example, and get credentials for that into your application. Having said that I think the extra effort needed for ECS is worth it, you end up paying less for the resources your consuming (in some cases significantly less), and you're sitting within AWS so integrating with other products they provide is a lot smoother.

If you can understand Lambda, ECS, and CF you can understand Kubernetes. The problem with Kubernetes is not that it’s hard, it’s that Kubernetes lexicon is new and people are still learning it.

Now that I’m knee deep in the world of Kubernetes I actually find it easier to use and run. CF is an absolute abomination in comparison. God help you if you need to rollback in CF or debug something. I have none of those problems in Kubernetes.

Kubeless is a lambda replacement that is easy to setup and run. Apache Openwhisk is another alternative.

Why would I ever want to lock my company down to a specific vendor and their tooling when I don’t have to? Eventually cloud providers will need to contend with the idea that most of the stuff they’re doing will be replicated in Kubernetes. Kubeless and projects like Cert-Manger are perfect examples.

Feels recognisable. We've outgrown Lambda and moved to Fargate. But now we're wondering whether we should dive into K8s. Worth the investment in your opinion?

Its a lot of work. Its useful if you want to merge platform with other departments.

However for a small team, I don't think its a great fit, yet.

I'm pretty sure Beanstalk predates Heroku. I'm curious how you think it misses the mark though. I've found it to be really easy to operate although that's mostly low-traffic systems.

Heroku was 2007. Beanstalk was 2011.

Salesforce purchased Heroku in 2010 for $212MM in cash before Beanstalk was even announced.

Beanstalk was announced in 2011. Heroku came out of beta in 2009.

I don't see how you could say it doesn't miss the mark of being a heroku level PaaS competitor. Heroku is leaps and bounds simpler to use and configure for most use cases. I mean getting started its either heroku new; git push or just point it at an existing public repo.

Reply on news.ycombinator.com