> 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.
You’re totally right! Maybe I could have chosen a better example. The point I was trying to make: If you’re building a PaaS – why not make it easy to do something as basic as attaching storage? The answer is probably: Just use S3 or something like that. But meh, that’s just more special APIs and vendor lock-in.
I think because setting up NFS and attaching it is still way more difficult to support than just allowing an app to make HTTPS calls to S3 to manage its storage.
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.
Distributed storage that is fast and reliable can feel like magic. But it's not something that software alone can solve. It's a coordination of capable hardware and purpose built software. The fact that Kubernetes cleanly decouples this instead of abstracting it away or ignoring the use case is a good thing.
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.
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.
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.