Containers are super-hot these days. In mainstream enterprise, many infrastructure teams are starting to look at supporting them officially (side note: the developers in those same enterprise have probably been using them unofficially for a year). This creates new operational and technological challenges for the networking team in the data center. Further, the vendor/technology landscape associated with container networking is dynamic and fragmented (Flannel, Weave, Docker, Contiv, Calico, Photon, OVN, just to name a few).
On one hand, you can think of containers as just another (potential) MAC address/IP address on the network – no big deal. On the other hand, the operational changes required to support containers in production are pretty substantial. As we describe in newly published research:
Container deployments are typically driven by application and architecture teams that desire infrastructure invisibility — they want to develop without having to understand the constraints of the physical infrastructure underneath. These teams want their application to work the same way throughout the development stages. Containers, by default, can be run on a laptop and require no changes to the underlying network.
So, the network just doesn’t matter in a world of containers, right? Wrong…and you don’t want to end up like this (image via https://www.pinterest.com/marineinsight/maritime-disasters/).
Further, to dispel some of the early container networking misconceptions, containers do not require SDN (perhaps it is time to update the 7 SDN Misconceptions). That said, the time to start preparing is now and we just published research on the topic:
Take (Limited) Action to Prepare Your Data Center Network for Containers, http://www.gartner.com/document/3268217
Summary: The hype surrounding Docker has led many enterprises to look at container technologies within their data centers. To date, the hype far outweighs production deployments, but it’s time for network architects to prepare for the unique challenges brought on by containers.
In the research, we introduce containers to the network team, including the why (and when) they matter, and describe the key operational and technological differences (i.e., portability, lifecycle/permanence, scale and automation to name a few) they present to network teams. We go on to describe specific actions to take (and not to take), and when. For example, here are just two of many recommendations from the research.
- Create isolated nonproduction network segments in the data center network, so that application and development teams can extend containers beyond their workstations.
- Eliminate manual network provisioning in containerized environments.
Fun Times in Vendorland
We also dive into the current and (anticipated) future vendor landscape around container networking. Right now, it is extremely dynamic and vendors are cranking up the vendorspeak, while touting their highly differentiated architecture to solve container challenges. Not to mention that basic things like network mgmt/visibility are essentially non-existent in the space right now. Fun times ahead.
Read Complimentary Relevant Research
Top Strategic Predictions for 2018 and Beyond: Pace Yourself, for Sanity's Sake
Technology-based innovation arrives faster than most organizations can keep up with. Before one innovation is implemented, two others...
View Relevant Webinars
Channel Trends 2017: Three Activities to Focus on
Widespread digital transformation and shifting buyer expectations are placing demands on technology provider channel leaders to enhance...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.