AgileStacks app templates use a similar approach to provide full stack DevOps automation for Kubernetes based apps. Just push your code and deploy: https://github.com/agilestacks/stack-apps/
We are far from a better Heroku for production apps in a hyper cloud
151–160 of 275 posts
Re: We are far from a better Heroku for production apps in a hyper cloud
#152People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review pro…
I agree Heroku has the perfect dev environment, not much to improve there. We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development. We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make…
> See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
This code is awful.
> Terraform which has the following advanatges: > 1. Terraform is the most popular
What an awful reason to pick a technology. I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? None of the others are particularly compelling for a "5-minute" setup either.
> 5. You avoid the cost and complexity of Kubernetes
But k8s is popular so why not use that?
>If you are not sure what correct permissions are then use AdministratorAccess as a temporay solution.
Aside from all of the spelling errors in the README I hate this advice. You have the infrastructure code, you know what's going to be provisioned. Create an IAM policy and add it to the code or README. Telling people to give their little app Admin access is a terrible idea.
In addition to all of the issues another commenter mentioned. This is hardly "production" quality code or infrastructure. Production should be able to scale, that's the entire point of using HyperCloud providers.
Re: We are far from a better Heroku for production apps in a hyper cloud
#153I like Heroku. I use it. I suppose maybe I'm a possible customer for these guys, but I just don't care about their nitpicks or glib / empty twitter quotes. Like I have a login for Heroku... it wasn't hard to make but apparently it was for them, that kinda makes me wonder about them. Meanwhile their example is the opposite of Heroku, super opaque: >The documentation says to create a new AWS IAM role with credentials f…
IAM is never fun, even if you work with it a lot. You always end up forgetting something and, come security audit time, you find out that people have been creating tons of policies that are just like "s3::*"
Re: We are far from a better Heroku for production apps in a hyper cloud
#154People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review pro…
User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used! I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.
I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are.
My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting something working quickly and easily.
Re: We are far from a better Heroku for production apps in a hyper cloud
#155Earlier quoted context omitted.
It would be helpful if the post was a bit clearer on that. FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use. That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and you…
I agree the blog post isn’t clear on that. I agree a simple production app can be great on Heroku. However besides being costly it is also hard when you want a managed service that isn’t on the platform. There are other reasons, https://gitlab.com/gitlab-org/5-minute-production-app/deploy... lists 9 in total. While a production app on Heroku isn’t hard it isn’t trivial either. We’re trying to make the 5 minute produc…
> Hypercloud
Why list all of these reasons and then make no use of them in the infrastructure code? The code doesn't scale, has huge downtime, you recommend granting Admin access to the CI jobs, the free tier is only for the first year the account exists. The purpose and focus of this repo isn't clear to me at all.
Re: We are far from a better Heroku for production apps in a hyper cloud
#156https://fly.io/ is the actual better Heroku.
Re: We are far from a better Heroku for production apps in a hyper cloud
#157Earlier quoted context omitted.
You're reading an employee's blog post not a gitlab corporate announcement. It's clear the author hasn't used Heroku's paid services at a larger scale given the points you've already made. I totally agree with the ease of use for Heroku and if you want to eat part of their market share you better make sure you're focused on the right aspect of Heroku.
It's a blog post on the company's official blog, no? I doubt it's like a free-for-all where any employee can post whatever they want without any review. Judging GitLab based on the content posted on their blog seems like fair game.
> It's a blog post on the company's official blog, no?
No. There’s a notice saying it’s unfiltered, with a link leading to a disclaimer saying, pretty much:
> it's like a free-for-all where any employee can post whatever they want without any review.
Or, in their own words:
> This blog is intended for user-generated content submitted by the GitLab team. The views and opinions represented in this blog are personal to the author of each respective blog post and do not represent the views or opinions of GitLab unless explicitly stated.
Re: We are far from a better Heroku for production apps in a hyper cloud
#158Earlier quoted context omitted.
You're reading an employee's blog post not a gitlab corporate announcement. It's clear the author hasn't used Heroku's paid services at a larger scale given the points you've already made. I totally agree with the ease of use for Heroku and if you want to eat part of their market share you better make sure you're focused on the right aspect of Heroku.
It's a blog post on the company's official blog, no? I doubt it's like a free-for-all where any employee can post whatever they want without any review. Judging GitLab based on the content posted on their blog seems like fair game.
It is fair game to judge us based on our blog. At the same time it is a free-for-all for employees for blog posts marked Unfiltered as this one is. The author apologized in https://news.ycombinator.com/item?id=26555617 and we've made 8+ updates to the article to reduce the bias https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/maste...
Re: We are far from a better Heroku for production apps in a hyper cloud
#159Earlier quoted context omitted.
Heroku not being AWS might be a feature. I'm not sure if AWS wouldn't try and integrate them and "break" something in the process. Whereas now, they still get money from it (Heroku runs on AWS) and can offer their own "alternatives" as part of the larger AWS offering.
The idea would be to allow Heroku working independently while offering their solution at literally AWS cost (without all the discount), or even AWS Graviton2 cost. This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering.
And they have a competitor to Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)
Re: We are far from a better Heroku for production apps in a hyper cloud
#160People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review pro…
AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines. The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.
In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly.
There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.