Today, servers are PCs. They have the same architecture as PCs. They run PC operating systems. But do they have to be PCs? Is there another approach? There might be.
First, let's consider PCs. PCs have lots of parts, from processor to memory to storage, but the one thing that makes a PC a PC is the video. PCs use memory-mapped video. They dedicate a portion of memory to video display. (Today, the dedicated memory is a "window" into the much larger memory on the video card.)
Which is a waste, as servers do not display video. (Virtual machines on servers do display video, but it is all a game of re-assigned memory. If you attach a display to a server, it does not show the virtual desktop.)
Suppose we made a server that did not dedicate this memory to video. Suppose we created a new architecture for servers, an architecture that is exactly like the servers today, but with no memory reserved for video and no video card.
Such a change creates two challenges: installing an operating system and the requirements of the operating system.
First, we need a way to install an operating system (or a hypervisor that will run guest operating systems). Today, the process is simple: attach a keyboard and display to the server, plug in a bootable USB memory stick, and install the operating system. The boot ROM and the installer program both use the keyboard and display to communicate with the user.
In our new design, they cannot use a keyboard and display. (The keyboard would be possible, but the server has no video circuitry.)
My first though was to use a terminal and attach it to a USB port. A terminal contains the circuitry for a keyboard and display; it has the video board. But no such devices exist nowadays (outside of museums and basements) and asking someone to manufacture them would be a big ask. I suppose one could use a tiny computer such as a Raspberry Pi, with a terminal emulator program. But that solution is merely a throwback to the pre-PC days.
A second idea is to change the server boot ROM. Instead of presenting messages on a video display, and accepting input from a keyboard, the server could run a small web server and accept requests from the network port. (A server is guaranteed to have a network port.)
The boot program could run a web server, just as network routers allow configuration with built-in web servers. When installing a new server, one can simply attach it to your network and then connect to it via SSH.
Which brings us to the next challenge: an operating system. (Or a hypervisor.)
Today, servers run PC operating systems. Hypervisors (such as Microsoft's Hyper-V) are nothing more than standard PC operating systems that have been tweaked to support guest operating systems. As such, they expect to find a video card.
Since our server does not have a video card, these hypervisors will not work properly (if at all). They will have to be tweaked again to run without a video card. (Which should be somewhat easy, as hypervisors do not use the video card for their normal operation.)
Guest operating systems may be standard, unmodified PC operating systems. They want to see a video card, but the hypervisor provides virtualized video cards, one for each instance of a guest operating system. The guest operating systems never see the real video card, and don't need to know that one is present -- or not.
What's the benefit? A simpler architecture. Servers don't need video cards, and in my opinion, shouldn't have them.
Which would, according to my "a PC must have memory-mapped video" rule, make servers different from PCs. Which I think we want.
The video-less server is an idea, and I suspect that it will remain an idea. Implementing it requires special hardware (a PC minus the video circuitry that it normally has) and special software (an operating system that doesn't demand a video card) and special boot ROM (one that talks over SSH). As long as PCs are dominant, our servers will simply be PCs with no display attached.
But if the market changes, and PCs lose their dominance, then perhaps one day we will see servers without video cards.
Wednesday, February 19, 2020
Wednesday, February 12, 2020
Advances in platforms and in programming languages
The history of computing can be described as a series of developments, alternating between computing platforms and programming languages. The predominant pattern is one in which hardware is advanced, and then programming languages. Occasionally, hardware and programming languages advance together, but that is less common. (Hardware and system software -- not programming languages -- do advance together.)
The early mainframe computers were single-purpose devices. In the early 21st century, we think of computers as general-purpose devices, handling financial transactions, personal communication, navigation, and games, because our computing devices perform all of those tasks. But in the early days of electronic computing, devices were not so flexible. Mainframe computers were designed for a single purpose; either commercial (financial) processing, or scientific computation. The distinction was visible through all aspects of the computer system, from the processor and representations for numeric values to input-output devices and the characters available.
Once we had those computers, for commercial and for scientific computation, we built languages. COBOL for commercial processing; FORTRAN for scientific processing.
And thus began the cycle of alternating developments: computing platforms and programming languages. The programming languages follow the platforms.
The next advance in hardware was the general-purpose mainframe. The IBM System/360 was designed for both types of computing, and it used COBOL and FORTRAN. But we also continued the cycle of "platform and then language" with the invention of a general-purpose programming language: PL/1.
PL/1 was the intended successor to COBOL and to FORTRAN. It improved the syntax of both languages and was supposed to replace them. It did not. But it was the language we invented after general-purpose hardware, and it fits in the general pattern of advances in platforms alternating with advances in languages.
The next advance was timesharing. This advance in hardware and in system software let people use computers interactively. It was a big change from the older style of scheduled jobs that ran on batches of data.
The language we invented for this platform? It was BASIC. BASIC was designed for interactive use, and also designed to avoid requests of system operators to load disks or tapes. A BASIC program could contain its code and its data, all in one. Such a thing was not possible in earlier languages.
The next advance was minicomputers. The minicomputer revolution (DEC's PDP-8, PDP-11 and other systems from other vendors) used BASIC (adopted from timesharing) and FORTRAN. Once again, a new platform initially used the languages from the previous platform.
We also invented languages for minicomputers. DEC invented FOCAL (a lightweight FORTRAN) and DIBOL (a lightweight COBOL). Neither replaced its corresponding "heavyweight" language, but invent them we did.
The PC revolution followed minicomputers. PCs were small computers that could be purchased and used by individuals. Initially, PCs used BASIC. It was a good choice: small enough to fit into the small computers, and simple enough that individuals could quickly understand it.
The PC revolution invented its own languages: CBASIC (a compiled form of BASIC), dBase (later named "xbase"), and most importantly, spreadsheets. While not a programming language, a spreadsheet is a form of programming. It organizes data and specifies calculations. I count it as a programming platform.
The next computing platform was GUI programming, made possible with both the Apple Macintosh and Microsoft Windows. These "operating environments" (as they were called) changed programming from text-oriented to graphics, and required more powerful hardware -- and software. But the Macintosh first used Pascal, and Windows used C, two languages that were already available.
Later, Microsoft invented Visual Basic and provided Visual C++ (a concoction of C++ and macros to handle the needs of GUI programming), which became the dominant languages of Windows. Apple switched from Pascal to Objective-C, which it enhanced for programming the Mac.
The web was another computing advance, bringing two distinct platforms: the server and the browser. At first, servers used Perl and C (or possibly C++); browsers were without a language and had to use plug-ins such as Flash. We quickly invented Java and (somewhat less quickly) adopted it for servers. We also invented JavaScript, and today all browsers provide JavaScript for web pages.
Mobile computing (phones and tablets) started with Objective-C (Apple) and Java (Android), two languages that were convenient for those devices. Apple later invented Swift, to fix problems with the syntax of Objective-C and to provide a better experience for its users. Google invented Go and made it available for Android development, but it has seen limited adoption.
Looking back, we can see a clear pattern. A new computing platform emerges. At first, it uses existing languages. Shortly after the arrival of the platform, we invent new languages for that platform. Sometimes these languages are adopted, sometimes not. Sometimes a language gains popularity much later than expected, as in the case of BASIC, invented for timesharing but used for minicomputers and PCs.
It is a consistent pattern.
Consistent that is, until we get to cloud computing.
Cloud computing is a new platform, much like the web was a new platform, and PCs were a new platform, and general-purpose mainframes were a new platform. And while each of those platforms saw the development of new languages to take advantage of new features, the cloud computing platform has seen... nothing.
Well, "nothing" is a bit harsh and not quite true.
True to the pattern, cloud computing uses existing languages. Cloud applications can be built in Java, JavaScript, Python, C#, C++, and probably Fortran and COBOL. (And there are probably cloud applications that use these languages.)
And we have invented Node.js, a framework in JavaScript that is useful for cloud computing.
But there is no native language for cloud computing. No language that has been designed specifically for cloud computing. (No language of which I am aware. Perhaps there is, lurking in the dark corners of the internet that I have yet to visit.)
Why no language for the cloud platform? I can think of a few reasons:
First, it may be that our current languages are suitable for the development of cloud applications. Languages such as Java and C# may have the overhead of object-oriented design, but that overhead is minimal with careful design. Languages such as Python and JavaScript are interpreted, but that may not be a problem with the scale of cloud processing. Maybe the pressure to design a new language is low.
Second, it may be that developers, managers, and anyone else connected with projects for cloud applications is too busy learning the platform. Cloud platforms (AWS, Azure, GCP, etc.) are complex beasts, and there is a lot to learn. It is possible that we are still learning about cloud platforms and not ready to develop a cloud-specific language.
Third, it may be too complex to develop a cloud-specific programming language. The complexity may reside in separating cloud operations from programming, and we need to understand the cloud before we can understand its limits and the boundaries for a programming language.
I suspect that we will eventually see one or more programming languages for cloud platforms. The new languages may come from the big cloud providers (Amazon, Microsoft, Google) or smaller providers (Dell, Oracle, IBM) or possibly even someone else. Programming languages from the big providers will be applicable for their respective platforms (of course). A programming language from an independent party may work across all cloud platforms -- or may work on only one or a few.
We will have to wait this one out. But keep yours eyes open. Programming languages designed for cloud applications will offer exciting advances for programming.
The early mainframe computers were single-purpose devices. In the early 21st century, we think of computers as general-purpose devices, handling financial transactions, personal communication, navigation, and games, because our computing devices perform all of those tasks. But in the early days of electronic computing, devices were not so flexible. Mainframe computers were designed for a single purpose; either commercial (financial) processing, or scientific computation. The distinction was visible through all aspects of the computer system, from the processor and representations for numeric values to input-output devices and the characters available.
Once we had those computers, for commercial and for scientific computation, we built languages. COBOL for commercial processing; FORTRAN for scientific processing.
And thus began the cycle of alternating developments: computing platforms and programming languages. The programming languages follow the platforms.
The next advance in hardware was the general-purpose mainframe. The IBM System/360 was designed for both types of computing, and it used COBOL and FORTRAN. But we also continued the cycle of "platform and then language" with the invention of a general-purpose programming language: PL/1.
PL/1 was the intended successor to COBOL and to FORTRAN. It improved the syntax of both languages and was supposed to replace them. It did not. But it was the language we invented after general-purpose hardware, and it fits in the general pattern of advances in platforms alternating with advances in languages.
The next advance was timesharing. This advance in hardware and in system software let people use computers interactively. It was a big change from the older style of scheduled jobs that ran on batches of data.
The language we invented for this platform? It was BASIC. BASIC was designed for interactive use, and also designed to avoid requests of system operators to load disks or tapes. A BASIC program could contain its code and its data, all in one. Such a thing was not possible in earlier languages.
The next advance was minicomputers. The minicomputer revolution (DEC's PDP-8, PDP-11 and other systems from other vendors) used BASIC (adopted from timesharing) and FORTRAN. Once again, a new platform initially used the languages from the previous platform.
We also invented languages for minicomputers. DEC invented FOCAL (a lightweight FORTRAN) and DIBOL (a lightweight COBOL). Neither replaced its corresponding "heavyweight" language, but invent them we did.
The PC revolution followed minicomputers. PCs were small computers that could be purchased and used by individuals. Initially, PCs used BASIC. It was a good choice: small enough to fit into the small computers, and simple enough that individuals could quickly understand it.
The PC revolution invented its own languages: CBASIC (a compiled form of BASIC), dBase (later named "xbase"), and most importantly, spreadsheets. While not a programming language, a spreadsheet is a form of programming. It organizes data and specifies calculations. I count it as a programming platform.
The next computing platform was GUI programming, made possible with both the Apple Macintosh and Microsoft Windows. These "operating environments" (as they were called) changed programming from text-oriented to graphics, and required more powerful hardware -- and software. But the Macintosh first used Pascal, and Windows used C, two languages that were already available.
Later, Microsoft invented Visual Basic and provided Visual C++ (a concoction of C++ and macros to handle the needs of GUI programming), which became the dominant languages of Windows. Apple switched from Pascal to Objective-C, which it enhanced for programming the Mac.
The web was another computing advance, bringing two distinct platforms: the server and the browser. At first, servers used Perl and C (or possibly C++); browsers were without a language and had to use plug-ins such as Flash. We quickly invented Java and (somewhat less quickly) adopted it for servers. We also invented JavaScript, and today all browsers provide JavaScript for web pages.
Mobile computing (phones and tablets) started with Objective-C (Apple) and Java (Android), two languages that were convenient for those devices. Apple later invented Swift, to fix problems with the syntax of Objective-C and to provide a better experience for its users. Google invented Go and made it available for Android development, but it has seen limited adoption.
Looking back, we can see a clear pattern. A new computing platform emerges. At first, it uses existing languages. Shortly after the arrival of the platform, we invent new languages for that platform. Sometimes these languages are adopted, sometimes not. Sometimes a language gains popularity much later than expected, as in the case of BASIC, invented for timesharing but used for minicomputers and PCs.
It is a consistent pattern.
Consistent that is, until we get to cloud computing.
Cloud computing is a new platform, much like the web was a new platform, and PCs were a new platform, and general-purpose mainframes were a new platform. And while each of those platforms saw the development of new languages to take advantage of new features, the cloud computing platform has seen... nothing.
Well, "nothing" is a bit harsh and not quite true.
True to the pattern, cloud computing uses existing languages. Cloud applications can be built in Java, JavaScript, Python, C#, C++, and probably Fortran and COBOL. (And there are probably cloud applications that use these languages.)
And we have invented Node.js, a framework in JavaScript that is useful for cloud computing.
But there is no native language for cloud computing. No language that has been designed specifically for cloud computing. (No language of which I am aware. Perhaps there is, lurking in the dark corners of the internet that I have yet to visit.)
Why no language for the cloud platform? I can think of a few reasons:
First, it may be that our current languages are suitable for the development of cloud applications. Languages such as Java and C# may have the overhead of object-oriented design, but that overhead is minimal with careful design. Languages such as Python and JavaScript are interpreted, but that may not be a problem with the scale of cloud processing. Maybe the pressure to design a new language is low.
Second, it may be that developers, managers, and anyone else connected with projects for cloud applications is too busy learning the platform. Cloud platforms (AWS, Azure, GCP, etc.) are complex beasts, and there is a lot to learn. It is possible that we are still learning about cloud platforms and not ready to develop a cloud-specific language.
Third, it may be too complex to develop a cloud-specific programming language. The complexity may reside in separating cloud operations from programming, and we need to understand the cloud before we can understand its limits and the boundaries for a programming language.
I suspect that we will eventually see one or more programming languages for cloud platforms. The new languages may come from the big cloud providers (Amazon, Microsoft, Google) or smaller providers (Dell, Oracle, IBM) or possibly even someone else. Programming languages from the big providers will be applicable for their respective platforms (of course). A programming language from an independent party may work across all cloud platforms -- or may work on only one or a few.
We will have to wait this one out. But keep yours eyes open. Programming languages designed for cloud applications will offer exciting advances for programming.
Wednesday, February 5, 2020
Windows succeeded because of laser printers
It is easy to survey the realm of computing and see that Windows is dominant (at least on desktop computers, and on lots of laptops in offices). But Windows did not always have dominance; it had to fight its way to the top. Windows had to replace PC-DOS/MS-DOS, it had to fight off OS/2, and it had to beat a number of other (smaller) contenders.
Much has been written about the transition from PC-DOS to Windows and the competition between Windows and OS/2. There is one factor, I think, that has received little attention. This one factor, by itself, may not have made the decision, but it was a factor that favored Windows.
That factor was the laser printer. (Specifically the Hewlett-Packard LaserJet printer.)
Laser printers were desired. They were expensive, which dampened their acceptance, but people wanted them. They were quieter, they were faster, and they produced better quality output. They could provide different typefaces and they could print graphics. And people wanted quiet, fast, high-quality output, especially with graphics.
One could use a laser printer with programs in PC-DOS. It was not always easy, and it was not always possible. PC-DOS provided few services for devices; just enough to send data to a parallel port or a serial port. Applications that wanted to use sophisticated devices (such as laser printers) had to build their own drivers. (The same issue was present for video cards, too.) Thus, when purchasing software, the first question was "Will it support a laser printer?". Some software did, some did not, and some supported laser printers poorly.
Windows supported graphics, video cards, and laser printers from the start. Windows was built around graphics; the first release of Windows was a graphics program. Windows also handled device drivers, allowing a device to have a single driver for all applications. If a program ran in Windows, it could print on all of the printers supported by Windows. Windows was graphics.
In contrast, the first version of OS/2 worked only in text mode. OS/2 users had to wait for version 2.1 to have graphics. Microsoft and IBM (developing OS/2 jointly) focused on multitasking and memory and security.
The difference between Windows and OS/2 was that orientation. Windows was an operating system for a PC; that is, an operating system for a video display board that had a processor and memory and storage attached. OS/2 was an operating system for a minicomputer; very good at multitasking for a use that communicated through a character interface. Even though PCs at the time had video boards, OS/2 pretended that the user was sitting at a terminal.
But people wanted graphics. They wanted graphics because they could see the print-outs from laser printers. They were willing to pay lots of money for laser printers, to impress their co-workers and their bosses.
Windows had graphics. OS/2 did not.
I cannot help but think that laser printers helped Windows win over OS/2.
(I do recognize that other factors contributed to the success of Windows. Those factors include licensing arrangements, marketing, and compatibility with PC-DOS applications. I think laser printers are another -- unrecognized -- factor.)
Today, we casually accept that just about every device works with Windows, and that we can print from any application to any device (laser printer, ink-jet printer, and even PDF file), and that it all works. The computing world of 2020 is very different from the world of 1985.
But maybe we should be looking forward instead of backward. Windows won over OS/2 because it met the demand of the market. It provided graphics on screen and on printouts. It gave people what they wanted.
Today, in 2020, what do people want? And which companies are providing it?
Much has been written about the transition from PC-DOS to Windows and the competition between Windows and OS/2. There is one factor, I think, that has received little attention. This one factor, by itself, may not have made the decision, but it was a factor that favored Windows.
That factor was the laser printer. (Specifically the Hewlett-Packard LaserJet printer.)
Laser printers were desired. They were expensive, which dampened their acceptance, but people wanted them. They were quieter, they were faster, and they produced better quality output. They could provide different typefaces and they could print graphics. And people wanted quiet, fast, high-quality output, especially with graphics.
One could use a laser printer with programs in PC-DOS. It was not always easy, and it was not always possible. PC-DOS provided few services for devices; just enough to send data to a parallel port or a serial port. Applications that wanted to use sophisticated devices (such as laser printers) had to build their own drivers. (The same issue was present for video cards, too.) Thus, when purchasing software, the first question was "Will it support a laser printer?". Some software did, some did not, and some supported laser printers poorly.
Windows supported graphics, video cards, and laser printers from the start. Windows was built around graphics; the first release of Windows was a graphics program. Windows also handled device drivers, allowing a device to have a single driver for all applications. If a program ran in Windows, it could print on all of the printers supported by Windows. Windows was graphics.
In contrast, the first version of OS/2 worked only in text mode. OS/2 users had to wait for version 2.1 to have graphics. Microsoft and IBM (developing OS/2 jointly) focused on multitasking and memory and security.
The difference between Windows and OS/2 was that orientation. Windows was an operating system for a PC; that is, an operating system for a video display board that had a processor and memory and storage attached. OS/2 was an operating system for a minicomputer; very good at multitasking for a use that communicated through a character interface. Even though PCs at the time had video boards, OS/2 pretended that the user was sitting at a terminal.
But people wanted graphics. They wanted graphics because they could see the print-outs from laser printers. They were willing to pay lots of money for laser printers, to impress their co-workers and their bosses.
Windows had graphics. OS/2 did not.
I cannot help but think that laser printers helped Windows win over OS/2.
(I do recognize that other factors contributed to the success of Windows. Those factors include licensing arrangements, marketing, and compatibility with PC-DOS applications. I think laser printers are another -- unrecognized -- factor.)
Today, we casually accept that just about every device works with Windows, and that we can print from any application to any device (laser printer, ink-jet printer, and even PDF file), and that it all works. The computing world of 2020 is very different from the world of 1985.
But maybe we should be looking forward instead of backward. Windows won over OS/2 because it met the demand of the market. It provided graphics on screen and on printouts. It gave people what they wanted.
Today, in 2020, what do people want? And which companies are providing it?
Thursday, January 30, 2020
The cloud revolution is different
The history of computing can be described as a series of revolutions. If we start the age of modern computing with the earliest electronic calculating machines, we have the following upheavals:
Each of these events were revolutionary -- they introduced new forms of computing. And all of these events (except one) saw an expansion of computing, an increase in the applications that could be performed by computers.
The first revolution (standardized computers) was in the days of the IBM 1401. Computers were large, expensive, and designed for specific purposes, but they were also consistent. One IBM 1401 was quite similar to another IBM 1401, ignoring differences in memory and tape drives. The similarity in computers made possible the idea of commonly used applications, and common programming languages such as FORTRAN and COBOL.
The second revolution (a general-purpose computer) was introduced by the IBM System/360. The System/360 was designed to run applications for different domains: scientific, commercial, and government. It built on the ideas of common applications and common programming languages.
The minicomputer revolution (minicomputers, or timesharing) expanded computing with interactive applications. Instead of batch jobs that could be run only when scheduled by operators, timesharing allowed for processing when users wanted it. In fact, timesharing expanded computing from operators to users. (Not everyone was a user, but the set of users was much larger than the set of operators.) Minicomputers were used to create the C language and write the Unix operating system.
The PC revolution brought computing to "the rest of us", or at least those who were willing to spend the thousands of dollars for a small computer. It applications were more interactive than those of timesharing, and more graphical. The "killer" app was the spreadsheet, but word processors, small databases, and project planning software was also popular, and made possible with PCs.
The web revolution introduced communication, and made applications available across a network.
Each of these changes -- revolutions, in my mind -- expanded the universe of computing. The expansions were sometimes competitive, with the "rebels" introducing new applications and the "old guard" attempting to copy the same applications onto the old platform. The expansions were sometimes divisive, with people in the "old" and "new" camps disagreeing on applications, programming languages, and techniques, and even what value the different forms of computing offered. But despite competition and disagreement, each camp had its own ground, and was relatively secure in that area.
There was no fear that minicomputers would replace mainframes. The forms of computing were too different. The efficiencies of the two forms were different. Mainframes excelled at transaction processing. Minicomputers excelled at interaction. Neither crossed into the other's territory.
When PCs arrived, there was no fear that PCs would replace mainframes. PCs would, after some time, replace stand-alone word processing systems and typewriters. But mainframes retained core business applications on big iron. (Minicomputers did die off, being caught between efficient mainframes and interactive PCs.)
When the web arrived, there was no fear that web servers would replace PCs. There was no fear that web applications would replace desktop applications. The web was a new place, with new capabilities. Instead of replacing PCs, the web expanded the capabilities of mainframe systems, providing a user interface into banking and corporate systems. PC applications such as word processing and spreadsheets remained on PCs.
Which brings us to cloud computing.
The cloud revolution is different. The approach with cloud computing, the philosophy, has been to absorb and replace existing applications. We have any number of companies ready to help "move applications to the cloud". There are any number of books, magazines, and online resources that describe tips and tricks for migrating to the cloud. The message is clear: the cloud is the place to be, convert your old applications to the cloud.
This mindset is different from the mindset of previous revolutions. The cloud revolution wants to take over all computing. The cloud revolution is predatory. It is not content with an expansion of computing; it wants to own it all.
I do not know why this revolution is different from previous changes. Why should this change, which is simply another form of computing, push people to behave differently.
At the root, it is people who are behaving differently. Cloud computing is not a sentient being; it has no feelings, no desires, and no motivations. Cloud computing does not want to take over the computing world; it is us, the people in IT, the developers and designers and managers who want cloud computing to take over the world.
I think that this desire may be driven by two factors: economics and control. The economics of cloud computing is better (cheaper) than the economics of PCs, discrete web servers, and even mainframes. But only if the application is designed for the cloud. A classic web application, "lifted and shifted" into the cloud, has the same economics as before.
The other factor is control. I think that people think that they have more control over cloud-based applications than desktop applications or classic web applications. The first is undoubtedly true. Desktop applications, installed on users PCs, are difficult to manage. Each PC has its own operating system, its own hardware, its own set of other applications, any of which can interfere with the application. PCs can fail, they can run out of disk space, and -- worst of all -- let an old version of the application continue to run. The cloud does away with all of that: control moves from the user to the cloud administrator and support becomes much simpler.
So I can understand the desire for people to move applications to the cloud. But I think that people are missing opportunities. By focusing on moving existing applications into the cloud, we do not see the possible new applications, possible only in the cloud. Those opportunities include things such as big data and machine learning, and can include more.
Imagine the PC revolution, with small computers that fit on desktops, and applications limited to copies of existing mainframe applications. The new PCs would be running order entry systems and inventory systems and general ledger. Or at least we would be trying to get them to run those applications, and we would be ignoring the possibilities of word processing and spreadsheets.
Cloud computing is a form of computing, just as mainframes, PCs, and the web are all forms of computing. Each has its strengths (and weaknesses). Don't throw them away for efficiency, or for simpler support.
- Standardized computers for sale (or lease)
- General-purpose mainframes
- Minicomputers
- Personal computers
- Web applications
- Cloud applications
Each of these events were revolutionary -- they introduced new forms of computing. And all of these events (except one) saw an expansion of computing, an increase in the applications that could be performed by computers.
The first revolution (standardized computers) was in the days of the IBM 1401. Computers were large, expensive, and designed for specific purposes, but they were also consistent. One IBM 1401 was quite similar to another IBM 1401, ignoring differences in memory and tape drives. The similarity in computers made possible the idea of commonly used applications, and common programming languages such as FORTRAN and COBOL.
The second revolution (a general-purpose computer) was introduced by the IBM System/360. The System/360 was designed to run applications for different domains: scientific, commercial, and government. It built on the ideas of common applications and common programming languages.
The minicomputer revolution (minicomputers, or timesharing) expanded computing with interactive applications. Instead of batch jobs that could be run only when scheduled by operators, timesharing allowed for processing when users wanted it. In fact, timesharing expanded computing from operators to users. (Not everyone was a user, but the set of users was much larger than the set of operators.) Minicomputers were used to create the C language and write the Unix operating system.
The PC revolution brought computing to "the rest of us", or at least those who were willing to spend the thousands of dollars for a small computer. It applications were more interactive than those of timesharing, and more graphical. The "killer" app was the spreadsheet, but word processors, small databases, and project planning software was also popular, and made possible with PCs.
The web revolution introduced communication, and made applications available across a network.
Each of these changes -- revolutions, in my mind -- expanded the universe of computing. The expansions were sometimes competitive, with the "rebels" introducing new applications and the "old guard" attempting to copy the same applications onto the old platform. The expansions were sometimes divisive, with people in the "old" and "new" camps disagreeing on applications, programming languages, and techniques, and even what value the different forms of computing offered. But despite competition and disagreement, each camp had its own ground, and was relatively secure in that area.
There was no fear that minicomputers would replace mainframes. The forms of computing were too different. The efficiencies of the two forms were different. Mainframes excelled at transaction processing. Minicomputers excelled at interaction. Neither crossed into the other's territory.
When PCs arrived, there was no fear that PCs would replace mainframes. PCs would, after some time, replace stand-alone word processing systems and typewriters. But mainframes retained core business applications on big iron. (Minicomputers did die off, being caught between efficient mainframes and interactive PCs.)
When the web arrived, there was no fear that web servers would replace PCs. There was no fear that web applications would replace desktop applications. The web was a new place, with new capabilities. Instead of replacing PCs, the web expanded the capabilities of mainframe systems, providing a user interface into banking and corporate systems. PC applications such as word processing and spreadsheets remained on PCs.
Which brings us to cloud computing.
The cloud revolution is different. The approach with cloud computing, the philosophy, has been to absorb and replace existing applications. We have any number of companies ready to help "move applications to the cloud". There are any number of books, magazines, and online resources that describe tips and tricks for migrating to the cloud. The message is clear: the cloud is the place to be, convert your old applications to the cloud.
This mindset is different from the mindset of previous revolutions. The cloud revolution wants to take over all computing. The cloud revolution is predatory. It is not content with an expansion of computing; it wants to own it all.
I do not know why this revolution is different from previous changes. Why should this change, which is simply another form of computing, push people to behave differently.
At the root, it is people who are behaving differently. Cloud computing is not a sentient being; it has no feelings, no desires, and no motivations. Cloud computing does not want to take over the computing world; it is us, the people in IT, the developers and designers and managers who want cloud computing to take over the world.
I think that this desire may be driven by two factors: economics and control. The economics of cloud computing is better (cheaper) than the economics of PCs, discrete web servers, and even mainframes. But only if the application is designed for the cloud. A classic web application, "lifted and shifted" into the cloud, has the same economics as before.
The other factor is control. I think that people think that they have more control over cloud-based applications than desktop applications or classic web applications. The first is undoubtedly true. Desktop applications, installed on users PCs, are difficult to manage. Each PC has its own operating system, its own hardware, its own set of other applications, any of which can interfere with the application. PCs can fail, they can run out of disk space, and -- worst of all -- let an old version of the application continue to run. The cloud does away with all of that: control moves from the user to the cloud administrator and support becomes much simpler.
So I can understand the desire for people to move applications to the cloud. But I think that people are missing opportunities. By focusing on moving existing applications into the cloud, we do not see the possible new applications, possible only in the cloud. Those opportunities include things such as big data and machine learning, and can include more.
Imagine the PC revolution, with small computers that fit on desktops, and applications limited to copies of existing mainframe applications. The new PCs would be running order entry systems and inventory systems and general ledger. Or at least we would be trying to get them to run those applications, and we would be ignoring the possibilities of word processing and spreadsheets.
Cloud computing is a form of computing, just as mainframes, PCs, and the web are all forms of computing. Each has its strengths (and weaknesses). Don't throw them away for efficiency, or for simpler support.
Tuesday, January 14, 2020
Another view of mainframes, minicomputers, and PCs
When thinking of the history of computing, one often thinks of hardware by size: mainframes, minicomputers, personal computers, smartphones, and servers. (I suppose one can think of a sixth, "elder days" era of mechanical and electromechanical devices. That's okay; it doesn't affect this post.)
In this classical view, computers are classified by size. Mainframes were large machines that filled rooms, minicomputers were smaller (the size of refrigerators), personal computers could fit on (or under) a desk, and smartphones can fit in your pocket. Servers pose a bit of a problem for this classification system, as servers are about the size of personal computers. They occupy the same "space" as personal computers. What distinguishes a server is that it can be mounted in a rack.
I have been pondering a different classification system. This new view looks beyond the hardware and the peripheral devices, and considers the major concerns of the people operating (or purchasing) computers.
Mainframes were big, but simple. The main concerns were processor speed, memory size, and storage. Storage was usually magnetic tape, but could have been magnetic disk (or drum) or possibly punch cards. Computer systems were rated based on the number of jobs they could run (either at one time or over a single night).
Minicomputers were smaller and still had processors and memory and storage, but the rating system had changed. Instead of the "number of jobs", people were now concerned with the "number of users". Minicomputer had terminals, something that mainframe computers initially lacked. (Mainframes did acquire terminals as purchasers wanted on-line systems, but the first and primary purpose of a mainframe was to run jobs efficiently.) The people who purchased minicomputers wanted to know how many users it could support.
Personal computers saw a different configuration for hardware. Computers kept processors, memory, and storage, but dropped the notion of "terminal". Personal computers were one-per-user, and instead of a terminal (a remote display and keyboard connected usually via a serial line) they used a keyboard attached to the main board and a display attached to a video board. While purchasers were interested in memory, storage, and processor speed, the main concern became video -- screen size, screen resolution, number of colors, and hardware dedicated to video.
Smartphones (and if we want, tablets) are different from personal computers physically, being smaller and portable. But it is not size that is the major issue with smartphones. Nor is the main concern the number of jobs, or the number of terminals, or the size and resolution of the screen. No, the big question in the purchase of a smartphone is battery life. How long does the battery last? How long to recharge? Screen size and weight are also factors, and some people are loyal to brands, so these are also factors. For smartphones, people think about quite different qualities than those for laptop computers.
Servers are different from all of these categories because people who buy servers want to run web sites, or (now more often) virtual machines. Purchasers want to complete requests (either on the physical server or on virtual machines on the physical server). They don't care about video -- that's for the requesting client to worry about. Thus, while servers are about the same size as personal computers, people think about them in very different ways. (In my classification system, servers are closer to mainframes than personal computers.)
What do these different concerns tell us? Well, it is interesting to see how concerns changed over time. Our interest in computers is not constant, we focus on different aspects of different classes of hardware.
Secondly, we should note that our interest in computers is not in the hardware or the software, but instead what the computer can do for us. We care more about how we use computers than how computers look or run.
Also, notice that how we store computers has changed over time, from large mainframes that are guarded in secure rooms to devices that are casually slipped into a pocket. (Much of this is a result of advances in technology.)
Now let's switch from hardware to software. Like hardware, software has changed over time, and our views of software have changed over time. Hardware definitely preceded software; indeed, the first computers were hard-wired to perform calculations and there was no software as we think of it.
Software for mainframes was designed for business purposes (accounting, inventory management, billing, etc.) and military purposes (ballistics tables were among the first applications). Software for minicomputers was designed for data analysis, which could leverage the interactivity of minicomputers with their terminals. The "killer app" for personal computers was the spreadsheet (Visicalc at first, then Lotus 1-2-3, and later Excel). For servers, databases and the web server; for smartphones, maps and GPS systems.
Our use of computers (hardware and software) has changed over time. Our expectations have changed. Initial uses of computers were "obvious": calculations better handled by machine. Later uses were not necessarily obvious but perhaps even more compelling -- including games such as "Space Invaders" and "Angry Birds".
This trend, I think, may tell us something about computing in the future. We may be more interested in computers (and applications) that serve us, that do things for us, than computers that don't. Or, we may be interested in computers that meet specific needs better than the computers we have today.
But that may not be a surprise.
Personal computers saw a different configuration for hardware. Computers kept processors, memory, and storage, but dropped the notion of "terminal". Personal computers were one-per-user, and instead of a terminal (a remote display and keyboard connected usually via a serial line) they used a keyboard attached to the main board and a display attached to a video board. While purchasers were interested in memory, storage, and processor speed, the main concern became video -- screen size, screen resolution, number of colors, and hardware dedicated to video.
Smartphones (and if we want, tablets) are different from personal computers physically, being smaller and portable. But it is not size that is the major issue with smartphones. Nor is the main concern the number of jobs, or the number of terminals, or the size and resolution of the screen. No, the big question in the purchase of a smartphone is battery life. How long does the battery last? How long to recharge? Screen size and weight are also factors, and some people are loyal to brands, so these are also factors. For smartphones, people think about quite different qualities than those for laptop computers.
Servers are different from all of these categories because people who buy servers want to run web sites, or (now more often) virtual machines. Purchasers want to complete requests (either on the physical server or on virtual machines on the physical server). They don't care about video -- that's for the requesting client to worry about. Thus, while servers are about the same size as personal computers, people think about them in very different ways. (In my classification system, servers are closer to mainframes than personal computers.)
What do these different concerns tell us? Well, it is interesting to see how concerns changed over time. Our interest in computers is not constant, we focus on different aspects of different classes of hardware.
Secondly, we should note that our interest in computers is not in the hardware or the software, but instead what the computer can do for us. We care more about how we use computers than how computers look or run.
Also, notice that how we store computers has changed over time, from large mainframes that are guarded in secure rooms to devices that are casually slipped into a pocket. (Much of this is a result of advances in technology.)
Now let's switch from hardware to software. Like hardware, software has changed over time, and our views of software have changed over time. Hardware definitely preceded software; indeed, the first computers were hard-wired to perform calculations and there was no software as we think of it.
Software for mainframes was designed for business purposes (accounting, inventory management, billing, etc.) and military purposes (ballistics tables were among the first applications). Software for minicomputers was designed for data analysis, which could leverage the interactivity of minicomputers with their terminals. The "killer app" for personal computers was the spreadsheet (Visicalc at first, then Lotus 1-2-3, and later Excel). For servers, databases and the web server; for smartphones, maps and GPS systems.
Our use of computers (hardware and software) has changed over time. Our expectations have changed. Initial uses of computers were "obvious": calculations better handled by machine. Later uses were not necessarily obvious but perhaps even more compelling -- including games such as "Space Invaders" and "Angry Birds".
This trend, I think, may tell us something about computing in the future. We may be more interested in computers (and applications) that serve us, that do things for us, than computers that don't. Or, we may be interested in computers that meet specific needs better than the computers we have today.
But that may not be a surprise.
Wednesday, January 8, 2020
Predictions for 2020
I have some predictions for 2020. They may (or may not) be correct.
Hardware: Virtual desktops and the cloud
I expect 2020 to be the "year of the cloud", in a sense. While cloud computing is popular, I see the phrase "the cloud" becoming more popular in the upcoming year, even more popular than cloud computing itself. How can this be? How can the term be used more than the actual thing?
I expect that lots of people with use the term "the cloud" to mean online (or web-based) computing, even in situations that do not use actual, honest-to-goodness cloud computing.
We will see an interest in virtual desktops, specifically for Windows. Today's PCs are real PCs with operating systems and applications. In 2020, look for a push (by Microsoft) for virtual desktops - instances of Windows hosted on servers and accessed by a browser or by Microsoft's Remote Desktop program.
Most folks will call this "Windows in the cloud" or "cloud computing". The former is a more accurate term, but the second is not too wrong. Virtual desktops will be hosted on servers, with some applications built for cloud computing and others not. Microsoft's Office products (Word, Excel, and Outlook) will all reside in the cloud as try cloud applications. Applications from other vendors will run on virtual desktops but won't be true cloud applications.
Virtual Windows desktops offer several advantages to Microsoft: they are paid as subscriptions, so Microsoft gets a steady cash flow. Second, Microsoft can move customers to the latest version Windows 10. Third, and perhaps most importantly, Apple is not prepared to offer a matching service. (Apple remains in the world of "fat desktops" which run the operating system and the applications. They cannot move that experience to virtual workstations hosted in the cloud.)
Cloud-based Windows is not for everyone. Some will be unwilling to move to virtual desktops, and some will be unable to move. Anyone who insists on running an older version of Windows will remain in "fat desktop" land. And anyone who cannot install their software (perhaps because they have mislaid the install CD-ROM) will stay with their current desktop computers.
Those who do move to virtual desktops will be able to use simpler, lightweight computers (perhaps Chromebooks, perhaps computers with "Windows in S mode") that run little more than the software necessary to access the virtual desktop. The physical desktop computer will be a "terminal" to the virtual desktop. The benefits for those users will be cheaper hardware, more reliable desktops, invisible backups, versioning of data files, and the ability to shift work from one lightweight desktop "terminal" to another.
Programming languages: More Python, less Perl
Perl was perhaps the first programming language to be designated a "scripting language". (It won the designation, although other languages such as Awk and Csh predate it.)
But Perl has fallen on hard times. Developers have left Perl for Python, and the "Perl 6" effort, delayed and poorly advertised, has now re-branded itself as "Raku" to allow Perl 5 to continue without the cloud of eventual shutdown. The change comes late, and I fear that many have abandoned Perl in favor of Python.
Ruby is in a similar situation, with Python appealing to many developers and interest in Ruby is waning.
Python is winning the "scripting race". Many schools teach it, and many experienced developers recommend it as a first language to learn. (I'm in that group.) It has good support with libraries, tools, and documentation. Microsoft supports it in "Visual Studio Code" and in "Visual Studio".
I expect Python to gain in popularity, and Perl and Ruby to decline.
Programming languages: Smaller languages
I expect to see a shift from object-oriented languages (Java, C#, and C++) to smaller scripting languages (Python and perhaps Ruby).
Object-oriented languages are effective for large, complex systems. They were just what we needed for the large, complex applications that ran on PCs and servers -- before cloud computing. With cloud computing, we build systems (large or small) out of services, and we strive to make services small. (A large application can built of many small services.)
Java, C#, and C++ can be used to build small services, but often Python and other languages can be a better fit. The "big" object-oriented languages carry a lot of baggage to make object-oriented programming work; the smaller languages carry less.
Two possible contenders for building services may be Swift and Visual Basic. Swift is relatively new, and still undergoing changes. Visual Basic has evolved through several generations and Microsoft may create a smaller, lighter version for services. (These are guesses; I have no indication from Apple or Microsoft that such projects are underway or even under consideration.)
Programming languages: Safer languages
The languages Rust and Go are getting a lot of attention. Both are compiled languages, letting one build fast and efficient applications.
Rust and Go may challenge C and C++ as the premiere languages for high-performance systems. C and C++ have had a good run, from the 1970s to today. But more and more, safety in programs is becoming important. The design of languages such as Rust and Go give them an advantage over C and C++.
C and C++ will stay with us, of course. Many large-scale and popular projects are written in them. I don't expect those projects to convert to Rust, Go, or any other language.
I do expect new projects to consider Rust and Go as candidate languages. I also expect projects to convert existing systems from their current technology (which could be COBOL, Fortran, or even C and C++) to think about Rust and Go.
Containers: Nice for deployment, little else
Containers were quite popular in the past year, and I expect that they will remain popular. They are convenient ways of deploying (or sharing with others) a complete application, all ready to go.
Containers offer no benefits beyond that, however, and they are helpful only to the people who must deploy applications. Therefore, containers, like virtual machines, will quietly move to the realm of sysadmins.
Development: better tech than ever
For the year 2020, the picture for development looks rather nice. We have capable languages (and lots of them); stable networks, servers, and operating systems; powerful tools for testing, deployment, and monitoring; and excellent tools for communication and collaboration. Problems in development will not be technical in nature -- which means that the challenges we face will be with people and interactions.
For developers (and project managers), I expect to see interest in collaboration tools. That includes the traditional tools such as version control, item tracking, and messaging tools such as Slack. We might see interest in new tools that have not been introduced as yet.
Summary
I see a bright future for development. We have good tools and good practices. The challenges will be people-oriented, not technology-oriented. Let's enjoy this year!
Hardware: Virtual desktops and the cloud
I expect 2020 to be the "year of the cloud", in a sense. While cloud computing is popular, I see the phrase "the cloud" becoming more popular in the upcoming year, even more popular than cloud computing itself. How can this be? How can the term be used more than the actual thing?
I expect that lots of people with use the term "the cloud" to mean online (or web-based) computing, even in situations that do not use actual, honest-to-goodness cloud computing.
We will see an interest in virtual desktops, specifically for Windows. Today's PCs are real PCs with operating systems and applications. In 2020, look for a push (by Microsoft) for virtual desktops - instances of Windows hosted on servers and accessed by a browser or by Microsoft's Remote Desktop program.
Most folks will call this "Windows in the cloud" or "cloud computing". The former is a more accurate term, but the second is not too wrong. Virtual desktops will be hosted on servers, with some applications built for cloud computing and others not. Microsoft's Office products (Word, Excel, and Outlook) will all reside in the cloud as try cloud applications. Applications from other vendors will run on virtual desktops but won't be true cloud applications.
Virtual Windows desktops offer several advantages to Microsoft: they are paid as subscriptions, so Microsoft gets a steady cash flow. Second, Microsoft can move customers to the latest version Windows 10. Third, and perhaps most importantly, Apple is not prepared to offer a matching service. (Apple remains in the world of "fat desktops" which run the operating system and the applications. They cannot move that experience to virtual workstations hosted in the cloud.)
Cloud-based Windows is not for everyone. Some will be unwilling to move to virtual desktops, and some will be unable to move. Anyone who insists on running an older version of Windows will remain in "fat desktop" land. And anyone who cannot install their software (perhaps because they have mislaid the install CD-ROM) will stay with their current desktop computers.
Those who do move to virtual desktops will be able to use simpler, lightweight computers (perhaps Chromebooks, perhaps computers with "Windows in S mode") that run little more than the software necessary to access the virtual desktop. The physical desktop computer will be a "terminal" to the virtual desktop. The benefits for those users will be cheaper hardware, more reliable desktops, invisible backups, versioning of data files, and the ability to shift work from one lightweight desktop "terminal" to another.
Programming languages: More Python, less Perl
Perl was perhaps the first programming language to be designated a "scripting language". (It won the designation, although other languages such as Awk and Csh predate it.)
But Perl has fallen on hard times. Developers have left Perl for Python, and the "Perl 6" effort, delayed and poorly advertised, has now re-branded itself as "Raku" to allow Perl 5 to continue without the cloud of eventual shutdown. The change comes late, and I fear that many have abandoned Perl in favor of Python.
Ruby is in a similar situation, with Python appealing to many developers and interest in Ruby is waning.
Python is winning the "scripting race". Many schools teach it, and many experienced developers recommend it as a first language to learn. (I'm in that group.) It has good support with libraries, tools, and documentation. Microsoft supports it in "Visual Studio Code" and in "Visual Studio".
I expect Python to gain in popularity, and Perl and Ruby to decline.
Programming languages: Smaller languages
I expect to see a shift from object-oriented languages (Java, C#, and C++) to smaller scripting languages (Python and perhaps Ruby).
Object-oriented languages are effective for large, complex systems. They were just what we needed for the large, complex applications that ran on PCs and servers -- before cloud computing. With cloud computing, we build systems (large or small) out of services, and we strive to make services small. (A large application can built of many small services.)
Java, C#, and C++ can be used to build small services, but often Python and other languages can be a better fit. The "big" object-oriented languages carry a lot of baggage to make object-oriented programming work; the smaller languages carry less.
Two possible contenders for building services may be Swift and Visual Basic. Swift is relatively new, and still undergoing changes. Visual Basic has evolved through several generations and Microsoft may create a smaller, lighter version for services. (These are guesses; I have no indication from Apple or Microsoft that such projects are underway or even under consideration.)
Programming languages: Safer languages
The languages Rust and Go are getting a lot of attention. Both are compiled languages, letting one build fast and efficient applications.
Rust and Go may challenge C and C++ as the premiere languages for high-performance systems. C and C++ have had a good run, from the 1970s to today. But more and more, safety in programs is becoming important. The design of languages such as Rust and Go give them an advantage over C and C++.
C and C++ will stay with us, of course. Many large-scale and popular projects are written in them. I don't expect those projects to convert to Rust, Go, or any other language.
I do expect new projects to consider Rust and Go as candidate languages. I also expect projects to convert existing systems from their current technology (which could be COBOL, Fortran, or even C and C++) to think about Rust and Go.
Containers: Nice for deployment, little else
Containers were quite popular in the past year, and I expect that they will remain popular. They are convenient ways of deploying (or sharing with others) a complete application, all ready to go.
Containers offer no benefits beyond that, however, and they are helpful only to the people who must deploy applications. Therefore, containers, like virtual machines, will quietly move to the realm of sysadmins.
Development: better tech than ever
For the year 2020, the picture for development looks rather nice. We have capable languages (and lots of them); stable networks, servers, and operating systems; powerful tools for testing, deployment, and monitoring; and excellent tools for communication and collaboration. Problems in development will not be technical in nature -- which means that the challenges we face will be with people and interactions.
For developers (and project managers), I expect to see interest in collaboration tools. That includes the traditional tools such as version control, item tracking, and messaging tools such as Slack. We might see interest in new tools that have not been introduced as yet.
Summary
I see a bright future for development. We have good tools and good practices. The challenges will be people-oriented, not technology-oriented. Let's enjoy this year!
Tuesday, October 1, 2019
A World without Windows
Could Microsoft discontinue Windows? Is it possible that the future will see no Windows PCs?
Windows has been the key product for Microsoft. Or it was, in the 1990s and 2000s. Back then, Microsoft's was to provide everything, and have all Microsoft products connect. Windows was the platform. The Office suite was the set of common tools. Exchange provided directory and authentication services; Windows used it to log in users and Outlook used it to route e-mail and store organization calendars. SQL Server was the database, and also used by other tools such as Visual Studio and TFS.
That strategy worked in the days of networked computers. It doesn't work today, and Microsoft has changed its strategy. They moved away from the "Windows and everything for every user" strategy. They now offer cloud services and cloud-based applications. Microsoft is happy to sell virtual Windows servers from the cloud. They are also happy to sell virtual Linux servers.
Windows is an expensive effort. It requires a lot of design, development, testing, and support. Microsoft gets revenue from Windows licenses. Is the revenue from Windows worth the expense? Today, the answer is most likely "yes". But five years from now? Ten years from now? Will the revenue cover the expense?
I think of Windows as two similar but distinct products. The first is the Windows we know: an operating system that runs on PCs. This version of Windows not only hosts applications but also handles all of the hardware of the PC: memory, video, sound, USB ports, clocks and timers, keyboard, mouse, ... everything. Windows has a hardware abstraction layer with drivers for specific devices. The upper layers of Windows (memory management, task switching, processes, and application programs) doesn't worry much about the lower-levels. Upper-level functions use the hardware abstraction layer as an API to lower-level functions.
That set of lower-level functions is complex, and expensive to develop and maintain. (The upper-level functions are expensive, too.)
There is another Windows product, one that isn't used on PCs. Microsoft offers Windows in the cloud -- virtual servers and workstations. This Windows product runs the same applications as the "real" Windows that runs on PCs, but it has a very different lower level.
The lower-level functions for "real" Windows (the one on your PC) must contain code for thousands of devices, and perhaps more. There are many models of PCs, with different chip sets for audio, USB, video, and all of the other hardware bits of a computer. Microsoft does a pretty good job at making Windows work with current and old PCs. (I recently installed Windows 10 on an old laptop that initially had Windows Vista, and everything works except for the wi-fi connection.)
The story is different for the "virtual" Windows (the one that runs in the cloud). That version of Windows has the same upper-level functions, but the logic below the hardware abstract layer is just about non-existent. Data to and from devices doesn't go to the server; instead it gets routed to the client computer that is using the virtual computer. This second computer has the actual hardware -- the keyboard, the mouse, USB devices, audio devices, etc. Getting data to those devices is the responsibility of the client PC operating system.
If the virtual PC is running Windows and the client PC is running Windows, then Windows must talk to all of those devices. If not the virtual Windows PC, then the client Windows PC. With a Windows client, Windows must talk to the devices.
But is it necessary for the client to be Windows?
I think Microsoft is asking itself this very question.
Suppose that Microsoft were to drop the client part and focus on the virtual part of that configuration. Suppose Microsoft simply let the PC version of Windows die. What would happen?
For starters, Microsoft would lose the revenue from Windows licenses for "real" PCs. But it would also lose the expense of developing drivers and low-level functions. Keep in mind that there are lots of devices, and Microsoft has been very good at supporting them.
(Microsoft does a very good job of support, but they do not support every device that was ever made. Please don't complain to me because Microsoft doesn't support your ancient video card, or unusual disk drive, or odd-ball USB device.)
Why would Microsoft do that? Why would Microsoft walk away from all of that revenue? The answer is simple economics: Does the PC version of Windows pay for itself? Does the revenue from PC Windows cover the expense of hardware management? If it does, then there is an argument to keep providing Windows. If the revenue does not cover the expense... then the argument is to abandon that market.
It may be that Microsoft will keep support for real PCs, but a limited subset of hardware. (Perhaps only Microsoft's Surface tablets and laptops, or a limited subset of certified computers.) Such a world would be very different from today's land of PCs running Windows. Linux may step in and provide the client base for access to virtual PCs (be those virtual PCs Linux or Windows). Vendors such as Dell and Lenovo may develop their own operating systems, possibly based on Linux, and tuned to their hardware.
If Microsoft can successfully migrate a large percentage of application users (users of Office, Project, SQL Server, etc.) to their cloud-based virtual Windows desktops, then we might just see that new world.
Windows has been the key product for Microsoft. Or it was, in the 1990s and 2000s. Back then, Microsoft's was to provide everything, and have all Microsoft products connect. Windows was the platform. The Office suite was the set of common tools. Exchange provided directory and authentication services; Windows used it to log in users and Outlook used it to route e-mail and store organization calendars. SQL Server was the database, and also used by other tools such as Visual Studio and TFS.
That strategy worked in the days of networked computers. It doesn't work today, and Microsoft has changed its strategy. They moved away from the "Windows and everything for every user" strategy. They now offer cloud services and cloud-based applications. Microsoft is happy to sell virtual Windows servers from the cloud. They are also happy to sell virtual Linux servers.
Windows is an expensive effort. It requires a lot of design, development, testing, and support. Microsoft gets revenue from Windows licenses. Is the revenue from Windows worth the expense? Today, the answer is most likely "yes". But five years from now? Ten years from now? Will the revenue cover the expense?
I think of Windows as two similar but distinct products. The first is the Windows we know: an operating system that runs on PCs. This version of Windows not only hosts applications but also handles all of the hardware of the PC: memory, video, sound, USB ports, clocks and timers, keyboard, mouse, ... everything. Windows has a hardware abstraction layer with drivers for specific devices. The upper layers of Windows (memory management, task switching, processes, and application programs) doesn't worry much about the lower-levels. Upper-level functions use the hardware abstraction layer as an API to lower-level functions.
That set of lower-level functions is complex, and expensive to develop and maintain. (The upper-level functions are expensive, too.)
There is another Windows product, one that isn't used on PCs. Microsoft offers Windows in the cloud -- virtual servers and workstations. This Windows product runs the same applications as the "real" Windows that runs on PCs, but it has a very different lower level.
The lower-level functions for "real" Windows (the one on your PC) must contain code for thousands of devices, and perhaps more. There are many models of PCs, with different chip sets for audio, USB, video, and all of the other hardware bits of a computer. Microsoft does a pretty good job at making Windows work with current and old PCs. (I recently installed Windows 10 on an old laptop that initially had Windows Vista, and everything works except for the wi-fi connection.)
The story is different for the "virtual" Windows (the one that runs in the cloud). That version of Windows has the same upper-level functions, but the logic below the hardware abstract layer is just about non-existent. Data to and from devices doesn't go to the server; instead it gets routed to the client computer that is using the virtual computer. This second computer has the actual hardware -- the keyboard, the mouse, USB devices, audio devices, etc. Getting data to those devices is the responsibility of the client PC operating system.
If the virtual PC is running Windows and the client PC is running Windows, then Windows must talk to all of those devices. If not the virtual Windows PC, then the client Windows PC. With a Windows client, Windows must talk to the devices.
But is it necessary for the client to be Windows?
I think Microsoft is asking itself this very question.
Suppose that Microsoft were to drop the client part and focus on the virtual part of that configuration. Suppose Microsoft simply let the PC version of Windows die. What would happen?
For starters, Microsoft would lose the revenue from Windows licenses for "real" PCs. But it would also lose the expense of developing drivers and low-level functions. Keep in mind that there are lots of devices, and Microsoft has been very good at supporting them.
(Microsoft does a very good job of support, but they do not support every device that was ever made. Please don't complain to me because Microsoft doesn't support your ancient video card, or unusual disk drive, or odd-ball USB device.)
Why would Microsoft do that? Why would Microsoft walk away from all of that revenue? The answer is simple economics: Does the PC version of Windows pay for itself? Does the revenue from PC Windows cover the expense of hardware management? If it does, then there is an argument to keep providing Windows. If the revenue does not cover the expense... then the argument is to abandon that market.
It may be that Microsoft will keep support for real PCs, but a limited subset of hardware. (Perhaps only Microsoft's Surface tablets and laptops, or a limited subset of certified computers.) Such a world would be very different from today's land of PCs running Windows. Linux may step in and provide the client base for access to virtual PCs (be those virtual PCs Linux or Windows). Vendors such as Dell and Lenovo may develop their own operating systems, possibly based on Linux, and tuned to their hardware.
If Microsoft can successfully migrate a large percentage of application users (users of Office, Project, SQL Server, etc.) to their cloud-based virtual Windows desktops, then we might just see that new world.
Subscribe to:
Posts (Atom)