Security Field Day 4 - Cisco Security Update - Tetration all the things

This time around Security Field Day 4 was all about Cisco Tetration. It seems they are focusing on how to solve security policy creation and management via big data and machine learning.

Rob Tappenden did the overview of Tetration, giving the background about why the product is around and why it is important. The goal is securing application workloads across on-premises Data Centers, Campus ang Cloud. It ingests IP data and is able to make policy enforcement decisions based on that data set, which is collected and analyzed over time. Tetration is doing data correlation and pattern matching to help define policies and also to determine if an application is currently matching an existing policy already defined.

Here is Rob's video:

Tim Garner then walked through the details around the policy process and operations of how Tetration does what it does. It was an interesting demo to watch, mainly because I have not had the chance to be hands on with Tetration at all myself. You can learn a lot about how a product functions by watching others use it. Tetration leverages both an agent and also flow data. The combination is likely the approach many with take as it gives the most complete view of the network. The demo had systems running in AWS with the agent installed, therefore exposing all the IP and network connectivity. The agent is able to do policy enforcement based off what you publish through Tetration and it is possible to run a simulation of your policy to see the impact prior to deploying it.

Here is Tim's video:

Then a more developer focused presentation was given by Remi Philippe, walking through a standard CI/CD workflow using Github and Jenkins to show how a developer would integrate and use/interact with Tetration. It was useful to see, but I am skeptical how many companies have operational team that are adopting Tetration and teaming with their developers in this way. I'm sure they are out there, but I am guessing that the majority of application developers are for more interesting in APM solutions like AppDynamics (owned by Cisco), New Relic, DataDog or Dynatrace than accommodating the operations team around Tetration. Because APM is code integrated and has an agent, I am doubting the desire of the app teams to run multiple agents on a host. The moment something goes wrong in an environment, the first thing that is turned off is security policy, firewalls and anything that might prevent the application to talk on the wire to each other. If that fixes it, then that agent or process isn't turned back on again.

Here is Remi's video:

I believe, over the long term, Tetration has to be integrated with AppDynamics and ThousandEyes (owned by Cisco) and have a single agent able to provide data to all those services. It also needs to support third party APMs because not all teams chose the same tooling and Cisco needs to open up there ecosystem to support that. I'm not sure that Tetration really isn't just the big data part (with a security angle) that all the APM providers already include as part of their product and that Cisco, over the long haul with have to reposition the produce around that story. I am speculating that it is a feature of a bigger product family over time. Only time will tell.

I will update the post when the video becomes available but you should be able to find them here when they post. You can also check out some of the other delegate's thoughts on the presentation such as Michael Davis, go check out his thoughts.

- 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 XFD4. 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.

Security Field Day 4 - A quick virtual hit of security

It has been awhile since I paid close attention to what is going on in the security space so I am excited to catch a few sessions with the Tech Field Day team for their Security Field Day 4 event happening tomorrow, Oct 21 virtually. You can catch everything live tomorrow and ask questions via twitter, just use the hashtag #XFD4 and cc: @techfieldday so those who are participating can ask your question live to the presenters.

Looks like the day will be with Cisco, and I think they need to impress, there are a lot of security companies out there with fantastic brands and products, this is a tough market. I hope they bring out the ThousandEyes team to talk about integration with AppDynamics to elevate Application level security and end to end monitoring and telemetry. I guess we will see what they have to say shortly!

Join me - you can hit the main website at https://techfieldday.com/ to watch live, it is 11-12 and 1-3pm PDT.

- 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 XFD4. 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.

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

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

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.

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:

VMware - VMware Cloud on AWS Onboarding, DC Extensions and Cloud Migration

Stellus

VMware - VMware Cloud on AWS Horizon 7 VDI, Kubernetes, AWS Services and Marketplace

SolarWinds

Pensando

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.

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.