This is the first in a three-part series on Chrome OS usage in Enterprises. Please find the links for parts two and three below:
Chrome OS in Enterprise – Why companies are pursuing it – Part 2
Up until a year ago, I’d never touched a Chromebook. Never had a reason to. Not that I was anti-Google, as I had long been a Chrome browser and YouTube user; I just didn’t see a need for it in my computing world. I had a company-issued Dell Precision running Windows 10 with plenty of horsepower, a powerful lab server at home, a tablet for media consumption in my downtime, and my mobile phone for the spaces in-between. My needs were met because believe it or not, even though I’ve been working in datacenters since I was 17, I don’t actually geek-out on tech when I go home. To me that’s time better spent with my family or pursuing outdoor hobbies like golf or fishing.
However, this time last year I took on a new role which caused me to stray outside of my comfort zone of Windows OS, Active Directory, Exchange, Office 365, and Azure. I was asked to investigate something interesting happening in the client computing space, where commercial (non-Education) customers were beginning to use Chrome OS within their Enterprises. As a lifelong Microsoft guy my first thought was pretty much, “Lol ok. This is niche but what the heck, I’ll learn a lot in the process”. I started by investigating Chromebook usage in education, and how Google essentially took over that market in ~5 years. I wanted to know what about Google’s model made the devices so appealing to school districts (I was a school district IT admin myself shortly after graduating college, but this was ~2006 so before the advent of Chrome OS).
I spoke with a few colleagues of mine who’ve worked with Chromebooks at school districts and also perused various technical forums and social media. You’d be surprised how many IT problems are solved by simply asking questions on forums. This is especially true in the education space where resources are constrained, IT Admins are more likely to be a “Jack of all trades”, or even a teacher serving the role of Systems Administrator. Below are just a few popular destinations for admins working with Chromebooks:
- Google Support Community Forums
- Chrome OS Subreddit
- Sysadmin Subreddit
I followed that up by speaking with a handful of commercial customers who were beginning to perform pilots of Chrome OS in their environments (Note: Google refers to commercial non-EDU as “Enterprise”).
What I discovered actually surprised me and had my inner monologue now saying, “Wow, it’s happening again. This is like 2011…”
Flashback to 2011: During this period of my career, I was spending most of my time working Exchange Server support and consulting escalations. I soon began working early migrations to the newly minted Office 365. This was the early days of “Hybrid” coexistence where on-premises and cloud Exchange Organizations were first possible. In January 2012 I attended the “Microsoft Certified Master: Exchange Server” training in Redmond Washington. At the end of the training we spent two days learning about Microsoft’s brave new world of Exchange Online, Office 365, and Azure Active Directory. We learned how to migrate mailboxes and setup hybrid environments for companies looking for an extended period of coexistence. We also learned “The Sales Pitch” for Microsoft’s cloud vision, including where they saw the industry going over the next decade. I remember hearing many of my colleagues sharing opinions about what they were hearing; “Why would a company host their mailboxes in the cloud?”, or “Maybe this will be useful for some percentage of mailboxes or for some smaller customers, but I don’t see this catching on for larger enterprises”, and “I just don’t see companies hosting their directory in the cloud.” During the initial years, many in the industry felt similarly. There would often be complaints at Ignite (formerly called TechEd) that all of the content focused on Microsoft Cloud and not on-premises technologies. Those were all valid concerns at the time, as Microsoft often suffers from thinking too far ahead into the future and assuming their entire customer base is ready to move at their pace.
However, Microsoft was ultimately correct. Here we sit in 2019 (~8 years later), and many companies must justify why they aren’t running their mailboxes and directory in the cloud, at least in some hybrid state. The default stance of many IT Decision Makers has become, “Prove to me why your mailbox needs to be on-prem.” The TCO (Total Cost of Ownership) savings of a Cloud model are just too great to be ignored. It’s hard to argue against the benefits of giving your users a 50 GB mailbox and increasing their productivity while removing the burden on your IT staff to back up the content and maintain the servers. Not to mention the increased High Availability, integrated compliance features, sophisticated management, and swath of advanced security solutions in Microsoft’s cloud. It has indeed been a paradigm shift, made possible through technical innovation and driven by significant cost/productivity benefits. The main takeaway here was that customers naturally gravitated towards technology which increased their productivity, increased their security, and lowered their costs.
I wrote all of that to say, what I saw in Chrome OS made me believe their vision of a “Cloud OS” was the vision of the future for commercial client operating systems. I believe that in 5-7 years the commercial client world will be significantly disrupted by Cloud Operating Systems in the same way the Messaging/Directory world was disrupted by Office 365 and Azure AD. Now before I lose you thinking I’m just spreading FUD or selling snake oil, let me explain some technical characteristics which make Chrome OS what it is.
Chrome OS – A different architecture entirely
When greeted with Google’s claims of “No Anti-Virus Needed” many are quick to say, “Oh let me guess, it’s because it runs Linux right? I’ve heard that one before”. Well the appropriate response is, “Yes it’s based on a Linux kernel, but that’s not the real reason you don’t need Anti-Virus.”
Chrome OS employs a very different architecture than what we’re familiar with in the Windows world. In a Windows OS, say for example you have multiple users logged into the OS with different profiles. The only thing separating those user’s data are a series of file and registry permissions. Also, if one user installs an application onto the system, that application is then available for use by the other users. That application then has its hooks into the Windows registry and access to system resources such as memory and CPU. This is the W32 application model that’s powered most of the client computing world for the past quarter-century. While certainly an important innovation in human history, it’s not been without its drawbacks. Memory leaks, Blue Screens of Death (BSoD), and granting applications more authority within an OS than they ever should’ve been are just some of the pain points of the W32 world.
You might ask, why should an application have the ability to bug check/bluescreen the machine? Why should a piece of malware have the ability to compromise the entire system? Why should one user even be allowed to view another user’s data, even if they’re an administrator (especially in the modern world of data privacy laws)? These characteristics have long been pain points for many end users and administrators. They often must resort to advanced policies, third-party applications, or services to solve these problems.
However, the Chrome OS behaves very differently. Each user login effectively behaves like a separate containerized instance of the OS itself. This is actually an oversimplification, but if I walked through every line of code on Chromium.org I’d lose your interest pretty fast. If one user logs into Chrome OS and downloads the Facebook Android app, that Facebook application is not available for any other user on the system. They would instead have to download the Facebook Android app themselves in order to use it. The effect here is that each user partition is independently encrypted and isolated from other user partitions as well as the OS system partition itself. There are zero pre-installed applications (aside from what Google themselves add to the OS, such as shortcuts to Docs, Sheets, Keep, Slides, etc.) nor are there any shared files between user accounts. In fact, user partitions are separately encrypted using the TPM chip on every Chrome OS device and not even an administer can access all user data on the device. As an example, I could log into a Chrome OS device which has been enrolled into Google’s Enterprise Admin console for work purposes during the day, but then log into the device with my personal Google Account in the evening (Administrators of enrolled devices must allow personal logins). In that scenario, the administrator has zero insight to anything the user does while logged into their personal account. Each user profile really does behave like an entirely separate instance of the OS (again, an oversimplification for educational purposes). While this does not make the user profiles purely stateless (although Guest Sessions can accomplish this), it does make them behave like their own siloed instance of an OS.
Separate from the user partitions is the system (or root) partition. Think of this as where the core system services of the OS live, which serve to interface with the HW and health of the system. There are actually two instances of the root partition, as illustrated below:
One instance is the “Active” while the other is the “Passive”. Understand that these are my terms, you’re welcome to read Chromium.org if you want the nitty gritty details. This “Passive” partition offers a few important benefits. When the system is being updated, the passive partition receives the update, allowing the user to continue working uninterrupted. The update would not take effect until after the next system reboot, depending on severity (a critical security update may request an immediate reboot).
Another key difference with Chrome OS devices is that all Apps, Drivers, Firmware, and BIOS are handled via the same update stream as the OS. This is the Chrome OS Auto-Update mechanism. Think of this as being akin to all drivers, firmware, and BIOS on a Windows device being pushed via Microsoft Update. This is a much more simplistic, seamless, and overall secure model than what Windows currently has today. If your goal is to ensure your device is secure from the hardware up to the application layer, a singular updating mechanism is the best means of accomplishing that. You wouldn’t require multiple agents present on the device to manage updates for each of these components; each taking up precious system resources and slowing down your user experience. You merely get a single notification about updates being ready for your system and a prompt to reboot when you’re ready to finalize them. After which, the passive root partition becomes the active partition and you’re met with a system update experience that took a fraction of your time (and frustration). Should a day-zero attack occur, your Chrome OS devices will likely be the first to be patched from top to bottom in a fraction of the time. In the Windows world, many third-party solutions can aid you in managing these types of application/driver/firmware/BIOS updates, but Google has decided to solve this natively within the OS.
Sandboxing – On a Chromebook, each web page and application runs in a restricted environment called a “sandbox.” If the Chromebook is directed to an infected page, it can’t affect the other tabs or apps on the computer, or anything else on the machine. The threat is contained.
Verified Boot – Even if malware manages to escape the sandbox, the Chromebook is still protected. Every time the Chromebook starts up, it does a self-check called “Verified Boot.” If it detects that the system has been tampered with or corrupted in any way, typically it will repair itself without any effort, taking the Chromebook back to an operating system that’s as good as new.
For an additional reference, check-out this Chrome OS Security Guide video.
How does this model remove the need for Anti-Virus you might ask? Well the cumulative benefits of the above architecture allow Google to back up their claim that you don’t need Anti-Virus on the system. If a process or user session is compromised, or misbehaves in any way, it’s merely terminated. In addition, it’s never given enough permissions to do any real damage outside of its “Sandbox”. Lastly, if malware were somehow able to modify system files, the system’s firmware would detect this and trigger a boot to a clean image.
Of course, the last scenario would result in a loss of locally stored user data, or trigger what Google calls a “powerwash”. On a Windows machine this would cause user frustration, at least in what I’ll call the traditional Windows usage model. This would be where users are primarily storing their data locally and relying upon locally installed applications (Office Suite, AutoCAD, Acrobat, Photoshop, etc.). However, this becomes less severe if the users are relying more on the cloud. Examples of this would be:
- File storage in Google Drive, OneDrive, SharePoint, Box.com, etc.
- Browser-based business applications (Salesforce, Tableau, SAP, Oracle, etc.)
- Browser-based productivity applications (Outlook on the Web, online versions of Word/Excel/PowerPoint/Teams etc., Gmail, Docs/Sheets/Slides/Hangouts etc.)
- VDI and Application virtualization for access to legacy W32 applications (Citrix, Horizon, etc.)
Of course, there’s nothing about Windows 10 that would prevent users from adopting such a “Cloud Usage Model”; the term Unified Workspace has been used to describe this usage model. All of the above technologies could be used on Windows 7/8/10 operating systems. In fact, Microsoft has been slowly shifting towards this model over the past decade. Integrating OneDrive into File Explorer, encouraging Microsoft Account usage for Windows sign-in (Connected Accounts), and investing heavily in browser improvements (Edge/Chromium Edge). However, Microsoft’s problem is the underlying Windows technology they’ve been relying on for decades was never originally designed for this cloud usage model. Microsoft has needed to re-engineer or what some would call “de-feature” Windows to try and optimize for this model, with Windows RT and S Mode being prime examples. Neither of which fared well in the market.
Comparatively, Chrome OS was designed with the cloud in mind; carrying with it no baggage of past expectations or backwards compatibility. Google was able to take the best elements of other operating systems (Linux, Mac OS, iOS, Android, thin-clients) and create something quite unique. It’s an OS experience that never set out to beat Windows at their own game, but rather provide the best experience for those pursuing this cloud usage model. It really is a true “Cloud OS” and is something I expect many companies to take notice of, but not so much for what its features allow you to do, but rather what its features allow you to go without doing because it’s simply no longer technologically relevant.
In the second part of this series I’ll detail where commercial customers are realizing the TCO savings of the Cloud OS model.