Systematic approach If, like me, you were a computer science graduate student who cut your teeth on Berkeley Unix – with the first open-source implementation of TCP/IP – you know section 8 as the cryptic section of system maintenance commands. of the Unix User’s Manual.
It was obvious to me that this concluding section deserved a closer look because the introduction warned, “The information in this section is not of great interest to most users.” Judging by my fondness for research problems over the years, reading Section 8 has proven to be a very good investment.
But before you get to Section 8, you first learned about the rest of Unix, where you discovered how exciting it is to be able to create new Internet applications. Anyone interested in how targeted investments in open source software, coupled with affordable hardware, can drive innovation should study the role of Berkeley Software Distribution (BSD) in the success of the Internet.
It’s easy to assume that the Internet as we know it today was inevitable, but by the time BSD Unix arrived, it wasn’t at all clear that incumbent telecommunications carriers might be disrupted. We have repeatedly commented on the power of APIs, but the impact of the Socket API (Section 2) on innovation beyond the Internet cannot be overstated. With this stable fixed point in the architecture, a thousand flowers have bloomed… and we have fortunately far exceeded the telecom vision of ISDN-B.
Section 8 was the second half of the story. In addition to describing how to stop and start a system, he defined the process for managing long-running daemon processes, the Unix equivalent of today’s microservices. If you were responsible for configuring and managing system services on your service’s server, which had superuser privileges, you should not only know how to program Unix, but also understand the ins and outs of using of Unix.
As a graduate student, the lessons I learned from being responsible for sendmail(8) on a live multi-user system were immeasurable. Every mistake instantly sent the faculty down the hall in search of the idiot responsible. (In my defense, this was at a time when email addresses contained % and ! operators in addition to @, and their priority was not well defined.)
The lessons I learned as a sendmail maintainer on a live multi-user system were immeasurable. Every mistake instantly sent the faculty down the hall in search of the idiot responsible.
BSD also gave me an early lesson in the power of having many eyeballs watching for security vulnerabilities. Examination of the source code for sendmail, for example, revealed a backdoor, through which one could telnet to port 25, type the magic command “wizard”, and create a root shell. So I made my counterparts at Berkeley and other universities aware of this vulnerability by doing just that.
Others probably did too, but it was a different time and the lesson didn’t happen initially. With the convenience of debugging and a naive sense of community security, the backdoor remained open by default in sendmail until the Morris worm used it as one of its attack vectors a few years later. late.
Gaining this kind of hands-on experience is obviously valuable if your plan is to become a system administrator, but I’ve long experienced that an opportunity to manage systems that provide services to real users is a big deal breaker. systems research, as well as fertile ground for platform innovations.
My doctoral thesis, born out of frustration with sendmail, turned out to be about naming and addressing; later, the actual experience of running a CDN on PlanetLab spawned a string of systems articles (as Vivek Pai and I reported in a 2007 CACM article); and more recently, our experience operating an edge cloud has led to an appreciation of the state management problem inherent in DevOps. And my experience is far from unique: Many cloud tools that we take for granted today – Kubernetes being a prime example – started out as someone’s answer to an operational problem.
All of this leads me to believe that an open operations platform (as documented in Section 8) is just as important as an open programming platform (as documented in Section 2) to democratize innovation.
Would BSD Unix have had the same impact in the 1980s and 1990s if the university computer center had taken it over rather than the computer science department leaving its graduate students to take over the operations problem? We can ask a similar question today. The value of being able to build new cloud applications is abundantly clear, but is there also a benefit of having open access to the tools used to manage and operate the cloud (rather than delegating the latter to cloud providers) ?
For me, the answer is clearly yes. It boils down to the virtuous circle of solutions made possible by platforms on the one hand, and platforms reshaped with user experience on the other. Stable platforms with well-defined APIs surely allow a thousand flowers to flourish, but the disruptive refactoring of these platforms is what leads to the next cycle of innovation.
Stable platforms with well-defined APIs allow a thousand flowers to flourish, but ultimately the disruptive refactoring of these platforms is what leads to the next cycle of innovation
Software-defined networking is a famous example of disruptive refactoring, but it only works if we have sophisticated enough tools to assemble all the components into a cohesive and manageable system. Orchestration and lifecycle management have become major operational issues because (a) many smaller parts need to be put together and (b) these individual parts are expected to change more frequently. These are essential elements of what we could call the Cloud OS.
Granted, not everyone who writes programs – whether they run on a personal server or in the cloud – needs to know how to run that program 24/7, but from the perspective To allow more people to participate in the creation of new systems, the operating platform must remain open and accessible to anyone who wishes to invest time in it.
Fortunately, there are a plethora of open source components today that can be used to operate and manage the lifecycle of a cloud. We’ve documented a roadmap for using them in Edge Cloud Operations: A Systems Approach (a sort of “Section 8” for the Cloud). We hope there are still a few people who are just crazy enough to give it a try. ®