Why the push for containers and kubernetes?

Applications are king. Everything we do from a data center hardware perspective is in support of delivering the application to the end user and storing the outcome of those user interactions. Upon an initial release of an application, developers are hard at work on the next release. New features, bug fixes and streamlining interfaces drive the need to improve the application. Unfortunately, past development methodologies produced applications that had 1000’s of lines of code and the ability to deploy new versions happened every three to six months.

Deploying these huge applications in the data center was accomplished by spinning up a new Virtual Machine and loading the corresponding operating system (and necessary hardware drivers) and the application. With the introduction of CICD, Continuous Integration Continuous Delivery, a DevOps approach to designing and deploying applications meant that those 1000-line applications would need to be broken down into smaller “chunks” with explicit unit testing.

With containerization the smaller bits of code could be loaded into a container and that application of 1000 lines could now be deployed in 120 containers. Want 10 copies of that application load balanced? That would result in 1200 containers. Sounds difficult but these 1200 containers can be deployed by Kubernetes in a few lines of a deployment.yaml file. Want to scale up from there? A single command to Kubernetes API would result in more resources made available to the application, on the fly with no service interruption.

Now that we have the smaller parts of our application, we can create automated testing and automated deployment. Due to the power of DevOps and CiCD, Amazon pushes new software updates to its website every 11 seconds.
Applications are King, Containerized applications are Kingier.

Change of the season

I would have to say I’m your average mad scientist. I don’t have bubbling beakers full of brightly colored fluids and sparks from electrodes zipping around my lab but I do have a lot of switches, routers, virtual machines and applications currently under development. I am not a professional programmer and everything I know about application development comes from the Googler and one or two books on the subject du jour from Amazon.

As expected, the winds of change bring changes, I find myself fascinated by another attraction. Plexxi.

Before we get to what it is, let’s start with why?

OK, Time for a little thought experiment. I want you to spin up a new Virtual Machine, with a new storage target in your data center…I’ll wait……OK! I bet it only took about 5 or 10 minutes for your to do that…..what didn’t you do? Configure the network. Did your new VM wind up in the right port group? What happens if you need to migrate the VM to another EXSi server? Is the VLAN on the destination server switchport? NO?

Then let’s start the stopwatch and see how long it takes the network team to make those changes for you. What if it just happens when we spun up the VM?

What kind of sorcery is this?……It’s not sorcery, it’s HPE composable Fabric formerly known as Plexxi.
api

When I talk about this teknology I like to think of a house. A house has a strong foundation, Walls that divide rooms from one another and a roof to keep me dry. Let’s start with the foundation.

We start by removing all the layers of network architecture and build a full mesh layer two network. Actually less physical links than a spine/leaf with 4 spines and eight leafs. We only need the leafs. The forwarding tables of each switch are managed and programmed by the controller. Oh and one little small thing to point out is the full mesh is auto instantiated!
api

Next up, the walls. Think about a convention center. One week they have a huge group in attendance and then next week it’s 10 small companies. They need to be able to move the walls and reconfigure the space to meet the needs of the customer. If you have attended any of these events, you’ll know what I mean. Composable Fabric is just about the same thing. I start with the full mesh network and then I am able to define Affinities, giving me the ability to isolate workload traffic. I’m not talking about separate vlans, I talking about real isolation. moving walls! Oh, and yes, this can be done dynamically, Affinities can be deployed and torn back down many, many times, without a single word on a command line by a human.
api

And finally, the roof, in composable terms this is the application integration layer. The application layer allows us to integrate into things like OpenShift/Kubernetes, OpenStack and vCenter (to name a few). We can look for events happening in these system and modify the network configuration to support changes in these upper layer cloud management systems. If you vMotion a VM from one ESXi host to another, the network port connected to the destination ESXi host is automatically configured and you didn’t even need to talk to the guy over in the network department. This means that the network is responsive to what the guys or gals are doing in the software defined compute/storage world……finally!
api

So, you can build your data center network like my Dad built his, or you can step into the world of self provisioning, self healing, software defined networking.

I ask you, are you a Fred Flintstone or a George Jetson?

Want more?….check it out… Here