> microservices severely impacted our ability to make cross-binary changes. It made us do things like flag-gate new features in each binary, evolve our data formats carefully, and maintain intimate knowledge of our rollout processes. Finally, having a predetermined number of specific microservices effectively froze our APIs; they became so difficult to change that it was easier to squeeze all of our changes into the existing APIs rather than evolve them.<p>I'm amused by how the rise of microservices was in part due to the promise of solving some of these problems as they arose in the classic monolith. Independent teams, decoupled deploys, etc.<p>Putting a network request between components doesn't decouple them, it just trades one kind of coupling for another. Even worse, some previously explicit coupling becomes hidden, but remains present.
OK.<p>We've been here before, the "transparent RPCs" path.<p>SunRPC, Mach Messages and MiG, various even more transparent distributed object systems etc. etc. etc.<p>So it would be <i>awesome</i> to have some reference to these earlier systems and how this project overcomes the problems they encountered. I checked the FAQ ( <a href="https://serviceweaver.dev/docs.html#faq" rel="nofollow">https://serviceweaver.dev/docs.html#faq</a> ) and didn't find anything.<p>Or a brief explanation why this is so incredibly different that those issues don't apply. Or a brief explanation that those issues weren't problems and everything is just dandy. Or even we didn't consider those systems at all.<p>Just <i>something</i>.<p>Cheers!
"Transparent Networking" achieved. To reach the next level you should unlock an "Actor Model" :)<p>PS for me, it's more like reinventing Erlang ideas in Golang. If you want to cut the corner here is the ready-to-use Framework in Golang <a href="https://github.com/ergo-services/ergo">https://github.com/ergo-services/ergo</a> - implements all Erlang' neats.
I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. The compiler would take care of serialization/deserialization and routing.<p>But how is it possible to not worry about network. Every function is now able to fail. Why don't you need to handle this explicitly? Or is there just a default behaviour that can be overriden?<p>Edit: after reading the docs I think I understand a bit more. You'll have have to deal with network errors on anything crossing module boundaries.
There has never been any issues with hiding distributed RPC calls.<p><a href="https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing" rel="nofollow">https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...</a>
This reminds me of "Distributed Applications" in Erlang (<a href="https://www.erlang.org/doc/design_principles/distributed_applications.html" rel="nofollow">https://www.erlang.org/doc/design_principles/distributed_app...</a>).
Using the term microservices here is confusing. The main point of microservices as an architectural pattern is decoupling release cadence between teams in very large organizations.
The scaling/redundancy part is not unique to microservices.
What this framework seem to be doing is allowing a team to deploy a system developed as a single binary monolith as a distributed system.<p>The organizational use case is orthogonal to what microservices were all about.<p>Granted, microservices have been cargoculted like crazy, so this distinction is probably lost on a lot of engs. But for those of us that remember the original meaning, mentioning microservices in the description of this framework, is odd.
Super cool. If I understand correctly:<p>- There's no IDL file, like a .proto file. Instead, weaver looks for marker interfaces by embedding weaver.Implements[T].<p>- Weaver interfaces must be serializable, which explicitly support protobufs. Was the intent to be able to port gRPC services to weaver?<p>- Weaver maintains a list of deployments, and each deployment has components. Components may only communicate with components belonging to the same deployment. Sounds like a way to implement atomic deploys.<p>- Named listeners are mapping over a net.Listener?<p>Sidenote: I'm going to steal the metrics implementation. I haven't found a lightweight metrics implementation for GCP.
One of the reasons I break code down into smaller pieces ( microservice ) is to have fast edit and compile times.<p>The versioning hell is why so many went to mono repos. There is only one git version and that’s it.<p>Also what about runtime version difference and schema evolution?<p>So many thing come into play.<p>I would rather just buy the bullet and use protobufs with NATS from day one . No load balances and heavy expensive gke / k8 stuff<p>Then deploy of fly where I have regions with auto scaling based on metric feedback loops.<p>Then use nats client on all client to get geo physical load balancing out to the nearest region.<p>Then use their postresql multi Region. Cockroach multi Region replication costs big money.<p>I did like their tooling in Weaver though. Even the converged logging was pretty nice.<p><a href="https://github.com/ServiceWeaver/weaver/blob/main/runtime/logging/files.go">https://github.com/ServiceWeaver/weaver/blob/main/runtime/lo...</a>
Microsoft Orleans is a really mature version of the actor model for the .NET stack that operates just like this. And the key difference is that it's used by Microsoft themselves in huge systems like Xbox Live.
Unison lang has a lot of overlap with model: <a href="https://www.unison-lang.org/learn/the-big-idea/" rel="nofollow">https://www.unison-lang.org/learn/the-big-idea/</a>
Is it correctly understood that this is useful for scaling the compute of a single logical application, probably maintained by a single team, and less for communicating across applications, where a traditional RPC or REST API might still make the most sense?
unfortunately the Service Weaver Google Group seems highly moderated (my message didn’t go through). Does anyone who’s tried SW over the weekend want to join #serviceweaver on Gophers Slack? I have questions. :)
Developers are too lazy to write specs for API, so there's this framework ?<p>Now the function call will have this kind of signature:<p>func Add(apiKey, apiSecret,...) {}<p>?