As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure.
> In the year 2030, no one will remember Kubernetes.
So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
> The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals.
Here is why we ended up here: In my experience, developers want to write code and ship features to hit their quarterly goals.
Sure, and my angry PlatformOps (formerly DevOps (formerly SRE (formerly Ops))) is stuck picking up the pieces because we are getting crap while we desperately paging you because we have no clue what "duplicate street key" in your logs mean. On top of that, InfoSec dropped us 10 tickets about code level library vulnerabilities in your docker container but all the Developer's Managers got together to convince them it was our problem somehow.
So we are forced to write this bundle of terribly written Ops type software in attempt to keep this train on the tracks while you strap rockets to cafe car.
WASM replacing containers is just a solution looking for a problem. Containers solved a problem of "How do we run two different versions of PHP on a single server without them colliding." Most of the containers problem is higher level DevOps problems that we haven't been able to solve and WASM isn't going to change that. I deal with a team that writes 100% Golang so their code is like WASM as it's ship binary and done. Yea, they begged for Kubernetes because it works a ton better then custom Ansible they wrote to keep these VMs/Load Balancer in sync.
WASM is powering Cloudflare workers in pretty much the fashion the guy describes and it does solve the problem of big latencies for cold starts with Lambda stuff
Instead of spinning up a container on-demand you spin up what is essentially a chrome tab in your V8 instance. Startup time is nil
In terms of solutions looking for a problem, that one seems to have fixed at least one problem for at least one person
This is obviously not true when the application itself can take arbitrary amount of time to initialize.
The overhead of WASM startup is small. But Firecracker is also very quick to start the virtualization; a lean compiled app in Firecracker would start quicker than a bloaty interpreted app in WASM. Both approaches can also freeze a pre-initialized application, and even clone those.
Reality is most "serverless" stuff is slow to start because the application itself is slow to start. WASM isn't going to change that, Enterprises are going to Enterprise. The hype field is just very strong.
WASM has select uses. Cold startups for functions is one of them and glad Cloudflare was able to use it.
I however don't have that problem. Every environment I've been in has banished Lambdas for most things because writing ourselves into knots to keep the lambdas going wasn't worth just having a small container listening to SQS/Kafka was easier and if we needed to scale, we could.
The impression I got initially was WASM is a way to ship and app into the browser as a blob of bytecode. No more random pile of js files that are largely unreadable due to trying to shave every last extra byte off them.
While I would lament the age that I came up in, where if some hot company down the street had just a killer javascript dropdown menu well you could just view source and maybe learn a few things. I think what that initial impression I got was a great idea.
But yeah, the concept has kind of expanded. I want to say you can write WASM 'plugins' for istio. Which I also think is pretty cool.
Something is going to replace containers, I say let them take a swing at it but I think at the end of the day you get something that ends up looking a lot like containers.
> In the year 2030, no one will remember Kubernetes.
So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
> The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals.
Here is why we ended up here: In my experience, developers want to write code and ship features to hit their quarterly goals.
Sure, and my angry PlatformOps (formerly DevOps (formerly SRE (formerly Ops))) is stuck picking up the pieces because we are getting crap while we desperately paging you because we have no clue what "duplicate street key" in your logs mean. On top of that, InfoSec dropped us 10 tickets about code level library vulnerabilities in your docker container but all the Developer's Managers got together to convince them it was our problem somehow.
So we are forced to write this bundle of terribly written Ops type software in attempt to keep this train on the tracks while you strap rockets to cafe car.
WASM replacing containers is just a solution looking for a problem. Containers solved a problem of "How do we run two different versions of PHP on a single server without them colliding." Most of the containers problem is higher level DevOps problems that we haven't been able to solve and WASM isn't going to change that. I deal with a team that writes 100% Golang so their code is like WASM as it's ship binary and done. Yea, they begged for Kubernetes because it works a ton better then custom Ansible they wrote to keep these VMs/Load Balancer in sync.