...then goes on to show it could be done in GitLab in a more convoluted way. Ignores the fact that Heroku doesn't require GitLab, and seems to not be aware that Heroku does not require the CLI to deploy.
...and the GL steps require that you have previously created an AWS account, IAM, and have the credentials.
At the end of it all, it's obvious GL is using Terraform at the back end, anyway.
I'm left wondering why anyone would use this? Heroku is stupid easy to set up and get going, but you wouldn't use it if your production demands were getting complicated. However, if your production demands were getting complicated you surely would not use this GL solution. This entire thing seems to be a solution in search of a problem. I don't get it.
And ultimately I wouldn't want my entire deployment pipeline to be dependent on my code hosting provider. GitLab just 5x'd their prices a few months ago. Going all in on them for your entire CI/CD pipeline just seems crazy to me.
That's quite a straw-man.
If I were GitLab, I wouldn't be criticising the UX of companies known for excellent UX like Heroku while GitLab's UX is in the state its in.
That kinda "draw the rest of the owl" stuff is why people like Heroku.
But the idea that something you did in five minutes is going to be better than heroku (in all ways?) is.... I don't know what the adjective is. Heroku is very mature and polished software, that almost always does what you expect -- it's a very non-leaky abstraction, I guess. You can almost always get away with ignoring the details. (Yes, not 100%, but almost always). And there's pretty high quality documentation explaining how all the parts work, when you do need to figure out something.
This is unlikely to be a "better heroku", that solves all the problems heroku solves with as little time/energy from the customer -- if it really is, this post definitely didn't convince me of it, I still don't totally understand what it's even demo'ing. And it just makes gitlab look rude and/or desperate to have a heading that's simply "Do not use Heroku" -- because it's not open source, is the argument, i guess? Plus a vague and sarcastic tweet? How would we feel if heroku (or github) had an article titled "Do not use gitlab" with no more of an argument than that? It's just... childish.
Going through the docs just a bit, I see some things have you using docker manually, like "Deploy Persistent Redis with Docker" -- that's not necessarily a barrier, but it is already less simple/abstracted than heroku. But still might be worth it.
I don't know how to keep up current awareness of this stuff, what the companies/options are. How do you?
They also have in beta a way to spin up whole environments for every PR your dev team has. Imagine every PR has it's own database, backend and frontend, spun up/killed on the fly.
It's a very compelling feature.
https://devcenter.heroku.com/articles/github-integration-rev...
But I am interested in checking out render, that I just heard about here.
(Not particularly interested in spending time checking out whatever Gitlab OP is trying to tell me about tbh)
I don't see a reason for such childish attacks of Heroku. I'm solving similar issues but to go be more cost-effective and support more types of apps. I still hold Heroku in high regard and had the pleasure of having some higher ups as mentors of mine when I was in Junto Institute in Chicago.
Plainly wrong. Easiest thing ever to spin a pg instance for free and have it immediately available for your app to use.
Better Heroku? Does it let you use a pipeline of dev, staging and prod? Does it auto create new copies of your app (db and other services included!) every time you issue a pull request? Does it destroy those apps/services when you merge to master? Does it let you push to prod with one button? Integrated logs viewable on the web ui? Hell, integrated bash to a copy of your app in the web ui? Oh I forgot testing... webhooks... access control for other devs...
Better Heroku. Pathetic
I’ve run production apps on Heroku in the past, best possible service for small teams. Gitlab? Given how expensive it is - I’m not so sure.
The article doesn’t do a great job of showing it, but the 5 minute production app makes it easier to setup stateful services on the hyper clouds.
And it does spin up a new environment for every merge request.
That's just the other side of coin. If you want a simple "push and it's up!" interface then Heroku is a shiny coin. If you want to sell multiple levels of CI pipelines then it looks rusty.
> Want to use Let’s Encrypt and your own domain name?
I've never seen a platform that is easier to add Let's Encrypt domain validated TLS than Heroku's. Yes it's manual steps, but it's manual because you have to set up your DNS to point to their load balancer. I fail to see how much simpler it could be than that.
> How about adding the deployment natively to GitLab to have a single application in your DevOps workflow?
> # A better Heroku: The 5 minute production app
> ... The documentation says to create a new AWS IAM role with credentials for automation.
Nothing that involves creating AWS accounts or IAM role creation would take five minutes for someone unfamiliar with AWS. And if does happen in less than five minutes than I guarantee you that new user either has no clue what they just created or (boolean, not exclusive) they've left some gaping wide hole in their IAM permissions.
I'm not saying that it can't be done. I'm saying there is no way that creating all of that from scratch can be done simply, securely, and quickly for a new user.
Setting up IAM is indeed hard. The most workable idea we have so far is having the user run as CloudFormation script to set it up, see https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
Not clear? The sub title to the article is "The 5 minute production app." and further down it includes timings like "8:43pm CET: Pipeline started with the build job. 2 min 33 sec." and "8:48pm CET: Deployed in 1 min 11 sec.".
> Setting up IAM is indeed hard.
Indeed. It's the iron triangle of devops: Speed, Simple, and Secure (You only get to pick two)
> The most workable idea we have so far is having the user run as CloudFormation script to set it up, see https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
That's likely the best approach for initializing an AWS account though it boils down to, "Just trust us and run this". I doubt any new user would take the time to expand that CFN template, find the script that it loads (https://vantage-public.s3.amazonaws.com/x-account-role-creat...), analyze the resources, and see that it grants read only access to everything every created in your AWS account via a cross-account authorization.
Rather than target "Go live in 5-minutes", I think it'd be more worthwhile to target a longer time frame that'd lead to better understanding of the components involved. Yes it's not as sexy as "git push and you're live!", but the selling point is that you end up with a platform that can do anything including running your own resources, not just pushing 12-factor app code.
You're saying it's about the fact that you aspire to make something that's simlar to heroku but better in some unspecified ways [I mean, cheaper would be nice], while telling people "Do not use heroku" right now?
Seriously, what is the article about, if it's not about how you have something better than heroku (which nobody should ever use) that will let someone deploy an app in 5 minutes, which is what it says it's about?
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 process line and you're done.
Everything is beyond easy and requires very little actual knowledge. You don't need a bunch of silly yml configs or knowledge of how containers work. You just pick a button and setup your git repo and it deploys your app. Want to SSH in? Install the CLI tools and type heroku ps:exec, want to see the logs? Go to the logs error to type heroku logs.
They have a perfect dev environment, fairly decent CLI tooling, bulletproof battle tested deployment setup (minus they fact they go down basically every 2 days if you aren't on the paid plans), and very little you need to understand.
The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.
There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.
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.
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.
This post seems a bit disingenuous. Gitlap + Terraform + AWS != Heroku.
When it gets too expensive, Cloud66 is a great migration path and offers the best of both worlds. It's a fairly simply transition too.
Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.
Well that's annoying, seeing as I've just done everything else on the CLI
The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the reproducibility story is so much flakier than the reproducibility story for containers. I imagine you can use something like Terraform for Heroku, but pretending that you can ignore reproducibility altogether is... really something. Maybe the parent means that "yaml is silly" and Heroku has a better reproducibility story in some other format (maybe graphical?)?
If you did all of the things required of launching a cloud level service for every signup page... few things would get done. There are some web apps which only need to exist for a few weeks or less before they can be tossed in a fire.
If I'm a startup with limited customer expectations of reliability and I just want to see if my friends would use my product demo... a point and click solution sounds pretty great.
"Update: This post does not live up to its original title We are building a better Heroku. It shows my own personal experience and reflects poorly on competitors. I am sorry about that."
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 easier. Setting up managed services on AWS is time consuming and that is what we want to solve. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
The contents of the blog post doesn’t warrant the title. We regret it.
* The web app is deployed to a single AWS EC2 instance which cannot be scaled horizontally.
* The web server is deployed from an AMI filter, when a new AMI matches this filter there will be downtime to redeploy the instance entirely.
* There does not seem to be any considerations for patching the web server.
* Everything shares a single security group. Although this is probably fine because you are using managed services for redis and postgres its still weird to allow port 443/22 from anywhere on your database.
I'd be happy to be proven wrong on these points.
There also seems to be quite a bit of assumed knowledge about AWS and Terraform. You mention the free tier a lot, but that only applies for the first year since your AWS sign up. After the free tier is up this infra is going to cost $40+ per month.
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 your other developers spend much less time dealing with server setup and debugging.
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.
"Setting up managed services on AWS is time consuming and that's what we want to solve."
Right, that's exactly what heroku has solved. Are you saying you don't think heroku has solved it as well as you have or you can?
> The contents of the blog post doesn’t warrant the title. We regret it.
OK, what SHOULD the title be, what's it actually about? Trying to build a heroku competitor?
Here's step 1 from the article: The documentation says to create a new AWS IAM role with credentials for automation.
At this point, you've already failed. You are forcing more complexity on me than I have to care about when using Heroku. And the underlying complexity is worse. You need to be familiar with Gitlab's CI/CD pipelines. Your included YAML file hides all the complexity and uses all your magic variables: https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
What happens when something breaks?
Quite literally, the only downside of Heroku is the pricing. Even that, I question for smaller teams where operational overhead can get way worse. I have yet to come across anything in the ballpark.
Anyway, this may still be a decent setup for deploying an app to AWS perhaps, but comparing to Heroku in the title is way off base.
You're paying Heroku to do the operational stuff for you so you can spend more time building your product. That's a price well worth paying to a point, and even then I don't think the default next step is going full-blown cloud and K8S. Although that seems to be the way these days.
I mean, if you've got a year's worth of runway to launch your product, then you don't really want the engineer you're paying 90k+ a year for to get bogged down in debugging a custom CI/CD pipeline.
What would you suggest as a 'next step' after heroku?
They are also being incredibly trite when they say “Do not use Heroku”, which is not at all the point of that Twitter thread, it’s a cheap way to push your own product.
The point Adam was making (which I don’t entirely agree with) was that we (the broader industry building PaaS features on Kubernetes - eg. Knative, others) are all chasing a design target from 2012 that he thinks is a dead end, and we should be trying new things.
I think the issue is less about the failure of Heroku as a design target than a failure to commodify the infrastructure it takes to get to Heroku-like ease of use. In other words, people like Heroku (or Cloud Foundry) but large market segments don’t want to pay for it. So we need to bring the price down by commodifying the tech.
Long run it would be nice to simplify broader classes of apps than “12 factor apps” (and indeed, I’ve seen “3 or 4 factor apps” run on these platforms), but for anyone that have seen the enormous productivity gains of those platforms, especially in a large company, it seems we still have a lot of low hanging fruit we can address.
Criticising other services is quite poor form already.
But then the criticism is a shallow dismissal by someone knowing nothing about Heroku, and with a minimal, odd example on top.
And the proposed alternative is running Terraform in a CI pipeline to set up AWS.
Yeah, that's not why people use Heroku...
I'm usually positive towards Gitlab, but if I were them I would make this post disappear as quickly as possible, it's that embarrassing.
That's what the Unfiltered tag is for. To resolve the company of any responsibility for this kind of thing.
Things I've noticed: * Segmentation Fault when deploying a Rails app, Heroku just works. * Ability to add Postgres but no ability to add Redis in the same ecosystem, you have to step out of the app platform, Heroku just one click and you have Redis associated with your app and many other add-ons.
There is a lot of potential on Digital Ocean, it in its infancy, the thing I like the most about it is $ for spec, with a $50 Heroku dyno I get 1GB RAM at DO the specs are way superior.
The blogpost mentions CLI usage and the global naming issues, those are annoying sure, but not the breaking point for Heroku.
The biggest competitor to Heroku IMO it's themselves. The fact their price remain the same even though specs and computational power has became way cheaper.
I would happily keep stuff in Heroku if they revisited their pricing policy.
You can a real server for about that money too, and it will leave all the clouds in the dust
I want a secured box. Everything rootless. SELinux. SSH hardening. Etc.
I am better off on my own and everybody else too. Next week I am doing pre-release of my book and I hope it will be a good resource for people to take the deployment to their own hands[0].
They're losing to GitHub. While they advertise that they have 2/3 of the self-hosted git server market share, they just barely have a double digit share of the total VCS market, which is where the real enterprise money and value is. I don't have figures on hand, but I'd guess they have a single digit percentage of actual enterprise market share. GitHub has the same domination over its space that Google has over search, and Microsoft is excellent at competing on enterprise partnerships.
Tech companies usually scale out their products eventually anyway, but in GitLab's case it's probably existential if they want to maintain status as a high growth, VC-backed company. They need to find another of their competitors' moats which is easier to chip away at, or they need to change the game and introduce something original.
In my experience their approach to pipelines and CI is a winner. In that regard GitHub seems to be playing catchup and the "checks" feel like second class citizens in GitHub while it feels really cohesive in GitLab.
AWS, on the other hand, is 500 different massive bloatwares that are scary to touch, to the point where there are literal courses available so you can learn how to use them. I've never had a good experience doing even basic stuff there.
It turns out, if you host the source, you hold the keys to the world of DevOps, too. It is completely natural then for GitLab to venture in to an ever expanding field of GitOps and eventually the Cloud computing market. I mean, Microsoft plonked billions on GitHub for Azure more than anything else.
People at GitLab, probably including sytse, have decided that it's worthwhile to build a new Heroku competitor into GitLab.
Then someone was tasked to write a PR blog post about it.
Then sytse did what he always does with GitLab PR, they post it on HN and tell GitLab employees to upvote it to make HN front page...
... and now when it has backfired because people point out how ridiculous this sounds sytse tries to play it down by saying it was a poorly written accident and deflects the blame from his own wrongdoing and pushes it on that employee. What a poor form of a CEO.
---
EDIT:
Proving my point:
- Blog posts tracked on Corporate Marketing:
https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
- Issue which mentions an internal Slack conversation where this was discussed:
https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11063
- PR which stated the release date of the post and was reviewed and approved by several people. It even had sytses (GitLab CEO) as an initial approver listed:
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
- 5 minute production app epic tracking issues, milestones, marketing, etc.:
https://gitlab.com/gitlab-org/5-minute-production-app
This was not a poor accident by a single employee. It's noble that the author tries to take all the blame on himself, but honestly, I feel like that is a moment where a leader has to step in and accept their mistake and not let a small trooper eat all the bullets.
The title was chosen poorly, and the blog post did not reflect on its intentions. For that, I deeply apologize.
The experience and first time with Heroku is my raw impression, also the fact that I am a backend developer who is learning frontend and web apps.
It is a hard lesson learned today, although I am here for it. Iterate and improve, listen to feedback, and learn.
Sytse helps with his expertise and vision on the 5 minute production app, responding here to help. He is not to blame at all, I truly appreciate his guidance and thoughtful responses.
A guy linked a bunch of GitLab tickets in another comment showing that you went through the proper process and had multiple other people approve the post, so I think there wasn't much else you could personally do.
Here's the context if someone really does care: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
It's also important to note in a non-transparent company you wouldn't see any of this
> This was not a poor accident by a single employee. It's noble that the author tries to take all the blame on himself, but honestly, I feel like that is a moment where a leader has to step in and accept their mistake and not let a small trooper eat all the bullets.
The issues you have found are all assigned to me, or I created them. My task is to create blog posts, some of which being a hackathon and challenge. The KPI are impressions, other metrics are hard to measure. As a Developer Evangelist, I often need to learn new technologies, or dive into unknown areas connecting the dots.
You can learn more about our focus areas in our handbook: https://about.gitlab.com/handbook/marketing/community-relati...
I'm focussing on the Ops side, with a backend development background in the past 15 years. I was once a maintainer of an OSS monitoring project called Icinga, a Nagios fork back then. I decided to take on a new journey with becoming a Developer Evangelist in March 2020 (you can learn more on my website https://dnsmichi.at/about/ in case you're interested).
That being said, I've found it interesting to learn about web apps and their deployment, and dive into new things. Never having found a use case for trying Heroku, March brought up one: There was a Twitter theme of "Everyone is building a better Heroku" - https://twitter.com/adamhjk/status/1369704730218299392?s=27
From there, I thought of learning Heroku while comparing it with the 5 minute production app. I underestimated the challenge of creating a web app with a persistent backend, and decided to stick with the simple battleships demo I had initially found.
This state of the blog post felt good enough for me, and I did not include the persistent backend just yet, but moved it into a separate blog post. This is feedback I got during the review.
Turns out that this decision was wrong, next to other negative raw sentiments I had added in the blog post.
You can try to convince that it is not my fault, and I will convince you - it is, and I am standing up for it. Public and transparent.
I know we all get better from making mistakes. The lesson I learned today helped me improve a talk I gave at a meetup in my evening, it added technical insights as well as helped with the story line. That's the tracking issue: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
We will continue to iterate, and have a retrospective on what we can improve from the lessons learned today. Thanks for your feedback.
For what it's worth, I kind of hate that we're using Gitlab for this, but as far as fully-integrated DevSecOps solutions that include VCS, binary artifact repositories, and pipeline orchestration all in one, there's Gitlab and there's Azure DevOps and that's it. No one else offers this, so here we are. My complain is more that, as much as I also hate Jenkins because the no database everything is configured via text files scales terrible, especially over NFS, and security is non-existent, but going from Groovy DSL to embedded bash scripts in a heredoc that is part of a yaml list object is a significant downgrade in pipeline developer experience and quality control as a vehicle for pipeline as code.
I really, really wish you guys hadn't gone with yaml-defined tasks as a pipeline scripting language. As bad as Jenkins is for every other reason, they really got the pipeline DSL correct.
Feels like an easy way out to claim whatever you want on company property without getting in trouble.
Besides, disclaimers like that don't even legally work. Employers can't disclaim responsibility for what their employees do when it is within the scope of their employment.
No editing either...
> This blog post is Unfiltered
with a link to the "legal disclaimer":
> DISCLAIMER: 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. All content provided on this blog is for informational purposes only. Neither GitLab nor any of the individual blog contributors ("Contributors") make any representations as to the accuracy or completeness of any information on this site. Neither GitLab nor any Contributors will be liable for any errors or omissions in this information or any losses, injuries, or damages from the display or use of this information. Comments are welcome, and in fact, encouraged. However, GitLab reserves the right to edit or delete any comments submitted to this blog without notice should GitLab determine them to i) be spam or questionable spam; ii) include profanity; iii) include language or concepts that could be deemed offensive, hate speech, credible threats, or direct attacks on an individual or group; or iv) are in any other way a violation of GitLab's Website Terms of Use. GitLab is not responsible for the content in comments. This policy is subject to change at any time.
Are we sure this wasn't written by some sort of new AI bot GitLab is employing? So many keywords stuffed in those opening lines.
The comparison in the article is incredibly naive, IMO; they are not being a better Heroku, this is just demonstrating something you can do if you already have good knowledge of three complex tools: AWS, Terraform, and GitLab Pipelines.
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 for automation.
Oh just jump in the "create a new AWS IAM role with credentials for automation" canon and fly off to AWS land? I've worked with AWS plenty and man it's not been fun. I'm sure someone who knows thinks that's a trivial step, but I don't do it often enough to be sure of what is going on / be all that comfortable with it.
That kinda "here's a link to some documentation for a vague step" (that they don't time....) is why I use Heroku...
Long gone are the 'gitlab is so amazing' comments, and the top comments are usually much more critical (clickbait, stability, . . .).
Not taking sides, just an observation that I make to myself pretty much every time I see Gitlab over here.
For reference : https://www.google.com/search?hl=en&q=%2Dsite%3Amedium.com%2...
Last time I checked GitLab was still significantly slower than GitHub.
> Especially Heroku as a deployment platform is a new area for me.
Maybe you should get some more experience with the product before writing your critique? Or write about something you know more about.
> Getting there and installing the pre-requisites on the CLI took longer than expected.
No mention of how long, but when you use your own tool instead you time it down to the second...
> Lots of CLI commands involved, and it did not run in a CI/CD pipeline with additional tests before deploying it.
You published your code on github, so we can all see that you didn't actually write any tests. Heroku does actually have a CI offering, but let's just ignore that I guess?
https://news.ycombinator.com/item?id=8371249
Let me be real clear here...only Heroku will ever beat Heroku.
Docker has enabled a lot of other great options that are all modeled after the experience that Heroku has created...but ultimately people keep looking to Heroku because they are the gold standard.
Better is a series of tradeoffs. Heroku has been refining the tradeoffs to using their platform for a decade. You may create tradeoffs that work better for a use case that you want to enable, but ultimately you're going to have to convince people that your set of tradeoffs has made things "better".
The goal is to “quickly make a stateful app that is deployed on a hypercloud” https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
Sorry to say but not having a git web UI doesn't mean you can't access it. The very next command you push to it via `git push heroku main`, meaning you have full access to it, including the ability to force push to it.
It takes a while to configure a persistent database, redis, and storage on Heroku. That is what we’re trying to make easier, as well as hosting it on a hyper cloud.
See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
Really? Have you actually tried this? In my experience Heroku couldn't make it any easier. You can provision a database in 60 seconds, from a Deploy to Heroku button in your Github README, or in the lovely dashboard, or on the CLI, or with two lines in heroku.yml.
We're a heavy Gitlab user and I'm a big fan of Gitlab's typically transparent communications style, but this article reflects really badly on you. I think you should take it down.
I don't see how you could possibly make this easier.
You could make it cheaper, and possibly "transportable to a differnet vendor" (even a non-AWS vendor), which is what some people are chasing. To do this while being as easy as heroku is the holy grail. (not easier but as easy because configuring a persistent db or redis is already at the literal maximum of easiness on heroku).
But you think you can make configuring a persistent database easier than heroku? I honestly have no idea what you are thinking of when you say this "takes a while to do" on heroku. Are we talking about the same heroku?
This is as worse as it can get. This is tabloid stuff. Have lost respect for you.
Name calling Heroku which is known for its UX and ease of use. And then offering nothing but some made up nonsense and buzzwords. What happened to your good standards ?
Why can't you be serious and build a better Heroku instead ? for real
I get the sentiment, but that's absolutely the last thing you want to do when going for the "5 minute production app".
> Apparently Heroku is not Open Source.
...Neither is AWS. And?
Gitlab is better than this.
Same thing applies to Netlify. This post seems quite desperate.
I would not care about new features if they had granular billing like AWS, GCP, etc... But here I am paying for Devsecops and a lot other stuff I don't use.
(Although I don't know if I ended up modifying my code to adhere to Heroku quirks, or if the changes I needed for Heroku are normal.)
One weird thing happened a few days ago. I noticed that my blog was offline, and I ended up needing to modify my Postgres connection code to explicitly enable encrypted connections. This struck me as very strange. I mostly work with Microsoft SQL, and those kinds of things are set via the connection string. Shouldn't Heroku have just updated my database connection string without breaking my site? Admittedly, I have a lot less experience with Postgres than Microsoft SQL.
Turns out heroku started requiring SSL for postgres connections on "hobby" tier only last month. (It had already been required for "standard" and "professional"; and the blog post says they had been advertising the deprecation for a while, although I hadn't noticed either -- the thing about heroku is it makes it so easy to just ignore it mostly, that you can just ignore it mostly).
https://devcenter.heroku.com/changelog-items/2035
Is there some way to encode this in the postgres DATABASE_URL? I'm not sure. With my particular app, it would have been ignored anyway, my app was deconstructing the DATABASE_URL into components to feed into the database connection configuration, and was not paying attention to any hypothetical part of it that would have specified ssl. This was per the instructions of the framework being used.
I could believe there's a way heroku could have done this better though... lately I do notice more and more things where heroku doesn't seem to be "dotting all the i's" [USA expression for attention to detail and perfection] as much as I used to count on them to.
It feels basically frozen. The Salesforce acquisition seems to have been a Yahoo!-type deal for them, where they just keep things running as long as the checks come in and will sunset when enough people leave. Which is sad. Or at least this is my perception.
The current focus has been on an incredible front-end experience, but we're working to become a first-party integrator with your favorite backend solutions.
For example, you can deploy a full-stack Next.js application with a PostgreSQL database in less than 3 minutes: https://twitter.com/leeerob/status/1351576575888797696
Then starts to show off how easy it is to use heroku, while complaining about how complex it is???
And at the end there are some vague screenshots showing a supposedly easier method of deploying things than using heroku, but first you have to learn GitLab CI/CD, Terraform, AWS, and probably a bunch of other things?
They're pretty much already the cheapest service out there, it's kind of weird to want something that's cheaper when their prices are more than reasonable.
This is not a positive thing, generally. Web-based deployments configurations are difficult to replicate and understand.
> The documentation says to create a new AWS IAM role with credentials for automation.
From experience, this step can take a large amount of time if you don't want to just say "grant all". But create a new account for this project and it's fine.
But overall this seems pretty cool if you want a quick start with a bunch of setup to get you started with a cloud app. Seems more customizable / controllable than Heroku.
> Update: This post does not live up to its original title We are building a better Heroku...It should have emphasized the building part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment. It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect.
What the heck does that mean? All of my apps are "production apps", what is a "development app" and why would I be deploying it to heroku? Nobody is paying heroku prices for something other than an app that will be in production! (Yes, you might have staging and feature demo etc... is that what they're tyring to talk about? They think heroku is great for deploying your staging phase, but when you get to the production phase.... they think the article explains this somehow? Cause it certainly does not).
I for real don't even underestand the distiction they are trying to make here about heroku being good for "development apps" not "production apps". Like before saying whether I agree or not, I don't even understand what they are talking about.
Aside: has anyone here ever tried to build an actual wheel? Like a wheel for a car, or a wheelbarrow, or a wagon? One that has to take hundreds / thousands of pounds, works in multiple environments, lasts years, requires little maintenance? I think the phrase "reinventing the wheel" understates the difficulty it takes to actually re-create a wheel even if you already know how it works. Not only is it wasted effort if a good wheel already exists, it's also much harder than you think.
Heroku first and foremost gives me peace of mind about my production up. Someone handles that my app is running, someone cares that my backups are in place and working, etc.
And adding additional components and integrations is super easy to do, I don't need to know much about the underlying technology and how to run it.
Also something that makes it easier to handle the dev/prod lifecycle. I'm sure it's all very easy once you have all your devops stuff down, but the setup is still somewhat convoluted and drowning in too much YAML.
... mmmkay
Ah no. That is exactly where Heroku is dead easy. The creating, maintaining, updating and general day-to-day management of these "addons" require almost no input from the user. DB failover and mgmt is almost magic.
I wished GitLab would stay away from this needless, click bait type articles. It's not even well researched, almost if they never really ran a serious app on Heroku.
Sure Heroku has quirks (no http2) but I bet a lot less quirks than a homegrown GitLab CI + Terraform solution.
Also, using S3 is simple and shouldn't incur much cost due to running in the same AWS region.
How will they do that? "Productized apps for hyperscale cloud". What does that mean? It's a bunch of buzz words our marketing and sales team invented.
This post doesn't live up to its title, I'm sorry about that.
The title should have been 'We are building a better Heroku FOR PRODUCTION APPS' (we'll add the 'for production apps' to the title)
It should have emphasized the _building_ part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment.
It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect. The examples in this post are contrived since it talks about a development app, as rightly called out by Heroku people https://twitter.com/johnbeynon/status/1374306499426652161
It should have gone into why hyper clouds might be preferable https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
It should have talked about state, we made a small improvement in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request... but we should have done the planned work in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11137 and made one post out of it.
I can see the point of a service like this and the comparison is cool but there's no need to complain about Heroku, especially when the Gitlab services are not 100% equivalent. If you come for the champ, you'd better not miss and all that.
