Why clouds are a mistake

I write this post because I am concerned about the development that we have seen in the last years regarding server infrastructure and clouds. I wonna write down my perspective of how things have developed and what makes sense for the future.

The beginning

At the starting phase, cloud hosts like gcloud or aws consisted of remote machines that one could start in one click and log into per ssh. That was a really handy feature and just so much better than managing your own machine. Someone on the other side managed the resources, the hardware, the internet connection and so on. You could just have your machine located in san francisco or whatever, start it, stop it, kill it and so on. Things were cool back then. I once installed a devops pipeline jst

Where things got out of hand

Later on, I guess it was Heroku who was leading in the deployment of pre-defined servers like databases, search services, frontends, minecraft servers and so on. That's where things started to get out of hand. The idea is not bad: You have your database up within seconds. You can connect your app to it within minutes. The cloud manages your backup if you want to. This is really nice. But everything comes at a cost. From now on, clouds started charging their customers for database reads and for the amount of database entries. This idea is just wild. You need to have some shitty code in your software that decides to go wild and you have as many reads as your engine can handle. Or you can get a DDos and your bill is just crazy. As a product owner of a serious app launched on the web somewhere, I would never trust such a payment option. Because internet is just wild and so is pretty much every source code.

Today's debacle

The thing is, modern billing is not even the worst part of clouds. A standard website that's proposed by those providers may look like that:

• A PostgreSQL Database for your data
• A Redis Database for caching
• A Frontend server with a CDN to be on the edge
• 2 Microservices for the backend (Or even worse, cloud functions)
• Maybe one ElasticSearch service to find some data because your database is shitty
• An Authentication service

And the list goes on. This is a classic example of an overengineered website. If you want to spin up something like that on AWS, you would need users setup for the services, users setup for the teams, have permissions set right, setup backup for everything, make sure communication is working, have separate logfiles and the list goes on and on. That is just so much to manage. I mean, some companies with huge traffic may need that but here is the point. The argument for clouds in the early days was their flexibility and easy setup. A system like the above on AWS may need several teams to manage. The bill would be all over the place and hard to decode. The cloud provider has all the power over the product. A small rise in the price and you cannot go away because you are just locked into the cloud with not just the system but also the people you have hired. This lock is just so scary. In the end, it means the cloud IS the product you make and the cloud makes the most profit of it as well. The engineering force spent into cloud providers could just as well be spent into a good docker setup with just plain old linux machines.

The alternative

That's where we arrive. I wonna provide some things to consider BEFORE deciding for a cloud architecture.

1. How much do you NEED to engineer your app? This is the first thing to look at. If you are a startup, just create a monolite and write shitty but fast code. May it be next.js, rails, node.js or whatever. Keep the code in one place and don't worry about performance because mostly, you have very few users in the beginning. If you grow, so does the income and that puts you in good places. But even there, you can scale with monolithic Opimizations and just more hardware as well. No need for crazy architectures in first place. Simplicity always comes first.
2. Dockerize everything. Docker is a great technology and instead of making GCloud or AWS Certificates, invest into being good at docker. Not even kubernetes but docker in first place. Once you have your app dockerized or all your app parts in a docker compose, you can spin it up on any machine you just want. You can have a GCloud compute instance. Google decides to mess up and all you need to do is spin up a Digitalocean droplet, start it with docker compose, migrate data and change the DNS entry and you are gone.
3. Keep it simple and handy I have made a great experience by hosting an app just using traefik and docker. For small apps, all you need is a proxy and docker. Traefik is a proxy that works with labelled docker containers. You label them with your subdomain and, once setup, traefik is handling the rest. I think coolify is using traefik as well and its my favorite hosting service. Check traefik out here: https://doc.traefik.io/traefik/ (No, I am not paid but it is a cool product).

I really wish we had more docker engineers than AWS experts in the industry. Another advantage: If you are dealing with sensitive data, just host it in your country or even just locally: Possible when you just know docker.

Sidenote: I like Digitalocean

I am not paid by the company, but I think digitalocean has managed to keep its cloud simple and easy. Make droplets, make sql services, connect them and there you are. They have just few products but document them really well. I have used digitalocean app machine as well with an SQL Database. As far as I remember, they don't charge by reads or something wild. It is still a cloud for users and devs and not for management.