[mad_vill]

I feel like the next generation of this type of company is smaller consultancies that have awesome developers that build customer tooling on the side. But the main revenue driver is consultancy.

Also it really feels like all the air has been let out of the docker/kubernetes/cloud-native balloon that was so popular in the late 2010s.

[gangstead]

> smaller consultancies that have awesome developers that build customer tooling on the side

I've worked at a couple consultancies and they were always chasing after that recurring product revenue. I grew to believe that it isn't possible under that business model.

When you are running a consultancy you are in the business of marking up developer hours: find a client to sign a contract for $150 / hour and hire a consultant who will do the job for $100k/year salary. Then convince them to work as many hours as possible for their fixed salary, plus the carrot of a bonus payout every once in a while if everyone bills lots of hours.

Having that developer spend any time working on the company's product causes all sort of problems. The most immediate is the loss of revenue. But also now this employee might see working on the product as cutting into their bonus since they are billing less hours. Everyone wants some of the upside if the side product generates revenue but how do you split it between people who worked directly on the product and people who worked on paying client jobs to generate the revenue so the others could work on the product? It ends up causing a rift.

The other thing I've seen while working at small and even medium sized consultancies is that they end up dependent on one large customer who calls all the shots and takes up all the available time, or all "extra" time not being billed is used working on sales for the next contract. Either way there doesn't end up being much capacity to work on cool tooling.

[mooreds]

> I've worked at a couple consultancies and they were always chasing after that recurring product revenue. I grew to believe that it isn't possible under that business model.

The only time I've seen this work (and I have seen it work multiple times) is with managed hosting.

So if you are an expert at developing web applications or solutions using <product X> you can offer a managed hosting solution to your clients where you host the web app or the <product X> solution. Not all of them will take you up on it, but some will. Those that do will pay you a monthly fee. This isn't free (you now have to carry a pager) but is recurring.

Building your own SaaS/other unrelated product? That's a rock I've seen several consulting ships crash into (to pick a metaphor). Here's one that some of my friends tried to build in the late 2000s that I wrote about: https://www.mooreds.com/wordpress/archives/506

[danjrslp]

I agree. Being good at running a consulting company does not translate to being good at running a product/SaaS/devtools company.

[softwaredoug]

And vice versa, i know a lot of product companies that have a really shitty profesional services arm that care more about shoveling more product down a customers throat than actually helping them from a neutral PoV.

[catherinecodes]

Right. I wonder what their cost structure was like. $10 million in revenue is enough to support a decent-sized team.

[gangstead]

Since they raised $61 million (source https://techcrunch.com/2024/02/05/cloud-native-container-man...) they probably had way more team than $10 million could support. Since they raised the VC money I guess that downsizing to a team that the business can sustain is not an option.

[nixgeek]

According to LinkedIn they were 50-200 employees which after excluding all the other costs for running a company, is definitely not enough to cover the fully-burdened payroll of even a 50 person organization that’s probably predominantly Engineering types, that assumption being if most people are US-based (or if they don’t do “location based” pay, and indexed off a more expensive location).

[0xbadcafebee]

"Air has been let out" in the sense that it's moved past the trough of disillusionment and is on its way to the plateau of productivity[1].

There are still a few people in the trough of disillusionment yelling about how a $5/month VPS is all you'll ever need, or a $50/month bare metal colocated server is all you'll ever need. But for the most part the people who benefit from cloud services & containerization will use it when they need to, avoid it when they don't. It'll continue to be a productive tool when used properly, with vendors supporting mature products using it that solve people's problems.

[1] https://en.wikipedia.org/wiki/Gartner_hype_cycle

[quickthrower2]

Must have miss the drama / holy war memos. Happily use a mix of k8s and non k8s at work and use that $5 VM for home side hussle.

[nprateem]

Like with big data I think most orgs (>80%) just don't need it due to the extra complexity. They might as well just use something managed like fargate and go back to building their own products.

[0xbadcafebee]

IMO that's an overly reductive take, which is very common for tools in this space, but (I think) needs to be addressed so people stop repeating it.

It reduces what "most orgs" are (as if 80% of businesses are the same, or solve the same problems, or have the same challenges, or use the same approaches, or have the same customers, have the same staff or expertise, budgets, timelines, etc, etc, etc.). Clearly there is no such thing as "most orgs", as there are many different kinds of businesses and how they approach solving problems varies from business to business. Their use of technology to solve problems also can't be easily reduced; the way the business chooses to solve problems doesn't necessarily dictate what technology they should use.

It correlates the need for complexity with whether an organization is in some 20% minority of organizations, as if only a minority of orgs should or shouldn't use a complex tool.

It reduces a given tool down to "complex or not", as if complexity is the only consideration of whether to use a tool or not. There may be many different reasons to use a tool regardless of whether it's complex.

It assumes that a given tool has some inherent complexity that isn't comparable to other tools. Other tools might have less inherent complexity, but their lack of complexity may then create new problems that have to be solved, which just moves the complexity from the tool to a bunch of other places.

Overall, it correlates the way you solve problems, with how complex a tool is, with whether your organization is of one of two large generic groups. This is such a sweeping conclusion that it would be impossible to prove or demonstrate.

Based on your comment about them "using Fargate" instead, I'm assuming what you're actually saying is you think people should be using a managed product which uses containerization [and possibly k8s], rather than managing a complex technology themselves. I agree. But that doesn't mean we can generalize about who should be using what and when.

[nprateem]

I wasn't writing a critiqued essay. It's perfectly reasonable to assume 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.

Also, no need to assume. I specifically said "use something managed".

[yebyen]

IMO "use something managed" gets reduced to "we shan't run Kubernetes on-premises" which ends up meaning "we won't learn anything about failure modes until it's too late to think about mitigating them"

Which might be in line with what you said about

> 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.

But also, would at least have some potential to be solved and much more cost effectively, or maybe at least grown past, if they would just spend some energy on deploying Kubernetes internally; even if we can't or won't afford an entire team dedicated to doing only that, (and even if we commit to using only managed services for production anywhere and everywhere.)

In my experience the way some places reflexively avoid it like it's a trap to be stayed out of, winds up being a bit like a self-fulfilling prophecy "we're not doing Kubernetes" - I empathize with the person who you triggered, even if now we're up to two walls of text from just a simple comment, I feel triggered too.

[nprateem]

This is basically a build vs buy discussion. Businesses have generally concluded they should only build things that give them a strategic advantage and buy other services to maintain focus on their sources of competitive advantage. Eg in the case of k8s, it's not just spinning it up, it's securing it, patching, monitoring, etc. It's for this reason the majority of orgs shouldn't run it themselves.

However some balance is needed. Orgs may want to do exploration since it may not be obvious where competitive advantage can come from, or like you say perhaps hybrid makes sense, using it only in non prod.

[marcinzm]

> Also it really feels like all the air has been let out of the docker/kubernetes/cloud-native balloon that was so popular in the late 2010s.

Not really, the space has simply grown faster than these companies could keep up with and were left behind.

I can code up a CICD pipeline that does per-PR namespace isolated deploys of an app stack on EKS using Github actions in well under a week. With docker compose for local testing. That wasn't the case 5 years ago but it is now. Why would I want to be locked into Weave Works?

[benjaminwootton]

GitHub actions must have eaten most of the DevOps tooling market. It’s pretty good and it’s fine for the vast majority of pipelines.

[Yasuraka]

GH Actions is just CI, maybe crude CD, and not the best at that.

It and (GitLab CI) ate Jenkins

[lmm]

Jenkins still does stuff that you can't do with GH Actions. Actions ate Travis / TeamCity / CircleCI, all the "more polished Jenkins for the 80% use case" products.

[yebyen]

What does Jenkins do that you can't do with GH Actions and Flux?

[lmm]

Based on the last time I looked: good handling of dependencies between builds (e.g. the ability to do an "edge build" where for any change in a given project, you check whether that will break your other projects when they upgrade to depend on that), advanced scheduling, plugins that integrate all sorts of random tools into your build views.

[xenophonf]

> a CICD pipeline that does per-PR namespace isolated deploys of an app stack on EKS using Github actions... [with] docker compose for local testing

Please teach me, oh wise prince!

[sytringy05]

<7000 lines of cut / paste YAML later> “it’s that easy!”

[xenophonf]

I'd love to see 7K of YAML as every time I've asked, no one's been able to show me a fully worked, end-to-end example.

[upupupandaway]

How does your pipeline work with an app that requires many other services to work?

[btown]

Your GitHub action can trigger a helm chart, or series thereof, or other infra tools. Declarative specifications, triggered procedurally with the context of the branch’s latest build. We use this pattern quite extensively for preview app workflows.

As of a year ago this is possible in a fully declarative way with Flux 2, but there’s a lot more moving parts and security footguns - and the idea that the maintenance of this project has lost one of its primary sponsors is worrying at best.

https://github.com/fluxcd/flux2/discussions/831

https://blog.kluctl.io/introducing-the-template-controller-a...

[swozey]

Hell, we do it once in terraform/pulumi/cdk and then it takes 10 minutes to tweak some variables and switch aws accounts and bam

Our devs/SRE put up apps and clusters in minutes (aside from the terrible alb/ecs/eks/etc deployment times).

[FourierEnvy]

Yeah this is nice if you have large teams and repeatable projects. Smaller companies have much more ad-hoc requests. I stood up an entirely new type of project end-to-end from a docker compose into our cluster. Re-used alot of code base but it was still a bit of work. Much less than it used to be though.

[swozey]

I have this installed but I've never actually done more than a quick test of it but this might be a good tool for you. It'll record all of your aws console actions and output them as terraform, couldformation, cdk, etc.

That'd give you a repeatable deployment for disaster recovery without having the toil of writing that part of it. Having to click through every checkbox in the console and iam perms and blahblah under fire is rough.

https://chromewebstore.google.com/detail/console-recorder-fo...

[master_crab]

This.

We looked at weaveworks and its competitor both as a product and an investment (mid 6 figure usage). Our big issue was that we had a lot of smaller teams doing different things and not one or two featured items raking in the majority of our revenue.

These solutions work if you have a bunch of snowflake workloads by design (or bad design).

[yebyen]

> a bunch of snowflake workloads by design (or bad design).

That's a really interesting characterization of WGE, and I can't say I disagree much (my personal opinion as an ex-Wyvern/OSS Engineer DX @ weaveworks)

[FourierEnvy]

Yeah I literally did this last week for a new in house AI assistant for my company. Just swap out Jenkins for GH actions (sadly). So... can confirm.

[mad_vill]

they did more than just CICD but I see your point.

[swozey]

> Also it really feels like all the air has been let out of the docker/kubernetes/cloud-native balloon that was so popular in the late 2010s.

Kubernetes is just boring now. It's stable, the people who need to know it probably know it. I started working and contributing to k8s in 2015 back in version 1.1. 7 years of the same technology. I haven't even used it in 2-3 years (1.18) and I know I can hop over to it and do exactly what I used to do with some CRD flare.

All of the contributors should be proud of what they've built, that's the goal in the end, stability to where it's an afterthought.

[softwaredoug]

"Smaller consultancies" are actually really hard. Especially if you want to deal with larger companies with the type of $$ to pay for consulting. Instead of doing the work you love you end up in procurement and payment hell.

[kensey]

Small consultancies also tend to fall into the trap of having one client (often their first client) that they utterly depend on the money from... but who doesn't depend on them to be able to survive. That customer almost always knows the relationship is unbalanced in their favor (sometimes they went into the relationship specifically because they knew it would be that way) and they will run you ragged with unreasonable requests, burning out your staff and ruining your relationships with other clients because you have to keep them happy so they keep writing checks (and then you're even more dependent on them, as a rancid little bonus).

The only way out is to either gut your way through it till you grow enough to be able to push back without risking your existence; detect that things are going that way early and fire them as a customer before it ever gets to that point... or keep burning out staff till you can't find fresh faces, then close up shop.

[mech422]

God, sales and collections suck ... and Net 90 can be a killer for smaller shops (and big clients tend to expect Net 90)

[jbu]

I know a bit of the history with this one.

Back in the day there was a smaller consultancy with awesome developers called LShift (mentioned here https://en.wikipedia.org/wiki/East_London_Tech_City). They worked out that an open source messaging thing would be useful, and created RabbitMQ (there were details about who, how it was funded internally, etc). That got sold to VMWare, and a bunch of people went with it, but LShift went on as before, happy, but always looking for another Rabbit. Didn't find one, was aquihired in the end.

Meanwhile, some of the Rabbit people formed Weave, looking for the killer business around the early container ecosystem (https://www.weave.works/oss/net/ was interesting, eksctl, flux, CNCF, lots of good things). But I guess they took a bite of the VC apple and sustainable technical contributions was no longer the goal.

I've huge respect for everyone I knew from Weave. Great people all. Best wishes and I know you'll land on your feet.

[mfer]

VC funded and looking for growth opportunities is far different than building a long term sustainable business. The carrot in the business model leads business decisions in very different directions and your setup is different to meet them.

Are there opportunities for VC funded with growth expectations in this kind of business?

[abhiyerra]

This is what we are doing with my company. We build out tooling that benefits everyone and open source most of it, but our bread and butter is consulting. Our consulting leads us to build more tooling to make our jobs easier, which leads to more effectively delivering our consulting.

I think this is the model most of the big shops like IBM and Oracle also use. Infrastructure tooling is not usually a core competency for most companies, and they want others to do it for them.

[ryanSrich]

> I feel like the next generation of this type of company is smaller consultancies that have awesome developers that build customer tooling on the side. But the main revenue driver is consultancy.

The issue here is the lack of appeal for investors, leading to a tenfold decrease in new cos. However, the startups that do launch are likely to be more sustainable

[BrittonR]

I feel like this is how a lot of the Nix community and Elixir community already functions.

[gtirloni]

> that was so popular in the late 2010s

Was? What's more popular than that today?

[goalonetwo]

Since the end of the free money era, a lot of people are rightly questioning the microservice/k8s/cloud-native model that requires you to run an operation team of 20 people and has a baseline cost of 200k$/year for a cluster that doesn't do anything yet.

[gtirloni]

It really doesn't and you won't get anything useful out of any discussion by making these exaggerations.

[goalonetwo]

Are you working for a vendor?

I have worked in multiple orgs that standardized on Kubernetes as end users. Those numbers are coming from my real life experience. If we include all costs it is actually probably way higher than 200k per cluster.

[tsimionescu]

> Also it really feels like all the air has been let out of the docker/kubernetes/cloud-native balloon that was so popular in the late 2010s.

As someone who works for a company that sells various k8s versions of products and services, we're only now seeing some of our bigger customers really starting to use k8s more exclusively. So at least my experience is the opposite of yours, it seems that at least in some industries k8s is only now seeing significant adoption.