I know this isn't the craziest startup shutdown story, but wow.
At $10MM of revenue they can afford to keep a staff of 50 at a fully loaded cost per employee of $200,000. Yet, according to Linkedin they peaked at nearly 200 employees.
In other words they somehow were running at a loss of about 1.5 million a month for three years until their runway "suddenly" ran out today.
According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company until some greater fool bought them out, which appears to have failed.
How do you find yourself as Board member or CEO of a company like this and not think to cut expenses a little sooner? Far better to be a growing, profitable 50 person company than a cash-burning Potemkin unicorn.
> According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company until some greater fool bought them out, which appears to have failed.
Because that is what startups do. 80% of startups that are "successful" follow this pattern
You shoot for the moon, if you don't take massive risks, then you won't be rewarded.
It sounded like they were about to be bought out or aquihired, but it fell apart at the last moment (It's not uncommon)
> Far better to be a growing, profitable 50 person company than a cash-burning Potemkin unicorn.
because probably they looked at the pipeline and realised that if they wanted to deliver the features/customer growth they needed, they required 200 people to get there.
"Shoot for the moon" seems like a reasonable strategy when you're making the investment.
However, certainly at some point while they were burning through that $36 million it became evident that "moon" was no longer a viable destination. Why wouldn't everyone be aligned with making the adjustments needed to get back to default alive? Something is clearly better than nothing.
Now if it got to the stage where the CEO no longer wanted to operate at the reduced scale (and nobody else would take the role) or the product couldn't support itself at the reduced scale, then closure may have been the only option. It's just that the "moon or bust" mentality doesn't seem like something that should be set in stone for the life of the company.
Because this is not what the VC wants. The VCs are diversified across many startups and frankly make most of their money from tail event startups in their portfolio (e.g. Uber / Facebook). Since they don't know which startup will be the tail event, they don't want a profitable business, but a max growing business. This is different from the bootstrap model.
When it's still enough runway to trim it down, there's often still some hope of greater success - and a VC investor might believe that it's more valuable to have a 1% chance of it becoming a unicorn or a few percent chance of arranging some last-minute buyout, rather than pick up the 100% certain but low price it has as a non-growth business based on its revenue.
Yes, due to their large bankroll and diversified position, VCs can afford to be risk-neutral and only care about expected returns. Founders and employees obviously cannot be risk-neutral, ergo startups are a great bet for a VC and a terrible bet for anyone else.
I don't really see why such a side deal would be possible - if the VC goal is to get the founder-manager to try for that narrow hope of few percent of major success and discourage them from settling for a lower-value stable business, allowing the founders to cash out would be counterproductive, it's in the VCs interests to ensure that founders personal financial motivation is aligned to theirs, that the founders are also motivated to go big or go bust.
In essence, if the startup is slowing down and perhaps not going anywhere, then the standard existing deal with founders where the founders can cash out only if they enable to VCs cash out at a profit (for example, if they manage to pull out all the stops to make a failing startup look attractive to some bigger fool) is exactly what VCs want, and in such a situation the founders have no leverage to extract a compromise that's worse for VCs.
The typical situation is the company has been around for a few years and the founder has some reasonable sounding expenses. Then the next round includes some cashing out as new investors join.
What to you (and pretty much anyone else) looks like a business that just needs adjustments to reach profitability, to the VCs it's profile maintenance work for little relative benefit in the long-term. The chances of that company turning 10-20x profits in the next few years is basically zero and they just cut their losses (in their view).
I know this is the case but I wonder if this is a self-fulfilling prophesy.
I can easily imagine an alternate reality where VCs invest more thoughtfully based on more careful analysis of companies and they would have a much higher success rate and end up with even higher returns without creating unsustainable wealth inequality.
> an alternate reality where VCs invest more thoughtfully based on more careful analysis of companies and they would have a much higher success rate and end up with even higher returns without creating unsustainable wealth inequality.
Unlikely. The problem of that view is that, when you're handling large uncertainty, you don't know which projects are the ones you should cancel and which ones to nurture. Past performance is a terrible indicator for lucky shots.
See the Talent-Luck simulation for instance.[1] You measure a population of projects affected affected by random events and profiting proportionally to talent, and the projects that end better off are the ones that chain multiple beneficial lucky strikes, with talent having little influence past a minimum level.
And the way to maximise gains over the whole population is setting a small flat subsidy for all, allowing everybody to explore their talent even after a wrong turn.
>> And the way to maximise gains over the whole population is setting a small flat subsidy for all, allowing everybody to explore their talent even after a wrong turn.
I don't think that's what VCs did. It looks more like they dumped millions of funding on a tiny number of hand-picked companies and used short term traction as the main metric and they equated profitability as anti-growth, failing to realize that, without demanding profits, growth could be produced artificially using money/advertising and that it doesn't mean that users actually want to use the product in the long run.
Profitability is how you know that users want to use a product; otherwise a company could just 'launder' investment money to their users somehow and of course nobody will refuse free surplus value and hence they will attract users... Until the investment money runs out and the surplus value stops being handed out to users.
Just think of Uber investors subsidizing rides as an example, as soon as that subsidy goes away, there's a good chance it will start declining. Uber is still unprofitable.
To you and I, this is patently obvious. This is not true however for VCs. In a lot of them, they'd prefer you fail entirely rather than limp along making 1x, 1.5x their investment. Zeroing out is preferable sometimes, weirdly.
I get preferring (10x or 0x) to (1.5x). I don’t get preferring a near-certainty of 0x to some recovery of their capital with a pivot to selling a smaller-but-sustainable business.
Is it something like they’re measured by LP’s (or someone?) on only non-zeroed investments?
I've worked at a VC, and consider that it is a low margin business until/unless you returns significantly above your targets. You get a management fee, which is a low yearly percentage of the invested amounts, and then you get carry - a proportion of the returns above a set target for the fund as a whole.
But carry doesn't kick in until you start exiting - for a typical VC fund it takes many years. (I left a year ago, and we were 6 years in when I left; I retained a portion of my carry rights, but still won't know for a couple more years how much I get if I get anything at all)
And surviving on the management fees after the initial phace of placing the investment requires being lean and not putting effort into your low performers.
Meanwhile while a 1.5x is better than nothing, a company that sells at 1.5x is likely to be near 0x for you, because odds are high that to get there there'll be one or more funding events along the way to help that happen at/triggering terms that will dilute you massively. And odds of failure remains high.
And you need the 10x or 100x's, but the low ones means little - most successful funds pay back the entire initial investment from just a couple of investments, and make their return on a couple more. Quite often a single "fund returner" carries the entire fund.
A small recovery here and there at makes almost no difference.
So even a 1% chance of salvaging a "moonshot" is better - most cases where you get back less than 1x is going to be a rounding error of your funds overall performance.
A VC is not where to get capital of you want to pull back and pivot when things get tough.
(And yes, you should keep that in mind if taking a job at a VC backed company as well, and it's part of why stock/options should be on top of your normal salary, not compensating for a low one, unless you get founder-level stock amounts, and even then, think it through; I once almost torpedoed a VC deal as a founder because I demanded a commitment to raising salary levels after the next raise, and I don't regret it for a moment because life would have sucked without it)
Don't VC companies basically gamble with other peoples money? So yes, the person that actually put the money into the fund might want 1x or 1.5x out over 0x, but for the VC firm it doesn't matter, right? It's not their money to begin with.
LPs in a VC fund know very well what the fund is incentivised to deliver. I worked for one, and our LPs would aggressively write low performers down to zero. It didn't matter to them either. Obviously wouldn't turn it down if still possible once all else has failed, but retaining even a fraction of a percent shot at a higher return was what mattered most, even knowing it was extremely unlikely.
Investors in these funds are diversified - they invest in VCs to take the high risk bets. They invest elsewhere for the steadier, lower risk returns.
That's not a major component of venture backed startups. For a company that has already been written off as a failure, often the board members that represent the VC would rather not have to stay involved and keep showing up for meetings -- they could be elsewhere; there's an opportunity cost.
You’re being way too reasonable! A stable, self-sustaining business is for mom and pop corner pizza shops.
Tech companies want to disrupt and destroy everything in their market segment or die trying.
I wish there were more companies that would focus on stability, sustainability and longevity. But in my experience lack of rapid growth is a mark of failure for most companies.
Oh indeed. But the problem is, you are the CEO, you are being told by your investors that you need more product market fit. This means selling more shit. PMF is the driver of value (we have x thousand/million/billion customers, therefore we are valuable)
That means you need more velocity. Which means more people.
More sales, more presales engineers, more subsidies to undercut the competition.
You have to remember that VCs are rarely there to make sustainable businesses, they are there to make valuable assets that can be sold. Even the nomenclature reflects this, startups are in batches. Because out of a set of 100, you expect 90 to fail after two years.
They could have done layoffs like almost every startup and big tech company did in the past few years. They could have gone there with 50 good employees. Gumroad almost went bankrupt then came back from the ashes.
>80% of startups that are "successful" follow this pattern
Doesn't this sound like selection bias? If every other startup follows this shoot fornthe moon plan then yeah it just becomes a self fulfilling prophecy
> But everyone is following the runbook as if they were the successful 1% (not even the successful 5%, they all act as if they are the top 1%)
I think it's because that's what makes sense from the VC's perspective. To the VC each startup is a lottery ticket with a low probability of an outsized success and a high probability of failure.
You can burn the startup as hard as you can, because the cost is primarily borne by the startup and the founders. If the startup fails it doesn't matter much to the investor because the portfolio is constructed to be resilient to a large number of failures.
What the OP is getting at is: if you look at this from the startup/founder's perspective isn't that kind of a huge waste? And yeah, it is. But I think the idea is that startups and founders aren't pets, they're cattle.
We are, of course, assuming that they grew the main dev group to 100, rather than creating a new team, for a new product.
The biggest issue is that product and project management isn't taught well. There isn't a wealth of easy to understand literature. The stuff thats available tends to be LLM level waffle.
you can hire consultants, but they also tend to speak in business vague, without offering specific advice.
Sadly, what you need are experienced PMs, lead engineers and business types. They are hard to find, and tend to come late to startups.
It is possible to grow a company from 25 devs to 100 and keep velocity. But it requires planning, clear communication and clear process to make sure that people are not spinlocking or re-inventing the wheel. I know its possible, because I've been at a place that's done it.
>> How do you find yourself as Board member or CEO of a company like this and not think to cut expenses a little sooner?
I've worked at several startups who never cut costs, meanwhile they're burning through cash faster than an incinerator at the local trash company. I had one company CEO who remodeled our entire offices, got sky boxes for all the local sports teams (there were four of those) and made a point to tell all the devs they're the highest paid startup devs in the city.
I found out later, our CEO also had a pissing contest with another startup CEO on the same floor of the building we were in. Both companies had over $200M in VC money, and both were trying to outdo each other with the lavish lifestyles they were living on the investors money.
The other company put on a massive "release" party to announce their internet software to the local tech new media. Apparently they blew close 10 $2M on it. Limo's for all the employees to the five star hotel ball room, a red carpet VIP entrance for all the employees like you see on those awards show, some 70's rock band played, and it was open bar all night and they reserved an entire floor of rooms in the hotel where the bash was thrown. Two of the devs told me afterwards, "Dude, totally not my scene, and none of our team were cool with this at all."
Less than two months later, both companies ran out of money, quietly shut their doors and closed down.
At a bar across the street, we had a group of devs from both companies sitting around lamenting what went wrong, where we were going to next, and reminisce about both companies.
We all reached the same conclusion:
>> According to the CEO's linkedin post, they were basically trying to keep up appearances
They're indoor VIP seatings the top of football stadiums with a panorama view of the entire field. It's usually where the sports commentators sit. Or rich people.
1) As a CEO, I want headcount. Being the CEO of a 200-person operation sets me up for better jobs than a 50-person one. Being in high-profile organizations if good too (and when they fail, I can switch jobs). Same for VPs and managers.
2) As a CEO, I want bonuses. Those come from growth. Zero bonus is the same whether the company lives or stagnates.
3) Rationally, in winner-takes-all markets, a lot of this depends on early losses and overspending. If you and I are building eBay, and I get there for $10M and you for $100M in 10% less time running massive losses, you win. A lot of tech is winner-takes-all or winner-takes-most.
.... and so on.
Except for retirement account holders whose money is being spent, it's almost certainly better to be a cash-burning Potemkin unicorn than a growing, profitable 50 person company.
>According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company until some greater fool bought them out, which appears to have failed.
That's probably pretty brutal summary of most of past two decades I guess?
Also, had it been bootstrapped, might have a different outcome, could scale down, pivot while staying a small profitable shop.
If they received $36 MM in a fundraise 3 years ago, you better believe that those investors put pressure on the business to grow fast or die trying. Those investors are not looking for a somewhat risky medium % return, they're looking for each company to have a small % chance of being a unicorn.
So who out there is running an investment fund that's looking to make a much more reasonable rate of return off successful but slowly growing companies? Because I would put money into that fund.
Assuming you’re asking in earnest I would begin with S&P 600 Small Cap companies, and see how they got their starts. These are all profitable companies with various levels of earnings growth and indebtedness.
Also commercial real estate fits your criteria almost perfectly.
You probably want the kind of private equity funds that do succession transactions.
Small slow growing businesses tend not to actually need capital very often, so there isn't exactly a huge market for investing in them.
On the other hand, you get a lot of businesses whose owners are getting old / sick of the business. They need somebody to buy them out and install a new management structure.
There are a bunch of funds who do things like that. Look for "Private Equity" as a more broad category rather than just "Venture Capital".
Because no one that matters cares about a company that makes $10 million per year, neither the cofounders nor the board. Everyone wants 100x that because they want to become 9 figure wealthy or more. Better to close down, fuck the customers, and then have the cofounders start a new "journey" in hopes of getting that unicorn status and become fabulously wealthy.
No to be pedantic, but payroll isn’t 100% of cost. Plus cash flow issues, sales volatility, probably declining revenue as you scale down…my guess is the headcount should be more like 20-30. And that might not cover their personnel needs if a lot of their revenue relies on services and customer success (which is usually the case for OSS companies)
Sometimes investors have no interest in anything but a large exit. So it's large exit or bust. Building something stable that grows at a reasonable pace is considered the worst outcome because it both consumes investors time/energy and delays closure of a fund. They're left holding shares that are illiquid.
It's perverse of course but it can be something baked into the structure of how VCs and other funds work.
More specifically, how much is a SAFE for 7% of a small business worth? If there are no liquidity events it will be impossible for investors to even get their money back let alone outperform SPX
> How do you find yourself as Board member or CEO of a company like this and not think to cut expenses a little sooner?
It's like playing Super Mario: one life left? Die sooner to restart again.
There will be a next startup soon, and saving this one does not worth effort. Besides that, the CEO has probably got his cut already as salary. This cow is done, bring in the next one.
Another 'CEO' with "Everything was going AWESOME! Our numbers were great and getting BETTER! Our customers LOVED us! Buuut...we're closing shop, today. Totes sorry, bro.". Not a single mention of "because we managed cash like a drunken sailor and bet the farm on a singular exit event". The spin is making me a tad dizzy.
I think, motivation would have been, if they were able to sell themselves as 200 person company, the CEO and Board would gotten a bigger piece of the pie in the landing space.
As I pointed out elsewhere the 200 person company is not accurate. The OP is quoting something listed as "peak" on Linkedin without even providing a reference. And for some reason everyone is running with that figure. Nearly every tech company had a peak headcount during the height of Covid. Techcrunch generally also has inaccurate tech company numbers in their profiles. Also you can't sell yourself as a 200 person company if you don't actually have 200 people as that would come out immediately in any due diligence an acquiring company would would do on you.
We don't know all the details. Maybe they had high costs elsewhere or a market insight that made them re-think whether they want to be continuing to operate that business
Incentives. Lots of incentive to ride the horse to death while the money's still available. You get free stuff, get to live the high life, gain celebrity, get interviewed, make social media posts people pay attention to, get invited to fancy parties like Davos. No bad publicity.
In a lot of cases, it seems like the real incentive is "pretend to have a really desirable product, make demo after demo to draw in investment, party as much as you can while pretending to make something, lateral to the next company while claiming external market conditions." Live the Wolf of Wall St. life while the Titanic sinks.
Still think the main Pokemon advancement for companies is mostly -> Bankemon -> Casinomon
It's not that unreasonable. During the post-covid inflation and high interest rates getting loans and attracting funding got very much more difficult. Downsizing by 75% probably would result in a failure that just took longer. They chose to keep going in attempts of securing that next step and it didn't work so they shuttered. The environment for funding changed and the less attractive startups shuttered, that's what happens. Maintaining a short runway is a vibe, a path towards a big reward or a quick failure. That risk isn't for everybody.
>"According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company"
Where in the linkedin post does the CEO state that?
My understanding is that they reduced headcount greatly over the last couple of years and were well below a 100 people. The source of this was a then current employee that my company interviewed in November.
we all know that once you get 36 Million$ of investment, you cannot "just" run a 50 people startup that will have a stable valuation of maybe 100m$.
Once you take big investment it comes with the expectation you will get to 500m$ at least. VCs don't want to 2x their money. They want a small chance of 20x.
It's a naive point of view, I know, but I often wonder how a business could function if wages and salaries were considered to be profit. This is clear enough for an individual running a business, or even a family operation.
For larger businesses would it be possible without adopting an extreme socialist (or even communist) approach? If so, how would you balance this with the interests of investors/owners (i.e. people that aren't involved in the operation of the business)? Would the businesses be more or less sustainable on average? Does the very existence of outside investors necessitate categorising wages and salaries as a cost?
Probably most popular thing they built was FluxCD if you are confused where you have heard their name before.
Their company provided a ton of extra tooling and consulting around the product. Hopefully as FluxCD user, this doesn't impact the development of Flux.
Right. Flux was a handy little tool[1] that sync'd yaml manifests in git repos to live clusters. The concept was fascinating, and the tool was well done--small and efficient. Easy to learn.
In 2019, they announced they'd be "merging" with argocd[2]. It seems the merge never really took place, and after that they deprecated flux and announced flux2[3].
The sudden changes of course were a little confusing and perhaps not too well communicated.
I was hired to support Flux v1 two years after the events you described, in the beginning of 2021 to go on supporting Flux v1 until we could get everyone off the boat.
(I worked at Weaveworks until last month, and I'm still a Flux maintainer! Keep the Flux talk in Present tense please! ;-)
That was my first recollection -- after CoreOS' Flannel, I think the next two (or at least two of the earliest) overlay networks available for Kubernetes were Weave Net and Calico (whose core maintainers started Tigera). Flannel is still around and under active development despite CoreOS being long gone; hopefully the tools Weave employees maintained can keep healthy communities going around them.
I think people got turned off from them when it came to light they had invented their own cryptography without doing any vetting that it was actually secure. At least, that’s why we moved away from it as quickly as possible with our reasoning being: “if someone is foolish enough to roll their own crypto, what else are they doing foolishly?”
Despite having been the main maintainer of Weave Net for ~4 years, I have no idea what you are talking about. Weave Net used Google's NaCL library from day 1; later adding optional AES using the in-kernel implementation.
The key exchange was/is totally custom without using anything standard, though it uses standard concepts (DH, though it does some non-standard things with it), which *might* be secure, but as far as I know, never actually put to the test.
We were using the weave CNI on our kubernetes cluster. It started failing, so we called weaveworks to try to buy support. They said no, recommending a different CNI which would necessitate a disruptive cluster replacement. Once that was a necessity, all the other CNIs were on the table and we went with cilium, which has been ok with k8s 1.22 on CentOS 7, but which is now having undiagnosed trouble with k8s 1.24 on Red Hat 8. The messy process of figuring that out is underway.
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.
> 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.
> 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
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.
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.
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).
"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.
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.
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.
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".
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.
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.
I agree that it makes more sense to buy your Kubernetes on an organizational basis because one should not reinvent the wheel, and taking advantage of a commoditized service is only possible if you work with a competent broker.
However I am wary of the capacity of skills vendors to take advantage when you come to depend on them, even when their intentions are good and all ideals aligned. Being able to deliver the limited Kubernetes experience for yourself in low-stakes contexts, where you can depend on it because you know how it works, well enough to administer in a pinch, but availing that also in a pinch you're not the bottleneck to solve a problem, because you use the managed broker in all the places where it matters, feels like a sweet spot to me.
I don't want to pay money to a broker every time I spin up a new experiment for the duration of the experiment =/= I don't want to perform experiments.
That's where I see the disconnect that "Leadership" may fail to understand. You can provide a service at low marginal cost to take some of the load off your people, and that might also have the effect of stopping any experiments that fall beneath a certain threshold as "not worth the cost" - all because we settled on getting something for cheap that should have been free.
Then again, dodging all those diversions might have been a part of the strategy...
> 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?
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.
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.
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.
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.
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.
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).
> 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)
> 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.
"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.
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.
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.
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?
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.
> 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
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.
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.
> 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.
I was following them on and off as they started around the same time I started a company in similar space and we shared an investor. Similarly, Armory.io also got sold in what seems a fire sale ($7M after raising $200M).
Companies dont want to pay for specialized building blocks. Similarly we've been looking at Coralogix recently but needed synthetics. We were offered some sort of package with ur company but decided to go with Datadog instead.
Atlassian’s market cap is $55 billion. GitLab’s market cap is $11 billion. GitHub sold for $7.5 billion in 2018. There’s money, you just have to be more than a point solution.
The services you're describing (Databases, Security, Auth) have become commodities. This means cut throat competition. Most new players will not have enough to differentiate them from existing offerings
A perennial topic at lots of IT/devops standups these days is how to get rid of SaaS overhead, so this isn't a sure thing either.
Bottom line is that developers and IT pros are cheap. I know because I am one. We always try to find a way to not pay for things and especially to avoid any kind of lock-in. I'm allergic to anything proprietary or anything with a SaaS, which is ironic because that's one of our company's products... makes me think perpetually about how to fix this broken market by offering a way to pay for good tools and products without either proprietary lock-in or eternal rent (and centralization and all that entails). It's a very hard problem, and it's not really a technology problem. More of a biz/legal/economic problem.
They’re cheap until the management realizes they just spent a year (so like $300k) educating their devops how cni works and they bounced to faang or some other startup so the project needs to be scrapped or restaffed again and started over. That’s where the services come in. Also yeah it’s well known ICs view saas as direct threat so everyone tries to skip them and go directly to KDM. That’s the reason nearly all enterprise software is pain to use
I think the comment you're replying to meant to say developers are cheap in the sense they allergic to spending money, not that their time/salary is cheap.
Example: "John is a cheap bastard. He never spends any money or buys the cheapest options".
It's not just the money, it's all the things around using corporate money. Procurement is its own level of hell. Dealing with (or even having to think about) vendors' sales critters is a drain on brain cycles. The frustration of "call us" pricing structures.
Or if you want to combine all of the above: perfectly functional but artificially gated features.
If you could pay for a service that GUARANTEES the vendor does not allow their sales people anywhere near your details, that might change things.
Honestly, I think any software business model where you're not paying an explicit monthly/yearly sum is more deceitful for B2B.
No business wants to use a software product that is not being actively maintained, so even if you get sold a perpetual license to "own" a version of the product, you will keep going back to the same vendor to get new versions. So, you are actually still paying a periodic fee, just maybe with capex instead of opex. And if the vendor goes out of business, you'll have to start moving to a new product, so you didn't really "own" the software any more than if you had been paying an explicit rent on it.
Now, SaaS where you are sending all your data to the company's servers is probably one step too far, for various other reasons. But perpetual licenses are generally a bigger scam than periodic ones for business software.
Experience building and operating large systems using public cloud services and design patterns without falling into the traps such as ludicrously overpriced SKUs, API limits, low quota, data transfer fees, and all the boring stuff in the fine print that will rack up a 7 digit bill.
I'm very interested to get connected to the DevRel and marketing folks. I'm one of the founders of Heroic Labs - we build OSS game server (Nakama). My email is mo at heroiclabs dot com - please ping me!
And you should too since k8s, while an 800lb gorilla on the side of the implementer, gives your dev teams the cloud experience without having to build the APIs yourself. Which is pretty nice honestly, making infra self-service isn't on offer most places hosting on-prem.
Flux for me was always superior to ArgoCD from a technical point of view, but they over the years ArgoCD became the more popular tool. I wonder if it was marketing, the missing UI or something else?
But super sad to see weaveworks shutting down I hope that the open source projects will continue to evolve.
The UI makes it easier to sell it to non-engineers.
Not that you need to "buy" anything - but IIRC the only offering that Flux had was a SaaS feature that sort of gave you an UI.
If the UI was what you were looking for, you'd go with ArgoCD.
Finally, I think they messed up the Flux 1 -> 2 migration as they weren't compatible with each other. For my own use case, instead of migrating to 2 I have just switched to ArgoCD.
Feature-wise, ArgoCD always seemed one step ahead, and more people seemed to prefer ArgoCD over Flux - and this can probably be seen also by the fact that they had an "ArgoCon" but there was never a "FluxCon".
Don't get me wrong, I love(d) Flux and I always rooted for that - but over time I switched to ArgoCD and never looked back. In the end, they were two products doing pretty much the same thing, under the CNCF umbrella.
One if the decision points for us using Flux was the the helm controller. ArgoCD will just render the helm chart and apply the manifests. If you already habe an Helm Release in your cluster the migration path was easier with flux.
I guess it was UI, indeed. Whatever "true engineers" think or say, it is an attractive option for many potential users (think not of Ops only, but of Devs, too). Therefore, it brings a bigger audience, i.e. more adopters, more contributors, more integrations, more whatever…
I personally consider the ArgoCD UI an anti-feature. Attaching some hulking mass of Javascript dependencies to the thing that has cluster-admin rights to my production cluster is unnecessary attack surface for me.
ArgoCD also has its own auth system and permissions. You give ArgoCD cluster-admin rights, then it uses impersonation to pretend like it has lower permissions. One little bug there and you can trick ArgoCD into escalating your permissions, which happens a lot: https://github.com/argoproj/argo-cd/security/advisories/GHSA...
While not officially supported, you can technically deploy Flux with limited permissions, but ArgoCD's dependence on impersonation means it cannot run with lower permissions.
Redis is also a requirement to run Argo CD. When comparing load on my home server, flux was much lighter.
Flux also has a pretty cool terraform controller too.
At work though, we use Argo and our developers use its gui to get an overview on their applications.
Thank-you - really appreciate this comment - acknowledging the work that great people did and the efforts they put in. I wish the outcome was different - but we really tried to do good things, and play well in the open source community.
I've worked with Kubernetes extensively since it became popular.
Of the maybe hundred of companies I've worked with trying to onboard to Kubernetes, I don't think a single one really had a use case that justified the increased complexity.
Kubernetes seems so great until you're suddenly drowning in YAML, un-upgraded clusters out of their support window, the need for an unbelievable amount of extra tooling (e.g. ArgoCD, Helm, CSI plugins, Operators), etc.
Plenty of places made it work by paying for huge teams to manage it, but deploying software on regular old Linux servers is fine for most people with just a small amount of discipline.
You don't actually need most of that additional tech. Github Actions + Managed Kubernetes + Helm is solid. Everything else can be additive as needed. ArgoCD is largely useful for deploying to multi single tenant customer installations, but overkill if you have a single prod cluster for example.
This is why whenever there is a choice between a grassroots open source project, and a corporate source project, I choose grassroots. When the corporation gets bored of the project (or just dies), the project dies too. Grassroots doesn't die as long as one person is still willing to merge PRs and make releases, and grassroots is much more likely to be forked and maintained in perpetuity. Community makes or breaks open source.
It has been 100% fine for me, was easiest to deploy, very easy to encrypt all network communication. Has been anything but a dumpster fire, will likely wait it out a see what happens with the plugin, rather than switch to something else.
I still use it, shamefully, ex-Weaveworks employee - there is a fork I can recommend which has a live maintainer, actively interested in keeping it up:
If you use Weave net still, definitely follow his work and consider learning to build the image, so you can keep it ahead of CVE scanners. (You are using a CVE scanner in your clusters, right?)
EKS + AWS CNI work great and will get you pretty darn far. Scaling ceiling is really just your cidr range space. If you're bumping up against that you may be outgrowing EKS, then cillium i guess
https://eksctl.io/ is a very useful tool developed and maintained by weaveworks. I hope it will continue to see development and maintenance despite this news.
Sad to see a good startup folding up. All the best for your next adventure.
I think it's worth giving praise for their contributions to Flux.
In my network, I'm the only one using ArgoCD. Supposedly they're equals, but it always made me curious to try Flux.
Are there any statements about the future of Flux and other open source tools, and whether the remaining community has enough resources to maintain development, or if they will reduce their contributions to only fixing critical bugs?
Can't tell for all their projects, but Flux seems to be safe. Stefan Prodan joined ControlPlane last month already and keeps developing Flux CD. Its latest release (v2.2.3) was delivered while working in the new company. He is also working on Enterprise Distribution for Flux CD (https://github.com/controlplaneio-fluxcd/distribution) there now.
Flux has a pinned discussion for nearly a month now, to be as upfront as possible, without being able to disclose anything that might be privileged information, but anticipating that the news would get out about our backer sooner or later (aiming to avoid 100 threads about the same topic)
This is a world that I have no knowledge of so I expect my comment is commensurately naive, but it does remind me of the days when I was an avid race-goer. If I bet on a horse to win that's all I wanted it to do; if the horse and jockey expended all their effort and won, fantastic, if they lost, better luck next time. Slow and steady may win the race in some circumstances but it's not the tactic most punters are hoping for. The analogy would be more complete if the loosing horses were sent to the knacker's yard and their stable hands all dismissed with only the trainers living to try, try, try again.
They were exciting when they first started, (8 years ago?) before k8s - they had some interesting networking capabilities including the ability to use zeroconf. A lot of Java clustering stuff builds off that which made them special in the age of Docker.
We will never understand the journey of the founders here. In the journey you make mistakes, some of them fatal some of them not so fatal. But the bottomline is that weaveworks did built some awesome tools for the k8s ecosystem. They kind of propagated Gitops in k8s ecosystem.
This is also a cautionary tale for the opensource centric businesses. I remember in my previous job, they would bundle and sell weavescope in the offering where in they would just get the latest version from quay or docker hub as is. I saw the same pattern with Grafana tools. Alot of "Make k8s simple" platforms bundle bunch of these VC funded devtools as offering. Loss of value sometime pains me.
Maybe it was edited later, but the post now says "(>$10M)". I interpret that as $10–19M. That's not great for a product that's been around for 9 years.
I consulted a similar company in their space ~5 years ago. What I found was that the way to make money in K8s automation/monitoring is to position it as a security solution. That's what Snyk did and they've been killing it, reaching $7B valuation as of last year. Both the company I was advising and Weave.works decided to stick to the developer productivity story and unfortunately both have now shut down. There are many factors to a company's success but it doesn't help to be positioned as a solution that's seen as just a "nice-to-have" or part of a "best practice."
Productivity is a hard sell for a company that is tech focused. Since a client basically can't measure the impact there is little external difference between a true solution and a fake solution. As a result even if you convince someone of the value a company that focuses on marketing to those paying the bills will win out against one that focused on building a better product.
Security has fairly proscriptive compliance requirements (ie: SOC, etc.) which provide a benchmark against which to measure impact. Not impact on security but impact on meeting the compliance requirements.
I think, in simpler terms. There's always a Chief Information Security Officer (CISO). But, there's rarely a Chief Productivity Officer. It's usually the CTO et al fighting for dev productivity if any, else nobody just cares and you get impenetrable tarball software
Is that because as soon as you become a so-called security product you are now selling to the CISO org?
My experience with the CISO org is that they love buying expensive B2B enterprise products that have very limited real-life use-cases but are really good at checking boxes. That whole cloud-native security industry is full of FUD and fear-based selling to non technical organizations
Can someone please explain what this company actually did? I’m not a cloud person per se, but I find it strange that I’ve never heard of them given the overwhelming number of people here who are familiar.
Outside of the Containers / Cloud Native world, not much. But they were the 10th-biggest contributor to Kubernetes as of 2020, which for a ~50-person company is something.
Weaveworks created “GitOps” as a buzzword.
Weaveworks created and/or substantially funded these Open Source projects:
I’m more confused now ha. So they had a killer developer first culture but very little recognition otherwise? Sounds to me like they forgot what the purpose of having a company is.
It makes sense if you take in context that Flux, the most visible and well-known product of Weaveworks, is a donated CNCF open source project, and that companies like Microsoft, VMWare, AWS – can all engage with it directly, or by forking, or by building support for it directly into their own products.
How do you place a value on Microsoft building Flux into Azure Arc? I know it isn't worth $0 but do they actually need a contract with anybody (at Flux or Weaveworks) in order to go on doing that - no. They don't need one.
In LinkedIn I also read some of their key people wrote a post with this wording for the announcement: "I americium precise bittersweet to denote – officially – that Weaveworks volition beryllium closing its doors and shutting down commercialized operations." and I almost had an stroke trying to parse it...
Sometime last year, they had someone cold call me from the US to sell me stuff. I’m not sure where they got my number from, but I don’t think that’s a good strategy for trying to sell B2B solutions.
One thing to bear in mind is that at Weaveworks we made massive contributions and did our best to be part of the community in the right way:
* Flux
* Flagger
* Cortex
* Ignite
* Weave Net
* and a whole host more
Oh and there's a load of people without jobs tonight - wondering about their futures - hopefully people will see the talent and the contributions and find roles for them.
And that's a huge bummer since I know people who rely on those products and they're getting value out of them. However, I don't think the company failed because it didn't use more aggressive advertising.
"LambdaTest" does that crap and will call even on weekends. I'm like gtfo of here man. Testing tools is like the last thing I want to talk about on weekend or on personal phone.
I’m a bit more receptive to offline messages if they’re targeted adequately. They can see my interests by skimming my LinkedIn, GitHub and StackOverflow accounts and contacting me via social media or by email is fine if their product is somewhat relevant to my work or hobbies. However, asking me to spend my time trialing their “new super-cool Kubernetes offering” is a huge nope. Especially if that interaction happens over the phone.
The acquisition talked about in the original post wasn't much more than a life-saver for the company so in that regard you could call it life-changing in that many of the fine folks I worked with wouldn't have lost their job.
It would have been very very far from what you usually call an exit, though. Nobody would have cashed out, except maybe some of the VCs and I'm not sure if they'd have called it a successful exit in terms of financial win.
At $10MM of revenue they can afford to keep a staff of 50 at a fully loaded cost per employee of $200,000. Yet, according to Linkedin they peaked at nearly 200 employees.
On top of this, they appear to have raised $36 million three years ago - https://www.weave.works/press/releases/weaveworks-raises-36-...
In other words they somehow were running at a loss of about 1.5 million a month for three years until their runway "suddenly" ran out today.
According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company until some greater fool bought them out, which appears to have failed.
How do you find yourself as Board member or CEO of a company like this and not think to cut expenses a little sooner? Far better to be a growing, profitable 50 person company than a cash-burning Potemkin unicorn.