How Developers Get You Stuck on a Cloud

The cloud hosting companies publish a lot of tutorials and tools and there are a lot of Developer Advocates hired to help persuade people to integrate. Usually it’s free to try and even free for casual professional use. Their success and ease has helped to concentrate a lot of expertise and power into Big Tech companies. Governments award cloud hosts contracts for big money. The cloud services are now dominating over traditional self-hosting or datacenter colocation options. Today we’ll take an unbiased alternative view illuminating the costs to the default cloud approach.

Cloud market at a glance

MachinesDatabasesStorageProcessingMonitoring
Cloud Instance
Kubernetes
Microservice
Autoscaled & managed SQL, JSON/NoSQL, Key-value storeS3 'Bucket'
Ceph
CDN
CI/CD
Functions FaaS
Workers
Logs & search
Notifications
Versus traditional & self-hosted approach
Server in your office
VPS
Dedicated machine
Colocated machine
Manually or automatically scaled SQL, JSON/NoSQL, Key-value storeHard drive + Synchronization
Minio S3-like 'Bucket'
IPFS
Jenkins
Cron & scheduling
systemd
Ansible
OpenFaaS journald
grep

The key differences are cloud services scale up virtually infinitely and with less initial effort than doing Sysadmin or DevOps team scaling. If you ever tried to scale your SQL or JSON database into a cluster there is a challenge both for making that cluster but it also changes the way developers use the database. If your users need to download files faster a CDN service can usually do it quicker and with less initial effort then synchronizing files or horizontally distributing them yourself.

It’s about who is doing the work and who has the expertise: you or them.

It begins with CDN📎

For storage developers tap into CDNs for JS, CSS, and images. It’s a quick copy and paste. Your app gets their jQuery or your Bootstrap and you don’t even have to host the files yourself! A lot of different assets can be combined leading to the ‘Mashup’ where an app ties together all these web scripts into something new and useful.

One of the things they don’t mention is that you’re giving those CDN companies access to your customer’s browser information. Have you notified your customers that you’re sending over their association with you, and which content they are browsing, and the details of their computer? Developers generally don’t discuss it. That risk doesn’t really show up on developer radar and business owners don’t see it.

Moving away from a CDN for files is relative easy compared with other services. The files would be copied and served. Optionally they are scaled horizontally across a few machines using DNS tricks.

Locking in the database📎

Developers become overwhelmed at the complexity of scaling the database. It’s not always clear if they can optimize queries or if they need to cluster the database server. It’s not always clear how that changes their maintenance, storage, and machines. Rather than taking the risk and responsibility in the company for doing that they’ll promote to management to simply sign up for a cloud database and then integrate it.

What they will not discuss is that access times from the app to the database are increased because they aren’t initially physically located next to each other. The app is still running in California while the database is in Virginia. A new problem arises with a cascade of choices usually resulting in moving the app also into the same cloud. That satisfies the speed solution but introduces now an app scaling and management lock in.

Locking in storage📎

Customer files used to be in a folder like /uploads and then the app scripts would selectively grant access based on who owns what or who purchased. Being more familiar with the cloud hosts the developer will transfer everything into S3 Buckets and get rid of the remaining internally-managed servers. The app is fully on the cloud. Internal transfers are free or cheap. It’s only the cloud hosts responsibility to ensure everything is up.

Plausible deniability📎

I’ll go check with the cloud and open a ticket.

If a problem arises the developer who used to part-time as a sysadmin can now instantly shift attention to the cloud host. People don’t like feeling responsible when an app is down or bugging out. The cloud is a convenient way to temporarily relieve ones’ self of fear. After the cause of the problem is discovered the developers can optionally say what the source of the problem was or leave the assumption of guilt on the cloud. Socially it smooths over a lot of interactions.

If your job involves assessing risk or quality you might want the true causes of problems to be clear or use them as a teaching exercise for employees. Maybe you want incidents documented so you can reduce recurrences. If it’s on your server your employee can view that problem at a moment. If we ask the cloud host there is some amount of time to wait.

It may also be undesirable to train developers or sysadmin to look to someone else to solve problems. For example if you wanted employees to stay long term then you might invest in them having the skills. If you only need employees temporarily then it makes sense to push the responsibility to the cloud.

Redundantly terrible📎

The cloud services do a great job at keeping apps running. If they crash they are automatically restarted and sometimes users wont even notice it was down because the app is running multiple instances. This effect has led develoeprs to be less cautious how they write their code because if it normally works and crashes are less obvious. Maybe nobody notices at all.

Another funny effect coming from the cloud and functions is that functions can call themselves or other functions leading to a cascade effect. Some customers have had a loop that incurred a hefty bill at he cloud. Usually clouds employees are understanding and will refund but it’s still an interesting phenomenon. It’s difficult to understand a graph of dependencies with complex cloud apps.

Some developers view code quality and craftsmanship as a core value but the careless developers who do not take care can appear the better when pitching to management. It sounds a lot better if we don’t mention any problems or cons. There is fear about rejection and responsibility if something can go wrong. If the cloud can cover our code quality problems that is an interesting business proposition in itself. We can understand either side in the quality debate.

Anticompetitive clouds📎

Governments in cooperation with the clouds have organized to label competition as “Racist” and toss them off their hosting. It’s hard to compete or defend yourself legally when the government propagandizes all of your ‘peers’ to hate different ideas and then delete your account. It’s considered to be acceptable now to slander competition where it used to require a duel to the death. We don’t think about the social costs and defending our honor. By becoming a customer of the cloud we’re reinforcing their political agenda and feeding a future enemy.

A critical but less talked about idea is that it is self-hate to become a customer of a cloud that has anti-white and anti-male hiring practices. Why do developers have such low self-esteem?

The phenomenon of being tossed off hosting for political censorship is ever growing. Many people are losing money from lost opportunities and their reputation being ruined. Opportunities to compete exist for the brave who want to capture the market of people persecuted by government-clouds.

Federation📎

Some governments like Brazil found that their communications were able to be accessed by USA spy agencies because it was at Google’s Gmail in USA! Germany found that due to using Microsoft Windows information about their networks and communications could be accessed by USA spies and also USA competitors. Some bit of legislation exists now for the purposes of preventing governments from using foreign clouds. There could be an interesting investment opportunity there to highlight these risks and provide solutions.

The rise of Cryptocurrencies was due to Central Bank monopolies using their powers of inflation to new levels diminishing the investments of all. The decentralization of currency also got people to think about hosting and cloud risks. New economies have sprung up like IPFS and Filecoin to provide storage and Ethereum cryptocurrency provides some shared processing.


Developers aren’t economists but they still have to try to communicate to the business the costs. The more enlightened the developer the more they will see and speak hidden costs. With the dominant culture being of being an immature hedonist it is likely to get worse before it gets better. We should expect more centralization, more app failures, and cloud failures. Eventually the costs will become clear from the social to the opportunity costs. The truth always comes out but it takes a while.

One day we will see developers get the appropriate tools for robust, secure, and scalable software. Entrepreneurs will invent the solutions and we will look back at his time of the government-clouds and ask ourselves: “Why did we do it that way?”