Future:NET 2018 Tech Talks VMware

The Future:NET is Service Mesh?

  1. The Future:NET is Service Mesh?
  2. Service Architecture: The Times They Are a-Changin’
  3. Is a Cloud-Native Network OS Required?
  4. Future:NET – Missing the blockchain future?
  5. It’s All About The Speed!
  6. Future:NET 2018 Unified SDN for Microservices: Reality or Fantasy?

VMworld is the ultimate customer event for VMware, this year hosted in Las Vegas at Mandalay Bay. While I have attended VMworld many times in the past, it is almost exclusively a partner event for me, not a customer one. But recently my role has changed. I have started a company (HexaBuild) with some good friends and colleagues in the IPv6 community and I am no longer working for a partner driven organization. Instead, we are providing high value consulting for companies trying to figure out Advanced Cloud, IoT and Security with IPv6. Obviously, I want to keep up to speed on what is going on in networking, after all, that is what IPv6 is all about. So how in the world does this relate to VMworld?

It turns out there is a unique invite only conference that happens on the last two days of VMworld called Future:NET. It is designed for industry peers involved in networking to gather and talk about what the future looks like in the networking industry. It is an attempt to look around the corner and understand where the innovation, next technology impact is going to happen in networking. The conference is hosted by the NSX technical executive leadership and I consider it a must attend to understand what is going on in the industry. Past presentations are available online (see below) and I have attended this event since it was first held back in 2016.

I wanted to share some thoughts on the theme of the conference this year (service mesh and automation featured heavily) and how this will play out over the next several years as networking vendors and their solutions start to adopt some of these ideas. In theory it is to advance the industry forward, but the impact on operators, architects and IT teams will be profound and I’m not sure our industry will look the same in 5-10 years.

Let’s start with some simple themes that are taking over in the IT industry today. Specifically the rise of DevOps (or DevSecOps as John Willis is promoting – which is likely way more needed and accurate, but we can cover that another day) and how everyone is pointing at the networking industry as being horribly behind in getting on board. While it is true that networking is behind, there are actually some rational reasons for this. First, systems and storage assume a network fabric is available to talk to other resources, from initial boot time all the way to decommission. The expectation is that they are able to address that resource and run commands on that resource. So, compute and storage fundamentally rely on networking. This means that networking MUST be there. This puts a higher demand on the reliability and scalability of networks and also means it is tougher to do any sort of maintenance window. It also means it is harder to redeploy networks, change their initial architecture and this means they tend to be brittle from an agility standpoint. Most networks run stable for a long period of time but they are not dynamic from a feature and functionality basis. It is often too high a risk to modify them to support rapid features or new functionality.

The expectation in our cloud first world is rapid provisioning, rapid dynamic changes in networking fabrics and the ability to add new features and functionality on demand. The network industry is addressing some of this with Software Defined Networking (SDN) and automation but these are still several modals away from where true DevSecOps is at for systems and storage. Hence the focus at Future:NET on service mesh and its related ecosystem. Let’s define a service mesh quickly. From the NGINX website:

“A service mesh is a configurable infrastructure layer for a microservices application. It makes communication between service instances flexible, reliable, and fast. … The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance”

Many would agree that the rise of Kubernetes as the de-facto container management and orchestration platform is driving many of the associated projects. Istio is one of the projects that looks to bridge the divide in networking for traditional operators to those having to run and manage containers. You can check out more info about Istio at the website but realize this project has been in the works for over a year, originally called Envoy, and you can read about the project from this blog post at the CNCF website. The presentation that addressed this most directly was from Google’s Louis Ryan with “Istio – A Network for Services Not Bytes” where he walks through why Google is using, adopting and contributing to Istio and how it is fundamentally different than what has come before. The difference is really the lense or focus direction of how a service mesh addresses the needs of developers to get services in a way that doesn’t impact or involve the operations teams. It makes sense, it is where things are going, but it is uncomfortable for traditional networking folks for sure.

The majority of presentations at Future:NET were talking about the impact or possible impact of this change. How we will have to adapt to make sure we have the tools, mindset and capabilities in our platforms to support these new operating methods and tools. Are we innovating in the right areas or will software developers leapfrog the networking industry and abstract our function away (doubtful but in theory it is possible)? It feels, at least today, that the industry is making the right moves and supporting the right integration and features (we will continue to have a job). I think the real question is if the talent pool will make the move to this new paradigm or if a new breed of network engineer will have to be developed (pun intended) to drive the industry forward. I’m not sure where that falls right now, it feels like there is a huge skills gap and not enough folks to address the need. But with automation, SDN, service mesh and intent based networking maybe we just won’t need as many network engineers to complete the work? Only time will tell but it will be an interesting journey for all of us.

Now “go away or I will replace you with a small shell script” takes on a whole new meaning!

About the author

Ed Horley

Ed Horley has spent over 20 years in tech, and is known as the “Crazy IPv6 dude”, co-chair California IPv6 Task Force, author (Apress and Pluralsight), blogger and occasional speaker.

Leave a Comment