What Are Managed Services?
"Managed services" is an offering of many businesses that provide Internet services. In the past couple of years, it's a term I've used to describe what I offer in my Blackfly Solutions Drupal and CiviCRM hosting business.
You may not know whether you would want such a thing, since it's a very badly named thing. This post will try and give a reason for why managed services is a thing at all, how it can be a good thing, and why it may be what you want.
Here's the short version: managed services exist to fill the gap between what machine automation can reasonably provide and what people actually want.
In a subsequent post, I'll explain how containers can be a useful tool for delivering managed services.
What Do You Mean by Services?
A "service" in the "managed services" context is the consumer-oriented one, i.e. something a consumer wants that they get from a service provider. For example: "hosting for my website", or "updating and hosting my website" or "providing me a tool to create and edit my website", or "email for my organization", or "a dedicated server". In other words a whole range of needs or wants that imply an ongoing service. Any particular "managed services" product doesn't usually tell you how that service should be delivered, and it doesn't necessarily do what you might think it does based on the label.
The word "service" can also mean a narrower machine-oriented one. UNIX/Linux has a concept of "service" that refers to a collection of processes that are available to "serve" certain types of machine requests. For example, at a machine level, a web browser makes an "http" request to a web server machine, and that request is "served" by an "httpd" service.
And finally, a "service" can also mean a collection of machine services that provide part or all of a consumer-oriented "service". For example, a modern "web server" typically runs a collection of machine services to deliver a particular website. These are sometimes called "applications" or "apps", though that word is horribly overused and I avoid it.
Conclusion: what you want as a "consumer service" is generally a mix of machine and application "services" held together with some human customer service and the ability to create/read/update and/or delete your "service".
The Creative Tension
If you are a modern internet-based business that needs to "service" a capital investment, then your goal is to automate as much as possible and to minimize the cost of your customer service, so you generally want to define your "service offerings" is in a way that lets you do that.
Of course, most people don't like to stay in boxes, and although businesses are always trying to tell consumers what they want, and sometimes succeed, many people have a great skill in pursuing what it is they actually want.
So there's a permanent, evolving tension between the needs of the consumer and what service provider businesses offer.
That's one way of describing the problem that 'managed services' addresses.
In the rest of this post, I'll describe the problem in more detail for a "website" service.
Automated Services That Work, and That Don't
Email is a good example of a service that can be almost fully automated. When Google first rolled out free gmail, there was no 'user support' - it managed to set it up fully automated without needing to actually answer the phone or answer emails about the service. Of course, there were still lots of people involved in delivering the service. And because you don't pay for it, it wasn't unreasonable to not provide any in-person support. And now that they do provide more premium and complicated services, Google does provide support from actual people.
On the other hand, websites are a good example of a service that has been around a long time (in Internet time) and still require humans to help develop them. Some versions of a 'website', like your facebook page, or blogger site (where you're reading this) are fully automated. But no one has managed to figure out a fully automated generic website service that works for any significant range of website needs. Not that it hasn't been tried (remember "Geocities"?), and continues to be tried (Squarespace, Wix, etc.).
The challenge comes from consumer desires for 'customization'. Lots of website systems provide tools for customization, but none of them have managed to capture enough of the scope of what people want - a requirement that is in constant flux.
Or perhaps, how we present ourselves to each other is too interesting and valuable to fully automate.
Filling in the Gap
My first job in this business was in 1996, building a site for the Canadian Friends Service Committee. I used a text editor to build some simple html pages and then uploaded them using FTP. It was functional and plain, suitable for the client and the audience and the time.
A year later, my second job was to get hired (in fact, by the service provider that was hosting that site), to provide user support. At that time, most of that support was helping people with their email, which (several years before gmail) was delivered with a client program like "Eudora" that had to get configured to talk to our mail provider, and helping people setup or trouble shoot their internet connection.
Because I had done some computer programming, I was then tapped to deliver some client projects. My first project was a form and a PERL script that allowed the Ontario Women's Directorate to collect information via an online survey.
By then, many organizations saw the value of having a website, and a new industry of "website development" grew up. Fairly quickly, it was seen that "content" could be separated from "presentation" and "functions", allowing clients to update their content without knowing html - and thus the CMS (content management system) acronym was born. Over time, the CMS was extended to managing parts of the presentation and functionality as well (e.g menus, themes, etc.).
Initially, these CMS tools were installed, configured and managed by the service providers. Sometimes they were even used exclusively by the service provider - i.e. they were just tools internal to the service provider that delivered the same service as before, but now with more consistency, and cheaper.
On the other hand, DIY customers and larger organizations with in-house expertise wanted both the extra power of the low-level access to the tools, as well as the savings of not having to pay a service provider to do things.
The Control Panel
About 15 years ago, the 'control panel' solution emerged as a new tool for 'managed services' solutions. In this case, the service provider would sell a 'server' (a dedicated or virtualized server with a control panel installed) to a 'power user' that would get a powerful web interface that provided fairly low level server functions via some simple button clicking.
This allowed the hosting companies, as a service provider, to offload the tricky negotiation bits to resellers (design agencies or individual running boutique hosting services) who would interface with the end user customer. In this way, the resellers would take responsibility for "managing" the customer services and just pay the hosting companies for the automation bit.
Larger companies and enterprising DIY customers were also interested in this solution, and as the price for control panel hosting came down, it lead to the current situation of a large number of websites that are managed via a web interface with no particular server expertise required.
In theory, this was a great solution, particularly for the big providers who had managed to do what the corporation was originally designed for: invest capital for maximizing return and minimizing risk.
The Managed Services Challenge
The control panel solution isn't terrible, but two problems stand out: security and maintenance.
Specifically, a control panel managed website starts out great, but gets progressively harder to keep up and is easy to not keep secure.
Partly, that's a design problem - the automation is focused on initial setup to promote sales, and there's less incentive to design tools to keep those sites fast, secure and robust.
But it's also a general problem of software: it's easier to set it up than to keep it up to date and secure. The key issue is that once the software is setup, the software and it's configuration and customization get mixed together in a way such that updating it is a thorny problem that prevents automation.
Containers
And now we get to "containers as a tool for solving the software security and maintenance issue".
"Containers" are a collection of low level server technologies that solve the problem of 'process isolation'.
The general version of this problem goes back to the beginning of computing: how to share computing resources in a 'good' way. One of the core tools that UNIX provided was the use of separate users and processes. That separation was a good start, but proved inadequate for many of the more complicated versions of the problem. As an example - a web server running multiple sites would typically all run with the same UNIX user id ("nobody", "apache", or "www-data" are the most common), so one website would be vulnerable to badly behaving other sites. Even when different sites are run as different users, that risk still exists because the separation of processes via users is limited.
"Containers" can be thought of as a super-set of this solution, by isolating the process in its own virtual operating system.
Containers for Managed Services
Containers are a useful tool for rethinking managed services for two reasons: they provide isolation of the environment in which individual machine services run so that security updates are less risky, and it also provides tools for a discipline of configuration.
In a subsequent post, I'll explore how my Drupal and CiviCRM managed services make use of containers for security, reliability and automation.