This message was deleted.

I used it briefly when I worked at TD bank, its very powerful but from talking with some of the devs that implemented it, it can be a bit of a pain to customize ( like most tools that are so versatile )

I haven’t used it myself, but I work for Syntasso building kratix.io and one of our users is creating APIs in Kratix that ServiceNow will call out to. Basically a thin UI over a more comprehensive API rather than paying the cost of configuring within SNOW like Hugo described.

@Loïc Guimard I have and you can create spokes to help with the process although it can be quite involved and SNOW developers are in demand. Some vendors create spokes like we do at Puppet which can help integrate with different components and workflows https://store.servicenow.com/sn_appstore_store.do#!/store/application/f8b747a607b42010c8b6f4218c1ed086

We are happy customers of Snow and are using it for basically every production workflow, but I believe an IDP would need a bit more integrations and extensibility. Snow has a pretty impressive number of integrations and AIPs already, but everything tends to be very workflow and resource creation-oriented. An IDP should also provide some visualization of the state of your resources and services, and I don't know if Snow would be best suited for this kind of task. But it definitely could be part of an IDP, I believe.

Thank you for your replies 🙂 . @David Sandilands, the tool looks interesting but we are not using puppet and the license cost + migration cost from our existing stack would quite huge I think. @PASCAL LOMBARD, i share your thoughts, i can see how it fits in an IDP (orchestration mostly). But for the UI, it looks very costly to achieve it and I am not sure you can get the same result as a standard application stack.

What service portal you pick, it's important to differentiate it from the IDP. The service portal is great to provide a comprehensive overview of all your services and templating but is not the core that drives self service and abstraction. What's the rest of your stack for your IDP?

I agree. we are not starting from the portal to the IDP. Its more the other way around. we already automated application provisionning of one of our standard stack: Angular/springboot, GKE, LB PSQL alongside with all the required tooling to build and deploy; artifactory, artifact registry (we use it as our registry), vault, IDP groups for right managment... It quite advanced on the automation side. Now we are looking at improoving the developer experience, and also incorporating other stack, tools and platforms on the same model.

@Loïc Guimard How do developers create infrastructure for their workloads with your current setup? Do they use TF templates? Crossplane? Or anything else?

We mainly use TF for cloud ressources, and we have a custom tool for K8S ressources provisionning.