Mistakes When Building Internal Developer Platforms (IDP) and Streamlining SDLC
Вставка
- Опубліковано 3 гру 2023
- This video explores the common mistakes encountered when building Internal Developer Platforms (IDP) and streamlining Software Development Life Cycle (SDLC).
#SDLC #IDP #InternalDeveloperPlatform
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
🎬 SDLC and platform engineering: • Your CI/CD Pipelines A...
▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendar.app.google/Q9eaDUHN8... to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox - Наука та технологія
Thanks for another great talk 🎉 I really like the way we got to the point where you finally get an IDP working, after setting up control planes, pipelines, clusters and God knows what else then ask what an IDP is to 10 people and you get maybe 15 different answers!
While all developers have been doing the same thing IDPs do for years by building UIs at the right level of abstraction in front of their APIs!
Thanks for clarifying
Gray area emerge in this configuration, like when security update impact both side (service and client). Example: When patch the update a connection definition(contract) and require that clients(usually library connection) either update.
The specialist can not update without communication all the teams that are around that service, and without provide a test service with updated to make sure all works correctly.
IDP need provide the most information or where find that.
Other that I think is the level of abstraction, this depends the context of enterprise some times more deep or less deep.
Viktor is on fire on this video! But seriously, slapping an UI (make or buy) will not help you at all with folks adopting a crap IDP and it's services! Of course having a bad UX in your IDP (like a crap UI) will neither help your adoption. At the end you have to think of your IDP as a product and do all the things you would do for "classic" product too.
Treating it as a product is a key. A product is not only a UI, not only a backend, nor only a CLI, not any other single thing. A product is a complete service or a group or service with everything that entails and that is true no matter whether that product is consumed internally or externally.
Great content. My main concern is how to tackle each of the steps. For example, how to provide a "skeleton yaml" file so that when the users apply it, that yaml file is "unfolded" into K8s native resources? I should create a custom resource definition and then write an operator?
By the way, that could be Episode 1 of a series that focuses on Platform Engineering (e.g. Episode 2 could show a small implementation of another step)
"I should create a CRD and then write an operator" - you just described Crossplane ;)
I prefer exposing services through API and that's where Kubernetes with CRDs and controllers comes in.
I am deeply involved with Crossplane which does that, but Crossplane is not the only option. You can use KubeVela, Metacontroller, or one of many other solutions to accomplish that without writing operators from scratch.
As for platform engineering videos... I already created a few.
ua-cam.com/video/j5i00z3QXyU/v-deo.html contains the overal architecture, and ua-cam.com/video/Rg98GoEHBd4/v-deo.html and ua-cam.com/video/UnNQYghc8uU/v-deo.html practical implementations (use them as an idea and not necessarily as the list of specific tools one should use).
While I do believe that Crossplane is a great option, it's not the only one. The important part is to accept CRDs and controllers as the way to go. The rest depends on what you need.
@@DevOpsToolkit thank you for your answers
Problem with abstraction level I tend to find that especially in technical companies, every user has a different opinion about what level and granularity there should be
In that case, the only path forward is for every user to build what he needs himself. I'm not saying that's a bad option, but that it is the only one. If common services are to be built, there must be a common use case. More often than not, it is a combination of the two. One can identify services that are used by many and leave those that are unique to those who need that uniqueness.
I am curious to know what tools you use to create your videos (adding diagrams and animations, etc).
I'm using services of an agency and I'm not sure how they do it 😔
you just reminded me with Datadog, then you have some logs are not showing even though the sampling rate is 1, and it can't show java traces error messages , ..., but it looks fine for many, you have em all in one place