#I worked on the original CUE SDK,

1 messages · Page 1 of 1 (latest)

void furnace
#

Taking to a thread.

Ok. I understand the direction now. Our take from a platform engineering point of view is, all this "how the orchstration works" detail should be abstracted from the developer. They shouldn't need to define config apart from what the app needs to run. Everything else should "just work".

You say, "the devs you serve". That sounds to me like you haven't yet built a proper IDP - internal dev platform yet. That is, not in the sense of what I noted above. Because, if you were doing what I said above, the devs you serve would never touch a CUE file a docker file or a k8s manifest. Never ever. 🙂

And, that is where the language SDKs fit fantastically. Where we can have CI workflow ran by Temporal workflows triggering "runs" in Dagger (this is what we are working on). I'm hoping your development processes for your code bases have standards set up in how they run. Those standards get modelled in Dagger modules and that is at best, where devs might "look into" the process. And because it is code, it should make perfect sense to them. If fact, if you insisted on CUE as the standard, you should really build a CUE-to-Dagger module. 🙂

So, I guess we see things from different perspectives and that is great. If everyone thought the same way, the world would be very boring (watch Pluribus on Apple TV for what I mean 😛 ).

dawn moat
#

the devs you serve would never touch a CUE file a docker file or a k8s manifest. Never ever

That's not reality, devs own their services e2e, they need to

  • write those k8s resource values somewhere, right? That's a config file
  • tweek builds, not every service is cookie cutter

where devs might "look into" the process. And because it is code, it should make perfect sense to them

Doesn't matter if it's code or config, look at something rarely and unfamiliar, they get the same feeling

#

I personally do not like Dagger modules, it's not an interface to the system I enjoy. The dev's I serve want to go back to Makefiles & Dockerfiles, as you say they shouldn't have to think about this, so they could care less for what cool new tech the devops team wants to use. They want standard tech they can poke into and understand when things break

#

I don't know if the devs i server are going to like what I cooked up with this, but I love it and am going to use it prodigiously!

#

Being able to consolidate, ELT, and intellisense across the SDLC as a giant config value is a pretty powerful capability

void furnace
#

The dev's I serve want to go back to Makefiles & Dockerfiles

This is where we set the line in the sand in fact. And if a dev wishes to do something funky in a Makefile above the standardized patterns, then they need to build a module for it.

Dockerfiles are read only in our system and are configured via a UI with a BOM selection of golden containers and specialized and vetted dependencies. Dockerfiles are simply too fragile and too invasive to leave up to the "tenant" devs. 😉

So, I think we have two different philosophies. The DevOps shift left "you build it you run it" mentality and the platform engineering shift down mind frame of, the application dev should be responsible mainly for their application's code and of course it's working in the system properly. Certainly one is harder to do than the other, but if IDP is done properly, then the cross-over between devOps and application development is much, much better IMHO.