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.
It also dramatically increases the flexibility THEY have in their underling infrastructure to scale up, down, and move your instances around.
When you interact with an NFS your code may have certain expectations of timeouts etc because you're using the filesystem API.
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.
Anyhow it’s the VPS I was talking about. The whole point of the VPS versus cloud thing is….. just run it yourself in a Linux server. Whatever you need, run it yourself.
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.
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.
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.
