5 ms·
Absolutely: * Avoid network and JSON serialization overhead * Perform larger refactorings or renamings without considering deployment staggering or API versio
by nthj 6y ago
Absolutely:
* Avoid network and JSON serialization overhead
* Perform larger refactorings or renamings without considering deployment staggering or API versioning
* testing locally is far easier
* Debugging in production is far easier
* Useful error stack traces are included for free
* Avoid (probable in my experience, at least in larger security software organizations) dependency on SecOps to make network changes to support a refactoring or introducing new components
If an organization is or will pursue a FedRAMP certification, as I understand it, that organization must propose and receive approval every time data may hit a network. Avoiding the network in that case may be the difference between a 50-line MR that's merged before lunch and a multi-week process involving multiple people.
- closeparen 6y agoHow are you getting around API versioning with independently deployable components?
- sokoloff 6y agoIf you call a piece of functionality from your own single deployable that you are refactoring, it’s much more like refactoring a function call than if it were an independent micro-service across a network.
- gen220 6y agoFWIW, I think that gRPC/protobufs have pretty compelling answers to each of the historically-valid complaints you've listed here. - cpu cycle overhead: this is valid if the overhead is very high or very important. otherwise, most companies would love to trade off cpu cycles for dev productivity. - refactorings/renamings without deployment staggering. protobufs were specifically designed with this in mind, insofar as they support deprecating fields and whatnot. However, writing a deprecatable-API is a skill, even with protos. If you have many clients and want to redo everything by scratch, you will have problems. - "testing locally" (which I take to mean integration testing locally) is the only one that requires some imagination to solve, assuming all your traffic is guarded by short-term-lease certs issued by vault or something similar. But even this is quite achievable. - error stack traces included for free: may I introduce you to context.abort(). It's not a stack trace by default, but you can actually wrap the stack trace into the message if you so-care to. opentracing isn't quite free, in a performance sense, but in a required-eng-time-to-setup-and-maintain-sense, it is pretty cheap. - dependency on secops to make network changes: I've never encountered this, but I bet you that a good platform team can provide a system where application teams effectively don't need to worry about this. It's impossible to overcome this challenge in an existing company that's used to doing things this way, though.
- deleted 6y ago[deleted]
- lmm 6y agoThrift or protobuf is a huge step up from the alternatives, but you still have a lot of overhead. Generics are limited and you're essentially forced to "defunctionalise the continuation" everywhere: any time you want to pass a callback around you have to turn it into a command object instead.
- vosper 6y agoPeople who are downvoting the parent comment: I’d love to know why? I won’t claim expertise here, but it doesn’t strike me as clearly incorrect.
- gen220 6y agoI don't disagree with you, this actually sounds like the beginning of a super interesting conversation. Can you share some examples of the generics problem and "defunctionalizing the continuation"? Does google's `any` package help with the generics problem you describe? (Acknowledging that it's obviously clunky)
- lmm 6y ago> Can you share some examples of the generics problem and "defunctionalizing the continuation"? Well, the generics problem is that you don't have generics. So you just can't define a lot of general-purpose functions in gRPC, and have to make a specific version of them instead. Even something like "query for objects like this and then apply this transform to the results" just can't be done, because there's no way to pass the transformation over the wire, so you have to come up with a datastructure to represent all the transformations that you want to do instead. "Defunctionalizing the continuation" is the technique for doing that, https://www.cis.upenn.edu/~plclub/blog/2020-05-15-Defunctionalize-the-Continuation/ https://www.cis.upenn.edu/~plclub/blog/2020-05-15-Defunction... is an example, but it's a manual process that requires creative effort each time. > Does google's `any` package help with the generics problem you describe? (Acknowledging that it's obviously clunky) Not really, because you don't have the type information at compile time. Erased generics are fine in a well-typed language, but just using an any type you can't even do something like: a function that takes two values of the same type.
- heavenlyblue 6y agoWhat is a network?
- Spivak 6y agoAny application boundary that requires that you serialize your calls/requests to the other service/component in some form. Any form of IPC basically.