I feel like Gitlab is going in a direction of AWS, except that instead of having separate products it just bundles everything in one. One massive bloatware that's scary to touch, no idea where features begin or end, or what is it even for in the end. Everything? I thought it was supposed to be Git hosting, but I'm not even sure anymore.
In this case I think it is more an ecosystem of build and deploy scripts that use the tools GitLab already provides (gitlab pipelines, terraform, etc.). GitLab is not providing the server space, instead you provide credentials to any supported cloud space and GitLab pipelines deploy the application.
That sounds like a good idea to me. For my personal projects I'd rather have everything in one place, especially if that one place is so well integrated like 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.
> Everything? I thought it was supposed to be Git hosting, but I'm not even sure anymore.
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.
Gitlab has a post money valuation of $6b on revenue of around $150m+. It’s not “winning” but arguably it’s okay to be #3 (behind Atlassian / Bitbucket though they’re more diversified). It’s clearly doing fine enough to IPO or get bought at a premium. They have some huge customers that refuse to use GitHub.
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.
> I feel like Gitlab is going in a direction of AWS...
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 Git URL unfortunately does not provide access.
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.
Yeah, I think it would have been better to differentiate in the article based on setting up state.
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.
I'm sorry but this is just a joke. It takes a while to configure a database, redis and storage on Heroku? This reads as someone who has never used Heroku.
> It takes a while to configure a persistent database, redis, and storage on Heroku
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 have been following these gitlab promotion threads here at HN and I dont usually comment, but I had to create this account after reading this post. It looks really bad and incompetent when a CEO of the company makes a statement like this. Have you ever used Heroku? On what basis are you allowing people to bash that product on your website? Do you consider Heroku your competitor? On what technical abilities of Gitlab do you think you have reached a place where you consider them your competitor? Some random meaningless doc someone put together to show how you will do better?
I don't know what you mean. It's literally one click to configure a persistent database and redis on heroku. It's true that "persistent storage" can get more complicated, depending on what you mean, partially because that phrase encompasses a variety of different things for different needs.
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?
> A typical web app requires a database, storage or caching backend, which can get complicated to run with Heroku.
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...
Yeah, if you write a promotional post for technical people (I don't know who else this post would be for) you should expect to be called out on your bullshit.
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.
It's not a mean spirited word. Gitlab and their army of users who post here at HN and bash their "competitors" have earned this. See their past threads where they have done a similar thing against github.
People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy.
Click a button, bam deployed.
Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick).
Want to scale up? Click a button, you're now scaled up.
Want a entire review system with staging links and everything? Setup the review 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.
I agree Heroku has the perfect dev environment, not much to improve there.
We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development.
We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make 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.
What does "hyper cloud" mean in this context? Searching only shows a headset with the name "HyperX Cloud" but I'm sure that's not what you are referring to.
As long as it is faster than gitlab itself, sure. Every time I go to the hosted gitlab, I cringe. I like the product but the whole thing is sooo slow. First, 5 seconds wasted to "check if my browser supports gitlab", then the lag on every click. Hopefully your heroku will have a better experience than your gitlab.
Oh my goodness, no. Beanstalk is a very poor clone of Heroku.
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.
I've never tried Heroku, but I have tried EB on a number of occasions and never had anything but grief with it. Often takes me days to get something deployed.
And the next time I do it, it's like it's all brand new. It never gets easier.
It would be helpful if the post was a bit clearer on that.
FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use.
That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and your other developers spend much less time dealing with server setup and debugging.
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.
I am not a Heroku user so cannot assess how this compares to their offering but as someone who spends ~4 hours a day looking at Terraform and the AWS console this does not look "production" quality at all.
* 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.
> 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.
> I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason?
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".
Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past.
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.
There isn't one. Piku does not concern itself with back-end stores, only apps (it was designed to run on ARM hardware, without containers and with minimal packages).
I fully agree, this should have been about it production app, not a development app which is already great on Heroku. Also see this post by the author https://news.ycombinator.com/item?id=26555617
What difference is the "production app" distinction supposed to make? Its not clear from neither the article nor the linked comment. If it's an attempt to suggest that Heroku isn't suitable for production use, that's going to need a lot of argument backing it up.
A production app has stateful services that retain data between deployments. The ambition of the 5 minute production app is to make this faster than doing it on Heroku.
The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.
Typical heroku apps have services like postgres and redis that maintain state between deployments. This is very typical, and trivial to provision. Still not sure what you mean. Are you sure you are at all familiar with heroku?
User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used!
I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.
I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are.
My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting something working quickly and easily.
AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines.
The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.
Amazon really should have bought Heroku instead of Salesforces. I continue to wonder why Salesforce bought it in the first place. And if they are willing to unload it.
Heroku not being AWS might be a feature. I'm not sure if AWS wouldn't try and integrate them and "break" something in the process. Whereas now, they still get money from it (Heroku runs on AWS) and can offer their own "alternatives" as part of the larger AWS offering.
The idea would be to allow Heroku working independently while offering their solution at literally AWS cost (without all the discount), or even AWS Graviton2 cost.
This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering.
And they have a competitor to Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)
> Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup.
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.
Heroku Buy AWS services at standard AWS Price (X) * (Substantial) Discount.
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.
Did not even know VPC peering was a thing. In the past I've often used Amazon RDS with Heroku Web servers for hosting Rails apps. For my current project I initially started out with Aurora Serverless which is VPC only, so I thought my web servers also had to be in the same VPC, so I decided to use Elastic Beanstalk instead of Heroku.
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.
Heroku not being AWS might be a feature, but Heroku being Salesforce is straight-up terrifying. I'm probably not moving my apps off Heroku anytime soon simply because they're running just fine maintenance free, but I'm not going to risk running any future apps on a Salesforce platform.
Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that.
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.
After a short exposure to SFMC I can see why someone would be concerned about the impact they would have on Heroku, but it is good to hear there are reasons for optimism.
In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly.
There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.
People use Heroku (and Google App Engine) because - if your app fits the model, and most do - you can completely skip ops/devops. Your whole team can go to sleep without a pager. You spend your life building features that customers care about instead of mucking with config files.
Yes!! Being part of a large org, nobody cares about the ops bit, leadership/product/dev mgrs just want features deployed!!!
It's very obvious that the sooner we can abstract all the ops away the leaner we'll be.
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?)?
There is a gap here in apps that (typical) developers need. There is absolutely a market for footguns that work 95% of the time as long as the developer pays some attention to it.
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.
Absolutely, I didn't mean to imply that there was no room for MVPs (as well as signup pages, demos, etc), but I didn't understand that the thread was limited in scope to MVPs. Is it?
"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."
I find Heroku rather easy. About a year ago I wrote a vanilla blog engine in NodeJS. It only required a small amount of debugging to get up and running on Heroku.
(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.
This actually happened to an app I'm invovled with too.
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).
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.
> lately I do notice more and more things where heroku doesn't seem to be "dotting all the i's"
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.
Yeah, I feel that. Although the salesforce acquisition was way back in 2010, I think heroku still had some innovation and progress after that for a few years. But not in a few years now.
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.
This was very cringey. A super contrived demo and bashing Heroku through a Twitter reference. Reads like someone is drunk/high and wanted to shitpost about a competitor. I would be appalled by this if I were GitLab's PR department!
> I have been a backend focussed developer in the past 20 years, web development is often fighting with Javascript and CSS. Especially Heroku as a deployment platform is a new area for me.
I would definitely caution you + the author of this post to tone down the rhetoric. Heroku has earned a tremendous amount of goodwill by being... basically fucking awesome and enabling tremendous amounts of productivity without having to screw around with infinite configuration settings. Just earn your own goodwill on your own merits, not by denigrating an extremely competent "competitor"
Yeah, seems they are trying to deflect their posts like this with a " This blog post is Unfiltered" notice that apparently frees them from anything mentioned as the 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"
Feels like an easy way out to claim whatever you want on company property without getting in trouble.
Or an easy way for a company to get the credit for a popular post, and hang a contributor out to dry if it's poorly received. Do the work and properly vet and edit your posts, and insist your employees post their own opinions on other platforms on their own time.
Calling it "user-generated content" when it's generated only by employees not actual GitLab users is quite disingenuous.
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.
Unless you need to scale up. Then it is significantly more expensive. Their PostgreSQL offering uses AWS on the backend too so once you start needing to make more changes or specify regions/sites it makes sense to switch to RDS, plus you end up saving a lot of money.
Agreed. Also, note this weird little flag/notice from the post:
> 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's written by a developer with a disclaimer that it's "unfiltered". I think it's part of their PR strategy to sound authentic and not salesy. Seems to mostly work for them.
I wish they would focus on other things. Things like GitLab CI's cache are unusable with most workloads, we even had builds which were faster without the cache than with it.
GitLab customer here. Sometimes I also feel like they are adding a lot of stuff instead of improving their core services. BTW I already gave up on using GitLab's native caching in favor of doing all my CI/CD with Kaniko + Multi Stage Dockerfiles
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.
I would love to hear more about this billing information in GitLab. Are you looking for build minutes and CPU of Runners per cloud service? What kind of questions are you typically trying to answer with that information?
GitLab product manager here. Would any of the cache best practices (https://docs.gitlab.com/ee/ci/caching/#good-caching-practice...) be helpful for your use case? I'm interested to learn more about what's not working for your workloads; why cache is not improving the speed of your builds.
Alternatively, I tried using DigitalOcean app platform (side note: super hard to Google for help due to the generic name) and it was way harder than setting up Heroku, I invested multiple hours in a few days and when I finally got the app running I was not confident enough to proceed with the migration yet.
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.
"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."
You can a real server for about that money too, and it will leave all the clouds in the dust
DO has Redis managed databases, and you can use those with Apps. You can associate an existing redis instance when creating the web app. Perhaps it's clunky if you create the web app first and then add the db?
My trouble with Digital Ocean app platform and "turnkey" templates from VPS providers is that I don't trust them.
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].
So I think heroku has stagnated a bit, and I am definitely very open to "better herokus".
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.
I mean if you want an open source Heroku or you want a cheaper option you can run on a droplet, there's always Dokku. 5 minutes' Googling would have told the author that yet not a mention in that blog post...
Nice, I hadn't heard of them, but does look interesting, I'll add it to the list to check out at some point.
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?
Thanks for the plug! Here's our (admittedly biased) Render vs Heroku comparison: we're not just cheaper; we're a better fit for how applications are built today.
I agree wholeheartedly. I'm one of the people in the world creating a "Better Heroku" but my whole premise of my product is that Heroku like you said has kind of stagnated but is still the gold standard.
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.
render.com is a better Heroku. Absurdly easy, inexpensive and killer UX.
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.
> Lots of CLI commands involved, and it did not run in a CI/CD pipeline with additional tests before deploying it. Now the web application is deployed into a black box.
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.
> The article isn’t clear about it but the 5 minute production app is an ambition, not a reality.
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)
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?
This post appears to be a comparison between deploying something on Heroku from scratch in 5 minutes, all-in, and someone knowledgeable about GitLab, GitLab CI and AWS, with accounts and credentials already created and configured, deploying something trivial in 6 minutes.
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.
Which goes back to the parent comment about criticizing a company known for great UX. I don’t think Gitlab understands why people like Heroku. I don’t want to go learn a bunch of individual services and then figure out how to wire it all together. For simpler architectures, you can make that setup, extremely easy, which is where Heroku really shines.
Gitlab has been trying to be a PaaS for years, but seems to subscribe to the “add more shiny features” school of product design rather than addressing the fundamental workflow of Heroku or Cloud Foundry.
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.
I think the title is a bit confusing. "We are building a better Heroku" implies some sort of announcement that Gitlab is adding a new service to their offerings, and that's what I expected when I clicked. This is more like a tutorial for how to make a deploy pipeline using Gitlab.
Has GitLab already finished building a better GitHub before they waste time in a better Heroku when in fact nobody else thinks that we need a better Heroku?
Last time I checked GitLab was still significantly slower than GitHub.
Honestly, this article presents a fairly ridiculous comparison. You could bump deploy times on Heroku to 20 minutes and I would still use it without a second thought. At best, I'll complain a little louder.
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.
Heroku's pricing is also justified IMO, since if you're using Heroku you're most likely saving money on hiring an on-call infrastructure or ops team, and saving money on having your engineers switch focus from feature development to maintaining the system, or doing dev-ops work.
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.
> Ended up in a Heroku blackbox for your stateful web app? GitLab introduces a better Heroku integrated into your DevSecOps workflow: The 5 minute production app.
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.
Then why not just publish the article on Medium or whatever? Nobody will notice or care about the "Unfiltered" label, they will just associate the authors' opinions with Gitlab regardless.
The place for employees to post their personal opinion that doesn’t represent the company is their personal blog, not “about.gitlab.com/blog”. After you’ve raised almost half a billion dollars in funding, you can afford a PR person to review posts that appear on the company blog.
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".
275 comments
[ 0.21 ms ] story [ 511 ms ] threadAWS, 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.
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.
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.
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.
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?
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...
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.
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.
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.
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.
Also it's very early stages - but the goal would to be better than Beanstalk
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.
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.
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.
* 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.
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.
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".
"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?
This post seems a bit disingenuous. Gitlap + Terraform + AWS != Heroku.
Well that's annoying, seeing as I've just done everything else on the CLI
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?
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.
The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.
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.
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.
The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.
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)
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.
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.
SFMC is easily the worst Salesforce project from a dev experience / integration point of view, agreed there.
There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.
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.
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."
(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 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.
No editing either...
Feels like an easy way out to claim whatever you want on company property without getting in trouble.
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.
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.
> 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.
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.
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].
[0] https://deploymentfromscratch.com/
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?
https://render.com/render-vs-heroku-comparison
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.
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)
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?
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.
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.
I get the sentiment, but that's absolutely the last thing you want to do when going for the "5 minute production app".
Last time I checked GitLab was still significantly slower than GitHub.
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?
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 gotta admit I laughed out loud when I read it.
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.
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.
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".