The future is self-hosted
leetsoftware.com
leetsoftware.com
When you use a SaaS solution, you are taking on risk, sure, but you are able to move much faster. There's no servers to set up and, more importantly maintain. By outsourcing of lot of operational complexity, your team can focus on building unique differentiated features and marketing them.
I love self-hosting and think you can learn a lot by operating your own infra. For certain use cases (really small apps, personal software, stable state) it can make sense. But I feel like SaaS is becoming the default and is definitely 'the future'.
Legal counseling for a trust or will for the hardware and software. Training and on-call support.
The challenge is keeping the tech in line with what the owner intended, staying off the cloud and preserving their values. That could mean anything from staying on legacy Java to maintaining an automated lawnmower written in embedded Tcl.
I self-host everything specifically because I remain in control of everything and I maintain physical custody of my data, and the software I'm relying on won't change underneath me. Maintenance isn't a big deal. When something goes wrong, I can fix it immediately rather than waiting a random amount of time for some external entity to do it. Setup costs don't matter to me because they're a one-time thing.
That said, I know people that I'd recommend SaaS instead of self-hosting to.
Then, I have no idea where your neck of the woods is, but that’s crazy.
If I had a nickel for every company that self-hosted but didn’t update in time, or self-hosted but had a flawed backup strategy, or self-hosted and hit scaling problems, or self-hosted and suffered a natural disaster, or self-hosted and experienced theft, I would be a millionaire.
A lack of functional backups isn’t a self-hosted problem, it’s an implementation problem. Plenty of SaaS companies out there variously 1) don’t have backups; 2) conflate backup and sync; 3) don’t test backups; or 4) have perfectly functional and tested backups that cover a level that isn’t useful if a single customer needs a restore.
And all of that could well be the case in any self-hosted environment too. Bad design, lazy or incomplete implementation, and good old fashioned negligence is at home and well in both SaaS and self-hosted shops the world over.
At least with self-hosted you can be either consummately diligent, entirely negligent, or somewhere in between all by yourself.
The minute you go self-hosted, your complexity goes up 10x, as does the services you'll need to provide to maintain it, and the hiring needed to fulfill that need.
WFH is super divisive right now. Imagine telling engineers "how do you feel about flying to Nebraska for a few weeks?" Doesn't work.
I can see using SaaS for exceptional/overflow traffic though.
Anything they give you, they can take it away.
It's gotten pretty ridiculous - let's say you buy a hammer. But to keep using the hammer, you have to pay a monthly subscription or the hammer stops working. And this is considered normal? Of course there are some tools that are so complex that you don't want to have to buy them and maintain them, so renting makes much more sense - but if your whole world is structured that way, you're just being bled.
But small software companies or "indie hackers" (like me) can make it make sense. It's also a good way for us to differentiate ourselves and have an angle in the bigger markets.
If I and 5 other devs go and make Dropbox, for example, you won't look at us. Dropbox will be much better. But if we offer a self-hosted version, we might just be able to carve a small portion of the market for ourselves through that angle.
- Deployment and configuration management
- Platform maintenance (not app upgrades)
- App upgrades
- Security
- Performance monitoring
- Data backup and disaster recovery
When considering taking on SH, it's important to be wise about all of the implications. Automating these, standardization, and making them more portable are what would make SH cheaper and more doable. Definitely create runbooks and detailed notes that are kept current, organized, and could be used to reconstruct production without automation.
So now you have to spend time manually reconstructing whatever dependencies exist in require production to be available. How well is that documented? If you have circular dependencies like that, probably not very well.
- a BOM that's shot to a major hardware vendor or already having network and server device spares; Dell is able to meet this sort of need
- a USB boot device to kickstart a rebuild, restore environment
- some sort of initial restore media or equivalent containing encrypted backups
- encrypted offline backup of the infrastructure wiki
- n-person split password key material to decrypt backups.
DR/BCP also requires thoughtful derisking by inventorying, identifying dependencies, prioritizing restoration (DNS, DHCP, AD, etc.), and removing/untangling cyclic dependencies if they happen up or down the stack. There are semi-automated tools to help with most of this, and infrastructure automation should assist it as much as possible, because if you can't rebuild it with confidence, then you don't have anything.
It requires significant thought, effort, standardization, continuous maintenance, and practiced at least yearly by someone(s) like SREs and with regular input of front-line IT-equivalent owners.
It’s just that it’s fairly common to see such circular dependencies.
I’ve seen many sitiations where one team just assumes that another team is looking after these things and that “it’s someone else’s responsibility” or some such. I am certainly not defending that.
Plenty of teams see things like backup as something that is somewhere else in the stack. Plenty of executives just assume their technologists are baking these capabilities into product. A lot of junior people haven’t really been given a solid education on these areas and it’s not uncommon to see newer-to-career people making basic mistakes like conflating synchronization and backup, or geo-redundancy with wholesale BCDR.
The core selling point (hiding latency) is big I think. But, if you self-host, the user/business can put their server very close and reduce latency to unnoticeable levels.
I think local-first is cool, really cool and makes beautiful apps. But I think it's only worth it for a small subset of software, far smaller then self-hosted.
Last time I checked TCO was higher unless you are sort of big enterprise or individual who values her time zero.
Do not get me started on capex
I only really spend time on maintaining them when I want to update them which is usually just a git pull and a docker compose command.
Hosting is very complicated, I tend to use an analogy about energy-production, where you can make your own energy or you can plug into the decentralised options.
Some things you might want to host, but the economic trajectory is telling us that the decentralised options are here to stay.
I agree there.
> Hosting is very complicated
But not here. Docker, imho, and cloud providers that make deploying Docker apps easy are making it very easy.
I don't really know what you mean by "decentralised" options though. Using an existent SaaS is far from decentralised imho.