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

31–40 of 69 posts

Re: Towards Modern Development of Cloud Applications (2023)

#31

Post by mkleczek »

pjmlp wrote: post #23
mkleczek wrote: post #17

Mobile code and "agent systems" were very fashionable 20 years ago. Java introduced built-in RMI with automatic stub downloading. In 1998 Sun published https://en.wikipedia.org/wiki/Jini that was an extension of this idea. Several higher level frameworks emerged (JavaSpaces among the most prolific). Reading the paper two thoughts come to mind: - "What's old is new again" - "those who do not learn from history are doo…

On the same vein, I now take a kick out of people criticizing Java and .NET application servers, while at the same time praising delivering WASM containers with Kubernetes YAML spaghetti into production. Need to get that VC money into the hot WASM space.

Let's be honest - deployment story with J2EE application servers was total mess and I still have nightmares.

But you're right - today's world of YAML programming is no better.

Nix and Guix are steps in the right direction (but both have their fair share of issues)

Re: Towards Modern Development of Cloud Applications (2023)

#32

Post by danielvaughn »

revskill wrote: post #16
kitd wrote: post #10

Earlier quoted context omitted.

What's new is that you don't choose, the runtime does, generating the cross-network interface as needed.

No way (or no need) to be such generic. You should have a choice (at least it's my choice). Because your app is separated by functionalities, not technical aspects.

Unless I'm misunderstanding, separation by functionality is only useful for engineering teams. Once it's in production, the only thing that matters are the technical aspects. By technical aspects, I'm interpreting to mean mem/cpu usage, throughput, security requirements, etc.

Re: Towards Modern Development of Cloud Applications (2023)

#33

Post by pjmlp »

mkleczek wrote: post #31
pjmlp wrote: post #23

Earlier quoted context omitted.

On the same vein, I now take a kick out of people criticizing Java and .NET application servers, while at the same time praising delivering WASM containers with Kubernetes YAML spaghetti into production. Need to get that VC money into the hot WASM space.

Let's be honest - deployment story with J2EE application servers was total mess and I still have nightmares. But you're right - today's world of YAML programming is no better. Nix and Guix are steps in the right direction (but both have their fair share of issues)

I rather deal with Websphere 5 (on purpose not the later much improved 6 and 7) than Kubernetes.

Re: Towards Modern Development of Cloud Applications (2023)

#36

Post by CharlieDigital »

sgt101 wrote: post #6

Bold claims... Performance is evaluated against a single example implementation (section 6.1) and 9x improvement was achieved when co-locating into a single process. To be fair this seems a reasonable thing to do if you can get the application to be efficient enough to allow it - but there may be very good reasons not to do it in many applications.

Network I/O is almost always the slowest part of any application regardless of the protocol and data encoding mechanism.

It seems to reason that if you can co-locate your calls into a single process, you'd gain at least 9x.

Re: Towards Modern Development of Cloud Applications (2023)

#38

Post by jen20 »

saulrh wrote: post #5
iamgopal wrote: post #2

Isn’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…

There’s absolutely nothing new about a binary that can be run in a number of different roles depending on configuration (either statically configured or assigned by some controller process).

For example, FoundationDB does exactly this (via dynamic assignment), as do many other databases. All of the HashiCorp runtime tools also do it. I’m sure there are also much earlier examples.

Re: Towards Modern Development of Cloud Applications (2023)

#39

Post by [deleted] »

mkleczek wrote: post #17

Mobile code and "agent systems" were very fashionable 20 years ago. Java introduced built-in RMI with automatic stub downloading. In 1998 Sun published https://en.wikipedia.org/wiki/Jini that was an extension of this idea. Several higher level frameworks emerged (JavaSpaces among the most prolific). Reading the paper two thoughts come to mind: - "What's old is new again" - "those who do not learn from history are doo…

[deleted]

Re: Towards Modern Development of Cloud Applications (2023)

#40

Post by sgt101 »

CharlieDigital wrote: post #36
sgt101 wrote: post #6

Bold claims... Performance is evaluated against a single example implementation (section 6.1) and 9x improvement was achieved when co-locating into a single process. To be fair this seems a reasonable thing to do if you can get the application to be efficient enough to allow it - but there may be very good reasons not to do it in many applications.

Network I/O is almost always the slowest part of any application regardless of the protocol and data encoding mechanism. It seems to reason that if you can co-locate your calls into a single process, you'd gain at least 9x.

Yeah - I think that their argument would be that their approach enables you to do that, and that there are significant gains on the table without that last step.

My main critique is that it's one example, and it would be good to see the technique exercised across a number so that we can see the strengths and weaknesses.

Post reply on HN