Cloud of Disillusion: The Broken Promise of PaaS

> Kubernetes allows you to mount block storage volumes for storing files. But each volume can only be mounted to a single server instance (pod). So if you want multiple pods to access your volume, you need to configure and deploy an NFS service. In which world is this simple, convenient, or straightforward?

While I am far from a microservice evangelist, when you adopt a framework you have to adjust your architecture to that platform to be as successful as possible.

Microservices are intended to be _bounded contexts_ and if you violate that concept you retain the complexity and lose the benefits of the tradeoff analysis that should have been done to decide on your chosen framework.

Adding crosscutting concerns like a NFS server violates the context boundary and leads you down the path of building a brittle distributed monolith.

The concept of independent deployability in microservices is a guide to help avoid architectural erosion.

The real answer to this problem is to quit making random golf course architecture decisions and make pragmatic choices.

Architecture is about finding the least worst option and is context specific with lots of nuance.

If you simply quit focusing on silver bullet myths and focus on what you needs are and adapt how you build your systems to work with the frameworks you have chosen things will work better.

Good Architecture is hard, but not nearly as hard as repeatedly building balls of mud and blaming the tools that you have chosen due to hype, habits, resume building and/or complacency.

> Kubernetes allows you to mount block storage volumes for storing files. But each volume can only be mounted to a single server instance (pod). So if you want multiple pods to access your volume, you need to configure and deploy an NFS service. In which world is this simple, convenient, or straightforward?

This isn't really correct.

So first, if you have a block-based volume (for which the host machine is doing block dev → filesystem), it should make some inherent sense that it can only be mounted by a single pod: it can only be attached to a single VM at a time, as otherwise the two FS drivers would corrupt the volume.

Outside of that, there are volume types you can mount multiple times in multiple pods. E.g., Azure Files. These are essentially NFS volumes, but since they're "aaS" you don't need to "deploy an NFS service", you just ask for the volume in k8s and it'll provision it.

The argument does not hold up for me. When I think of PaaS I think of Heroku which was a breath of fresh air at the time and is a model that still works well for the initial stage of a project. Fly.io and Kubernetes may fit in the same general circle but I don't believe are comparable to a Heroku.

Agree that Fly.io is pretty terrible experience as it markets an edge case that I don't believe the vast majority of systems need. The base PaaS case is pretty magical though and abstracts away a lot of the things I honestly don't care about for the first N thousand users.

Especially the point about having to get a silver support plan for 150$ to even be able to report a downtime... And then hoping that the corporation sees that issue as a priority while you can do nothing at all.

> Kubernetes allows you to mount block storage volumes for storing files. But each volume can only be mounted to a single server instance (pod). So if you want multiple pods to access your volume, you need to configure and deploy an NFS service. In which world is this simple, convenient, or straightforward?

If you're running your software on multiple VPS's you still need an NFS.

The only moment you don't need an NFS is when you have 2 processes running on the same machine touching the same folder.

The author touches upon Heroku in the sense that they say they've used it, but I think it is still, to date, the best PaaS out there, and makes some (if not many) of the author's arguments void.

There's been so many apps on Heroku that I can deploy with just `git push heroku master`, and I've worked on team where we've scaled on heroku on the db and app side with very little devops work, if any.

What the author is completely right on, however, is Fly.io -- it's unfortunately a platform that has _just enough PaaS_ to seem easy, but ends up being frustratingly difficult and comes with a lot of hard edges, even for simple apps.

Provisioning a postgres db on Fly.io is a great example - just use `fly postgres create` and go through the steps! Uh oh, the provisioned db template is defaulting to `SQL_ASCII`, I need `UTF8` encoding, what's the best way to do that? Good luck -- the Fly.io docs don't talk about that at all, and if you aren't a high enough "tier" of plan you get 0 customer support, just a community forum, with people asking questions and many times getting no responses.

Hetzner is what is always mentioned for VPS in these sorts of posts but worth considering IONOS too https://www.ionos.com/servers/vps#packages

None of this is a problem in Azure PaaS. There is autoscaling and shared storage volumes for serverless components. Perhaps the problem is Kubernetes?