Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards Modern Development of Cloud Applications (2023)

dl.acm.org

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Towards Modern Development of Cloud Applications (2023)

#61

Post by fizx »

dilyevsky wrote: post #58
dti wrote: post #42

Looks 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.

They're claiming that the runtime will figure it out for you.

It wouldn't be too surprising if this is the sort of thing that an optimizing compiler or query planner could do better than a human.

If not, you're probably at the scale where performance regressions are caught and rolled back at early phases of rollout.

Like most magic, it's either going to make things 100x better or 100x worse, depending on how leaky the abstraction is at its current state of maturity.

Re: Towards Modern Development of Cloud Applications (2023)

#62

Post by fizx »

dti wrote: post #42

Looks 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…

> local RPC calls have to serialize protocol buffer messages

They don't have to, they artificially added that constraint to make the benchmarks fairer.

5ms protobuf, 2ms custom, 0.4ms in-process

Re: Towards Modern Development of Cloud Applications (2023)

#63

Post by jamesfinlayson »

rezonant wrote: post #12
erulabs wrote: post #8

Interesting! This has been my recommended pattern for a for years now: a monorepo with multiple entrypoints. Worker and api and emailer etc etc services are running independently, but it’s one codebase running with different options. All the developer benefits of a monolith and all the devops benefits of sane and isolated deployments.

Also often allows you to simplify the development experience dramatically-- instead of spinning up twenty processes and running a complex live rebuild process or manually rebuilding and restarting certain parts, you just need to start the whole thing, because in development it all runs in a single process (or, at least less processes than you do when it is run in production)

> Also often allows you to simplify the development experience dramatically

Always the afterthought. At a previous job we had a bunch of microservices developed on peoples' computers, and they only place they all ran together was the handful of integration environments.

Re: Towards Modern Development of Cloud Applications (2023)

#64

Post by dilyevsky »

fizx wrote: post #61
dilyevsky wrote: post #58

Earlier quoted context omitted.

> 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.

They're claiming that the runtime will figure it out for you. It wouldn't be too surprising if this is the sort of thing that an optimizing compiler or query planner could do better than a human. If not, you're probably at the scale where performance regressions are caught and rolled back at early phases of rollout. Like most magic, it's either going to make things 100x better or 100x worse, depending on how leaky th…

I'm going to (at least I should) design my application logic very differently if I know in advance the call might take a while or timeout completely. If I'm not offered that info during development time it's just going to turn into terrible mess in production. Ain't nothing any framework can do about it if the language itself lacks the semantics to express developer's constraints.

Re: Towards Modern Development of Cloud Applications (2023)

#65

Post by thesecretsquad »

I was reminded of this article (https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicros...) from Uncle Bob while reading this paper.

From the article:

> The Deployment Model is a Detail.

> If the code of the components can be written so that the communications mechanisms, and process separation mechanisms are irrelevant, then those mechanisms are details. And details are never part of an architecture.

> That means that there is no such thing as a micro-service architecture. Micro-services are a deployment option, not an architecture.

Re: Towards Modern Development of Cloud Applications (2023)

#66

Post by solatic »

Sounds a lot like NextJS's concept of framework-defined infrastructure: https://vercel.com/blog/framework-defined-infrastructure . A single file that includes both backend and frontend code infers a static bundle deployed to a CDN + server-based resources for the backend.

Re: Towards Modern Development of Cloud Applications (2023)

#67

Post by ajdjujjeiznc »

throwaway892238 wrote: post #60

I 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 gilde…

[dead]

Re: Towards Modern Development of Cloud Applications (2023)

#69

Post by AtNightWeCode »

awenix wrote: post #51

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.

Looks like it. I used to work with it some years ago. I will never use it again or any other actor model based platform with remoting and magic schedulers.
Post reply on HN