Storage and modern tech stacks

 As a developer, I must say; I am baffled at the industry's current stance on storage persistence.

It seems as though modern development stacks are actively against the notion of persistent storage. Docker, Kubernetes and the likes along with Serverless all like to think of data as something they shouldn't need to manage.

I saw an article today stating that future of storage is API driven.

Now, don't get me wrong. I have nothing against my storage being API driven in particular. But, it is a popular trope among those who dislike mounting volumes in their containers or acknowledging the existence of their file system.

And APIs can be a very good solution in a number of scenarios. But, arguably, most scenarios do not.

The first problem with APIs is it means putting an additional layer between you and your data. And the second is that the data still needs to be persisted somewhere. In other words, you haven't actually eliminated that persistence layer. You've just tried to absolve yourself of the ownership it at the cost of performance. 

If I have a need for an extensible/agnostic storage solution and I don't want my application code beholden to a particular implementation, then an API is a great answer.  That API still needs the volumes mounted and needs to know how to interact with the underlying storage system. But, I can keep my other services agnostic to all of that.

And this doesn't change if your storage solution is Amazon S3, or your own custom system, or some other competitor. As I said before, the only real difference is if you choose a 3rd party provider, the actual worry over how storage is mounted and persisted is left to someone like Amazon. IT STILL HAPPENS. You have changed NOTHING. Only, now you have introduced additional overhead for every single storage related call.

So, like I said, sure, there are times and places where it will make sense. But, there are probably far more places where it simply makes sense to handle it yourself. And, I mean, you could simply store everything in SQL or another DBMS system. That is still an API. And, it stresses the reality; you can't escape it. Most application require data persistence. I don't understand why people are so hell bent on trying to abstract it out of existence. They'll never succeed. And, unless you need that abstraction you'll take a hit.

Now, I can agree that if you have a microservices or even server less architecture where you may have multiple services or at least endpoints all interested in a variety of data that it might make sense to centralize that behind an API. But, I would still suggest in most cases that you decide to own your own data.