Was 2017 the Year of Containers & Kubernetes?

With 2017 behind us, I found myself doing some reflecting on the tech industry. In particular I found myself looking back at some of the trends I saw at Tech Field Day 14 & 15, which were about 6 months apart. As it turns out, it was interesting to see some small signs of change in May, and then see additional and more prevalent changes in September.

CONTAINERS & THE DEVOPS MOVEMENT

There is no doubt that the use of containers continued to grow in 2017. We saw more and more announcements around products, as well as what seemed to be a larger adoption in use. Some recent buzz in the industry was created when Red Hat announced its intent to acquire CoreOS. Although we saw this announcement in 2018, it builds on the direction from 2017.

Back in May 2017 at Tech Field Day 14 in Boston, the topic of containers came up quite frequently. If memory serves, I think it was mentioned at least once by each presenting company. In some cases it was a matter of “we are looking at implementing support for containers”. In other situations though, we saw companies fully embrace containers.

It also seems that whenever the term containers comes up, we are seeing it paired with DevOps. They appear to be a natural fit together with how much can be done programmatically to spin containers up or down. However controlling the running state of containers is just one aspect of their use.

CONTAINERS STILL NEED STORAGE

NetApp presented at TFD14 in Boston. You can read my original write up about the event in my blog post from that time. What really stood out to a lot of the delegates was that although we were talking about using storage and policies, NetApp’s ONTAP software was only given a brief mention. Instead, we were heavily focused on programmatically assigning storage capacity, and performance. The beauty with this solution is that storage admins can still define SLAs and whatnot for developers to use. But developers can also build these requests into their work flows.

I’m not going to rehash everything I have previously said. What I do look back at is how serious NetApp was about this venture. Their Trident project is still going strong, and clearly it is still a high-priority commitment for NetApp.

CONTAINERS STLIL NEED NETWORKING

At Tech Field Day 15 in Silicon Valley, we saw Cisco present. Cisco has a very wide reach in enterprises. Although we know them primarily for their networking equipment, they also do compute (UCS) and communication (VoIP, Spark, etc.). So when we started hearing about containers, APIs, and Kubernetes, I took note.

As each day goes on, I am willing to bet that we are seeing fewer and fewer instances where containers are spinning up to run in their own, isolated environments. Containers need networking, too. Can you imagine working in an environment where you need to spin up 1000 web server containers, and you somehow need to manage the networking for that? Cisco saw this and decided to embrace it.

GIVING PROGRAMMERS NETWORK ACCESS

Cisco has been working hard on integrating their Application Centric Interface (ACI) with Kubernetes. The goal is to give programmers an easy way to utilize the network. Since ACI is a Software Defined Network (SDN) solution, leveraging APIs to integrate it into workflows seems like a no-brainer.

Policies and restrictions can still be set by network administrators, but no longer will programmers need to wait, or harass network admins to provision ports, setup VLANs, or just provide general access. Rather, they can use Cisco’s solution to add networking to containers when needed.

STEPPING BACK AND TYING IT TOGETHER

Although many companies out there are working with Kubernetes and container technology, Cisco and NetApp really stood out to me. They are both behemoths in their respected areas, and they both realize that containers are here to stick around. On their own, Cisco’s and NetApp’s offerings are a great step forward for programmers, and DevOps in general. But when you combine them, and you find that you can now use APIs to handle beginning to end container deployments … well, that’s when you may start to see power of these solutions.