This is what I've done in those rare cases I've had to fix a bug in a tool or a library I've used professionally. I've also made sure to do that using online identities with no connection to my employer so that any small positive publicity for the contribution lands on my own CV instead of the bureaucratic company getting the bragging rights.
Developer-specific sandbox environments with hot code reload is the golden standard here but Localstack is great if you can't do that due to (usually IT deparment-related, not technical) reasons.
As someone with years of experience on serverless stuff on AWS I might be a bit biased BUT I'd argue serverless is the sweet spot for most applications. You need to remember however that most applications aren't your typical startups or other software products but simply some rather boring line of business software nobody outside the company owning it knows of.
Concerning how IT departments in most non-software companies are, the minimal operational burden is a massive advantage and the productivity is great once you have a team with enough cloud expertise. Think bespoke e-commerce backends, product information management systems or data platforms with teams of a handful of developers taking responsibility for the whole application lifecycle.
The cloud expertise part is a hard requirement though but luckily on AWS the curriculum is somewhat standardized through developer and solutions architect certifications. That helps if you need to do handovers to maintenance or similar.
That said, even as a serverless fan, I immediately thought of containers when the performance requirements came up in the article. Same with the earlier trending "serverless sucks" about video processing on AWS. Most of the time serverless is great but it's definitely not a silver bullet.
I like your angle, but most applications is a big difference from most companies. Serverless comes after deciding whether or not to break up the monolith, and after breaking up engineering into separate teams. It's a good way to manage apps with high variance in traffic while keeping cloud spend down.
The 4.x series was the one where the ideas still making Plasma so powerful were seeded. While I loved KDE 3 the design for 4 seemed revolutionary. Too bad it was alpha/beta quality up until the 4.6 release years later. I fared through all the bugs, crashes and performance issues with a young student's determination (while running Fluxbox on the side) but I can very well understand people doing serious work had limited patience for the issues.
Anyhow, happy anniversary from a long-time KDE user!
It's a story that's very similar to Windows Vista. It gets a lot of hate for breaking stuff at the time it was originally released, but the reason it broke stuff is because it put in a new foundation for later releases to build upon. The later releases were better because of the breakage. Something something gotta breaks some eggs to make an omelette something something.
In a sense the simplicity of SLS is a trap: immediately when you need to move past the synchronous lambda invocations via API GW use case (caching, service integrations, step function workflows etc) you need to either fall back to plain CloudFormation or rely on third party plug-ins with possible problems with maintenance, quality and feature-completeness. This makes it a difficult choice to recommend beyond simple use cases.
Yeah this is one area it really struggles. I built a harness (using SST, actually!) for things like step functions, background jobs, cron-ed tasks that I'll try to open source once I clean it up a bunch.
I kind of see that as an unforced error on SLS's side as well; AWS EventBridge is pretty simple and would make those types of workflows possible, but the integration with SLS is really rough.
I loved the folder view! It really highlighted the shift to a modular design in Plasma and solved the problem of desktop eventually ending up as a garbage dump of stuff that at some point was relevant but now impossible to find by providing configurable views to files that exist elsewhere and can be adjusted to fit current needs.
The 4.0 release was otherwise painful though as it was a slow, constantly crashing mess of bugs. At around 4.3 it became stable enough to serve as the primary desktop but IIRC that took years and I saw a lot of friends adopting Gnome or XFCE.
