Google has always been a head of the curve: from mapreduce to big table and grpc. They're always building for scale and productivity at the company. Service weaver is an evolution of that. The idea that developers themselves don't have to decide how to separate and manage services. There's so much plumbing to grpc that's unnecessary for developers to deal with. But the service boundary and development style that lets you write modular code is really important. The thing is, most code has overlapping concerns and cross dependencies. Network based boundaries using APIs were a way to allow teams to operate in isolation while providing external APIs to access different services but it comes at a huge costs. It was the hammer for people and team scale, not compute scale. Now the tools are evolving, where we can actually operate on monolithic codebases at huge scale as Google and others have shown and that also means the deployment technology can also evolve to cater to that mode of development while seamlessly handling the technical scale details for separating and deploying the code for specific services across data centers and the cloud at large.
What does it all mean. Well it's a technology built for Google scale. It may have merits in other place as a lot of tech has done, but at the same time, for 90% of teams this doesn't matter. You have a monolithic code base in a single repo and you can deploy and vertically or horizontally scale quite easily depending on your requirements. For companies that are 200+ engineers split across 15-20 teams this might matter. They already be doing some sort of microservices or service splitting while still using a monorepo. Being able to remove a lot of platform level code that you manage versus it being an open source thing is advantageous because you can go back to focusing on the business case not the glue code.
There is nothing about being ahead of the curve with gRPC.
That is only people getting the point parsing JSON and XML all over the place doesn't scale and there is a reason why SUN-RPC, DCE, CORBA, DCOM, Java RMI, and .NET Remoting existed in first place.
What does it all mean. Well it's a technology built for Google scale. It may have merits in other place as a lot of tech has done, but at the same time, for 90% of teams this doesn't matter. You have a monolithic code base in a single repo and you can deploy and vertically or horizontally scale quite easily depending on your requirements. For companies that are 200+ engineers split across 15-20 teams this might matter. They already be doing some sort of microservices or service splitting while still using a monorepo. Being able to remove a lot of platform level code that you manage versus it being an open source thing is advantageous because you can go back to focusing on the business case not the glue code.