My appetite for side projects is considerably larger than my enthusiasm for recurring bills.
Last year, I started sharing work between a small cloud server and hardware at home. Since then I've added capacity at home, and the cloud server's job has needed another look. I want to use the hardware I own without making every new project a reason to rent a bigger machine.
The useful distinction is between being reachable from the internet and doing the application's work. Visitors need a reliable way to reach my sites. That doesn't mean the machine greeting them also needs to run the applications, keep their data, and coordinate their conversations.
A receptionist is useful. A receptionist who also runs the kitchen and signs for every conversation between the chefs has been given a questionable job description.
The Scenic Route to the Next Desk
Some of those conversations were taking a particularly enthusiastic route. Programs near each other were sending requests out to the cloud and back again, even when the work could happen locally.
Imagine asking a colleague at the next desk a question by posting a letter to head office. Head office forwards it to your building. Your colleague replies through head office. It works. Everyone has an address, the letters arrive, and the arrangement is admirably consistent.
You might still consider turning your chair around.
This happens quite naturally in software. An address that works from anywhere is convenient, so you keep using it after the programs have moved closer together. The address hasn't become wrong. The journey has become unnecessary.
I changed where the relevant services run and how other programs reach them. For one group of programs, the migration checks showed that requests had stopped appearing in the cloud logs while successful local calls continued. The work hadn't disappeared; the detour had.
That saves an external round trip for those calls. They no longer need the cloud server to be reachable just to talk to their neighbour. The permission checks still happen. A shorter route is not permission to skip them.
Less Work for the Front Desk
The cloud server now concentrates on receiving and directing public traffic, rather than running the applications too. I also replaced several separately managed connections with a shared way of carrying application traffic. That let me retire the old forwarding processes and their recovery machinery.
There is still networking to maintain. There is simply less separate machinery whose only job is to persuade two programs to have a conversation.
For me, the payoff is practical: more application work uses capacity I've already bought, local conversations needn't take an internet trip, and the public-facing server has fewer application-specific responsibilities. Changing the software an application needs no longer means maintaining that software on the cloud server as well.
This puts more responsibility on the home equipment. Its power and connectivity still matter, and visitors still depend on the public path working. I haven't made those dependencies disappear. I've chosen where the work belongs, rather than letting the first place I deployed it make that decision forever.
The cloud server hasn't retired. It just no longer works in every department.