This message was deleted.

see here: https://pulumi-community.slack.com/archives/C84L4E3N1/p1691701770485089 License change doesn't affect the SDKs or Providers

If going by indications from the hackernews forum about it, IF there is merit to the claim that for big players it might be financially more viable to switch to pulumi than go with hashicorps prices, there might be a huge influx of new developers coming in...

Time to become a consultant again 🤣

I've been wondering lately how devops specific consultancy would look like, with it needing to have longer running gigs to properly evaluate, plan, move, transform stuff

Me too @cuddly-easter-41456. When I look around, it’s mostly writing pipeline yamls and migrating stuff from on-prem to the cloud. I am dreaming of a consultancy that essentially offers external SRE/DevOps teams as a service. Being a consultant that isn’t just hired to create 15 pipelines but instead is expected to give input and help drive the organisation or a team in the right direction sounds infinitely more interesting. The primary problem with DevOps consultancies is that the customers are not fully aware of what they actually need. Sure, they might need to migrate 25 windows boxes to AWS, but they will never ask for a holistic strategy that increases productivity across an entire org. The solutions are often so esoteric and specific to specific tech that they would never know what to ask for. That’s a hunch tho. I have never been a consultant. Mostly because of the above…

I have the exact same thoughts. Basically what I did in my last 3 jobs was that of finding a solution that works for specific companies and implement that. Just the problem of maintenance once I left was a huge one... so no idea how to deal with that

I have been thinking of a consultancy that sells fully managed hosting of applications to companies that don’t want to staff an entire SRE/DevOps team. Everything but the Git repository basically. It is then the job of the consultancy to build a general purpose platform to run said applications on and provide CI/CD, telemetry and all of those bells and whistles. It’s of course difficult to make it truly general purpose, so i would expect to have to pick and choose customers a bit. But if there’s enough similarity between the customers, it should be possible for a small-ish SRE/DevOps team to handle many applications for many customers. Scalability is equal to profit. Writing pipelines 1 by 1 is not very scalable…

I am dreaming of a consultancy that essentially offers external SRE/DevOps teams as a service

The problems we quickly found was it ended up being treated as "just keep legacy services ticking" by customers. If they already have engineers actively working on a project, why spend money on what they saw as "maintenance". We ended up inverting it, so we were SRE/DevOps specialists for our feature teams (engineers doing active development for customers on new products). This worked well, let us share knowledge around well. But SRE outsourced directly, not so well.

I had similar thinkings. Like a developer-self-service thing but for companies picking their stuff. The project I am currently working on, utilizing pulumi, is a similar thing that helps self servicing developers with configuration into the in-house stuff. Like: My project under repo X needs a user from database Y and logging from service Z .... and it makes it happen

The problems we quickly found was it ended up being treated as “just keep legacy services ticking” by customers.

If companies will pay enough money and you have the chance to try and reduce the amount of manual work necessary to keep it going, it sounds like a fairly good deal? I think that outsourcing SREs is again something that doesn’t necessarily scale very well from a profit perspective. You can’t replicate yourself. I would much rather sell an off the shelf product to the ones that want it and try to maintain that in a scalable way. Bespoke SRE consulting is profitable enough, but the other way would scale much better. Basically something heroky-esque, but still allowing for certain customizations that would fit into the platform. @cuddly-easter-41456 Our team is building a solution which is essentially “Pulumi on top of Pulumi”. It’s a software system for defining and executing sets of Pulumi programs. The idea is that teams are responsible for individual pulumi programs and we maintain the system that manages the individual programs. We support both custom programs, but also defining stacks via JSON/Yaml. Right now we manage about 12000 pulumi resources with this system and we execute all changes via a fairly simply pipeline in GitHub Actions. Our hardest problem is generalising our offerings without forcing teams to do too much work, so that’s where my opinion on “picking and choosing” customers come from. As @dry-keyboard-94795 said, it’s sometimes hard to justify maintenance work just for the sake of fitting into a box. It doesn’t provide immediate business value.

I love how the Pulumi Automation API exists because people immediately saw opportunities arising coming from how Pulumi thinks. But the Automation API comes with some big gotchas that are, in my opinion, still a big factor why it does not gain more traction (this is purely anecdotal and empirical). Going back to the initial information: If pulumi did any changes to anything that might impact Automation API and solutions made with that (And off the top of my head I can't imagine any yet), that would be a similar impact to what Hashicorp does right now

@cuddly-easter-41456 I’d love to hear more about the “big gotchas” with the Automation API. Feel free to DM me with more details, or respond here in thread. I can take this feedback to our product team.

A bit late to the party but someone pointed me to this thread and I wanted to chime-in. @sticky-match-71841

I am dreaming of a consultancy that essentially offers external SRE/DevOps teams as a service. Being a consultant that isn’t just hired to create 15 pipelines but instead is expected to give input and help drive the organisation or a team in the right direction sounds infinitely more interesting.

...

I have been thinking of a consultancy that sells fully managed hosting of applications to companies that don’t want to staff an entire SRE/DevOps team. Everything but the Git repository basically.

What you state here, especially that last statement was, and still is, the reason why I started Cloudy Sky Software. I left Pulumi early last year after having built a few things there since 2018. I launched Cloudy Sky Software and have a focus (bias?) on Pulumi. I try to work with teams that: a.) don't have the resources, b.) don't need someone full-time, c.) don't know how to "cloud"/it's not their focus, or d.) think they need to use k8s.

I have been thinking of a consultancy that sells fully managed hosting of applications to companies that don’t want to staff an entire SRE/DevOps team. Everything but the Git repository basically.

I have tried something similar to this but I never launched it publicly. I built infrastructure app kits (one for each major public cloud; with concerns such as the compute platform to use, baseline security with the possibility to add a cache or a DB) with everything a team will need (including running Pulumi in CI/CD) and the goal was for these "kits" was to serve as a starting point for early/small teams and keep things very simple for them. I ended up holding back after the launch of GPT because...well, these kits could be seen as mere templates that anyone could generate using AI...which is not completely wrong but where I think I differ is the assistance and expertise that I would provide to the team + it's just downright nice to talk to a human who knows a thing or two to help you when there is a problem. 😄 So this has taken a back seat while I focus on other things for the rest of this year and in 2024. I am still looking for the right opportunities with teams to offer that as a service.

It is then the job of the consultancy to build a general purpose platform to run said applications on and provide CI/CD, telemetry and all of those bells and whistles.

I have thought about this personally and to be honest, modern PaaS like Render, fly.io, or event Railway, etc., do a pretty good job.

I think that outsourcing SREs is again something that doesn’t necessarily scale very well from a profit perspective. You can’t replicate yourself. I would much rather sell an off the shelf product to the ones that want it and try to maintain that in a scalable way. Bespoke SRE consulting is profitable enough, but the other way would scale much better.

I very much agree with this. Although, the concern I have with building a platform, well, it's a cloud platform and I'd rather have someone else handle the pager duty 😄 and not be in the line of fire. Instead, I have shifted my focus to something else. I provide value-add services (guidance, hands-on engineering for literally every part of your stack) and software adjacent to Pulumi. In some sense, I consider myself/my business as an aftermarket store while Pulumi is the OEM. I want to build things that complement the Pulumi ecosystem and makes Pulumi a stronger choice for teams. I am not alone in that regard (Spacelift, Klotho are two examples that come to mind) but perhaps unique in that I am solo right now and don't have investors. I want my business to not just be a "service/consulting company" and for that reason I spend my own time on product development. Like you said before, in my case, most of my revenue comes from me being the product and that's very risky. I build plugins/providers for Pulumi but only native ones based on a cloud provider's publicly available API spec. I've contributed https://github.com/cloudy-sky-software/pulschema publicly, as well as three providers using that: Render, Tailscale Native and Scaleway Instances. And for some more shameless self-promotion: I've also built a (free but not open-source) desktop app and a (free and open-source) browser extension. You should give it a try and I hope you'll agree that it's useful, especially when you have a lot of projects you are dealing with or are using a self-managed backend. Also if any of you know of a team that could use my help, I have some capacity in Q4 🙂 I don't believe in estimates by number of hours. I block off dates to work exclusively with a team and t-shirt size my work.