Monday, January 13, 2020

Network Field Day 21 - NGINX - Making Sense of Service Mesh

NGINX presented on their service mesh solution at Network Field Day 21, and you should check out the presentation by Faisal Memon explaining what they have built. He explains what a service mesh is, why you might need it and how it is integrated into NGINX.

If you have spent any significant time as a practitioner in network engineering you will eventually end up helping with a project that involves a distributed publish/subscribe message system - which today we call a service mesh. In earlier times, we might have referred to it as a service or message bus and used technology like the Common Object Request Broker Architecture (CORBA) which is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. Or maybe you installed and used a commercial software solution like Tibco Rendezvous which has been around for 20 years or you were involved in the financial industry and you implemented the FIX protocol.

My point is, the concepts and design ideas for a service mesh have been around for decades and really are nothing new at all. Effectively, they are a distributed message queue with a standard API run over a network. What has changed over time is the ubiquity of their use in many common platforms and architectures today. I believe one of the reasons so many platforms use them is because developers have become increasingly frustrated with the networking NAT/PAT/DNS problems and would prefer to have a more elegant routing and name space than what classic IPv4 and DNS provide. There is a lot to unpack around that last sentence and I likely won't get to it in this post but just accept that the way many enterprises are deploying and running their network are not optimal for application developers trying to deploy new application workloads within the data center environment.

There are many options to choose from for a service mesh. A not so brief list of some options would be:
Istio/Envoy
Console Connect
Linkerd2
Maesh
NGINX Service Mesh
Microsoft Azure Service Fabric
RabbitMQ
Hashicorp Consul
AWS App Mesh

Because of the role that a service mesh provide, it matches very cleanly with application proxy services. This is a natural fit for something like NGINX because that is where it is commonly deployed too. Often NGINX is used as an application delivery controller (ADC) or a classic server load balancer (SLB) along with a proxy for application traffic. This proxy role allow NGINX to have a comprehensive view into the application, even with a distributed application front end. Providing a sidecar proxy function to allow more enhanced services to be managed and run without burdening the application developer is one of the benefits you gain. For example, TLS certificate management, mutual TLS (for secure app to app communication), tracing and monitoring, metrics and reporting, traffic controls and any other services can be coordinated, synchronized and managed separately from the application and not burden the developer with having to know all those specific items to get their application work.

One of the benefits of having a service mesh built into NGINX is the fact that NGINX is now the most widely deployed commercially supported web server in the top 1000 websites. This means that having a service mesh solution integrated into the platform makes adoption and use of a service mesh far more likely to occur because NGINX is used in so many places and in so many deployments. The other interesting part is the fact that many service mesh solutions can be swapped in and out depending on the need requirements of the application developers. That means that other platforms can either leverage with NGINX has build with their service mesh technology or they can swap it out and use Hashicorp Consul or whatever other service mesh technology they are already utilizing. It is very flexible and it is a technology all network engineers should be comfortable helping deploy, operate and support in their environment.

So it is highly likely, at some point, you will be involved with some a project that makes use of a service mesh and you should take the time to learn and understand how it is used and commonly deployed. Because of the popularity and wide scale adoption of NGINX it makes a lot of sense to have a good understanding of what they have built and how to use it.
- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, November 26, 2019

Network Field Day 21 - Itential - The Steady Progression of Network Automation


At some point you run into tool overload. Given the diverse number of tools coming out for networking thing can get complex in a hurry. With automation all the rage along with software defined networks, intent based networking, SD-WAN, underlays, overlays, controllers and new security solutions it is incredibly hard to integrate everything. Never mind the streaming telemetry and analytics, logging, cloud networking, cloud security, IP address management and tracking all these resources too.

So how do you stitch all this together into something that is usable, practical and matches the workflow that your team has adopted? How can you allow these things to work together but not invest years in your networking team to build up coding skills that are not core to their daily jobs? Finally, is there anything flexible enough and extensible to allow your team of low code or no code network engineers to be functional quickly but leverage some of the gains of automation and tool integration?

This is where Itential comes into the picture because they are a network software automation company that is trying to address this core transformation problem. They are not trying to replace any of the best of breed tools that you have (or are considering adopting) for your environment. Instead, they are trying to provide the widest capabilities to integrate them together and do it in a low code or no code manner with the right API and third-party support. What is great is that your network engineer team today can likely integrate and extend the tools they are using (or are interested in using) right away. This means they can replicate many of the common tasks and workflows they are doing manually and making them repeatable and audit-able in the Itential world. Most of those tasks are likely run-book or step by step guidelines for getting changes made to an environment or updating settings or parameters on a variety of networking gear. This is where Itential can have the greatest impact of helping you to understand what you have in your existing environment, managing a workflow and providing the building blocks to get to more complex and interesting automation.

In the overview presentation by Chris Wade, Co-founder and CTO of Itential, he outlines the typical phases of network automation. Starting at Legacy, which starts at manual (CLI) and some scripting. Next moves to the Current view, what they term assisted manual. The Next view covers machine first and finally Future covers programmable. The following Diagram show the specifics. It helps frame the journey and the likely steps you will take in automating your environment.



The descriptions and diagram don’t do justice to how Chris explains it, so it is worth the time to go watch what he has to say. It is a quick 20-minute investment of time but super helpful because he explains many of the typical challenges and the process many organizations go through in moving to network automation and how their product is built to match up to that.

I’m very interested in what Itential is doing because it can have a broad and meaningful impact on many organizations to help move them forward in adopting network automation. But the move isn’t a huge burden or hurdle, it is incremental, builds on existing investments and provides a clear road-map of what you would tackle next. This is often missing in many other solutions, so it is nice to see a company who gets the longer term journey and shares that in an upfront way with their customers.
Ed

ps: You can also check out fellow #NFD21 delegate Amy Arnold's blog post on Itential where she does a great job covering the API aspect of what Itential is up to with their automation gateway solution.

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, November 05, 2019

Network Field Day 21 - Network to Code - Changing the networking landscape


It is not often you get to see a friend and colleague start and grow a business from scratch and have major impact on your industry. My friend Jason Edelman has done just that with his company, Network to Code. It was cool to have him, and his team, present at NFD21 and I wanted to highlight a couple of the things I found impressive about what they are investing in.

First, they are supporting NetBox as an open source project and developing on top of that. They are extending what NetBox can do by hiring Jeremy Stretch (who started the project while he was at Digital Ocean) to work full time on building out functionality and features in NetBox. This allows Network to Code to provide best in class capabilities for companies that wish to use, extend and scale up their projects leveraging NetBox. If you haven’t heard of NetBox, you can check it out the GitHub repository at https://github.com/netbox-community/netbox and the documentation at https://netbox.readthedocs.io/en/stable/ for a more in depth understanding. In summary, from the documentation site: “NetBox is an open source web application designed to help manage and document computer networks.” And it includes the following:

  • IP address management (IPAM) - IP networks and addresses, VRFs, and VLANs
  • Equipment racks - Organized by group and site
  • Devices - Types of devices and where they are installed
  • Connections - Network, console, and power connections among devices
  • Virtualization - Virtual machines and clusters
  • Data circuits - Long-haul communications circuits and provider
  • Secrets - Encrypted storage of sensitive credentials
As accurate as the description is, it really doesn’t do this project justice. It is cool what Jeremy and the community has built out, I think many organizations will find it incredibly useful in helping to keep their infrastructure world in order without having to glue together a crazy number of NMS, spreadsheets and diagrams together in a wiki and hope to keep that current. Because it is API and automation focused it makes it easier for operators to leverage custom scripts, normalized data models, and integration into a lot of other tools. The exciting part is that Network to Code is planning on providing commercial support for the product so customers who are nervous about not having formal support for an open source product they would run can obtain it from Network to Code. This is fantastic news for adoption and interest in NetBox. You should check out the NFD21 presentation Jeremy and John gave about NetBox.

Second, for me is the community and the effort that Network to Code has put into helping to put support and resources behind that. If you are not aware, they host a Network to Code slack channel (https://slack.networktocode.com/ ) that has 10,000+ members and is a great resource to start learning about what is happening in the networking automation space. They continue to invest in open source tooling and contributions and believe in the model of sharing and supporting interesting projects. The team at Network to Code has build some of the largest commercial network vendor integrations for a variety of platforms but most notable is for Ansible. If you are not familiar with Network to Code then check out Jason giving an overview of the company, and explaining who is Network to Code.
I’m excited to hear what Network to Code will do next and they are a company you should keep an eye on if you are in the networking space. Great people with a goal to change how the industry is doing networking.
 - Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, October 22, 2019

Network Field Day 21 - Forward Networks - Useful Intent Based Networking


One of the challenges in larger organizations and service providers is the inherent complexity in the design, deployment and operation of their networks. The reasons are varied and often a function of their business needs, their legacy technology and business drivers and many decades of merger and divestitures. Basically, things out of the control of the technology implementors and operators. The operational impact of deploying or removing a service from the network can be profound. It is often not documented completely, has changed over time and is intertwined with other services in some way that may not be obvious with just a simple assessment.

These challenges are the source of real operational risks that can translate to financial losses for a company. It is no wonder that many larger organizations are slow to implement changes, have challenges understanding impacts of changes they need or want to do and have increasingly complex security and policy issues. Compliance and validation are now becoming standard audit requests from third parties and financial penalties are not insignificant to those that fail to pass many of these new standards.

So, what is an organization like this to do regarding getting their arms around the impacts of changes within their environment? How will they manage a multi-vendor, heterogeneous networking environment? ForwardNetworks is addressing this need by allowing companies to build a digital twin of their network, which is not easy! This approach allows organizations to validate configuration changes, their impacts and understand what actions could potentially be damaging and negatively impact their compliance, SLAs or business services. This digital twin allows for several unique aspects of what Forward Networks can provide to customers. They are an intent driven solution that provides network automation and verification with a useful and practical user interface that enables network operators to really understand the impact of planned changes.

I recommend watching the Network Field Day presentation from Brandon Heller, CTO and co-founder which explains what Forward Networks does and goes over the UI of the product. I do believe that the product, as it is built today, is likely more appropriate for larger organizations. However, I can easily see them expanding their customer base and providing the product as a SaaS platform for small to medium sized companies with less complex networks to leverage the automation and validation capabilities. Given the natural fit to integrate to cloud networking via API’s and their support of existing network and security product technologies that are used on-premises this would be a very desirable solution for many in the complex role of operating highly available or complex networks.

I was impressed with what Forward Networks has built and for operators I believe there are many that would spend most of their time within their UI versus spending their time in the CLI of most networking and security platforms. The good news is that they do not preclude you from using the CLI still and can work in conjunction with many solutions that are based on that as the primary interface to deploy and operate their products. It is a win/win in terms of helping teams adopt a new method and tool.

If you are struggling with large scale networking changes within your organization or you want better validation and verification, along with automation to push out changes then seriously evaluate Forward Networks. I have my fingers crossed that their product will go down market and be something even more of us get to use.
- Ed

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.

Tuesday, October 15, 2019

Network Field Day 21 - Aruba SD-Branch - Evolution


I am going to focus on the Aruba SD-Branch solution (their combination of SD-WAN -LAN and Cloud making it SD-Branch) presentation that is only a portion of the overall presentation that Aruba gave at Network Field Day 21. I digress quickly, the industry is stuck on Software Defined or SD as a naming convention and I think someone in marketing needs to be creative and break away from it and come up with a solution/product name. Honestly, SD-<anything> has lost all meaning. I think Aruba should rename the product to fit into their existing product naming and not cave to industry convention. With that done, let’s get back to the technical nuts of bolts of what Aruba presented.

We started with an overview presentation (https://techfieldday.com/video/aruba-why-sd-branch/) around Why SD-Branch and how it is different than tradition SD-WAN. In simple terms, they are using the same technology to do application insight and management for LAN, WAN and Cloud services through a single interface which is build on their wireless and wired LAN portfolio. It really does make a lot of sense for companies to want to move this direction. To be able to manage LAN, WAN, Cloud, Wireless, Wired, Identity and Security from a common interface with metrics and performance. In addition, props to the Aruba team for having a great user interface. It makes sense, is easy to find things, is clean and snappy too.

So, what was most compelling about SD-Branch and specifically the SD-WAN portion? First, you get a unified interface to manage everything and one that is done correctly, not just cobbling together a bunch of separate products and hoping everyone uses the same terms and layout. Second, I think it was the flexibility in configuration. The fact that you can easily stand up and have multiple design topologies for VPN and do that across multiple Internet and private dedicated links in many combinations shows that Aruba really understands what customers are trying to address. The demos really highlight how easy and straight forward it is to configure, monitor and operate the network so you should check that out at https://techfieldday.com/video/aruba-seamless-sd-wan-orchestration/ and finally, you really should see how everything is displayed in a single view for operations. If you are willing to invest and go all in with Aruba you get a lot of upside from an operations view. Check out https://techfieldday.com/video/aruba-simplify-network-operations/

Given that most SD-WAN solutions will likely provide a break even ROI in 12-18 months it is likely worth investing in Aruba SD-Branch if you are an existing Aruba wireless/wired customer. If you are doing an evaluation of products today such as LAN (wired and wireless), WAN, Cloud, and SD-WAN you would be doing a disservice in not putting Aruba on your list. I’ve been very impressed with what they have been doing over the last several years and my experience at #NFD21 has shown they are continuing down the right road and build on top of their great product portfolio.

One note, they don’t have IPv6 support in their SD-WAN product yet, but given the great IPv6 support they have in their LAN (wired and wireless) products today I would not be surprised to see that happen for SD-WAN soon. Fingers crossed they keep up the great work and get IPv6 in there and push their competitors to do the same.
Ed

ps: You can also check out fellow #NFD21 delegate Remington Loose's blog post on Aruba where he does a great job covering the technical aspects and components of what Aruba is up to with their SD-Branch solution.

In a spirit of fairness (and also because it is legally required by the FTC), I am posting this Disclosure Statement. It is intended to alert readers to funding or gifts that might influence my writing. My participation in Tech Field Day events was voluntary and I was invited to participate in NFD21. Tech Field Day is hosted by Gestalt IT and my hotel, transportation, food and beverage was/is paid for by Gestalt IT for the duration of the event. In addition, small swag gifts were/are provided by some of the sponsors of the event to delegates. It should be noted that there was/is no requirement to produce content about the sponsors and any content produced does not require review or editing by Gestalt IT or the sponsors of the event.