I was thinking the other day about the journey from paper to Google Docs, and how it’s similar to the journey from hardware to containers. How did we get from Point A to Point B? The road is long and winding, but please stick with me. For the purpose of this analogy, forget about FTP, SSH, and remote access; just think back to how people shared copies of development environments, aka drafts. It all started off pretty tedious.
Remember paper? You wrote on it. You could physically pass it or even mail it to other people. In fact, the only way to share it was by mailing it. Different people could make changes to the document, but they would need physical access to do so. It was tough to know who had done what, and anything written on the paper was more or less permanent. Oh, you could erase the marks on the paper, but the paper was never really the same (especially depending on what kind of writing instrument was used).
When you think of it, server hardware of old is a lot like paper. If you needed a server—usually for a dedicated application—you had it shipped to you. You’d need to load an OS, the application, and maybe some management and security software. You’d have to have to make firmware updates, and chances were good that you needed physical access to the system to do all of this stuff. We called this process “burn in.” Multiple people could make changes to the system, but it was tough to know who had done what. And, while the system could be wiped for a different purpose down the line, the server was never really the same. More important, it had to be shipped to its new home, like a letter.
We’ve come a long way, baby—thank goodness!
But, to continue the comparison, if old server hardware is a lot like paper, then virtual machines can be likened to the progeny of paper: early word processors. I’m not going all the way back to things like WordStar (which, not for nothing, predates me by quite a while). I’m talking the early days of Microsoft Word.
Remember how we used to share documents back then? Mostly over email, as attachments (and all those “lovely” Outlook PST files). Say you sent a proposal draft as a Word doc to five people over email. Those five people would click on five different attachments and save the documents to their own hard drives. They would make five different sets of revisions and send five (if you’re lucky) different emails, including the attachments, back to you via email.
These five people hopefully renamed their revised documents using a standard convention, but they might not have renamed it at all. You’d then have the tedious task of finding and opening all the emails and related attachments, then integrating all the changes into the original doc. Heaven forbid you should get a follow-up email with the subject line “IGNORE THAT LAST DOC—USE THIS ONE INSTEAD!” And double or triple the time it would take to do all of this if you didn’t understand or agree with a change and had to seek out the collaborator by phone or email, or by walking over to his or her cubicle.
If you have any experience with virtual machines, you likely see where I am going with this comparison. The way we worked with virtual machines was a lot like the way we used to develop, share, and revise early Word docs. We had to pass VMs back and forth to make changes, and it was often difficult to determine how a VM got modified and who modified it. You could track changes to a degree, but it was a tedious affair. Configuration management like CFEngine, Puppet, Chef, and Ansible helped for the pieces they configured, but there was always this nagging feeling with a VM—“what has been changed outside of configuration management?” Passing VMs around as a development environment was quite tedious, so we usually didn’t bother. Most of the time, a single person would build the development environment, then put it into a shared environment. Then, we would just stop tracking changes and keep messing with it, year after year. Remember when everyone was more scared to touch the dev environment than prod, because nobody knew how to rebuild it? The proverbial pet problem.
Fast-forward to today’s Google Docs (and, to be fair, Office 365, which itself has come a long, long way). With these cloud-based systems, it is very easy to build a document, share it, collaborate on it, and discuss any changes in real time. It’s also very easy to track changes, down to the most minute punctuation change, and to see who did what when.
It’s the same way with containers. Containers start with a base image, which is quite similar to a gold build with bare metal and VMs. Then changes are added by different people. These changes are almost always blueprinted with a Dockerfile, scripting, or some form of configuration management. We use similar tools and processes to what we did with bare metal and VMs. This is only natural, because the contents of a container image are pretty much identical to what we have always used to collaborate: files and packages. Furthermore, these blueprinted changes are tracked with source control, like Git.
Once a container is built, other developers can see the container image it was built on and all the layers on top. Further, experts from different areas—security, performance, business logic, database admin, and so on—can effectively collaborate on and contribute to a container simultaneously and in real time, with everyone’s changes easily tracked and versioned. This is true collaboration and it has strikingly similar to the transparency to working with Google Docs.
Of course, any time you are dealing with more than one container and multiple people making changes to containers, things can get out of hand. That’s where technology like Kubernetes orchestration makes containers even more useful. (Now, if we could only get the equivalent of Kubernetes for Google Docs, to orchestrate my increasingly “data rich” Google Drive and tame the typical torrent of changes that come when multiple people with multiple opinions about what’s right are making multiple changes to a document.)
I could probably take this comparison even further—serverless is like texting, maybe?—but I think it makes sense to put containers in the Google Docs context for any company thinking about using or expanding their use of the containers. The Google-Docs-vs.-early-Word analogy might be especially useful for developers trying to sell the use of containers up the chain. (You might get some glazed expressions if you go all the way back to servers and paper or even mainframes and stone tablets, as I have done in conversation). The main point is that, in business cases, document writing, and system configuration (dare I say development?), each generation of technology has made it easier and easier to collaborate on complex and nuanced changes.
This article is published as part of the IDG Contributor Network. Want to Join?
