I hope there always will be a big enough minority of software engineers who will be actively working against all the complexity and resume driven development (RDD) and pushing simpler and more scalable solutions instead of Rube Goldberg machine of the cloud (there is a lot of use for a cloud, but most of the companies just doesn't need it).
On the other side, loosing deployments to some "cloud solutions" will make things worse for everyone and general PC computing - right now macOS and Windows is only usable for development and general PC computing because of software engineers needed it. The moment it will be fully replaced by cloud - all major OSs will be locked down as much as possible.
Branding "serverless" as a cloud feature was a huge marketing ploy - there were serverless software before cloud existed, it was running on yourpersonal computer, not on someone else's server.
Changing something for the sake of changing something is meaningless. If whatever works for you works - you're fine, don't change a thing.
Though, I'd comment that you don't need to go all-in in AWS, you can use EC2 instances the same way as bare metal servers from Hetzner and get some cool benefits, if you need them (and ok with 10x+ extra costs) - easy backup/snapshots, migrations, better server access and management (I like having SSM to connect to the server with MFA).
It's not even funny how many software engineers just don't know that, SQL is crazy fast and performant, if you have basic understanding about it - I was once refactoring (or, rather, getting rid of) a microservice that was just a JSON blob storage on top of Postgres, without having any schema for blobs, with 100s of 1000s of them, no indices, and main complaint was - it's slow.
It's nice to see the trend unwinding, microservices are egregiously overused as a silver bullet for any problem (not just scaling).
There are probably dozens (/s) of companies that would benefit from going all-in with microservices. Some companies would benefit from having a few microservices; but most would be more than successful running a monolith.
The most significant problems with microservices arise when they're adopted too early and when data separation is not properly handled, resulting of even the simplest requests ended up querying 3-5+ microservices.
Latest anecdata point: doing exactly that (unwinding microservices) in a team of 20 engineers (15 swe/5 sre) and 400+ repositories (which isn't a "wrong", but having so many different places to update, for example, Python version is nuts). The whole project is nuts.
And persuading management was not an issue, it was enough to show current AWS bills and potential savings from moving from 50+ microservices to smaller numbers of consolidated services and deprecating/refactoring some features. The real challenge was persuading the engineering team to prioritize and work on this issue - which is still ongoing.
On the other side, loosing deployments to some "cloud solutions" will make things worse for everyone and general PC computing - right now macOS and Windows is only usable for development and general PC computing because of software engineers needed it. The moment it will be fully replaced by cloud - all major OSs will be locked down as much as possible.
Branding "serverless" as a cloud feature was a huge marketing ploy - there were serverless software before cloud existed, it was running on your personal computer, not on someone else's server.
Same for localhost.
Localhost should be alive forever.