Insights from our 2017 State of Application Delivery survey.

You can tell a lot about organizations use and adoption of technologies by how and where they want to deploy their app services. You may recall that app services is a big umbrella under which a variety of technologies actually lives. Load balancing (scale), acceleration (performance), and web app firewall (security) are all “app services”. That’s because they live, topologically, between a user (client) and an app (server). Requests and responses must flow through an app service. What that app service does is variable. It may modify it, strip things out or add things in. It may do nothing at all but keep an eye on it. But it does something that’s considered important to the success and security of that app, or else it wouldn’t be deployed.

So when we ask respondents to our State of Application Delivery surveys where and in what form factor they prefer to deploy those app services, it tells us something about where they’re deploying applications and with what kind of architecture they may be working.

For example, this year (2017), we added “Containers” to the list of form factors for which respondents could select a preference. They could choose hardware, software (virtual appliances), containers, or the always popular “D. All of the above” option. For containers, we were pleasantly surprised to discover an existing preference that’s striking considering the age and maturity of the technology.

In general, containers were preferred by 5% of respondents. When we filter that through the lens of “cloud-first” organizations, that jumps to 8%. Remember, that’s for app services, not apps. Which kind of implies that apps are already deployed in containers (or are about to be) and respondents want to deploy the appropriate app services in containers along with them.

More surprising, perhaps, was that the largest role to express that preference was respondents in infrastructure and network roles. Twenty-nine percent (29%) of those who want containers self-identify as “infrastructure” or “network” professionals.

who wants containers soad17As noted in an earlier blog about containers and usage habits, containers appears poised to explode on-premises, at least, given their broad applicability across application types and architectures. Rather than being relegated to supporting “emerging” application architectures like microservices, containers appear to be flourishing as a mechanism to gain portability and scalability of legacy (often called ‘monolithic’) applications as well.

This, in itself, should not be surprising given the “legacy” use-case promoted by virtualization. One of more appealing aspects of virtualization (a category into which containers can be loosely included) is its ability to support aging apps within more modern network and infrastructure architectures. Containers are able to do this, as well, and are rapidly gaining the automation and orchestration supportive structure necessary to enable the same capabilities it took virtualization years to realize.

While there’s certainly something to the argument that containers are better at enabling the real-time migration to and from off-premise cloud environments we’ve always been promised, it is more likely that the innate capabilities of the orchestration and automation frameworks surrounding containers and enabling efficient, on-demand scale are behind containers rapid rise across all IT concerns. Scale, today, is of major importance to not only IT but business, too. With digital transformation efforts – internal and external facing – driving new applications and services into production, it is inevitable that scale and security will rise to the fore of requirements for business success.

Containers, for all their rough edges (and make no mistake, these fledgling systems certainly have them just as any tech in its infancy), are an appealing alternative to existing options. With a native affinity for API-driven integration with the various other systems and services in the data center necessary to scale applications, containers are indicative of a new mindset within the data center that’s driven by a focus on scale from the get-go, rather than as a bolt-on after-thought “if we need it.”

It’s not just the ability to scale quickly and automatically; it’s the built-in assumption that you will and the support innate to the orchestration and scheduling systems that’s likely to propel containers higher and higher in the “preference for” category across all IT roles.

Containers are rising. They’re not in ascendancy yet, but I don’t think I’d be crazy (or alone) to predict that it won’t be long before they will be.