Remember Koenig’s Fundamental Theorem of Software Engineering: “We can solve any problem by introducing an extra level of indirection”? :-)
You would be surprised if I could tell you the number of customers that asked about Cloud Block Storage. This is one of the most requested services! Since all storage is block storage at the lowest level of abstraction on top of the device, it is always used by higher level abstractions. The question is whether that level of abstraction is appropriate for your application and your productivity as a developer if writing new apps. I see block level storage as the most versatile because it is the most fundamental and you can use it for anything: storage for emails, storage for tables and indexes of your favorite database, storage for file systems, archives, etc., by building that abstraction on top of blocks.
But I agree with the basic idea of your comment: as the most fundamental layer, then it may also be too low an abstraction layer to be used directly if you are writing a new high level app (think a business app for instance). That’s why there are file systems, databases, etc., all of which use blocks to do their thing and provide higher level functionality. I like to use the example of how most people don’t stop to think that systems really do not know about files and directories, or database tables and indexes. They just know blocks. But the file system abstracts blocks and provides the appearance of files and directories and hierarchy. And DBAs and developers using our Cloud Databases product are happy to do SELECT A, B FROM T WHERE C=’value’ without having to worry about blocks. But blocks are always there, underneath all that.
Whether you would want to stay at that lower level of abstraction depends on what you are doing. The higher the level the more specialized the abstraction, the more flexibility you gain at that level and the less flexibility you have to optimize at the lower level. For example, on average, 50% of the last block used by a file is wasted in many file systems. Nothing you can do about that. But I bet those directories and ability to find a file by name come in handy at that higher level.
I think that there are two cases where block is needed. The first one is to deploy commercial applications, databases, file systems, etc. for which you have no choice because you did not write the app. The second is for optimization of storage for infrastructure applications you are writing and have control of and where you want that optimization.
Many people writing business applications or web apps will be happy to use object storage or Cloud Databases for MySQL. No need to worry about block level because we abstract it for them. Many people will need a file system: they will just create a block storage device and format it as an fs and move on with their lives. Others will use it as a database. Others will write apps we cannot even imagine right now. But blocks will be there, humbly, doing their work.
Remember Koenig’s Fundamental Theorem of Software Engineering: “We can solve any problem by introducing an extra level of indirection”? :-)
You would be surprised if I could tell you the number of customers that asked about Cloud Block Storage. This is one of the most requested services! Since all storage is block storage at the lowest level of abstraction on top of the device, it is always used by higher level abstractions. The question is whether that level of abstraction is appropriate for your application and your productivity as a developer if writing new apps. I see block level storage as the most versatile because it is the most fundamental and you can use it for anything: storage for emails, storage for tables and indexes of your favorite database, storage for file systems, archives, etc., by building that abstraction on top of blocks.
But I agree with the basic idea of your comment: as the most fundamental layer, then it may also be too low an abstraction layer to be used directly if you are writing a new high level app (think a business app for instance). That’s why there are file systems, databases, etc., all of which use blocks to do their thing and provide higher level functionality. I like to use the example of how most people don’t stop to think that systems really do not know about files and directories, or database tables and indexes. They just know blocks. But the file system abstracts blocks and provides the appearance of files and directories and hierarchy. And DBAs and developers using our Cloud Databases product are happy to do SELECT A, B FROM T WHERE C=’value’ without having to worry about blocks. But blocks are always there, underneath all that.
Whether you would want to stay at that lower level of abstraction depends on what you are doing. The higher the level the more specialized the abstraction, the more flexibility you gain at that level and the less flexibility you have to optimize at the lower level. For example, on average, 50% of the last block used by a file is wasted in many file systems. Nothing you can do about that. But I bet those directories and ability to find a file by name come in handy at that higher level.
I think that there are two cases where block is needed. The first one is to deploy commercial applications, databases, file systems, etc. for which you have no choice because you did not write the app. The second is for optimization of storage for infrastructure applications you are writing and have control of and where you want that optimization.
Many people writing business applications or web apps will be happy to use object storage or Cloud Databases for MySQL. No need to worry about block level because we abstract it for them. Many people will need a file system: they will just create a block storage device and format it as an fs and move on with their lives. Others will use it as a database. Others will write apps we cannot even imagine right now. But blocks will be there, humbly, doing their work.