Live data from Hacker News

Towards Modern Development of Cloud Applications (2023)

dl.acm.org

21–30 of 69 posts

Re: Towards Modern Development of Cloud Applications (2023)

#21
Interesting paper, i've thought about this topic a lot.

In previous projects I defined systems in a single code base, and parts could be deployed separately by providing different configuration files.

It was a very productive approach: one could run the whole system in a single process during development, which made writing integration tests a lot easier than spinning up dozens of docker images.

It still required some manual work, and deployments were still to static for my liking. Ideally it should be possible to split off and scale subparts dynamically.

In the Clojure world there are several projects now that explore splitting up services in a transparent way.

For example Electric Clojure splits up your code into frontend and backend parts, making the frontend-backend split transparent. Another project is Rama, which does something similar but for distributed steam processing and partitioning.

I'd love to explore something like this but for enterprisey service meshes: the programmer just defines services, and a compiler decides how to split these over different machines, and all the RPC/serialization/deserialization is done for you.

Re: Towards Modern Development of Cloud Applications (2023)

#22
post #20

Google has always been a head of the curve: from mapreduce to big table and grpc. They're always building for scale and productivity at the company. Service weaver is an evolution of that. The idea that developers themselves don't have to decide how to separate and manage services. There's so much plumbing to grpc that's unnecessary for developers to deal with. But the service boundary and development style that lets…

There is nothing about being ahead of the curve with gRPC.

That is only people getting the point parsing JSON and XML all over the place doesn't scale and there is a reason why SUN-RPC, DCE, CORBA, DCOM, Java RMI, and .NET Remoting existed in first place.

Re: Towards Modern Development of Cloud Applications (2023)

#23

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.

Re: Towards Modern Development of Cloud Applications (2023)

#24
Interesting indeed. While still doing two services we manage local development using gems in ruby which allow us to seamlessly include the other service’s code as a library and we write unit tests using that integration. The two binaries are built as two gems with versions and tested locally. When it comes to deploy we deploy both at the same time. We get many advantages mentioned here while the services operate independently.

Re: Towards Modern Development of Cloud Applications (2023)

#25
post #21

Interesting paper, i've thought about this topic a lot. In previous projects I defined systems in a single code base, and parts could be deployed separately by providing different configuration files. It was a very productive approach: one could run the whole system in a single process during development, which made writing integration tests a lot easier than spinning up dozens of docker images. It still required som…

Regarding your last paragraph, interesting idea about the compiler doing the work, but isn't RPC/serdes basically built into CORBA or OLE transparently? Never used the former, and the latter was so long ago I forgotten it, but I thought that was the idea.

Re: Towards Modern Development of Cloud Applications (2023)

#27

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…

I find it very amusing that most of the people who abhor dynamic linking of libraries and executables as an over-complex, error-prone mistake of computer history these days seem to have not the faintest trace of restraint when they're about to turn EVERYTHING into a RPC/RMI over complex, multi-layer (and I don't mean OSI), often completely proprietary and opaque network abstractions like there's no tomorrow.

Re: Towards Modern Development of Cloud Applications (2023)

#28

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…

Your last sentence is almost the only reply the article requires.

Re: Towards Modern Development of Cloud Applications (2023)

#29
Feels 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

Post reply on HN