Cloudism and futurism: An operating system for the future
Because the future is in the cloud(s)
A few years ago, I attended MS Build invited by Microsoft (and wrote about it quite extensively here). I guess that, in a way, I saw the light. But the light I saw was that of a cloud-centric future with a side serving of artificial intelligence.
These are the notes in a set of slides for a talk I gave in a later MS event that same year. Since they were just buried there, I thought that I could just as well re-publish them in article form. They might be a bit outdated, but conceptually they are still hot.
And a that cloud centric future is going to be a multifaceted future, as above. A picture with many facets, because that picture represents a ballsy statement by Amazon, but also because the future is going to be composed of many different vendors and players, as well as many different ways of running your programs, many different technologies to ship and deploy loosely connected pieces of code. These facets, precisely, might be a part of what I consider a problem.
There is blue sky among the clouds, and we academics are known for our blue-sky way
of thinking, mainly about the future. So that is what I’m going to write next, starting with what precisely I have perceived as a problem. And let us learn from art, because art always comes before (computer) science.
Present ≈ Past
Futurism is an artistic movement that tries to reflect the motifs, speed and dynamism of modern life, as well as the passage of time. I find it appropriate for this topic, because it was a way of saying that painting was made so far did not make sense in the modern world, and also a way of investigating new ways of communication that combined different expressions: design, painting and typography.
Just like cloud combines different levels of virtualization, data sources, data processors and data sinks.
The work above represent kinda-futurist designs in some dresses. Not incredibly breaking, but at least it’s a way of introducing the future into past dress patterns and designs. You can find works by Liubov Popova, more cubist than futurist, in the Thyssen Bornemisza collection, right here in Madrid, along with other Russian futurist, including Rozanova, as well as male painters of the mainstream Italian futurist branch. In this present, and in the cloud, what we have are things looking modern, but that are largely a
small change from old, data-center and metal based, methodologies.
And the problem is that, for the time being, lots of people just keep doing their old thing in new places. If you had a MEAN or XAMP stack in a shared host or a VPS, you now have it on the cloud. Maybe add monitoring and some other thing on the side. You find containers, and what you do is to put a whole stack inside a container. And this sentence by William Gibson is always true:
The future is here, only it’s not evenly distributed.
I talked to some IT center guys some time ago, couple of months (that was 4 years ago, though), telling them about the cloud. They said something to the tune of “Yes, we studied it, it’s not for us”. There is something called “Cloud Center” in some city in my country. Do you think they use cloud software like OpenStack? Do you know what they do to scale? They get a phone call to do
it.
Present and future, both fragmented and divided
While the spatial fragmentation and the use of collages are a sample of its experimental endeavour, the brilliant colors come from the traditions of her native land. On the other hand, the objects are the usual ones in cubist still lives, like the bottle and the cup, which are at the center of the composition, intermingled with different ad collages as well as a big A crossed by an arrow, placer on the left and top corner. (Description of the painting in the museum catalogue, translation mine)
Futurism started with a technique called divisionism, which divided colors in patches that interacted to create an impression; the the collage was used as a way to compose the picture.
This divisionism is what you find right now when you want to develop for the cloud using AI (or, for that matter, almost anything at all). There are myriad APIs that allow you to tap different computing units at different virtualization levels. Most SDKs and APIs are then fragmented, in such a way that most people use, if anything, a small percentage of the computing services every platform has to offer, not to mention higher-level services.
There are so many services, that in fact right now there’s a joke making the social networks about the totally fake, but plausible, Infinidash AWS product.
It’s also fragmented along vendor lines. You can either develop for Amazon lambda or for Azure functions or for OpenWhisk. The situation is similar in the GPU arena, where they don’t even have the same names for the same things, or even with FPGAs.
Unfortunately, this is also reflected in the user groups, or Stackoverflow tags, themselves: Containers here, cloud SDKs there, but they are basically working with the same stuff and tapping the same resources.
One of the consequences of this divisionism is the religious nature of most tools; by religious or devout we mean non-agnostic. You can work with a single vendor, and that happens at any level of the cloud stack. People commit to anything depending on the ROI, but agnosticism is always better from that point of view. It’s not worth the while to be religious if you know that you are going to have to divest in 4 or 5 years.
But it’s dejà vu all over again: Desktop computing took off when there was a single platform, the PC+MSDos, and later Windows and Linux, which you could target your applications for. Before, you could commit yourself to an Olivetti, or Burroughs, or whatever platform, but what was the point? It could be gone, or unsupported, in a few years. When the religious division of the early 80s gave way to the agnosticism of the PC, it was the end of the IBMs and EDS and the emergence of Microsoft and Lotus, and those agnostic companies that could write to a whole set of computers, all of them with a common abstraction layer over them. Their investment (the one made by vendors, as well as the one made by consumers) was returned.
The problem now, and in the cloud environment, is that most agnostic tools fall very short of covering the full range of functionalities, and it even fails in basic stuff like IAM authentication or specification of containers. There are some steps in this particular direction like the Open Container Initiative but that’s it. Terraform also is agnostic, but it still lacks the functionality to work with all the possible functionalities. So either you have a very specialized, vendor provided, tool, that you can use for mostly everything (or thin layers over it like Terraform), or you have some general purpose tools which will need plugins, custom development or both, like Ansible or Vagrant (which is eventually only used in very limited, development environments).
To make matters wors, there’s a ever-growing gap between academia and industry
futurismo.orgLots of references to Italian futuriste, or women artists, in this article. Find out more about Rosa Rosà at this article, who was also a science-fiction writer, one of the first to introduce the gender identity issue in a novel.
WRT to the gap, it’s not only that academia does not give a shit about this new environment, it’s that even if it did, I’m not sure we’re ready for the onslaught of new concepts, APIs, and methodologies. New stuff is created yearly and you need 10 years to change courses, at least in Spain. There are new recommendations by professional societies (like ACM and IEEE) with even a longer period. Current methodologies, which (usually and unfortunately) concentrate in a single tool (for instance, they make all assignments and examples work in AWS, or Azure), are not ready for this.
But, additionally, common languages used in academia and desktop or server operating systems are not ready for this asynchronous, concurrent, AI-asisted, cloud world. That is why companies are investing in people to help them adapt their systems to the new era. People who haven’t, and can’t even, have acquired that experience in academia.
The problem with closed source
Closed source, proprietary software, in general, is bad in the cloud or any context. For the end user, it’s difficult to manage.
But it also keeps innovation within the companies, and does not allow an environment of coopetition which will push the whole technology forward. Non-standard APIs are also a problem, even more so than a closed API. And it happens across the table, everywhere. Data stores, message queues, security parameters, they are private and thus there is no way to test or install in-house, debug, and all the problems that closed source brings.
There is also a big gap between what is offered by OpenStack or other open source players and what you get for big players. That is a problem for academia, and increases the gap above.
Little by little, we’re getting there
There are many initiatives that attempt to give a holistic, unified view of the cloud, which is, after all, where we nowadays run our computer. We saw a little bit of that in MS Build, and more after it, but it’s still in its infancy, akin to when you were programming in the 80s and 90s and needed to work with interrupts and port addresses when you wanted to make something sound or, for that matter, with a printer or anything that did not come with the computer.
First operating systems and compilers were made with that: they used heuristics and engineering to create code that was the best for every combination of hardware, using FPU when available, and so on. You could recompile for a slightly different configuration, but that’s it. Today you don’t need to fire a different program with an ARM Cortex or an Intel i7: the fragmented reality of the underlying hardware is embedded, as knowledge, in the operating system and toolchains.
In the cloud or its fringes, we have Isomorphic javascript, for instance. We also have serverless libraries that work with any framework. Terraform is able to work with many different providers, and Kubernetes works acrosss organizations.
But even if we have some low-level or mid-level patterns, we still lack a common way of creating whole buildings from scratch. Draft, which was released by Microsoft yesterday
Remember I wrote this four years ago, in 2017
, is an amazing piece of work. It allows someone to work easily with Kubernetes, just by defining something like a “buildpack”, which is a way to insert different tool and languages inside containers and connect them. This is interesting from the point of view of abstraction.
As we fly into the future, we find ways of adding layers of abstraction to our tools that bridge that gap, that veritable chasm that exists between what we have learned, or whatever we have experience with, and the tools we have to use.
We need an operating system for the cloud: a FuturOS
This is what it’s said about “The Cyclist” in its description:
Despite its renowned importance in the history of Russian art, this scene by Goncharova is something of an anomaly among Russian Futurist paintings given its depiction of the action of motion — an approach usually only found in Italian Futurist works. This work layers the Western focus on motion with a distinctively Russian focus on language. Fragments of words have been captured on the canvas indicating the window advertisements of the shops the cyclist passes — silk, thread, hats, and more. However, the cyclist seems to ignore these expensive wares as he pedals doggedly on; he is even directed back from whence he came by a large hand pointing behind him. His difficult journey on cobbled streets reverberates through his body, and the painting becomes a commentary on the state of the working condition rather than a celebration of modern locomotion. While the political aspects of the painting are similar to some of Goncharova’s earlier works, its frame-by-frame depiction of movement sets it apart. It exists in-between; neither Italian Futurism nor strictly Russian, it seems to capture the conflict between the two movements.
The nice and amazing thing about this picture, which for me is the best in the Futurist movement, since it bridges the Italian and Russian brand of it, is that it shows the discovery of a new pictorial language that is able to capture the motion, the speed, the information overload of the city, as well as its social aspects.
In the computer realm, languages and operating systems are needed to abstract the underlying functionalities, allowing us to create applications easily, but also to understand the system as a whole, and not as a sum of parts. That operating system, or the compilers working with it, will have to include machine learning and artificial intelligence to self-reconfigure for the best and cheapest combination of cloud services available on call, be it hybrid, public or private. Nowadays you don’t care where the rendering of a textured, multifaceted polygon is taking place, because it’s the compiler that takes care of generating the correct code. Why should you care about your function running in a container, a PaaS, or using ready-made software as a service?
The Russian futurism proposing a new visual and linguistic vocabulary for modern experience. This FuturOS together with a cloud toolchain and a language that reflects the underlying system will be, of course, free software, but will allow us, like this painting (that is, for me, the summit of futurism), to use it to full capabilities. Also bridge the gap with academia. At least a little bit.
And to the extent that bridging is, at all, possible. Which right now I’m not sure it is.
