I had the great pleasure to go out of my space this week to San Diego for Cisco-Live-US 2019. Remember, I’m really not a network guy. I find the conversation about packet loss, and latencies, firewall rules, etc. to be very challenging.

However, I think that the reason I was here was because this core (no pun intended) skill is not actually my domain. I am able to bring differing perspective to the conversation, and oddly, in this presentation, I was completely intrigued.

The solution in conversation was all around the Cisco HyperFlex product, using Kubernetes, and GCP, and the Anthos management platform. Does that sound like a lot of complexities? There’s actually logic behind it. I hope that I’m able to explain it well…

Approach –

The “Brass Ring” is the concept of full migratability for multi-cloud. Containers are a step along the way. Theoretically, a well-designed architecture should be able to move the actual container from location to location. Multi-cloud architectures should support it. But the management of these containers, the ability to update, maintain, track these, etc., requires a management layer. Bringing in Anthos, which is a recent addition to the portfolio, makes this far more manageable. Without Anthos, building the containers on-prem or in the shared platform (currently Google Cloud Platform), but both had been a challenge. No longer. I feel this added component really solidifies the approach.

HyperFlex is a solid architecture toward HCI. I’ve always appreciated the functionality that allows the scalable growth of the environment. Need storage? Add another storage node. Need compute? Add another UCS server. Many of the HCI solutions already in place require a full “Block” to be added to the architecture once the existing one gets outgrown. Even more to the point, if you run out of either the storage or the compute, but aren’t lacking on the other piece, many architectures require a full additional buildout. I do see the value in a modular approach.

To be clear here, the build requires virtualization. So, the traditional HyperFlex actually starts the same with this newer approach. Toward that end, one may run a standard virtualized environment and the container side as well on the platform. I see this as critical as an organization moves their environment from virtualized servers toward a more dynamic container-based, dev-ops oriented future. We also know that as virtualization is not ideal for everything (quite a bit, though), also much legacy application doesn’t necessarily containerize (I still want that to be a word) well.

There has been some provision for apps on their journey toward containerization, in the form of a proxy. Essentially, this proxy sits as a communication go-between toward the container, from the source. Another thing that I didn’t know prior to this presentation, and, of distinct value as well.

I think, in addition, that the leveraging of GCP for this as an initial partner, not only makes sense, given the tie-in with Anthos and Kubernetes. But, the goal is to be able to ultimately support whatever cloud partner is desired. I understand this is aspirational, but hardly seems unachievable.

My concerns –

Let’s open this part by re-stating the obvious. I am a storage guy… Containers don’t always associate with some persistent local storage, but sometimes they do! So, how does this (or other approaches) handle the migration of storage reliant containers? I asked this question in the presentation. Seemed that there may be some thought that may need to be placed into this. I was reminded of when I worked with my old EMC team on the vPlex (the old Yadda Yadda) approach to larger stretch clustered live migrations. This may have been around 2010? Anyway, there were provisions in place with vPlex for fully cloning the VM across geo’s, then the migration would be accomplished by a sync of the changed data from the live to the standby version, while both sides would be fully in digital conversation with each other, acknowledging the migration, and allowing for what essentially is a geographically stretched vMotion. Of course, this is an extremely simplified version of the approach.

I would like to see some greater effort into this migration approach. I do believe that they will get there, once they work out the syncing and cache-coherency issues resolved.

Meanwhile, the idea of a reference architecture designed around the containerization of applications, to me feels like a great approach for my customers who are moving into the dev-ops, serverless, container-based world. Very interesting presentation, and I am really looking forward to seeing how they move this forward.