There is a somewhat forgotten concept of SOHO (small office, home office - small office, home office - MODO, if you please in Russian).
Its development spurred 2 more phenomena:
- the development of remoteness after covid
- development of self hosting – people are abandoning public clouds and switching to applications running at home (here is my series of notes “Home cloud”)
I would like to note that startups are in the early stages (of course, we are not talking about hundreds of people here) they also fit the definition of SOHO.
For simplicity of technical discussion, a SOHO solution is a solution that up to 20 people are working on and whose databases are placed on one physical server (albeit a large one). It doesn’t matter how many people the solution itself is designed for.
Melvin Conway’s “law” has long been known:
Organizations designing systems are limited to a design that copies the communication structure in that organization.
You can reformulate something like this: the structure of the organization significantly affects the architecture of the application.
And add about the size: the size of the organization significantly affects the architecture of the application.
And then we have an obvious, but sometimes incredible consequence: the technologies used should depend on the size of the organization.
In other words, what is good for Google is not the fact that it will be good for you.
Let’s take an example of Kubernetes. The technology allows you to automate the deployment of applications, shift more maintenance from the team of a specific application to the admin department (for example, if previously each fairly large system had its own monitoring and databases, now it is provided by the devops department through K8s). But is Kubernetes suitable for the home? No:
- 2 cars are enough for the house, the minimum is 3 extra
- too much overhead – even pure Kubernetes constantly asks all its abstractions for everything – and at home, in the absence of activity, the application should not do anything
Therefore, for SOHO (and startups) I usually suggest “deployment via Podman”.
Similarly with databases: Cassandra and Mongo are usually not needed in SOHO. Postgres and SQLite are better suited here (no matter how it sounds at first glance).
The thoughts of this note echo those of [You are not Google] (https://habr.com/ru/companies/infopulse/articles/330708 /), then there the author wants to bring most of the text to emotions.
I have formed such basic requirements for SOHO systems:
- easy operation
- no constant analysis of logs and metrics by a separate team
- automatic recovery after failures
- and easy reinstallation with data recovery from backup if everything went wrong
- remote management (mobile application and/or web, without Linux consoles)
- low power consumption
- silence, or maybe even shutdown, if you don’t need applications on the machine right now
- fast system loading so that you don’t have to wait a long time when you need it
- adequate hardware requirements aka good down scaling (for example, Kafka requires too much for a small HA installation on 2 nodes)