Companies with ample cash will be fine, of course, but all these spurious startups with egregious VC funding, overpaid Pulumi and Kubernetes and <insert all the other unnecessary tech> engineers will soon be out of work and unable to find similar employment comp.
People who get shit done and can run lean profit driven businesses will continue to survive just fine.
> Low interest rates in 1998–99 facilitated an increase in start-up companies
> In 2000, the dot-com bubble burst, and many dot-com startups went out of business after burning through their venture capital and failing to become profitable.
Sound familiar? It should, because history rhymes.
People have seemingly predicted 20 of the last 1 tech bubbles. The "Dot Com Bust 2.0" headline is practically a meme at this point. I feel like it's something lazy journalists do on slow news days. Here's a brief sampling from the last 8 years.
From 2014 - "In Some Ways, It’s Looking Like 1999 in the Stock Market"[1]
From 2016 - "This Tech Bubble Is Bursting"[2]
From 2018 - "Silicon Valley tech bubble is larger than it was in 2000, and the end is coming" [3]
From 2020 - "6 Reasons This Tech Bubble Is Bursting"[4]
Ad infinitum.
[1] https://www.nytimes.com/2014/03/30/business/in-some-ways-its...
[2] https://www.wsj.com/articles/this-tech-bubble-is-bursting-14...
[3] https://www.cnbc.com/2018/05/22/tech-bubble-is-larger-than-i...
[4] https://www.fool.com/investing/2020/09/10/6-reasons-this-tec...
Companies relying on crazy market valuations will pop just like they always did. Companies with sufficient revenue OR cash should continue.
Kubernetes is fine and it's not _unnecessary_. It's absolutely crucial to many companies and having this tech available has solved many problems. It creates other problems, of course.
People like to complain about Kubernetes, but my viewpoint is that microservices is the unnecessary tech here. Sure, some stacks may benefit, but I'm willing to wager that most companies are not doing microservices, they are actually creating distributed monoliths just to be able to ship their org chart. And, in the process, adding all sorts of technologies that shouldn't be necessary.
It’s not just that of course. It’s the entire web toolchain and build pipelines, SPAs, react, node/npm, that entire community reinventing “SSR” and caching.
It’s the “modern data platform” movement where people stop using databases and slap everything into python and 10 layers of ETL and job queues and dags all so it loads into a cloud data platform with a separation of storage and compute at the end.
It’s all a bunch of crap is my issue and why I call it a bubble. Nobody is solving actual business problems. They’re just creating tooling and then new companies to make that tooling less insufferable.
As one tiny example, how much of say Datadog’s revenue is coming from overfunded VC companies who have never considered cost or utility. Those logs should have been sent to /dev/null in the first place is usually the answer.
> Nobody is solving actual business problems.
I think most people are solving business problems and that you're (perhaps justifiably) jaded on the tech side of it.
The entire CNCF doesn't solve a single business problem. And I say this while working with K8s since 2016. Not once has a customer thanked me for my tech stack.
You and the parent are probably talking about different people.
Hmm, I disagree with that assertion. Yes, a customer isn't going to thank you for making an investment in depending on open standards. But it's often a worthy investment because it lets you hold other vendors you depend on accountable. I've seen this firsthand with OpenTelemetry and the Observability space, where it's not uncommon for vendors to lock you in and get weird and shitty with you. I'd love to live in a world where that didn't happen, but in this case I think there's a very real business problem being solved.
Not sure about Pulumi, looks like they only have a series B 1.5 years ago. Either they have a very short runway at this point or found some real ARR.
Also how many IAC vendors are there really? Hashicorp, Pulumi and AWS? What are the others?
As I recall before cloud era infrastructure on any kind scale was still code, its just that the code was maintaining thousands of lines of Kickstart of FAI configs and associated preinstall and postinstall shell scripts. I don't remember that being any more pleasant to maintain.
What OP is getting at is that IAC is often not /sold/ this way, it's sold as way to make managing complex systems simpler, in the sense that someone with less expertise can use it effectively, because marketers and salespeople love promising something that will remove all that pesky setup work and let you start on whatever it is you actually want to do. This can be true for some tools (e.g. I don't have a great deal of knowledge about compiler internals or assembly, but my compiled code still does what I wrote it to do), but not necessarily all.
Managing an AWS environment is an inherently complex task, and IAC tools can't reduce that complexity without being prescriptive. We may in the distant future get to the point where prescriptive configuration is fine (I trust that my compiler will make better assembly optimization decisions than I ever will), but we're not there now. What we have now addresses UX issues with using GUIs for these tasks.
i've tried to fight this by leading by example with https://dhall-lang.org/ but apparently having a configuration compiler is too much... unless the compiler takes yaml as input, then it's fine.
It's almost like someone had a bad idea and put XKCD and Xzibit in a blender...
It's not unlike LISP's predilection for sexpr-based DSLs, I suppose.
I hate yaml as much as the next developer, but I've met plenty of folks who far prefer it to using a "real" language. Different strokes for different folks?
The challenge from a product standpoint is how to balance these different ways to do something without (a) ostracizing one group, and (b) creating a confusing mess on the "get started" path.
In the case of IaC, what the customer really wants is a programmatic way to generate instructions for Pulumi to use to build infrastructure. The dream of "declarative" anything is to explain what you want and have a machine make it reality, right? But in practice that's hard to do. The machine needs to be very, very smart.
But it's not that smart. So we cheat and invent non-programming-languages, so that people end up telling the machine in far too much detail what they want. Do I really want to tell the machine to "go in a loop creating resources as long as there are resources in a list" ? Or do I really want to do some other thing, and making these resources should just be an incidental part of that that I shouldn't have to explain at all?
Programmers who like YAML for anything other than pure data serialization don't actually like YAML, they just like that they can cheat with it. No need to write a configuration format if you read your configuration from it. No need to write a DSL if you execute logic based on it. The programmers who don't like YAML wanted to do the same things, but were bitten by all the problems that came from using the wrong thing for the wrong purpose.
So really, the product person and experienced engineer need to work together to prevent this whole situation from ever occurring. Create a schema, and create libraries that can generate YAML based on the schema, but do it in such a way that no human would ever want to edit it by hand, and too complicated to ever write a generator for it without the schema. This way the customer can't shoot themselves in the foot, or demand changes which would make everything worse.