Hello everyone! Super happy to have found this slack. I run the platform engineering team at Weave in Lehi, UT. We have been building an internal developer platform for over 4 years and before the term platform engineering was a mainstream idea. Our team is called the developer experience team. Here's our journey to platform engineering: https://engineering.getweave.com/post/platform-engineering-at-weave/. Excited to be a part of this amazing shift in the industry!

Amazing Jon, welcome 👋 I'll read your blog for sure. Cc @Morgan Perry

🙏 I've done a couple others as well illustrating how we built specific pieces to our internal developer platform such as: • Our deployment pipeline: https://engineering.getweave.com/post/deployment-pipeline/ • API gateway and gRPC generation: https://engineering.getweave.com/post/api-gateway-and-grpc-generation/

Do you know how much it costs you to build your IDP?

In time or compute? Or both? Haha

I mean in engineering time

Well, we have a team of 8 full time engineers working on it continually

Wow. I can't wait reading your blog posts

We have done so many cool things in the last 4 years but just recently launched a Weave Engineering Blog so I've only written a few. Excited to document all the other things we have been able to do and what we are planning. Such a cool field to be a part of

@Jon Stevens I wonder, are you working in cloud-native K8s environments?

Yes we are in GKE

Interesting, I’d love to pick your brain then, let’s continue in DM @Jon Stevens

Hey @Jon Stevens thanks for sharing your DevX experience with us. Your blog posts are gold:)

We have 6 different clusters. On demand and preview environments are not something we support at this point because we are in the process of building out a service mesh that will allow our engineers to test their code in production with canary deployments

Jon, your blog is an amazing reference, thank you for putting it together. Lots of valuable insights into how your team has through through the process, and what the benefits are

Thank you! We have so much more in the works and I can't wait to put together some posts on all the things we are doing. I really believe it is the most interesting and fun area of the industry getting to architect fully customized solutions for your organization. My biggest complaint with what I do is there is not enough time in a day to do everything I want to do haha

Jon, I just launched my Platform Engineering newsletter - and I have dropped your article into it! https://www.platformengineeringweekly.com/weekly-1/

Looks like the preview image of my article is broken

Yes. If you fix it I will refresh the cache

@Jon Stevens interesting reads, thanks for sharing! 👍I was wondering, in your setup there is the central ‘bart’ CLI component which sort of ties it all together (a workflow through all the tools in your platform). Obviously this works well for you but how much of this is ‘externalizable’ to other orgs? Would you recommend that we all create a custom CLI tool that ties everything together into workflows? I guess I'm trying to figure out if we all need to reinvent the wheel everytime, what is org/context specific in your bart tool (assuming Github could be exchanged for Gitlab and Argo CD for Flux etc.)? Hope the question makes sense 😄

Ya for sure, good question. In my opinion, it would be incredibly beneficial for any org to write a developer cli tool that abstracts away all the complexity of an IDP and presents it in a way that the engineers can consume. The exciting part about this field is that every org is different and has different needs and therefore different technologies and different solutions to different problems. Having something that abstracts away these complicated systems to the average engineer is essential so that they don't have to understand every detail about what goes into them to be able to use them. This can be done with a cli, or a UI for that matter. We have both. But, to get the most benefit, it should be custom built by the platform engineering team. It would be near impossible to build a standard solution that ties into all the possible pieces to an IDP for all different types of organizations

@Jon Stevens we are targetting Backstage as a mechanism to provide an easy interface for devs to consume and create services. You say you have both (CLI and UI). Can you elaborate a bit on the UI part? Is it on par with bart functionality and did you use a framework like Backstage? Does the UI solve something that the CLI cannot provide?

We looked at backstage a few years ago but wanted to wait until it was a little more mature. We actually started building out our backstage implementation a few months ago. We will be incorporating a lot of the custom UI pieces that we built inside of backstage but that will ultimately replace the UI that we built in house

Awesome, thanks for your answers @Jon Stevens, very insightful.

Awesome blog post, glad to see im not the only one building a custom cli to wrap all that things lol 😄

Nope! CLIs for the win

we did something similar at one of my previous places, wrapped up all the ‘glue’ into some simple commands that worked with all our pipelines etc. Very effective to put that ‘cognitive load’ factor into an interface the developer experience team could own and give to the rest of Engineering as a ‘product’. Welcome to our slack!