We are far from a better Heroku for production apps in a hyper cloud(about.gitlab.com) |
We are far from a better Heroku for production apps in a hyper cloud(about.gitlab.com) |
... 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.
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.
The good news is that heroku started out so solid that it can last a while in this state still being a good product. But it doesn't seem great.
I still don't know of anything else as good as heroku for "we don't really have any ops expertise in-house, do it for us and make it Just Work". I doubt the OP is that. I really don't have time (or honestly interest) to learn kubernetes.
The idea behind this effort is to put you in a cloud native hyper cloud environment of your choice to start with and make that just as easy as Heroku. The big difference will be when you "graduate" - you'll already be in AWS or what have you, and under the covers isn't a black box but is a well formed set of GitLab primitives that you can now continue to use and expand upon.
given that they are a GitLab employee, I doubt that.
As long as vercel has lame security, I'll consider it a toy, nice for quick jokey blogs and stuff but not something to use for a serious project. Not about to risk getting sued just to use vercel simply because your stuff's easy to use
More on the security of our platform here https://vercel.com/security, as well. Thank you!
Slow to boot, and subject to denial-of-wallet attacks.
I do love vercel for static sites, and also think my blog with a minimal backend for comments is a good fit.
But less sure how it'll hold up to even a single heroku dyno, which can do a lot of concurrent request at very low cost.
Lambdas are not slow to boot because of the methods used to tune how hot they stay; in a production application doing millions of invocations a day we saw 0.03 % of all invocations suffering a cold start that added an additional 100ms latency only. And if you absolutly have to have warm Lambdas always for even that 0.03% you can use provisioned concurrency that always keeps a certain number of Lambda functions warm.
[1]: https://www.serverless.com/blog/firecracker-what-means-serve...
But this post makes me think it's unlikely to be gitlab.
Not entirely. There's room for improvement on pricing. But you have to employ a culture where being cost-effective is engrained in the company.
I like to quote the pizza chain Lil Caesar's when I discuss this, which is why my company I am building is able to provide the same core features but cost less. We look for ways to save on operational costs and resources ourselves so that we can pass the buck down to our customers without compromising on quality.
But heroku charges a pretty big multiplier over the underlying AWS resources and does a pretty large volume (I don't know if the numbers are public, so I could be wrong, but my sense is they have a LOT of customers).
It seems likely to me that their prices are more about "what the market will bear" than about what they need to support the business. There's nothing wrong with that, nobody's forcing any customers to pay for heroku, the customers think the value is there.
It just makes me surprised that nobody's competing effectively on price. Which may mean I'm wrong and you are right. But there could also be other explanations.
If they HAD competitors offering the same thing, we might think that the competitors were forced to compete on price so all maybe were charging the least they could to support the business. At least that's the theory. But that they have no real competitors offering quite what they're offering... when what they're offering has been so successful... is surprising to me.
Maybe it's just hard to create something as high-quality as heroku Or to do it without funding, or to get funding for it?
No one knows or cares what "unfiltered" means. My initial take was "unfiltered" meant "straight talk." There's no reason for a casual visitor to have any clue it means "rando blog rant spam."
This sort of post on this sort of domain is implicitly endorsed by the corporation and it's malpractice to pretend otherwise.
sytse, there's no one else I know who's your equal in the kind of leadership you show in managing GitLab.
The transparency, the honesty in everything GitLab does is truly astonishing. Thanks for letting folks like me who know next-to-nothing about building companies be a fly-on-the-wall from oceans away, watch your meetings on YouTube, go through your plans and processes, observe eng designs and discussions around them, among other valuable career-building things. What you're doing is tectonic, all the while continuing to grow what's already a huge business.
Thank you.
https://about.gitlab.com/handbook/total-rewards/compensation...
That's increasing opaqueness.
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.
That employee being the CEO ;)
...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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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?
I dont think you should. Being the CEO of the company which published this blog, the last thing you should do is ignore a genuine review of what quality that blog post is.
This “git push” is a killer feature — maybe it doesn’t really make sense security-wise or in a real architecture, but it makes it very sexy.
They don't really mean "because it's popular", they mean because it's the industry incumbent and de-facto standard. You can't use anything else, because nothing else makes sense.
You need to standardize on one tool, especially if your infrastructure / teams grow. If you want to deploy something on AWS using an API with a minimal graph of dependencies, there's just Terraform. Pulumi isn't totally free, you have to write more code, there aren't nearly as many providers, not as many people know it, etc. There's basically nothing else. As a result, it's "popular".
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 production app faster to set up than Heroku for production apps by automatically configuring a bunch of services. We’re not there yet but that is the goal.
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.
Reminds me of the famous old HN comment about Dropbox
I’m not saying it’s right or wrong, but that’s where it comes from.
I do question the “kitchen sink” product strategy and whether it’s sustainable - Atlassian pulled it off by building a product line rather than an all-in-one.
The quote was from the blog. Making it seem like doing things off the CLI was a plus point
Right now I have a git alias that does everything, including pushing to my heroku master, in one command. Why would I want to go off the CLI?
The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.
And you should really institute a review process. There is no such thing as "unfiltered" blog posts on an official domain.
It reflects badly on the company.
See this comment: https://news.ycombinator.com/item?id=26557589
This is how "unfiltered" blogs work: https://about.gitlab.com/handbook/marketing/blog/unfiltered/
I believe there were at least marketing people involved in approving the post though.
So which is it, this was just one employee's personal opinion or this was an attempt to meet a company OKR? You can't have it both ways, and it's quite shitty to put your employees in a situation where if they're successful the company takes credit but if they're not they get thrown under the bus.
And the "we" there refers more to my team - the author of the post is on my team. GitLab OKRs start at the company level, but every team has their own that roll up: https://about.gitlab.com/company/okrs/.
We're also going to learn from this and improve how we write blog posts in the future, too.
To address your last point, I want to be clear that the author is a valued member of my team. His hard work has been recognized repeatedly in recent weeks in the form of awards and other recognition. This blog post will not change the high regard I, and his other colleagues, hold him in.
Everything you have seen today is our team living up to its values: the author's bias for action in publishing this post, the transparency and being quick to say sorry in how we responded and addressed this community's feedback, and how our team assumed positive intent and worked together to try to improve and learn from this situation.
You can read more about our values here: https://about.gitlab.com/handbook/values/
Context: I have used Elastic Beanstalk in real production apps for years. For my Rails side project, figured I would use Beanstalk instead of Heroku so that I'm using the same platform (although I have also used Heroku in prod settings).
Quick summary is the AWS tutorial for launching their Rails sample app in Elastic Beanstalk doesn't work at all. I though maybe my Rails install was borked somehow, so I tried launching a sample app at Heroku. Worked on the first try.
Heroku really spends time making sure everything works out of the box, and that's what you're paying for.
And the next time I do it, it's like it's all brand new. It never gets easier.
Also it's very early stages - but the goal would to be better than Beanstalk
If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.
This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
And they have a competitor to Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)
SFMC is easily the worst Salesforce project from a dev experience / integration point of view, agreed there.
I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services still for X, eating Heroku's margin plus the margin it already had on the AWS offering.
Parent was proposing that AWS sell Heroku services at cost.
As you say, my point was it doesn’t make sense
HeroKu Sell their services at (Y) where currently Y is >(X).
If they had acquired Heroku by Selling it at AWS Price (X), Amazon is still earning where they previously were not earning from those heavy Discount. At the expense of the Operational Cost of Heroku Team. And the benefits of further lock in and additional market segment which is currently not very well served by AWS.
I do wish Amazon had an offering like Heroku. While Elastic Beanstalk works pretty good it's nowhere near as nice or easy to use as Heroku. It has gotten a bit better with Amazon Linux 2 [Procfile, platform hooks], but still leaves a lot to be desired. I wish I could scale up/down faster like you can with Heroku. There is probably a way to improve it, but right now the way it's set up any deploy, config change, etc bundles the gems and precompiles the assets which take a while. So deploy/scale up take around 8-10 minutes. It's been a while since I've used Heroku but from what I remember it's pretty much instant to add more dynos.
I also ran into a couple of other annoying issues with EB.
1. There is a bug if using Amazon Linux 2 Ruby 2.7 deploying a RoR app where assets are not precompiled on configuration changes. It was an easy fix, just needed to add a script to .platform/confighooks/predeploy but it should have just worked.
2. When migrating to Amazon Linux 2 I deployed a version of the app that needed some code changes to work on Amazon Linux 2. There is no way to disable rollback on failed deploy on EB. Setting the "Ignore Health Check" option to true does not help here. I ended up in a situation where I needed to both push a code update and update some environment variables. However any code update I would push would fail because of the missing environment variables and rollback and any configuration change to update the environment variables would rollback because the current code had an error. I ended up having to tear down the environment and recreate it to get out of this loop.
3. Another minor issue is the Monitoring/Health dashboard. It will show warning/degraded/severe during scaling operations. For example when you trigger a scale down event it will complain:
"Environment health has transitioned from Ok to Warning. ELB processes are not healthy on 1 out of 6 instances. ELB health is failing or not available for 1 out of 6 instances."
Like of course it's not responding, the autoscaling group just terminated it.
I feel like Elastic Beanstalk really could be a Heroku competitor if AWS cared enough to put the work into it. It just needs some polish and quality of life improvements, but I guess this way they still make their money and Heroku has a good business middle-man'ing it.
I'm wondering if perhaps I would be better off using ECS or EKS, or if that's what AWS wants me to use hence why they are not putting much effort in EB.