To avoid sysadmin tasks, and keep costs down, you've got to go so deep in the cloud, that it becomes just another arcane skill set. I run most of my stuff on virtual Linux servers, but some on AWS, and that's hard to learn, and doesn't transfer to GCP or Azure. Unless your needs are extreme, I think sysadmin'ing is the easier route in most cases.
For so many things the cloud isn't really easier or cheaper, and most cloud providers stopped advertising it as such. My assumption is that cloud adoption is mainly driven by 3 forces:
- for small companies: free credits
- for large companies: moving prices as far away as possible from the deploy button, allowing dev and it to just deploy stuff without purchase orders
- self-perpetuating due to hype, cv-driven development, and ease of hiring
All of these are decent reasons, but none of them may apply to a company like fastmail
Also CYA. If you run your own servers and something goes wrong its your fault. if its an outage at AWS its their fault.
Also a huge element of follow the crowd, branding non-technical management are familiar with, and so on. I have also found some developers (front end devs, or back end devs who do not have sysadmin skills) feel cloud is the safe choice. This is very common for small companies as they may have limited sysadmin skills (people who know how to keep windows desktops running are not likely to be who you want to deploy servers) and a web GUI looks a lot easier to learn.
In small companies, cloud also provides the ability to work around technical debt and to reduce risk.
For example, I have seen several cases where poorly designed systems that unexpectedly used too much memory, and there was no time to fix it, so the company increased the memory on all instances with a few clicks. When you need to do this immediately to avoid a botched release that has already been called "successful" and announced as such to stakeholders, that is a capability that saves the day.
An example of de-risking is using a cloud filesystem like EFS to provide a pseudo-infinite volume. No risk of an outage due to an unexpectedly full disk.
Another example would be using a managed database system like RDS vs self-managing the same RDBMS: using the managed version saves on labor and reduces risk for things like upgrades. What would ordinarily be a significant effort for a small company becomes automatic, and RDS includes various sanity checks to help prevent you from making mistakes.
The reality of the industry is that many companies are just trying to hit the next milestone of their business by a deadline, and the cloud can help despite the downsides.
> For example, I have seen several cases where poorly designed systems that unexpectedly used too much memory
> using a managed database system like RDS vs self-managing the same RDBMS: using the managed version saves on labor
As a DBRE / SRE, I can confidently assert that belief in the latter is often directly responsible for the former. AWS is quite clear in their shared responsibility model [0] that you are still responsible for making sound decisions, tuning various configurations, etc. Having staff that knows how to do these things often prevents the poor decisions from being made in the first place.
Not a DB admin, but I do install and manage DBs for small clients.
My experience is that AWS makes the easy things easy and the difficult things difficult, and the knowledge is not transferable.
With a CLI or non-cloud management tools I can create, admin and upgrade a database (or anything else) exactly the same way, locally, on a local VM, and on a cloud VM from any provider (including AWS). Doing it with a managed database means learning how the provider does it - which takes longer and I personally find it more difficult (and stressful).
What I cannot do as well as a real DB admin could do is things like tuning. Its not really an issue for small clients (a few generic changes to scale settings to available resources is enough - and cheaper than paying someone to tune it). Come to think of it, I do not even know how to make those changes on AWS and just hope the defaults match the size of RDS you are paying for (and change when you scale up?).
having written the above I am now doubting whether I have done the right thing in the past.
There are other, if often at least tangentially related, reasons but more than I can give justice to in a comment.
Many people largely got a lot of things wrong about cloud that I've been meaning to write about for a while. I'll get to it after the holidays. But probably none more than the idea that massive centralized computing (which was wrongly characterized as a utility like the electric grid) would have economics with which more local computing options could never compete.
Free tiers, startup credits, easily available managed databases, queues, object storage, lambdas, load-balancing, DNS, TLS, specialist stuff like OCR. It's easy to prototype something, run for free or for peanuts, start getting some revenue.
Then, as you grow, the costs become steeper, but migrating off of the cloud looks even more expensive, especially if you have accumulated a lot of data (egress costs you, especially from AWS). Congrats, you have become the desirable, typical cloud customer.
I'm very interested in approaches that avoid cloud, so please don't read this as me saying cloud is superior. I can think of some other advantages of cloud:
- easy to setup different permissions for users (authorisation considerations).
- able to transfer assets to another owner (e.g., if there's a sale of a business) without needing to move physical hardware.
- other outsiders (consultants, auditors, whatever) can come in and verify the security (or other) of your setup, because it's using a standard well known cloud platform.
Those are valid reasons, but not always as straight forward:
> easy to setup different permissions for users (authorisation considerations)
Centralized permission management is an advantage of the cloud. At the same time it's easy to do wrong. Without the cloud you usually have more piecemeal solutions depending on segmenting network access and using the permission systems of each service
> able to transfer assets to another owner (e.g., if there's a sale of a business) without needing to move physical hardware
The obvious solution here is to not own your hardware but to rent dedicated servers. Removes some of the maintenance burden, and the servers can be moved between entities as you like. The cloud does give you more granularity though
> other outsiders (consultants, auditors, whatever) can come in and verify the security (or other) of your setup, because it's using a standard well known cloud platform
There is a huge cottage industry of software trying to scan for security issues in your cloud setups. On the one hand that's an advantage of a unified interface, on the other hand a lot of those issues wouldn't occur outside the cloud. In any case, verifying security isn't easy in or out of the cloud. But if you have an auditor that is used to cloud deployments it will be easier to satisfy them there, that's certainly true
It never disappeared in some places. In my region there's been zero interest in "the cloud" because of physical remoteness from all major GCP/AWS/Azure datacenters (resulting in high latency), for compliance reasons, and because it's easier and faster to solve problems by dealing with a local company than pleading with a global giant that gives zero shits about you because you're less than a rounding error in its books.
