Files have been the common element of computing since at least the 1960s. Files existed before disk drives and file systems, as one could put multiple files on a magnetic tape.
MS-DOS used files. Windows used files. OS/2 used files. (Even the p-System used files.)
Files were the unit of data storage. Applications read data from files and wrote data to files. Applications shared data through files. Word processor? Files. Spreadsheet? Files. Editor? Files. Compiler? Files.
The development of databases saw another channel for sharing data. Databases were (and still are) used in specialized applications. Relational databases are good for consistently structured data, and provide transactions to update multiple tables at once. Microsoft hosts its Team Foundation on top of its SQL Server. (Git, in contrast, uses files exclusively.)
Despite the advantages of databases, the main method for storing and sharing data remains files.
Until now. Or in a little while.
Cloud computing and web services are changing the picture. Web services are replacing files. Web services can store data and retrieve data, just as files. But web services are cloud residents; files are for local computing. Using URLs, one can think of a web service as a file with a rather funny name.
Web services are also dynamic. A file is a static collection of bytes: what you read is exactly was was written. A web service can provide a set of bytes that is constructed "on the fly".
Applications that use local computing -- desktop applications -- will continue to use files. Cloud applications will use web services.
Those web services will be, at some point, reading and writing files, or database entries, which will eventually be stored in files. Files will continue to exist, as the basement of data storage -- around, but visited by only a few people who have business there.
At the application layer, cloud applications and mobile applications will use web services. The web service will be the dominant method of storing, retrieving, and sharing data. It will become the dominant method because the cloud will become the dominant location for storing data. Local computing, long the leading form, will fall to the cloud.
The default location for data will be the cloud; new applications will store data in the cloud; everyone will think of the cloud. Local storage and local computing will be the oddball configuration. Legacy systems will use local storage; modern systems will use the cloud.
Showing posts with label files. Show all posts
Showing posts with label files. Show all posts
Monday, September 25, 2017
Thursday, May 16, 2013
Life without files
Mobile devices (tablets and phones) are different from PCs in that they do not use files. Yes, they have operating systems that use files, and Android has file managers which let you access some or all files on the device, but the general experience is one without files.
The PC experience was centered around files. Files were the essential element of a PC, from the boot files to word processor documents to temporary data. Everything was stored in a file. The experience of using a PC was running an application, loading data from a file, and manipulating that data. When finished, one saved the information to a file.
Unix (and Linux) also have this approach. Microsoft Windows presented data in a series of graphical windows, but it stored data in files. The "File" menu with its options of "New", "Open", "Save", "Save As", and "Exit" (oddly) were standard in the UI.
The mobile experience relies on apps, not files. The user runs an app, and the app somehow knows how to get its data. Much of the time, that data is stored in the cloud, on servers maintained by the app provider. There is no "File" menu -- or any menu.
Shifting the experience from files to apps is a subtle but significant change. One tends to miss it, since keeping track of files was tedious and required discipline for structuring directories. When apps load their data automatically, one doesn't really mind not worrying about file names and locations.
With the "loss" of files, or more specifically the access to app data outside of the app, one is more conscious of sharing information between apps. In the PC age, one didn't share information between applications -- one stored data in a public place and let other applications have their way with it.
This "data available to all" makes some sense, especially for developers. Developers use multiple tools on their data -- source code -- and need it shared liberally. Editors, compilers, debuggers, lint utilities, and metrics tools all need unfettered access to the source code.
But the "free for all" model does not work so well for other data. In most shops, data is used in a single application (most often Microsoft Word or Microsoft Excel) and occasionally sent via e-mail to others. But this latter act is simply sharing the data; a better way to share data could eliminate a lot of e-mails.
Sharing data and allowing others to update it (or not) requires an infrastructure, a mechanism to make data available and control access. It requires data to be structured in a way that it can be shared -- which may be different from the internal format used by the app. Yet defining an external format may be good for us in general: we can eliminate the task of reverse-engineering proprietary file formats.
Life without files. Because we want to get work done, not read and save files.
The PC experience was centered around files. Files were the essential element of a PC, from the boot files to word processor documents to temporary data. Everything was stored in a file. The experience of using a PC was running an application, loading data from a file, and manipulating that data. When finished, one saved the information to a file.
Unix (and Linux) also have this approach. Microsoft Windows presented data in a series of graphical windows, but it stored data in files. The "File" menu with its options of "New", "Open", "Save", "Save As", and "Exit" (oddly) were standard in the UI.
The mobile experience relies on apps, not files. The user runs an app, and the app somehow knows how to get its data. Much of the time, that data is stored in the cloud, on servers maintained by the app provider. There is no "File" menu -- or any menu.
Shifting the experience from files to apps is a subtle but significant change. One tends to miss it, since keeping track of files was tedious and required discipline for structuring directories. When apps load their data automatically, one doesn't really mind not worrying about file names and locations.
With the "loss" of files, or more specifically the access to app data outside of the app, one is more conscious of sharing information between apps. In the PC age, one didn't share information between applications -- one stored data in a public place and let other applications have their way with it.
This "data available to all" makes some sense, especially for developers. Developers use multiple tools on their data -- source code -- and need it shared liberally. Editors, compilers, debuggers, lint utilities, and metrics tools all need unfettered access to the source code.
But the "free for all" model does not work so well for other data. In most shops, data is used in a single application (most often Microsoft Word or Microsoft Excel) and occasionally sent via e-mail to others. But this latter act is simply sharing the data; a better way to share data could eliminate a lot of e-mails.
Sharing data and allowing others to update it (or not) requires an infrastructure, a mechanism to make data available and control access. It requires data to be structured in a way that it can be shared -- which may be different from the internal format used by the app. Yet defining an external format may be good for us in general: we can eliminate the task of reverse-engineering proprietary file formats.
Life without files. Because we want to get work done, not read and save files.
Wednesday, May 25, 2011
Files are out, web services are in
The trusty file has been with us (that is, us PC users) since before the dawn of time. (If we consider the "dawn of time" to be the introduction of the IBM PC.) It has been the workhorse of data containers, going back to the elder days of CP/M and DEC PDP-11 computers.
While files have served us well, they are poor citizens of cloud computing. Files insist on being, on existing, at some location (usually on a disk). Because they have a known physical location, they are problematic for the cloud. A file is a singular thing, existing on a singular host. Even files on a device such as a SAN are on a singular host -- the SAN, arguably, is a host. A single point of access is a bottleneck and a threat to performance.
But it turns out that we don't need files. Files are nothing more that a collection of bytes. Some consider them a stream. Others will think of them as a collection of not bytes but characters.
We need collections (or streams) of bytes (or characters). But we don't have to house those collections in files.
In the cloud, we can use web services. Web services can provide collections of bytes (or characters) just like files. Web services can be distributed across multiple hosts, eliminating the bottleneck of files. Unlike files, web services are identified by URIs, and this gives us flexibility. A "file" provided by a URI can come from one server or from one of many (although you must ensure that all servers agree upon the contents of the file).
The design of a classic PC application involved the specification of input and output files. The design of a cloud application must involve the specification of web services.
While files have served us well, they are poor citizens of cloud computing. Files insist on being, on existing, at some location (usually on a disk). Because they have a known physical location, they are problematic for the cloud. A file is a singular thing, existing on a singular host. Even files on a device such as a SAN are on a singular host -- the SAN, arguably, is a host. A single point of access is a bottleneck and a threat to performance.
But it turns out that we don't need files. Files are nothing more that a collection of bytes. Some consider them a stream. Others will think of them as a collection of not bytes but characters.
We need collections (or streams) of bytes (or characters). But we don't have to house those collections in files.
In the cloud, we can use web services. Web services can provide collections of bytes (or characters) just like files. Web services can be distributed across multiple hosts, eliminating the bottleneck of files. Unlike files, web services are identified by URIs, and this gives us flexibility. A "file" provided by a URI can come from one server or from one of many (although you must ensure that all servers agree upon the contents of the file).
The design of a classic PC application involved the specification of input and output files. The design of a cloud application must involve the specification of web services.
Subscribe to:
Posts (Atom)