Obviously you now need to add an API client layer but in terms of code organization, if your packages are cleanly separated then you've done a lot of the work already. (Transactions being the obvious piece that you'll often have to rethink when crossing a service boundary).
The advantage of this approach is that it's much easier to refactor your internal "services" when they are just packages, than it is to refactor microservices after you've extracted them and set them free (since upgrading microservice APIs requires more coordination and you can't upgrade clients and servers all in one go, as you often can inside the same codebase).
Keep all your code in one repo, deploy that codebase to multiple servers, but have it acting in different capacities.
1 email server, 5 app servers dishing out html, 2 api servers
Etc
It works very well and was able to handle spikes of traffic during super bowl ads without any problems.
A properly organized codebase scales very well when partitioned into services.
It is my default approach for all new projects for the last 10 years or so.
His talk was pretty cool and helpful if you want to split monolith!
