the overhead of maintaining multiple different microservice binaries—with their own configuration files, network endpoints, and serializable data formats—significantly slowed our development velocity.
Service Weaver, is a framework that has the best of both worlds: the development velocity of a monolith, with the scalability, security, and fault-tolerance of microservices.
I think most people can still leverage the Service Weaver framework to help write and maintain modular code even when deployed as a monolith. The builtin observability tools, packaging, and deployment SDKs are pretty dope too.
If the time comes and you need to deploy parts of the app independently, to create a security boundary for example, then ideally you’re a configuration change away.
The ability to vary deployment boundaries independently from package boundaries has been around a long time. At least as far back as the 90s.
Rails can already be made to work this way, for instance, if you build “engines” instead of a single “app.” For deployment, you can declare a single application, or many, and mount any number of engines in each app.