kaspar1992

You talk about scaling with GitOps is difficult. But isn't this an issue of scaling itself? Management overhead, communications channels (Conway's law). Scaling is always hard.

This is pretty dope. Can you briefly elaborate how this is done? Is the database in AWS for instance still "RDS" or an Aiven DB? Maintenance-wise, that solves a lot of overhead problems damn!

An Internal Developer Platform (IDP) is an essential step for rapidly scaling companies to keep their developers working productively and happily. In this roundtable discussion I speak with Jason Warner, the current CTO of GitHub and previous VP of Engineering for Heroku about how IDPs help teams of that scale build efficiently.

"We will invest further to ensure Bing is comparable to our competitors and we remind people that they can help, with every search Bing gets better at finding what you are looking for."

This is a splendid way of putting it. Why don't you just tell the users "it's your fault Google ever got as good as they did"?

How much freedom should developers have in the perfect DevOps setup? What does”you build it you run it” truly mean? I’ve been reflecting on this for a while after seeing some 120 DevOps setups in 2020 (through Zoom).

So I tried wrapping my head around this and spent (too much) time together with 8 DevOps leaders on this article “DevOps: Standards v Freedom”. I’d love all of your opinions on this as it’s touching several fundamental DevOps core beliefs.

So what is it about:

I’ve gathered my thoughts alongside a concept I call “the evil triangle of engineering processes”. It basically means that in DevOps reality you somewhat need to choose two of the three velocity, maintainability and freedom. If you let everyone spin up any infrastructure, write config scripts however they want and don’t align on anything you will not get anywhere. If you restrict everything you will lose creativity.

Imo it comes down to the question how you interpret the “You build it, you run it” paradigm and I think many DevOps practitioners get this wrong and we don’t have enough of a discussion around this. For me there are three patterns:

Will show how you can implement this in your Internal Developer Platform in minutes in this webinar: https://humanitec.com/webinars/automating-delivery-workflows

Hey HN, We’re shipping webhooks for optimizing your continuous delivery workflows when you are building your Internal Developer Platform.

Webhooks can trigger on events such as a deployment starting or being completed. The resulting actions could be as simple as posting a Slack message or as complex as running a suite of integration tests or initializing data.

Here are some examples: Notifications: post to a slack channel when a deployment starts completed. Triggering processes: kick off a test suite once a deployment has been completed. Audit; record a new environment being created in an inventory system. Cleanup; remove references to a deleted environment in an external monitoring system.

How much freedom should developers have in the perfect DevOps setup? What does ”you build it you run it” truly mean? I’ve been reflecting on this for a while after seeing some 120 DevOps setups in 2020. I went back and forth with several DevOps/Engineering leaders on an article called “DevOps: Standards v Freedom”.

I’ve gathered my thoughts alongside a concept I call “the evil triangle of engineering processes”. It basically means that in DevOps reality you somewhat need to choose two of the three velocity, maintainability and freedom. I'd love your opinion on the article. We're having a community discussion on the topic: https://humanitec.com/webinars/how-much-freedom-should-devel...

Humanitec is looking for a developer advocate/technical writer/speaker and awesome storyteller. The position is (and will remain) fully remote:

https://humanitec.com/open-positions/senior-developer-advoca...

This is an incredibly exciting job offering for anyone in software engineering who has a passion for writing and speaking. For anyone who wants to evangelize an entirely new category (Internal Developer Platforms) in a lean, fast and crisply executing company. An Internal Developer Platform is like Heroku but on top of the tech and tools you use already.

You'll work with a bunch of exceptional and experienced colleagues on enabling other developers to focus on code rather than the underlying infrastructure. Truly rewarding job you can learn a ton in with weekly coaching sessions with industry leading advisors such as Chris Schagen (ex CMO Contentful).

I highly encourage you to apply even if you don't have previous experience with developer advocacy but just want to get into this field. If you have experience with software engineering and especially kubernetes and devops that's totally fine!

Please everyone, share, comment and spread the word everywhere it's much appreciated!

Last week I had the chance to catch up with Jason Warner on what an IDP is, why Github had to build one and why this is a new category of tools teams have to look at. To quote him: "If you slow down you die, if you care about not dying, this is one of those investments you make".

My key-takeaways:

IDPs are like Heroku on the tech and tools you use today. Which is an interesting way to put it because Jason was Herokus VP Eng.

There are pivotal moments in a team, such as adopting microservices, going multi-cloud or crossing a certain number of developers. Jason: “like having your first child, nothing will ever be the same again”.

Teams that are building on unstructured scripts get slow because of key-person dependencies and maintenance. Jason: “if you slow down you die.”

Serving internal developers matters as much as serving external companies.

He also talks about what's next for Github. Super interesting!

If you want to learn how to build your own Internal Developer Platform Christoph and myself are holding a webinar on how to do that on Dec 15th (link in the comments). Don't miss that and like, share and please spread the word!

There is a fundamental design flaw with Helm, leading to dramatic long-term consequences and you have to solve this now. My view is that of a DevOps manager in an enterprise engineering team.