Looks very similar to Service Fabric https://learn.microsoft.com/en-us/azure/service-fabric/servi.... I have heard it scale upto 2000 nodes and extensively used internally at microsoft.
Towards Modern Development of Cloud Applications (2023)
51–60 of 69 posts
Re: Towards Modern Development of Cloud Applications (2023)
#52Feels a lot like old school CORBA - quoting from the paper: “Components may be hosted by different OS processes (perhaps across many machines). Component method invocations turn into remote procedure calls where necessary, but remain local procedure calls if the caller and callee component are in the same process.” What is old is new again
I had the exact same thought when I read that.
Re: Towards Modern Development of Cloud Applications (2023)
#53Looks interesting. > The call to hello.Greet looks like a regular method call That’s a departure from how components interact in boq — an internal and widely used production platform that has _some_ of the features from the paper. There component interfaces _are_ RPC interfaces (e.g., Stubby / gRPC + protocol buffers), and interaction between them is possible exclusively through the component interfaces. Hence it’s v…
> However, I don’t understand why local RPC calls have to serialize protocol buffer messages — can’t they already pass them as-is to the local handler? I didn't read the paper in enough detail to know the answer to this, but mightn't this enable different implementation languages for different components? In my experience, it's difficult to accomplish reliably that without using a language-agnostic serialization form…
I see I may have been unclear — I was surprised they don't use protobufs (which one should be able to pass as-is without serialization to the locally-deployed component), but apparently using a custom optimized format for non-local calls is the primary motivation (not local calls with grpc requiring serialization — that shouldn't be the case).
However, now that I think again about the serialization format choice, it may result in a limitation on the size of monoliths (in terms of the number of people / teams contributing to it). When the number of contributors grow, the likelihood of bugs in a binary grows, and teams adopt more elaborate qualification processes, and also become much more sensitive to binary rollbacks as a remedy to discovering bugs in prod. Then they could institute policies like all changes should be protected by a feature flag (aka an experiment).
If non-versioned serialization format is used, that means that the platform cannot possibly rollback a single component. However, using versioned serialization won't be enough on its own to support per-component rollbacks — it at least requires independent component qualification (where each component is tested against "stable" versions of other components) + rollback testing to make rollbacks A2 -> B2 to A2 -> B1 safe.
I wonder if it's an explicit design choice — i.e., whether Service Weaver supports monoliths up to a certain organizational size (and then you should split into separate service weaver apps)?
Re: Towards Modern Development of Cloud Applications (2023)
#54Isn’t this prevailing wisdom among HN crowd ?
I think that this might actually be something new - you have the same topology as a microservice architecture, but rather than actually programming and deploying one binary per microservice, you build a single binary with all of the functionality and it gets deployed as a fleet of microservices, running a different subset of all of that functionality depending on what it's deployed as. Which means you have only one b…
Ah, the good old "worst of both worlds" approach, I see
Re: Towards Modern Development of Cloud Applications (2023)
#55I have read the paper, although maybe not deeply enough.
It is an interesting idea, but I'm not sure I'm fully convinced.
Sure, you can parse remote calls and package imports to find dependencies. But this assumes applications are integrated using remote procedure calls. What if applications talk to each other using a message bus? Asynchronous patterns are meant precisely to decouple publishers and subscribers - in number (how many processes will read a message?), identity (who are those processes?) and time. It looks like this system would not be able to decouple portions of code talking to each other using a message queue.
Any thoughts?
Re: Towards Modern Development of Cloud Applications (2023)
#56Looks interesting. > The call to hello.Greet looks like a regular method call That’s a departure from how components interact in boq — an internal and widely used production platform that has _some_ of the features from the paper. There component interfaces _are_ RPC interfaces (e.g., Stubby / gRPC + protocol buffers), and interaction between them is possible exclusively through the component interfaces. Hence it’s v…
In your experience, how does this kind of approach behave with asynchronous dependencies?
Let's say you start from a codebase with three portions (call them services, modules, whatever): A, B, C, D. A sends a (synchronous) remote procedure call to B, which sends a message over a message bus which is also used by C and D. C and D do not talk to each other except over the bus.
It sounds like this approach would identify the remote call dependency between A and B (which could be split into different deployment units), but not the message bus usage. Or, at least, it can't identify who is subscribing to a topic where B pushes its events.
As a result, you would get two deployment modules:
- A
- B and "everything else"
Which doesn't sound right.
Am I missing something?
Re: Towards Modern Development of Cloud Applications (2023)
#57I have read the paper, although maybe not deeply enough. It is an interesting idea, but I'm not sure I'm fully convinced. Sure, you can parse remote calls and package imports to find dependencies. But this assumes applications are integrated using remote procedure calls. What if applications talk to each other using a message bus? Asynchronous patterns are meant precisely to decouple publishers and subscribers - in n…
I built a simple example using Postgres and .NET as a runtime: https://github.com/CharlieDigital/dn8-modular-monolith
I don't think it would be very difficult to replace the poll on the database table with a pull from SQS instead.
Re: Towards Modern Development of Cloud Applications (2023)
#58Looks interesting. > The call to hello.Greet looks like a regular method call That’s a departure from how components interact in boq — an internal and widely used production platform that has _some_ of the features from the paper. There component interfaces _are_ RPC interfaces (e.g., Stubby / gRPC + protocol buffers), and interaction between them is possible exclusively through the component interfaces. Hence it’s v…
> RPCs looking like regular method calls sound a bit scary (easy to miss in code reviews);
CORBA had the same issue. The call could take 10us or 10s and no way to tell by the user. This was ofc widely considered as huge design flaw.
Re: Towards Modern Development of Cloud Applications (2023)
#59Related:
Towards Modern Development of Cloud Applications [pdf] - https://news.ycombinator.com/item?id=38146809 - Nov 2023 (10 comments)
Re: Towards Modern Development of Cloud Applications (2023)
#60I think this paper is well-intentioned, but is trying to treat the symptoms rather than the cause.
The paper focuses on microservices, and then tries to avoid claims of "they just don't like microservices" by describing the ways in which microservices are improperly used. Do they go back and compare this to monoliths or other architectures? Nope; it's really just "hey I have another microservices idea", heavily gilded. They mention "monolithic applications divided into logically distinct components", but you could just claim your microservices are divided into logically distinct components.
They also seem to completely ignore the problem that a logical separation doesn't mean your components are better off. In a complex system, often completely separate components still need to be integrated together in order for the system to function at all, much less operate efficiently. It's not a design flaw to combine different things. It depends on the application. So just separating things logically isn't some scientific computing advancement, it's just categorization.
In reality, their solution (a "single binary business logic application" and "an interface that can combine them") is literally a description of shell scripting with Unix tools. Don't get me wrong, that obviously works great, since it's been popular for 44 years (older than IPv4). But if you want to come up with some kind of modern paradigm for distributed computing, maybe we should flush it out a bit more. What we have here is a Google engineer's attempt to make a paper suggesting we make shell scripting for the web, without much to show for it.
(Personally, I think the more people try to control the interface, the worse things get. The best and most long-lived solutions in all of computing have had almost no interface at all; a raw TCP stream, 3 raw file descriptors, a set of random arguments, and a set of random key=value pairs, have enabled all modern computing paradigms to flourish)