Does anyone have any experience using https://www.kratix.io/ or similar tools? We are looking for something we can use to create a simple abstraction on top of k8s and infrastructure resources.

Hi @Havard Noren - never used it but I’m sure @Abby Bangser and @Daniel Bryant can help here (they are from Kratix) 🙂 What type of abstraction do you need to build on top of k8s? What’s your goal exactly? Disclaimer, I’m co-founder: If you are looking to build an Internal Developer Platform on top of Kubernetes with an excellent Developer Experience you can take a look at Qovery.

Here's a post about what types of abstractions you can do with a portal for K8s specifically https://thenewstack.io/developer-portals-can-abstract-away-kubernetes-complexity/

Hey @Havard Noren (and thanks for the tag, @Romaric Philogène 🙏 )! Let me know if @Abby Bangser or I can help -- a quick conversation to understand your goals is always a good first step. To learn more about the overall vision, you can check out a recent blog post and slide deck I put together

(out of topic: @Daniel Bryant this is an excellent slide)

Hi all, and thanks for the response. I’ll explain a little about our and stack first: We are about 20 developers, we have 1 shared backend team and the rest are pure frontend teams. We run the backend services on eks, if frontend needs a backend, they get a service on eks or they use serverless. The frontend teams know almost nothing about cloud services or iac, the backend team has limited experience with cloud services, iac and kubernetes. We have 1 person responsible for assisting all teams filling out the experience they are lacking. The iac is written in terraform, currenttly in a repo where only two people have access, our immediate goal is to expose the parts of our iac repo that our teams use the most, which is mostly dns changes. Our end goal as a IDP, a service catalog with self service actions to setup and configure all the services also some of the shared infrastructure, though most likely we will not get there unless we get more devops resources, so before we get there, we want to make sure that the teams can function in case our 1 devops person is not available for any reason. We are considering creating terraform modules as abstraction layer, and by abstraction layer, its just supposed to serve as a “simple” way to let developers configure what they need, it’s not meant as a replacement for our devops guy, we still need someone with that expertise if the abstraction layer fails. We have also considered using crossplane, since we already have a kubernetes cluster and the company has a plan to expand our expertise within kubernetes. This is where kratix became interesting, with kratix we can create our “abstractions” through CRDs and together with crossplane we can have the same abstractions for both infrastructure and services that need to be deployed.

Great context 👍 Is it an initiative from you @Havard Noren or from your engineering team?

It’s mainly an initiative from me, I’m the 1 devops guy working directly under the CTO

Makes a lot of sense @Havard Noren, we have a similar sized org doing a similar thing with Terraform. FWIW this sounds like a quintessential free tier use case and I would be happy to white board it out with your devops person. We are working on some TF use cases with other customers so the value to us would be hearing another use case, and hopefully the value for you would be knowing if it is useful for you without having to go deep into the implementation!

If you want to make it a success - from my experience it’s great if you include your engineers as soon as possible in your platform process. The sooner you got their feedback, the better it is to get them involved and provide the platform they need.

I try to run surveys towards the developers when I need input, I’m not sure what the best way of involving the developers are, since I’m a builder myself, but for now, I’m trying to discover what the developers use most of our stack and what they see as blockers. I look at this first initiative as more a building block for me that I can use to build better services for our developers, I plan to create a quick prototype and try to get some feedback from the devs (from my experience in this company, most honest feedback from devs come after they use a tool, which can take some time,)

I look at this first initiative as more a building block for me that I can use to build better services for our developers

this1 This is a great perspective. Your devs may want a GUI or a CLI or something else, but at the end of the day, what you need is a way to manage offerings for a full lifecycle (creation, updating, upgrading, sunsetting…) and that is where a platform orchestrator can help. I’ll DM to set up a white board time with you, but hope we can keep the bulk of learnings here for more to join in!

Perfect thanks, I also prefer if we keep our learnings here for others to view, our devs definitely needs some kind of tool, for now, but in the beginning, they will have to manage with documentation + kubernetes manifests in a folder deployed using fluxcd. Even with that setup, they are also lacking in observability into the process, but one step at a time

Hmmm, I normally don’t say this, but… after reading into the context and getting to the 20 developers part, I’d probably not advise you to actually build your own IDP @Havard Noren. Orgs of that size are usually flexible enough to adapt their processes a bit, so choosing something that is not as flexible as an IDP, aka PaaS is probably going to be the better investment for quite some time to go. If you’re not planning to scale massively, then you’ll be able to compensate the higher cost of a PaaS vs. an IDP easily by not hiring “one more devops to make that work”.

I agree with @Clemens Jütte - the amount of work will be huge in your case and the outcome low. But still good to experiment tho

@Clemens Jütte I agree that an IDP at this stage is too much work than benefit, even using a ready made product, because they still require a lot of configuration and even if we made and IPD, it would only be the devops and backend team that would have any benefit of it and at that stage we are talking about only 7 developers. Currently I’m looking into ways of automating devops processes of the most used processes in the company, this is both processes other developers require and processes that devops handle alone. I’m juggling with a balance between good documentation and scripts so these tasks can be handled by someone else if devops is not available. With that in mind, I’m also looking to experiment and possibly build the basic building blocks of an IDP, at least the self service part of a future IDP.

Currently I’m looking into ways of automating devops processes of the most used processes in the company

This is the start of a platform, likely (starting to) moving from provisional to operational on the CNCF maturity model if that helps you thinking about things!

That’s exactly what I was guessing @Havard Noren - automation is the single biggest value generator you can have at that stage. It will allow you to care more for your devs instead of executing repeating tasks on your own. Also all automation includes a bit of abstraction as you’re creating a new interface with your (scripted) solution - which will make things more approachable in your absence. However - if you look at PaaS like Vercel, Heroku or friends, they will directly supply you with the needed abstractions and RBAC for self-service of most tasks without the needs to script the whole thing. I wonder if this might be the less exciting but outcome wise more interesting option?

Thanks for elaborating @Clemens Jütte and yes, for our case and I guess for others that doesn’t have that many developers, using PaaS would free up part of the responsibility for devops so they can focus on all the other tasks that needs to be done. With that in mind, we could also look at services like spacelift for running our terraform code in pipelines, so we don’t have to manage that ourselves. Price wise it’s probably also cheaper using a PaaS than building and supporting it yourselves. You can always migrate away from it if the price becomes to high, at that point, you are probably big enough to make things yourself either way. It’s also well documented, which means devs can start using it without assistance from devops.

I’m looking forward to hearing how your decision went in the end and what the deciding factors were - if you can share that after the fact. These cases are really valuable for the community! CC @Luca Galante - probably we can have something like a “case corner” were cases are kept for longer than the retention period of the community slack?