Monday, May 04, 2020

Cloud Field Day 7 - VMware Cloud on AWS

For those who are traditional VMware enterprise customers you are likely comfortable with their products and technologies and rely on it daily to help keep your company up and running in a highly available configuration. Adoption of public cloud, that is a different story for many. If you have not been keeping up with the innovations and use cases around public cloud you might be caught off guard by the adoption and scale that it is providing to many enterprise customers, some of them might even be your competitors. VMware recognized this gap and decided to brave the waters by partnering with Amazon Web Services (AWS) to make VMware Cloud on AWS. For anyone who has followed the public cloud market, you will be familiar with how daunting that can be for a well established enterprise software company like VMware. A lot of other software companies have tried and failed to move their solutions and buying patterns to a public cloud model.

Remarkably, I think VMware pulled it off. At least for now. They released a solution to help customers run workload in AWS and take advantage of their existing investment in VMware. They extended that to the scale and flexibility that AWS provides while also providing native hooks and features from AWS that extend what an enterprise can leverage from both VMware and AWS. Granted, it is not like going all in native AWS, but, for many companies that effort is incredibly daunting and likely too large an undertaking for any one team. A major workload migration of applications and services for many companies requires multiple projects and years to complete.

VMware is helping address this gap by allowing enterprises to migrate workloads into AWS but still leave them in their native VMware format. The tools and constructs (Software Defined Data Center or SDDC) that VMware customers are used to stay the same, so they can just leverage running them in AWS. This flexibility gives customers more time to determine what is the right environment, cost model and workload placement for their needs. Long term, I still believe that most customers will figure out how to properly leverage native cloud services (from all the public cloud providers) but this solution is a smart way to address an immediate need that will last several years. I think of it as the "easy button" for enterprise IT teams who need to have workloads running in AWS to help support their organization.

Day 1

Day One of VMware Cloud on AWS


The day one presentations at Cloud Field Day 7 focused on an overview of the offering, a deep dive into the networking and how that works, details into data center extension and hybrid cloud, and finally how to do migration and the tools available to you. If you are not familiar with VMware Cloud on AWS then watching these videos will go a long way to understanding what is offered. It is a unique offering, even though VMware has agreements with Microsoft Azure and Google Cloud the integration and partnership is different. I won't belabor the points of how they are different, theses presentations were all about the AWS offering, just know that the work and partnership has been more extensive. I would recommend the migration and networking presentations if you already know a bit about VMware Cloud on AWS, it helps to explain how you will leverage what they have built out.

 


Day 2


Day Two of VMware Cloud on AWS


The day two presentations jumped into specific services and attributes of the solution. It went over virtual desktop using Horizon 7 on top of VMware Cloud on AWS - I'm not entirely convinced this is any better than Workspaces that AWS provides, but it does keep things the same if you have already deployed Horizon 7 on-premises. DR as a Service (DRaaS) was up next showing off how to leverage SRM, very straight forward, they really did make this part easy for admins. No cloud service offering can go to long without bringing up Kubernetes (K8s) and this was no exception. The offerings and options are pretty overwhelming so check out the video for more information if K8s is your thing. If you want to integrate your VMware Cloud on AWS with native AWS services then you need to have a method to make that integration work. They presented on how this functions (it is slightly different than if you are used to using AWS service endpoints). Many organization who want to leverage application streamlining make use of marketplaces and pre-build packages to make standing up well known applications and platforms a bit easier. VMware has a cloud marketplace for that purpose. I'm not sure how viable their marketplace will be long-term given the ease that you can deploy from the AWS Marketplace to a VPC and leverage that native ability but it is a "nice to have" in the current transition for those that can't deal with porting their apps or platforms.

So what does this mean for enterprises running the full suite of VMware products and technology?
  1. You have a relatively easy way to getting your existing environment running in public cloud - but it really isn't public cloud in how the IT market defines it. You are leveraging public cloud infrastructure and a few of their constructs but you are really running VMware SDDC as a Service.
  2. You will be paying to run your existing application and platforms in AWS but you won't have as much control over size, scale and costs as if you were to do the effort to port and move to AWS.
  3. You will have to address a shared administrative role and permissions (VMware is running the environment in AWS for you), some enterprises that is a deal breaker.
  4. You need to evaluate the benefits this solution versus starting to adopt public cloud in an incremental way and port or migration your applications to a native cloud architecture.
  5. You can potentially reduce or completely decommission any data centers you operate for disaster recovery or high availability reasons and leverage VMware Cloud on AWS and scale as needed.
  6. You could use VMware Cloud on AWS to potentially spin out a division or company and then hand off that infrastructure, applications and platforms to a new team with much less headache than moving things out of your data center.
  7. You will still have data gravity problems, they just won't look the same as they do for public cloud services.
  8. You will need to have a savvy networking team as the requirements around VMware NSX and AWS networking services are not going to get easier.

If you decide to watch the videos and you have a question feel free to hit me up on twitter (@ehorley) and use hashtag #CFD7, that way others can jump in to help if I missed it. I'm always interested to hear a different perspective or view about a technology, let me know what you think about VMware Cloud on AWS and if it is a good solution for the market right now.
- 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 CFD7. 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 if travel was involved. In addition, sometimes 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, April 21, 2020

Cloud Field Day 7 - All virtual but still a Tech Field Day event in every way

Adapting to the times is a given in the technology field and the current worldwide crisis around COVID-19 has forced some changes for Tech Field Day events and the Cloud Field Day 7 event starting April 22, 2020 in particular. We will be doing everything online and while I will miss getting to hang out with many of my friends and colleagues who will be participating it is nice to know we can continue to contribute and engage in this fashion.
So check out the live feeds and videos, it all starts Wednesday morning at 8 am PDT. The line up of sponsors is good. We will be hearing from these sponsors over a few days, check the site for specifics:

If you decide to watch and you have a question during one of the live sessions feel free to hit me up on twitter (@ehorley) and I will see if I can get it asked. You can also just use hashtag #CFD7 and others can jump in to help if I missed 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 CFD7. 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.

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.