Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
piku
The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> 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)
> 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.
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
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.
Hi,
> 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.
AgileStacks app templates use a similar approach to provide full stack DevOps automation for Kubernetes based apps. Just push your code and deploy: https://github.com/agilestacks/stack-apps/