Hacker News Reader

Comment by BilalBudhani | Hacker News Reader

I'm someone who likes configuring & running my own servers, it is always a pleasure reading how others small / solo businesses are running their show.

It is so cool to see one-person SaaS business running on old school bare metal servers without needing any fancy devOps / containerize tooling.

View on HN

From what I observe, developer prefer to stay in API abstractions than spending time on servers/other infrastructure. Partially I can understand their choice.

What do you mean? The economics and decision-making are different between one-person companies through small and large organizations. When you have to know to to do everything, and fix anything, it is a problem when there is complexity, and you lack control. As organizations get larger, there is more value from abstractions and more leeway for their use.

In many ways it is a luxury to be able to use said abstractions and be able to open a ticket with someone else. Of course, a single-person startup could use the same tech, but it seriously impacts their costs and they don't have time to deal with the sprawl of abstractions.

I believe it’s the opposite? In a large org, you can have a dedicate team managing your servers. When you’re a one man business, you want to abstract as much as possible to focus on value proposition.

True. Although more often than not it's the opposite in my experience. Large organizations can afford to spend the money on GCP/aws/Azure and deploy thousands of services. They can also afford the money to hire infrastructure engineers to maintain such services. Also, in large companies everything needs to be implemented "the same way", so no matter if you want to deploy a tiny service or a huge one, you must do it the same way other services in the company are deployed.

Whereas when you are a one-man business, all you have is (free) time and prefer to spend as little money as possible while your business is not profitable. This means: walk away from dedicated databases, managed servers, huge aws bills, etc. You do everything "the old" way: rent a server (bare metal or cloud) and maintain it yourself.

In theory, a one-man business should "abstract as much as possible". In practice, it doesn't work out like this because you are responsible for everything about the business and it's easier to actually operate and maintain the relatively small number of bare-metal servers that run the business. Your advantage as a solo developer is that you can move fast at any time, and it's harder to do when you are encumbered with abstractions. That's not to say build versus buy isn't an evaluation that happens. There are strategic bets, maybe on analytics, or things that help, but aren't core to what you build.

This pattern plays out with many indie app developers as well, both now with iOS apps, and back in the day with Delphi shareware. The cost of taking a dependency on a 3rd party library turns out to be much higher for the solo developer than larger orgs. That's not to say they don't make bets, but they don't build the way that someone at a larger org would do because they have to maintain a higher degree of direct control.

Marco Arment (https://marco.org/) has elaborated a lot on this topic. You can also get a feel for the limits on the upper bounds of his developer experience. Many on HN are not willing to work at a low-level with such boring and dull technologies.

That fancy devops/containers tooling is easier to maintain and work on vs running on bare metal servers.

Is that some kind of universal truth or just what you think

When there are just 9 servers and a single developer like in the article your opinion doesn't matter.

It's not easy to maintain I can tell you

I said easier, not easy.

I don't see how it is easier to maintain.

I follow a simple rule of thumb - the more abstractions you introduce the more complex it gets to maintain

Life is easier if you can get away with lesser abstractions.

The more tools you have the more difficult it is to maintain yourself. In a larger team with dedicated DevOps you might be right. But in my case where I maintain frontend, backend, databases, security, hosting and the servers I cannot have too much complexity. And i find container tools too complex to fully understand as a full stack software developer (not an expert in anything). Same for heavy weight frontend or backend frameworks. I like to keep it simple without too many abstractions on all layers. So far I managed to build apps used by millions of daily users for about 10 years.

I think you and the people disagreeing with you are both right, in a sense. These tools can absolutely simplify and improve even a small deployment…for someone with significant experience using them. But there’s a lot of learning that has to happen to get to that level of experience. And for a solo operator or small team without that experience, investing that time into learning may not be the best investment.

You see this contextual disagreement a ton here on HN. Those who gave taken the time to learn these tools and have practical experience using them for real deployments see the alternative as primitive, error prone and fundamentally limiting. Those without the experience see the tools as overly-complex distractions. Both are true, depending on your situation. Like almost all tech decisions, there are no universally correct answers. The best decisions are those tailored to the specific circumstances.

Reply on news.ycombinator.com