I've been experimenting with this sort of thing for awhile, but without automation to determine the deployment topology (nice!). Lacking a better name, I've been calling it a monolithic micro service architecture. Obviously nothing here prevents you from creating a distributed monolith, but it can allow a smaller team to enjoy better horizontal scaling without as much cost, while still retaining ease of forward development.
Towards Modern Development of Cloud Applications (2023)
11–20 of 69 posts
Re: Towards Modern Development of Cloud Applications (2023)
#12Interesting! 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)
Re: Towards Modern Development of Cloud Applications (2023)
#13I am a big proponent of the fat lambda paradigm, but it falls short in a few areas and then you need to split
- security boundaries (e.g. isolating user code)
- dependency overheads
Re: Towards Modern Development of Cloud Applications (2023)
#14I am a big proponent of the fat lambda paradigm, but it falls short in a few areas and then you need to split - security boundaries (e.g. isolating user code) - dependency overheads
[deleted]
Re: Towards Modern Development of Cloud Applications (2023)
#15https://serviceweaver.dev/
Because it is a bit buried in the paper, this is the prototype implementation they talk about.
Re: Towards Modern Development of Cloud Applications (2023)
#16I've used this paradigm for a long time. What's new here ? Basically your code has no concept of "network boundary", there's only package import each other, there's no "microservice". But when deploying, i can choose which package to be deployed as a service.
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.
Re: Towards Modern Development of Cloud Applications (2023)
#17Mobile 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 doomed to repeat it"
There were several attempts in history to implement transparent RPC (new again). All failed due to https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu... (learn from history)
Looks like any abstraction trying to hide distribution is inherently too leaky.
Re: Towards Modern Development of Cloud Applications (2023)
#18the proclet name brings back so many old memories of the wonderful technology at startent-networks ! what is described here is how (in principle) various things (inter)worked.
what a lovely time !
Re: Towards Modern Development of Cloud Applications (2023)
#19Mobile 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…
> - "those who do not learn from history are doomed to repeat it"
or as mark-twain would (probably) say
"History Does Not Repeat Itself, But It Rhymes"
Re: Towards Modern Development of Cloud Applications (2023)
#20Google 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 you write modular code is really important. The thing is, most code has overlapping concerns and cross dependencies. Network based boundaries using APIs were a way to allow teams to operate in isolation while providing external APIs to access different services but it comes at a huge costs. It was the hammer for people and team scale, not compute scale. Now the tools are evolving, where we can actually operate on monolithic codebases at huge scale as Google and others have shown and that also means the deployment technology can also evolve to cater to that mode of development while seamlessly handling the technical scale details for separating and deploying the code for specific services across data centers and the cloud at large.
What does it all mean. Well it's a technology built for Google scale. It may have merits in other place as a lot of tech has done, but at the same time, for 90% of teams this doesn't matter. You have a monolithic code base in a single repo and you can deploy and vertically or horizontally scale quite easily depending on your requirements. For companies that are 200+ engineers split across 15-20 teams this might matter. They already be doing some sort of microservices or service splitting while still using a monorepo. Being able to remove a lot of platform level code that you manage versus it being an open source thing is advantageous because you can go back to focusing on the business case not the glue code.