Interclouds And The Future of Cloud Computing

Interclouds And The Future of Cloud Computing

I am finally taking the time to write this piece about interclouds, workload mobility and application portability. Some of my engagements during the past four weeks led me several times to discussions about interclouds and workload mobility.

Cloud to Cloud Interoperability and Federation

Who has thought back in 2012 that we will have so many (public) cloud providers like AWS, Azure, Google Cloud, IBM Cloud, Oracle Cloud etc. in 2022?

10 years ago, many people and companies were convinced that the future consists of public cloud infrastructure only and that local self-managed data centers are going to disappear.

This vision and perception of cloud computing has dramatically changed over the past few years. We see public cloud providers stretching their cloud services and infrastructure to large data centers or edge locations. It seems they realized, that the future is going to look differently than a lot of people anticipated back then.

I was not aware that the word “intercloud” and the need for it exists for a long time already apparently. Let’s take David Bernstein’s presentation as an example, which I found by googling “intercloud”:

This presentation is about avoiding the mistake of using proprietary protocols and cloud infrastructures that lead to silos and a non-interoperable architecture. He was part of the IEEE Intercloud Working Group (P2302) which was working on a standard for “Intercloud Interoperability and Federation (SIIF)” (draft), which mentioned the following:

Currently there are no implicit and transparent interoperability standards in place in order for disparate
cloud computing environments to be able to seamlessly federate and interoperate amongst themselves.
Proposed P2302 standards are a layered set of such protocols, called “Intercloud Protocols”, to solve the interoperability related challenges. The P2302 standards propose the overall design of decentralized, scalable, self-organizing federated “Intercloud” topology.

David Bernstein Intercloud

I do not know David Bernstein and the IEEE working group personally, but it would be great to hear from some of them, what they think about the current cloud computing architectures and how they envision the future of cloud computing for the next 5 or 10 years.

As you can see, the wish for an intercloud protocol or an intercloud exists since a while. Let us quickly have a look how others define intercloud:

Cisco in 2008 (it seems that David Bernstein worked at Cisco that time). Intercloud is a network of clouds that are linked with each other. This includes private, public, and hybrid clouds that come together to provide a seamless exchange of data.

teradata. Intercloud is a cloud deployment model that links multiple public cloud services together as one holistic and actively orchestrated architecture. Its activities are coordinated across these clouds to move workloads automatically and intelligently (e.g., for data analytics), based on criteria like their cost and performance characteristics.

The Future of Cloud Computing

I found this post on Twitter on May 19th, 2022:

Alvin Cheung Berkeley Intercloud

Alvin Cheung is an associate professor at Berkeley EECS and wrote the following in his Twitter comments:

we argue that cloud computing will evolve to a new form of inter-cloud operation: instead of storing data and running code on a single cloud provider, apps will run on an inter-operating set of cloud providers to leverage their specialized services / hw / geo etc, much like ISPs.

Alvin and his colleagues wrote a publication which states “A Berkeley View on the Future of Cloud Computing” that mentions the following very early in the PDF:

We predict that this market, with the appropriate intermediation, could evolve into one with a far greater emphasis on compatibility, allowing customers to easily shift workloads between clouds.

[…] Instead, we argue that to achieve this goal of flexible workload placement, cloud computing will require intermediation, provided by systems we call intercloud brokers, so that individual customers do not have to make choices about which clouds to use for which workloads, but can instead rely on brokers to optimize their desired criteria (e.g., price, performance, and/or execution location).

We believe that the competitive forces unleashed by the existence of effective intercloud brokers will create a thriving market of cloud services with many of those services being offered by more than one cloud, and this will be sufficient to significantly increase workload portability.

Intercloud Broker

Organizations place their workloads in that cloud which makes the most sense for them. Depending on different regulations, data classification, different cloud services, locations, or pricing, they then decide which data or workload goes to which cloud.

The people from Berkeley do not necessarily promote a multi-cloud architecture, but have the idea of an intercloud broker that places your workload on the right cloud based on different factors. They see the intercloud as an abstraction layer with brokering services:

In my understanding their idea goes towards the direction of an intelligent and automated cloud management platform that takes the decision where a specific workload and its data should be hosted. And that it, for example, migrates the workload to another cloud which is cheaper than the current one.

Cloud Native Technologies for Multi-Cloud

Companies are modernizing/rebuilding their legacy applications or create new modern applications using cloud native technologies. Modern applications are collections of microservices, which are light, fault tolerant and small. These microservices can run in containers deployed on a private or public cloud.

Which means, that a modern application is something that can adapt to any environment and perform equally well.

The challenge today is that we have modern architectures, new technologies/services and multiple clouds running with different technology stacks. And we have Kubernetes as framework, which is available in different formats (DIY or offerings like Tanzu TKG, AKS, EKS, GKE etc.)

Then there is the Cloud Native Computing Foundation (CNCF) and the open source community which embrace the principal of “open” software that is created and maintained by a community.

It is about building applications and services that can run on any infrastructure, which also means avoiding vendor or cloud lock-in.

Challenges of Interoperability and Multiple Clouds

If you discuss multi-cloud and infrastructure independent applications, you mostly end up with an endless list of questions like:

  • How can we achieve true workload mobility or application portability?
  • How do we deal with the different technology formats and the “language” (API) of each cloud?
  • How can we standardize and automate our deployments?
  • Is latency between clouds a problem?
  • What about my stateful data?
  • How can we provide consistent networking and security?
  • What about identity federation and RBAC?
  • Is the performance of each cloud really the same?
  • How should we encrypt traffic between services in multiple clouds?
  • What about monitoring and observability?

Workload Mobility and Application Portability without an Intercloud

VMware has a different view and approach how workload mobility and application portability can be achieved.

Their value add and goal is the same, but with a different strategy of abstracting clouds.

VMware is not building an intercloud but they provide customer a  technology stack (compute, storage, networking), or a cloud operating system if you will, that can run on top of every major public cloud provider like AWS, Azure, Google Cloud, IBM Cloud, Oracle Cloud and Alibaba Cloud.

VMware Workload Mobility

This consistent infrastructure makes it especially for virtual machines and legacy applications extremely easy to be migrated to any location.

What about modern applications and Kubernetes? What about developers who do not care about (cloud) infrastructures?

Project Cascade

At VMworld 2021, VMware announced the technology preview of “Project Cascade” which will provide a unified Kubernetes interface for both on-demand infrastructure (IaaS) and containers (CaaS) across VMware Cloud – available through an open command line interface (CLI), APIs, or a GUI dashboard.

The idea is to provide customers a converged IaaS and CaaS consumption service across any cloud, exposed through different Kubernetes APIs.

VMware Project Cascade

I heard the statement “Kubernetes is complex and hard” many times at KubeCon Europe 2022 and Project Cascade is clearly providing another abstraction layer for VM and container orchestration that should make the lives of developers and operators less complex.

Project Ensemble

Another project in tech preview since VMworld last year is “Project Ensemble“. It is about multi-cloud management platform that provides an app-centric self-service portal with predictive support.

Project Ensemble will deliver a unified consumption surface that meets the unique needs of the cloud administrator and SRE alike. From an architectural perspective, this means creating a platform designed for programmatic consumption and a firm “API First” approach.

I can imagine that it will be a service that leverages artificial intelligence and machine learning to simplify troubleshooting and that is capable in the future to intelligently place or migrate your workloads to the appropriate or best cloud (for example based on cost) including all attached networking and security policies.

Conclusion

I believe that VMware is on the right path by giving customers the option to build a cloud-agnostic infrastructure with the necessary abstraction layers for IaaS and CaaS including the cloud management platform. By providing a common way or standard to run virtual machines and containers in any cloud, I am convinced, VMware is becoming the defacto standard for infrastructure for many enterprises.

VMware Vision and Strategy 2022

By providing a consistent cloud infrastructure and a consistent developer model and experience, VMware bridges the gap between the developers and operators, without the need for an intercloud or intercloud protocol. That is the future of cloud computing.

 

Other relevant resources:

 

 

Build a Digital Manufacturing Platform with the VMware Edge Compute Stack

Build a Digital Manufacturing Platform with the VMware Edge Compute Stack

VMware revealed their edge computing vision at VMworld 2021. In VMware’s view the multi-cloud extends from the public clouds to private clouds to edge. Edge is about bringing apps and services closer to where they are needed, especially in sectors like retail, transportation, energy and manufacturing.

In verticals like manufacturing the edge was always important. It’s about producing things than you can sell. If you cannot produce, you lose time and money. Reliability, stability and factory uptime are not new requirements. But why is edge becoming so important now?

Without looking at any analyst report and only providing experience from the field, it is clear why. Almost all of the large enterprises are migrating workloads from their global (central) data centers to the public cloud. At the same time, customers are looking at new innovations and technologies to connect their machines, processes, people and data in a much more efficient way.

Which requirement did all my customers have in common? They didn’t want to move their dozens or hundreds of edge infrastructures to the public cloud, because the factories should work independently and autonomously in case of a WAN outage for example. Additionally, some VMware technologies were already deployed at the edge.

VMware Edge Compute Stack

This is why VMware introduced the so-called “Edge Compute Stack” (ECS) in October 2021, which is provides a unified platform to run VMs alongside containerized applications at the far edge (aka enterprise edge). ECS is a purpose-built stack that is available in three different editions (information based on initial availability from VMworld 2021):

VMware Edge Comput Stack Editions

As you can see, each VMware Edge Compute Stack edition has the vSphere Enterprise+ (hypervisor) included, software-defined storage with vSAN is optional, but Tanzu for running containers is always included.

While ECS is great, the purpose of this article is about highlighting different solutions and technologies that help you to build the foundation for a digital manufacturing platform.

IT/OT Convergence

You most probably have a mix of home-grown and COTS (commercial off-the-shelf) software, that need to be deployed in your edge locations (e.g., factories, markets, shops etc.). In manufacturing, OT (operational technology) vendors have just started the adoption of container technologies due to unique technology requirements and the business model that relies on proprietary systems.

The OT world is typically very hardware-centric and uses proprietary architectures. These systems and architectures, which were put into production 15-20 years ago, are still functional. It just worked.

While these methods and architectures have been very good, the manufacturing industry realized that this static and inflexible approach resulted in a technology debt, that didn’t allow any innovation for a long period of time.

Manufacturing companies are moving to a cloud-native architecture that should provide more flexibility and vendor interoperability with the same focus in mind: To provide a reliable, scalable and flexible infrastructure.

This is when VMware becomes relevant again with their (edge) compute stack. VMware vSphere allows you to run VMs and containers on the same platform. This is true for IT and OT workloads, that’s IT partial IT/OT covergence.

You may ask yourself how you then would  design the network. I’ll answer this topic in a minute.

Kubernetes Operations

IT platform teams, who design and manage the edge have to expand their (VMware) platform capabilities that allow them to deploy and host containers. Like I said before, this is why Tanzu is included in all the VMware Edge Compute Stack editions. Kubernetes is the new Infrastructure-as-a-Service (IaaS) and so it makes only sense that the container deployment and management capability is included.

How do you provide centralized or regional Kubernetes management and operations if you don’t have a global (regional) data center anymore?

With a hybrid approach, by using Tanzu for Kubernetes Operations (TKO), a set of SaaS services that allow you to run, manage, connect and secure your container infrastructure across clouds and edge locations.

IT/OT Security

Now you have the right platform to run your IT and OT workloads on the same hypervisor or compute platform. You also have a SaaS-based control plane to deploy and manage your Kubernetes clusters. 

As soon as you are dealing with a very dynamic environment where containers exist, you are having discussions about software-defined networking or virtualized networks. Apart from that, every organization and manufacturer are transforming their network and security at the edge and talk about network segmentation (and cybersecurity!).

Traditionally, you’ll find the Purdue Model implemented, a concept model for industrial control systems (ICS) that breaks the network in two zones:

  • Information Technology (IT)
  • Operational Technology (OT)

The Purdue Model of Computer Integrated Manufacturing

Source: https://www.automationworld.com/factory/iiot/article/21132891/is-the-purdue-model-still-relevant 

In these IT and OT zones you’ll find subzones that describe different layers and the ICS components. As you can see as well, each level is secured by a dedicated physical firewall appliance. From this drawing one could say that the IT and OT world converge in the DMZ layer, because of the bidirectional traffic flow.

VMware is one of the pioneers when it comes to network segmentation that helps you driving IT/OT convergence. This is made possible by using network virtualization. As soon as you are using the VMware hypervisor and its integrated virtual switch, you are already using a virtualized network.

To bring IT and OT closer together and to provide a virtualized network design based on the Purdue Model including a zero-trust network architecture, you would start looking at VMware NSX to implement that.

In case you are looking for a software-defined load balancer or application delivery controller, have a look at NSX Advanced Load Balancer (formerly known as Avi).

PLC Virtualization

In level 2 of the Purdue Model, which hosts the systems for supervising, monitoring and controlling the physical process, you will find components like human-machine interfaces (HMI) and supervisory control and data acquisition (SCADA) software.

In level 3, manufacturing execution systems (MES) can be found.

Nowadays, most companies already run their HMIs, SCADAs and MES software in virtual machines on the VMware vSphere hypervisor.

The next big thing is the virtualization of PLCs (programmable logic controller), which is an industrial computer that controls manufacturing processes, such as machines, assembly lines and robotic devices. Traditional PLC implementations in hardware are costly and lack scalability.

That is why the company SDA was looking for a less hardware-centric but more software-centric approach and developed the SDA vPLC that is able to meet sub 10ms performance.

This vPLC solution is based on a hybrid architecture between a cloud system and the industrial workload at the edge, which has been tested on VMware’s Edge Compute Stack.

Monitoring & Troubleshooting

One area, which we haven’t highlighted yet, is the monitoring and troubleshooting of virtual machines (VMs). The majority of your workloads are still VM-based. How do you monitor these workloads and applications, deal with resource and capacity planning/management, and troubleshoot, if you don’t have a central data center anymore?

With the same approach as before – just with a cloud-based service. Most organizations rely on vRealize Operations (vROps) and vRealize Log Insight (vRLI) for their IT operations and platform teams gain visibility in all the main and edge data centers.

You can still use vROps and vRLI (on-premises) in your factories, but VMware recommends using the vRealize Cloud Universal (vRCU) SaaS management suite, that gives you the flexibility to deploy your vRealize products on-premises or as SaaS. In an edge use case the SaaS-based control plane just makes sense.

In addition to vRealize Operations Cloud you can make use of the vRealize True Visibility Suite (TVS), that extends your vRealize Operations platform with management packs and connectors to monitor different compute, storage, network, application and database vendors and solutions.

Factory VDI

Some of your factories may need virtual apps or desktops and for edge use cases there are different possible architectures available. Where a factory has a few hundred of concurrent users, a dedicated standalone VDI/RDSH deployment might make sense. What if you have hundreds of smaller factories and don’t want to maintain a complete VDI/RDSH infrastructure?

VMware is currently working on a new architecture for VMware Horizon (aka VMware Horizon Next-Generation) and their goal is to provide a single, unified platform across on-premises and cloud environments.  They also plan to do that by introducing a pod-less architecture that moves key components to the VMware-hosted Horizon (Cloud) Control Plane.

This architecture is perfectly made for edge use cases and with this approach customers can reduce costs, expect increased scalability, improve troubleshooting and provide a seamless experience for any edge or cloud location.

VMware Horizon Next-Generation 

Management for Enterprise Wearables

If your innovation and tech team are exploring new possibilities with wearable technologies like augmented reality (AR), mixed reality (MR) and virtual reality (VR) head-mounted displays (HMDs), then VMware Workspace ONE Unified Endpoint Management (UEM) can help you to securely manage these devices!

Workspace ONE UEM is very strong when it comes to the modern management of Windows Desktop and macOS operating systems, and device management (Android/iOS).

Conclusion

As you can see, VMware has a lot to offer for the enterprise edge. Organizations that are multi-cloud and keep their edge locations on-premises, have a lot of new technologies and possibilities nowadays.

VMware’s strengths are unfolded as soon as you combine different solutions. And these solutions help you to work on your priorities and requirements to build the right foundation for a digital manufacturing platform.

DevSecOps with VMware Tanzu – Intrinsic Security for a Modern Application Supply Chain

DevSecOps with VMware Tanzu – Intrinsic Security for a Modern Application Supply Chain

Intrinsic security is something we heard a lot in the past from VMware and it was mostly used to describe the strategy and capabilities behind the Carbon Black portfolio (EDR) that is complemented with the advanced threat prevention from NSX (NDR), that form together the VMware XDR vision.

I see similarities between intrinsic security and workout I am doing in the gym. My goal is to build more strength and power, and to become healthier in general. For additional muscle gain benefits and to be more time efficient, I have chosen compound exercises. I am not a fan of single muscle group exercises, which involve isolation exercises. Our body has a lot of joints for different movements, and I think it’s just natural if you use multiple muscle groups and joints during a specific exercise.

Therefore, when you perform compound exercises, you involve different muscles to complete the movement. This improves your intermuscular coordination of your muscles. In addition, as everyone would tell you, these exercises improve your core strength and they let your body become a single unit.

While doing weight training, it is very important to use the proper technique and equipment. Otherwise, the risk for injuries and vulnerabilities increases.

This is what intrinsic security means for me! And I think this is very much relevant to understand when talking about DevSecOps.

Understanding DevSecOps

For VMware, talking to developers and talking about DevOps started in 2019 when they presented VMware Tanzu the first time at VMworld. The ideas and innovation behind the name “Tanzu” should bring developers and IT operators closer together for collaboration.

DevOps is the combination of different practices, tools and philosophies that should help an organization to deliver applications and services at a higher pace. In the example above it would mean, that application developers and operations teams are not working isolated in silos anymore, they become one team, a single unit. But technology plays very important role to support the success of the new mindset and culture!

DevOps is about efficiency and the automation of manual tasks or processes. You want to become fast, flexible and efficient. When you put security in the center of this, then we start talking about DevSecOps. You want to know if one of your muscles or parts of the body become weak (defect) or vulnerable.

Tanzu DevSecOps Flow

Depending on where you are right now on this application modernization journey, doing DevSecOps could mean a huge cultural and fundamental change to how you develop applications and do IT operations.

For me, DevSecOps is not about bringing security tools together from different teams and technologies. If DevOps and DevSecOps mean that you must change your mindset, then it is maybe also about time to consider the importance of new technology choices.

If DevSecOps means that you put security in the center of a DevOps- or container-centric environment, then security must become an intrinsic part of a modern application supply chain.

The VMware Tanzu portfolio has a lot of products and services to bring developers, operations and security teams together.

Where do we start? We need to “shift left” and this means we need to integrate security already early in the application lifecycle.

Code – Spring Framework

Before you can deliver an application to your customer, you need to develop it, you need to code. Application frameworks are a very effective approach for developing more secure and optimized applications.

Frameworks help to write code faster and more efficient. Not only does a framework can save your developers a lot of coding effort, but it also comes with pre-defined templates. They incorporate best practices and help you simplifying the overall application architecture.

Why is this important? To achieve better security or a more secure cloud native application, it makes sense to standardize and automate. Automation is key for security. Standardization makes it easier to understand or reuse code. You can write all the code yourself, but the chances are high that someone else did parts of your work already. Less variability reduces complexity and therefore enhances security.

There is the open-source Spring Framework for example, which uses Java as the underlying language (or .NET for Steeltoe). Both projects are managed by VMware and millions of developers use them.

Tanzu Spring Steeltoe

What happens next? You would now run your continuous integration (CI) process (integration tests, unit tests) and then you are ready to package or build your application.

Build – Tanzu Build Service (TBS)

So, your code is now good for release. If you want to deploy your application to a Kubernetes environment, then you need a secure, portable and reproducible build that can be checked for security vulnerabilities, and you need an easy way to patch those vulnerabilities.

How are you going to build your container image where you application is going to be built into? A lot of customers and vendors have a dockerfile based approach.

VMware recommends Tanzu Build Service (TBS), which uses Tanzu Buildpacks that are based on the open-source Cloud Native Buildpacks CNCF project to turn application source code into container images. So, no dockerfiles.

TBS is constantly looking for changes in your source code and then automatically builds an image based on that. This means with TBS you don’t need any advanced knowledge of container packaging formats or know how to optimally construct a container creation script for a given programming language.

Tanzu Build Service knows all the images you have built and understands all the dependencies and components you have used. If something changes, your image is going to be rebuilt automatically and then stored in a registry of your choice. More about the registry in a second.

Tanzu Build Service

What happens if a vulnerability comes out and one of your libraries, operating systems or components is affected? TBS would patch this vulnerability and all the affected downstream container images would be updated automatically.

Imagine how happy your CISO would be about this way of building secure container images! 🙂

Build – Harbor

We have now pushed our container image to a container repository, a so-called registry. VMware uses Harbor (open-source cloud native registry by VMware, donated to the CNCF in 2018) as an enterprise-grade storage for container images. Additionally, Harbor provides static analysis of vulnerabilities in images through open-source projects like Trivy and Clair.

Tanzu Build Service Harbor

We have now developed our applications and stored our packaged images in our Harbor registry. What else do we need?

Build – VMware Application Catalog (VAC)

Developers are not going to build everything by themselves. Other services like databases or caching are needed to build the application as well and there are so many known and pre-packaged open-source software freely available online. This brings additional security risks and provides malicious actors to publish container images that contain vulnerabilities.

How can you mitigate this risk and reduce the chance for a critical application outage or breach?

In 2019, VMware acquired Bitnami, which delivers and maintains a catalog of 130+ pre-packaged and ready-to-use open-source application components, that are “continuously maintained and verifiably tested for use in production environments”.

Known as VMware Application Catalog (VAC, formerly also known as Tanzu Application Catalog), VAC as a SaaS offering provides your organization a customizable private collection of open-source software and services, that can automatically be placed in your private container image registry. In this case in your Harbor registry.

Example apps that are supported today:

Language Runtimes Databases App Components Developer Tools Business Apps
Nodejs MySQL Kafka Artifactory WordPress
Python PostgreSQL RabbitMQ Jenkins Drupal
Ruby MariaDB TensorFlow Redmine Magento
Java MongoDB ElasticSearch Harbor Moodle

How does it work?

VMware Application Catalog - How it works

There are two product features that I would like to highlight:

  • Build-time CVE scan reports for container images using Trivy
  • Build-time Antivirus scans for container images using ClamAV

Your application, built by Tanzu Build Service and VMware Application Catalog, is complete now, and stored in your Harbor registry. And since you use VAC, you also have your “marketplace” of applications, that is curated by a (security) team in your organization. 

If you want to see VAC in action, have a look at this Youtube video.

Note: Yes, VAC is a SaaS hosted application and you may have concerns because you are a public/federal customer. That’s no problem. Consider VAC as your trusted source where you can copy things from. There is no data stored in the public cloud nor does it run anything up there. Download your packages from this trusted repository over to you air gapped environment.

Run – Tanzu Kubernetes Grid (TKG)

Your application is ready to be deployed and the next step is in your pipeline is “continuous deployment“. We finally can deploy our applications to a Kubernetes cluster.

Tanzu Kubernetes Grid or TKG is VMware’s own consistent and conformant Kubernetes distribution that can run in any cloud. VMware’s strategy is about running the same Kubernetes dial tone across data centers and public cloud, which enables a consistent and secure experience for your developers.

TKG has a tight integration with vSphere called “vSphere with Tanzu”. Since TKG is an enterprise-ready Kubernetes for a multi-cloud infrastructure, it can run also in all major public clouds.

If consistent automation is important to you and you want to run Kubernetes in an air gapped environment, where there is no AWS, Azure or any other major public cloud provider, then a consistent Kubernetes version like TKG would add value to your infrastructure.

Manage/Operate – Tanzu Mission Control (TMC)

How do we manage these applications on any Kubernetes cluster (VMware TKG, Amazon EKS, Microsoft AKS, Google GKE), that can run in any cloud?

Some organizations started with TKG and others already started with managed Kubernetes offerings like EKS, AKS or GKE. That’s not a problem. The question here is how you deploy, manage, operate, and secure all these different clusters.

VMware’s solution for that is Tanzu Mission Control, which is also a SaaS-based tool hosted by VMware, that is the first offering I’m going to cover, that is part of a global Tanzu control plane. TMC is a solution that makes your multi-cloud and multi-cluster Kubernetes management much easier.

With TMC you’ll get:

  • Centralized Cluster Lifecycle Management. TMC enables automated provisioning and lifecycle management of TKG cluster across any cloud. It provides centralized provision, scaling, upgrading and deletion functions for your Kubernetes clusters. Tanzu Mission Control also allows you to attach any CNCF-conformant Kubernetes cluster (K8s on-prem, K8s in public cloud, TKG, EKS, AKS, GKE, OpenShift) to the platform for management, visibility, and analytic purposes. I would expect that we can use TMC in the future to lifecycle managed offerings like EKS, AKS or GKE.
  • Centralized Policy Management. TMC has a very powerful policy engine to apply consistent policies across clusters and clouds. You can create security, access, network, quota, registry, and custom policies (Open Policy Agent framework).
  • Identity and Access Management. Another important feature you don’t want to miss with DevSecOps in mind is centralized authentication and authorization, and identity federation from multiple sources like AD, LDAP and SAML. Make sure you give the right people or project teams the right access to the right resources.
  • Cluster Inspection. There are to inspection that you can run against your Kubernetes clusters. TMC leverages the built-in open-source project Sonobuoy that makes sure your cluster are configured in a conformant way with the Cloud Native Computing Foundation (CNCF) standards. Tanzu Mission Control provides CIS Benchmark inspection as another option.

Tanzu Mission Control

Tanzu Mission Control integrates with other Tanzu products like Tanzu Observability and Tanzu Service Mesh, which I’m covering later.

Connect – Antrea

VMware Tanzu uses Antrea as the default container network interface (CNI) and Kubernetes NetworkPolicy to provide network connectivity and security for your pods. Antrea is an open-source project with active contributors from Intel, Nvidia/Mellanox and VMware, and it supports multiple operating systems and managed Kubernetes offerings like EKS, AKS or GKE!

Antrea uses Open vSwitch (OvS) as the networking data plane in every Kubernetes node. OvS is a high performance and programmable virtual switch that not only supports Linux, but also Windows. VMware is working on the achievement to reach feature parity between them, and they are even working on the support for ARM hosts in addition to x86 hosts.

Antrea creates overlay networks using VXLAN or Geneve for encapsulation and encrypts node-to-node communication if needed.

Connect & Secure – NSX Advanced Load Balancer

Ingress is a very important component of Kubernetes and let’s you configure how an application can or should be accessed. It is a set of routing rules that describe how traffic is routed to an application inside of a Kubernetes cluster. So, getting an application up and running is only the half side of the story. The application still needs a way for users to access it. If you would like to know more about “ingress”, I can recommend this short introduction video.

While a project like Contour is a great open-source project, VMware recommends Avi (aka NSX Advanced Load Balancer) provides much more enterprise-grade features like L4 load balancing, L7 ingress, security/WAF, GSLB and analytics. If stability, enterprise support, resiliency, automation, elasticity, and analytics are important to you, then Avi Enterprise, a true software-defined multi-cloud application delivery controller, is definitely the better fit.

 

Secure – Tanzu Service Mesh (TSM)

Let’s take a step back and recap what we have achieve until here. We have a standardized and automated application supply chain, with signed container images, that can be deployed in any conformant Kubernetes cluster. We can also access the application from outside and pod-to-pod communication, so that applications can talk to each other. So far so far good.

Is there maybe another way to stitch these services together or “offload” security from the containers? What if I have microservices or applications running in different clouds, that need to securely communicate with each other?

A lot of vendors including VMware realized that the network is the fabric that brings microservices together, which in the end form the application. With modernized or partially modernized apps, different Kubernetes offerings and a multi-cloud environment, we will find the reality of hybrid applications which sometimes run in multiple clouds.

This is the moment when you need to think about the connectivity and communication between your app’s microservices. Today, many Kubernetes users do that by implementing a service mesh and Istio is most probably the most used open-source project platform for that.

The thing with service mesh is, while everyone thinks it sounds great, that there are new challenges that service mesh brings by itself. The installation and configuration of Istio is not that easy and it takes time. Besides that, Istio is also typically tied to a single Kubernetes cluster and therefore Istio data plane – and organizations usually prefer to keep their Kubernetes clusters independent from each other. This leaves us with security and policies tied to a Kubernetes cluster or cloud vendor, which leaves us with silos.

Tanzu Service Mesh, built on VMware NSX, is an offering that delivers an enterprise-grade service mesh, built on top of a VMware-administrated Istio version.

The big difference and the value that comes with Tanzu Service Mesh (TSM) is its ability to support cross-cluster and cross-cloud use cases via Global Namespaces.

Global Namespaces

A Global Namespace is a unique concept in Tanzu Service Mesh and connects resources and workloads that form the application into a virtual unit. Each GNS is an isolated domain that provides automatic service discovery and manages the following functions that are port of it, no matter where they are located:

  • Identity. Each global namespace has its own certificate authority (CA) that provisions identities for the resources inside that global namespace
  • Discovery (DNS). The global namespace controls how one resource can locate another and provides a registry.
  • Connectivity. The global namespace defines how communication can be established between resources and how traffic within the global namespace and external to the global namespace is routed between resources.
  • Security. The global namespace manages security for its resources. In particular, the global namespace can enforce that all traffic between the resources is encrypted using Mutual Transport Layer Security authentication (mTLS).
  • Observability. Tanzu Service Mesh aggregates telemetry data, such as metrics for services, clusters, and nodes, inside the global namespace.

Monitor – Tanzu Observability (TO)

Another important part of DevSecOps with VMware Tanzu is observability. What happens if something goes wrong? What are you doing when an application is not working anymore as expected? How do you troubleshoot a distributed application, split in microservices, that potentially runs in multiple clouds?

Image an application split into different smaller services, that are running in a pod, which could be running in a virtual machine on a specific host in your on-premises datacenter, at the edge, or somewhere in the public cloud.

You need a tool that supports the architecture of a modern application. You need a solution that understands and visualizes cloud native applications.

That’s when VMware suggests Tanzu Observability to provide you observability and deep visibility across your DevSecOps environment.

Tanzu Observability

Tanzu Observability has an integration with Tanzu Mission Control, which has the capability then to install the Wavefront Kubernetes collector on your Kubernetes clusters. The name “Wavefront” comes from the company Wavefront, which VMware acquired in 2017.

Since Tanzu Observability is only offered as a SaaS version, I would like to highlight that it is “secure by design” according to VMware:

  • Isolation of customer data
  • User & Service Account Authentication (SSO, LDAP, SAML)
  • RBAC & Authorization
  • Data encryption at rest and in transit
  • Data at rest is managed by AWS S3 (protected by KMS)
  • Certifications like ISO 27001/27017/27018 or SOC 2 Type 1

Summary – Tanzu Portfolio Capabilities

The container build and deploy process consists of the Spring runtime, Tanzu Application Catalog and Tanzu Build Service.

The global control plane (SaaS) is formed by Tanzu Mission Control, Tanzu Service Mesh and Tanzu Observability.

The networking layer consists of NSX Advanced Load Balancer for ingress & load balancing and uses Antrea for container networking.

The foundation of this architecture is built on VMware’s Kubernetes runtime called Tanzu Kubernetes Grid.

Tanzu Advanced Capabilities

Note: There are other components like Application Transformer or Tanzu SQL (part of Tanzu Data Services), which I haven’t covered in this article.

Secure – Carbon Black Cloud Container

Another solution that might be of interest for you is Carbon Black Container. CB Container also provide visibility and control that DevSecOps team need to secure Kubernetes clusters and the application the deploy on top of them.

This solution provides container vulnerability & risk dashboard, image scanning, compliance policy scanning, CI/CD integration, integration with Harbor and supports any upstream Kubernetes like TKG, EKS, AKS, GKE or OpenShift.

Conclusion

DevSecOps with VMware Tanzu helps you to simplify and secure the whole container and application lifecycle. VMware has made some strategic acquisitions (Heptio, Pivotal, Bitnami, Wavefront, Octarine, Avi Networks, Carbon Black) in the past to become a major player the world of containerization, Kubernetes and application modernization.

I personally believe that VMware’s approach and Tanzu portfolio have a very strong position in the market. Their modular approach and the inclusion of open-source projects is a big differentiator. Tanzu is not just about Kubernetes, it’s about building, securing and managing the applications.

If you have a strong security focus, VMware can cover all the layers up from the hypervisor to the applications that can be deployed in any cloud. That’s the strength and unique value of VMware: A complete and diverse portfolio with products, that provide even more value when combined together.

Don’t forget, that VMware is number 1 when it comes to data center infrastructures and most of the customer workloads are still running on-premises. That’s why I believe that VMware and their Tanzu portfolio are very well positioned.

In case you missed it the announcements a few weeks ago, check out  Tanzu Application Platform and Tanzu for Kubernetes Operations that meet the needs of all those who are concerned with DevSecOps!

And if you would like to know more about VMware Tanzu in general, have a look at my “10 Things You Didn’t Know About VMware Tanzu” article.

 

VMworld 2021 – Summary of VMware Projects

VMworld 2021 – Summary of VMware Projects

On day 1 of VMworld 2021 we have heard and seen a lot of super exciting announcements. I believe everyone is excited about all the news and innovations VMware has presented so far.

I’m not going to summarize all the news from day 1 or day 2 but thought it might be helpful to have an overview of all the VMware projects that have been mentioned during the general session and solution keynotes.

Project Cascade

VMware Project Cascade

Project Cascade will provide a unified Kubernetes interface for both on-demand infrastructure (IaaS) and containers (CaaS) across VMware Cloud – available through an open command line interface (CLI), APIs, or a GUI dashboard.  Project Cascade will be built on an open foundation, with the open-sourced VM Operator as the first milestone delivery for Project Cascade that enables VM services on VMware Cloud.

VMworld 2021 session: Solution Keynote: The VMware Multi-Cloud Computing Infrastructure Strategy of 2021 [MCL3217]

Project Capitola

VMware Project Capitola

Project Capitola is a software-defined memory implementation that will aggregate tiers of different memory types such as DRAM, PMEM, NVMe and other future technologies in a cost-effective manner, to deliver a uniform consumption model that is transparent to applications.

VMworld 2021 session: Introducing VMware Project Capitola: Unbounding the ‘Memory Bound’ [MCL1453] and How vSphere Is Redefining Infrastructure For Running Apps In the Multi-Cloud Era [MCL2500]

Project Ensemble

VMware Project Ensemble

Project Ensemble integrates and automates multi-cloud management with vRealize. This means that all the different VMware cloud management capabilities—self-service, elasticity, metering, and more—are in one place. You can access all the data, analytics, and workflows to easily manage your cloud deployments at scale.

VMworld 2021 session: Introducing Project Ensemble Tech Preview [MCL1301]

Project Arctic

VMware Project Arctic

Project Arctic is “the next evolution of vSphere” and is about bringing your own hardware while taking advantage of VMware Cloud offerings to enable a hybrid cloud experience. Arctic natively integrates cloud connectivity into vSphere and establishes hybrid cloud as the default operating model.

VMworld 2021 session: What’s New in vSphere [APP1205] and How vSphere Is Redefining Infrastructure For Running Apps In the Multi-Cloud Era [MCL2500]

Project Monterey

VMware Project Monterey

Project Monterey was announced in the VMworld 2020 keynote. It is about SmartNICs that will redefine the data center with decoupled control and data planes for management, networking, storage and security for VMware ESXi hosts and bare-metal systems.

VMworld 2021 session: 10 Things You Need to Know About Project Monterey [MCL1833] and How vSphere Is Redefining Infrastructure For Running Apps In the Multi-Cloud Era [MCL2500]

Project Iris

I don’t remember anymore which session mentioned Project Iris but it is about the following:

Project Iris discovers and analyzes an organization’s full app portfolio; recommends which apps to rehost, replatform, or refactor; and enables customers to adapt their own transformation journey for each app, line of business, or data center.

Project Pacific

Project Pacific was announced at VMworld 2019. It is about re-architecting vSphere to integrate and embed Kubernetes and is known as “vSphere with Tanzu” (or TKGS) today. In other words, Project Pacific transformed vSphere into a Kubernetes-native platform with an Kubernetes control plane integrated directly into ESXi and vCenter. Pacific is part of the Tanzu portofolio.

VMworld 2019 session: Introducing Project Pacific: Transforming vSphere into the App Platform of the Future [HBI4937BE]

Project Santa Cruz

VMware Project Santa Cruz

Project Santa Cruz is a new integrated offering from VMware that adds edge compute and SD-WAN together to give you a secure, scalable, zero touch edge run time at all your edge locations. It connects your edge sites to centralized management planes for both your networking team and your cloud native infrastructure team. This solution is OCI compatible: if your app runs in a container, it can run on Santa Cruz.

VMworld 2021 session: Solution Keynote: What’s Next? A Look inside VMware’s Innovation Engine [VI3091]

Project Dawn Patrol

Project Dawn Patrol

So far, Project Dawn Patrol was only mentioned during the general session. “It will give you full visibility with a map of all your cloud assets and their dependencies”, Dormain Drewitz said.

VMworld 2021 session: General Session: Accelerating Innovation, Strategies for Winning Across Clouds and Apps [GEN3103]

Project Radium

VMware Project Radium

Last year VMware introduced vSphere Bitfusion which allow shared access to a pool of GPUs over a network. Project Radium expands the fetature set of Bitfusion to other architectures and will support AMD, Graphcore, Intel, Nvidia and other hardware vendors for AI/ML workloads.

VMworld 2021 session: Project Radium: Bringing Multi-Architecture compute to AI/ML workloads [VI1297]

Project IDEM

IDEM has been described as an “easy to use management automation technology”.

VMworld 2021 session: Solution Keynote: What’s Next? A Look inside VMware’s Innovation Engine [VI3091] and Next-Generation SaltStack: What Idem Brings to SaltStack [VI1865]

Please comment below or let me know via Twitter or LinkedIn if I missed a new or relevant VMware project. 😉

Must Watch VMworld Multi-Cloud Sessions

I recently wrote a short blog about some of the sessions I recommend to customers, partners and friends.

If you would like to know more about the VMware multi-cloud strategy and vision, have a look at some of the sessions below:

VMworld 2021 Must Watch Sessions

 

VMware is Becoming a Leading Cybersecurity Vendor

VMware is Becoming a Leading Cybersecurity Vendor

For most organizations it is still new that they can talk about cybersecurity with VMware. VMware’s intrinsic security vision is something we have seen the first time at VMworld 2019, and since then it has become more a strategy than a vision.

VMware is not new to enterprise security and it didn’t start with Workspace ONE nor with NSX. Security was already part of their DNA since it was possible for the first time that two virtual machines can share a physical host and have isolated compute resources assigned.

Another example of (intrinsic) security came with vSAN and the encryption of data at rest, then followed by unified endpoint management and identity/access management with Workspace ONE. But wait!

It was August 2013 when Pat Gelsinger introduced NSX as the platform for network virtualization, which included the distributed firewall capability already. The internal firewall is built into the VMware hypervisor since almost 8 years now, wow!

NSX Service-Defined Firewall

I had no customer so far, who wasn’t talking about achieving zero trust security with micro-segmentation to prevent lateral (east-west) movement. Zero trust is one approach to improve data center defenses with the inspection of every traffic flow within the data center. The idea is to divide the data center infrastructure into smaller security zones and that the traffic between the zones is inspected based on the organization’s defined policies.

Perimeter Defense vs Micro-Segmentation

Micro-segmentation puts a firewall to each virtual machine or workload, allowing us to protect all east-west communication.

So, deploy micro-segmentation and the problem is solved, right? Not quite. While the concept of micro-segmentation has been around for a while, organizations still face barriers when trying to apply it in practice.

Let’s have a look at some of the barriers to micro-segmentation and why this solution alone is not enough (anymore) to achieve zero trust:

  • Policy discovery challenges – Identifying the right micro-segments and configuring the proper security policies is an extremely daunting task, especially in a dynamic data center environment.
  • Limited-access controls – Basing micro-segmentation solely on L4 attributes (e.g., IP addresses and ports) is not enough. The ephemeral nature of applications and flows requires more than that.
  • Reliance on agents – Some micro-segmentation implementations require the installation of extra software agents on each virtual machine (VM), causing complexity and introducing vulnerability.
  • Lack of threat detection and prevention – Threats often masquerade as normal-looking traffic. Settling for basic traffic blocking rules isn’t enough.

What does that tell us? Understanding the current applications’ topology and communication flows between their sub-services and -components is not easy. And with applications, which become less monolithic but very dynamic and distributed across multiple clouds, it becomes almost impossible, right?

NSX Intelligence is a home-grown solution that automates policy discovery, understands the communication between services and can construct apps and flows maps (topologies).

NSX Intelligence Recommendations

Can we assume that traffic from A to B over HTTPS is safe per se with micro-segmentation? Nope.

If we want to enhance traffic analysis capabilities and have a deeper look into traffic, the L7 (application layer) capabilities for micro-segmentation can be used.

Firewall rules cannot consume application IDs. A context-aware firewall identifies applications and enforces a micro-segmentation for east-west traffic, independent of the port that the application uses.

Other use case: For virtual desktop infrastructures (VDI), you could use VMware NSX’s ability to provide Active Directory identity-based firewall (IDFW) rules.

Okay. We have a topology now and can create context-aware service-defined firewall rules. How can we differentiate between good or bad traffic? How can we detect network anomalies?

Today’s attacks are becoming more sophisticated and hackers use masquerading techniques to embed threats within normal-looking traffic flows. Micro-segmentation alone will not intercept hidden threats, it only identifies traffic flows that should be allowed or blocked.

It’s time to talk about advanced inspection capabilities.

NSX Distributed IDS/IPS

In general, for a firewall to inspect traffic, the traffic has to pass through it. In a virtual world this means we would redirect traffic from the VM’s to the firewalls and back. A practice called hair-pinning:

Firewall Hair-Pinning

That results in additional traffic and unnecessary latency. NSX has a distributed architecture, there is no centralized appliance that limits security capacity and network traffic doesn’t need to be hair-pinned to a network security stack for traffic inspection. Everything done with physical appliance can now be done in software (see coloring).

Software-Defined Networking without Hair-Pinning

The term intrinsic security always means that security is built into the infrastructure. The micro-segmentation capabilities including NSX Intelligence come without an agent – no reliance on agents!

The VMware NSX Distributed IDS/IPS functionality adds additional traffic inspection capabilities to the service-defined firewall and follows the same intrinsic security principles.

Note: These regular-expression IDS/IPS engines detect traffic patterns and are programmed to look for malicious traffic patterns.

NSX Distributed IDPS

NSX Advanced Threat Prevention (ATP)

At VMworld 2020 VMware announced NSX Advanced Threat Protection, that brings technology from their Lastline acquisition to the NSX service-defined firewall.

In my understanding, Lastline’s core product was a malware sandbox that can go deeper (than other sandboxes from other vendors) by using a full-system emulation to look at every instruction the malware executes.

The Lastline system uses machine learning that recognizes essential elements of an attack, unlike the narrow signature-based systems that miss the many variants an attacker may use. The Lastline approach is not just anomaly detection – anomaly detection treats every outlier as bad and results in many false positives. Lastline leverages the deep understanding of malicious behavior to flag clearly bad activities such as East-West movement, command and control activity, and data exfiltration.

This brings us to the powerful combination of the existing VMware capabilities with recently integrated Lastline feature set:

NSX FW with ATP Features

NSX Network Detection and Response

Network Detection and Response (NDR) is a category of security solutions that complement EDR (we talk about Endpoint Detection and Response later) tools.

Powered by artificial intelligence (AI), NSX NDR maps and defends against MITRE ATT&CK techniques with the current capabilities:

NSX NDR MITRE ATTACK Framework Capabilities Q2 2021

NSX NDR protects the network, cloud and hybrid cloud traffic, and provides a cloud-based and on-prem architecture that enables sensors to gain comprehensive visibility into traffic that crosses the network perimeter (north/south), as well as traffic that moves laterally inside the perimeter (east/west).

NSX NDR uses a combination of four complementary technologies to detect and analyze advanced threats:

NSX NDR Technologies

Behavior-based Network Traffic Analysis (NTA)

Network Traffic Analysis tools are all about detecting anomalies within the network (on-prem and public cloud) and use AI to create models of normal network activity and then alert on anomalies.

VMware NTA Anomalies

The challenge today is that not all anomalies are malicious. With Lastline’s NTA, VMware can now pick up threat behaviors and correlate these to network anomalies and vice versa. Because of this, according to VMware, they have the industry’s most accurate threat detection with minimal false positives.

NSX NDR NTA Anomaly 2

Intrusion Detection and Prevention System (IDPS)

The NSX Advanced Threat Protection bundle includes IDS/IPS, which is integrated into NSX. The NSX Distributed IDS/IPS benefits from the unique application context from the hypervisor and network virtualization layers to make threat detection more accurate, efficient and dynamic.

The key capabilities of NSX Distributed IDS/IPS include:

  • Distributed analysis
  • Curated, context-based signature distribution
  • Application context-driven threat detection
  • Policy and state mobility
  • Automated policy lifecycle management

Use cases for NSX Distributed IDS/IPS include:

  • Easily achieving regulatory compliance
  • Virtualizing security zones
  • Replacing discrete appliances
  • Virtual patching vulnerabilities

NSX Advanced Threat Analyzer (Sandbox)

Included with NSX Advanced Threat Prevention, Advanced Threat Analyzer provides complete malware analysis and enables accurate detection and prevention of advanced threats. It deconstructs every behavior engineered into a file or URL, and sees all instructions that a program executes, all memory content, and all operating system activity.

NSX NDR Sandbox Ransomware

Other malware detection technologies, such as traditional sandboxes, only have visibility down to the operating system level. They can inspect content and identify potentially malicious code, but they can’t interact with malware like NSX Advanced Threat Analyzer can. As a result, they have significantly lower detection rates and higher false positives, in addition to being easily identified and evaded by advanced malware. (Advanced threats evade other sandboxing technologies by recognizing the sandbox environment or using kernel-level exploits.)

VMware Threat Analysis Unit (TAU)

With the Lastline acquisition VMware could further increase the capabilities provided by the VMware Carbon Black Threat Analysis Unit (TAU) with network-centric research and behavioral analysis.

The VMware Threat Analysis Unit automatically shares the malware characteristics, behaviors and associated IoCs (Indicator of Compromises) of every malicious object curated and analyzed by VMware with all VMware customers and partners.

NSX Advanced Threat Analyzer continuously updates the VMware TAU in real time with intelligence from partner and customer environments around the world.

NSX Security Packages – How to get NSX ATP

According to the knowledge base article Product Offerings for VMware NSX Security 3.1.x (81231), the new NSX Security editions became available in October 2020:

  • NSX Firewall for Baremetal Hosts. For organizations needing an agent-based network segmentation solution.
  • NSX Firewall. For organizations with one or more sites (optionally including public cloud endpoints) that primarily need advanced security services, select advanced networking capabilities, and traffic flow visibility and security operations with NSX Intelligence.
  • NSX Firewall with Advanced Threat Protection. For organizations that need NSX Firewall capabilities as well as advanced threat prevention capabilities, such as IDS/IPS, threat analysis, and network detection and response.

Use Case with Network Virtualization

If you are a customer with a NSX Data Center Advanced or Enterprise+ license, who uses NSX for network virtualization only today, you just need the “NSX ATP add-on” for NSX Data Center Advanced or Enterprise+.

Note: The ATP add-on requires NSX-T 3.1 and above.

Use Case without Network Virtualization (no NSX Data Center)

If you have no need for network virtualization for now, you have the following options:

  1. If you look for base firewall features, you can get started with the NSX Firewall license.
  2. Should you look for base firewall features plus advanced threat protection, then start with NSX Firewall with Advanced Threat Protection.
  3. From here you still can down the network virtualization path and get the NSX Data Center Enterprise+ add-on for ATP

Use Case for VCF Customers

VCF customers have the option to start with the NSX ATP add-on for NSX NDC Adv/Ent+ as well.

If you are looking for more even security, want NSX Advanced Load Balancer (GSLB, WAF) and/or Carbon Black Cloud Workload Protection (NGAV, EDR, Audit & Remediation) as well, then you have to get the “network and app security” or “advanced security” add-on.

Carbon Black Endpoint Detection and Response (EDR)

Before the Carbon Black acquisition, VMware already had strong technology, but was not seen or known as cybersecurity vendor. And it was really this acquisition that made the whole industry understand that VMware had to be taken seriously now as a security vendor.

So, what is EDR according to Wikipedia?

“Endpoint detection and response technology is used to protect endpoints, which are computer hardware devices, from threat. Creators of the EDR technology-based platforms deploy tools to gather data from endpoint devices, and then analyze the data to reveal potential cyber threats and issues. It is a protection against hacking attempts and theft of user data. The software is installed on the end-user device and it is continually monitored. The data is stored in a centralized database. In an incident when a threat is found, the end-user is immediately prompted with preventive list of actions.”

EDR is essential since local activities on machines that may be malicious are not visible on the network. VMware Carbon Black EDR is an incident response and threat hunting solution designed for security operations centers (SOCs) and incident response (IR) teams. Enterprise EDR is delivered through the VMware Carbon Black Cloud, an endpoint protection platform that consolidates security in the cloud using a single agent, console and dataset.

The Lastline acquisition, which came after Carbon Black, was just another brilliant move from VMware!

XDR – VMware Security brings together EDR and NDR

Again, while EDR protects endpoints, NDR protects the network, so that an organization’s entire IT infrastructure is secured. EDR gives security professionals visibility into endpoints that might be compromised, but this isn’t enough when an attack has moved across the network and into other systems by the time the security team is aware of it.

This is where XDR comes in. VMware rolled out its Extended Detection and Response (XDR) strategy at VMworld 2020. By the way, it was in 2020 when Gartner named XDR as one of the top nine cybersecurity trends.

By providing a holistic view of activity across the system that avoids visibility gaps, XDR allows security teams to understand where a threat comes from and how it’s spreading across the environment – in order to eliminate it. In other words, XDR offers greater analysis and correlation capabilities and a holistic point of view.

EDR NDR Context Correlation

VMware’s XDR platform is the Carbon Black Cloud. Carbon Black Cloud’s evolution into an XDR platform includes product integrations with existing VMware products like Workspace ONE, vSphere and the NSX service-defined firewall, as well as third-party partner platforms.

At the Carbon Black Connect 2020 event, VMware announced launched their Next-Gen SOC Alliance that features integrations with the VMware Carbon Black Cloud to deliver key XDR capabilities and context into Security Information and Event Management (SIEM) technologies.

We’re in an epic war against cybercrime. We know the asymmetric nature of this war – you will not win by trying to staff your SOC with more analysts. Nor can the battle be won by deploying an individual technology focused on only one part of your IT infrastructure. EDR and NDR along with your SIEM form the winning combination you need to win the war.

Conclusion

The Carbon Black acquisition gave VMware a strong cybersecurity foundation to build on. The recent acquisition of Lastline VMware added sandboxing and network traffic analysis capabilities to their internal firewall, which is provided by NSX.

I don’t think it’s about “can VMware become a leading cybersecurity vendor” anymore. VMware has the most advanced internal firewall and is already becoming a leading cybersecurity vendor. The recent Global InfoSec award just confirms this statement:

  • Most Innovative in Endpoint Security” for VMware Carbon Black Cloud
  • “Market Leader in Firewall” for VMware NSX Service-defined Firewall

If you want to learn and see more, this YouTube video with Stijn Vanveerdeghem, Sr. Technical Product Manager and Chad Skipper, Global Security Technologist, is a good start.

Thanks for reading! 🙂

The Rise of VMware Tanzu Service Mesh

The Rise of VMware Tanzu Service Mesh

My last article focused on application modernization and data portability in a multi-cloud world. I explained the value of the VMware Tanzu portfolio by mentioning a consistent infrastructure and consistent application platform approach, which ultimately delivers a consistent developer experience. I also dedicated a short section about Tanzu Service Mesh, which is only one part of the unified Tanzu control plane (besides Tanzu Mission Control and Tanzu Observability) for multiple Kubernetes clusters and clouds.

When you hear or see someone writing about TSM, you very soon get to the point, where the so-called “Global Namespaces” (GNS) are being mentioned, which has the magic power to stitch hybrid applications together that run in multiple clouds.

Believe me when I say that Tanzu Service Mesh (TSM) is rising and becoming the next superstar of the VMware portfolio. I think Joe Baguley would agree here. 😀

Namespaces

Before we start talking about Tanzu Service Mesh and the magical power of Global Namespaces, let us have a look at the term “Namespaces” first.

Kubernetes Namespace

Namespaces give you a way to organize clusters into virtual carved out sub-clusters, which can be helpful when different teams, tenants or projects share the same Kubernetes cluster. This form of a namespace provides a method to better share resources, because it ensures fair allocation of these resources with the right permissions.

So, using namespaces gives you a way of isolation that developers never affect other project teams. Policies allow to configure compute resources by defining resource quotas for CPU or memory utilization. This also ensures the performance of a specific namespace, its resources (pods, services etc.) and the Kubernetes cluster in general.

Although namespaces are separate from each other, they can communicate with each other. Network policies can be configured to create isolated and non-isolated pods. For example, a network policy can allow or deny all traffic coming from other namespaces.

Ellei Mei explained this in a very easy in her article after Project Pacific had been made public in September 2019:

Think of a farmer who divides their field (cluster + cluster resources) into fenced-off smaller fields (namespaces) for different herds of animals. The cows in one fenced field, horses in another, sheep in another, etc. The farmer would be like operations defining these namespaces, and the animals would be like developer teams, allowed to do whatever they do within the boundaries they are allocated.

vSphere Namespace

The first time I heard of Kubernetes or vSphere Namespaces was in fact at VMworld 2019 in Barcelona. VMware then presented a new app-focused management concept. This concept described a way to model modern application and all their parts, and we call this a vSphere Namespace today.

With Project Pacific (today known vSphere with Tanzu or Tanzu Kubernetes Grid), VMware went one step further and extended the Kubernetes Namespace by adding more options for compute resource allocation, vMotion, encryption, high availability, backup & restore, and snapshots.

Rather than having to deal with each namespace and its containers, vSphere Namespaces (also called “guardrails” sometimes) can draw a line around the whole application and services including virtual machines.

Namespaces as the unit of management

With the re-architecture of vSphere and the integration of Kubernetes as its control plane, namespaces can be seen as the new unit of management.

Imagine that you might have thousands of VMs in your vCenter inventory that you needed to deal with. After you group those VMs into their logical applications, you may only have to deal with dozens of namespaces now.

If you need to turn on encryption for an application, you can just click a button on the namespace in vCenter and it does it for you. You don’t need to deal with individual VMs anymore.

vSphere Virtual Machine Service

With the vSphere 7 Update 2a release, VMware provided the “VM Service” that enables Kubernetes-native provisioning and management of VMs.

For many organizations legacy applications are not becoming modern over night, they become hybrid first before the are completely modernized. This means we have a combination of containers and virtual machines forming the application, and not find containers only. I also call this a hybrid application architecture in front of my customers. For example, you may have a containerized application that uses a database hosted in a separate VM.

So, developers can use the existing Kubernetes API and a declarative approach to create VMs. No need to open a ticket anymore to request a virtual machine. We talk self-service here.

Tanzu Mission Control – Namespace Management

Tanzu Mission Control (TMC) is a VMware Cloud (SaaS) service that provides a single control point for multiple teams to remove the complexities from managing Kubernetes cluster across multiple clouds.

One of the ways to organize and view your Kubernetes resources with TMC is by the creation of “Workspaces”.

Workspaces allows you to organize your namespaces into logical groups across clusters, which helps to simplify management by applying policies at a group level. For example, you could apply an access policy to an entire group of clusters (from multiple clouds) rather than creating separate policies for each individual cluster.

Think about backup and restore for a moment. TMC and the concept of workspaces allow you to back up and restore data resources in your Kubernetes clusters on a namespace level.

Management and operations with a new application view!

FYI, VMware announced the integration of Tanzu Mission Control and Tanzu Service Mesh in December 2020.

Service Mesh

A lot of vendors including VMware realized that the network is the fabric that brings microservices together, which in the end form the application. With modernized or partially modernized apps, different Kubernetes offerings and a multi-cloud environment, we will find the reality of hybrid applications which sometimes run in multiple clouds. 

This is the moment when you have to think about the connectivity and communication between your app’s microservices.

One of the main ideas and features behind a service mesh was to provide service-to-service communication for distributed applications running in multiple Kubernetes clusters hosted in different private or public clouds.

The number of Kubernetes service meshes has rapidly increased over the last few years and has gotten a lot of hype. No wonder why there are different service mesh offerings around:

  • Istio
  • Linkerd
  • Consul
  • AWS Apps Mesh
  • OpenShift Service Mesh by Red Hat
  • Open Service Mesh AKS add-on (currently preview on Azure)

Istio is probably the most famous one on this list. For me, it is definitely the one my customers look and talk about the most.

Service mesh brings a new level of connectivity between services. With service mesh, we inject a proxy in front of each service; in Istio, for example, this is done using a “sidecar” within the pod.

Istio’s architecture is divided into a data plane based on Envoy (the sidecar) and a control plane, that manages the proxies. With Istio, you inject the proxies into all the Kubernetes pods in the mesh.

As you can see on the image, the proxy sits in front of each microservice and all communications are passed through it. When a proxy talks to another proxy, then we talk about a service mesh. Proxies also handle traffic management, errors and failures (retries) and collect metric for observability purposes.

Challenges with Service Mesh

The thing with service mesh is, while everyone thinks it sounds great, that there are new challenges that service mesh brings by itself.

The installation and configuration of Istio is not that easy and it takes time. Besides that, Istio is also typically tied to a single Kubernetes cluster and therefore Istio data plane – and organizations usually prefer to keep their Kubernetes clusters independent from each other. This leaves us with security and policies tied to a Kubernetes cluster or cloud vendor, which leaves us with silos.

Istio supports a so-called multi-cluster deployment with one service mesh stretched across Kubernetes clusters, but you’ll end up with a stretched Istio control plane, which eliminates the independence of each cluster.

So, a lot of customers also talk about better and easier manageability without dependencies between clouds and different Kubernetes clusters from different vendors.

That’s the moment when Tanzu Service Mesh becomes very interesting. 🙂

Tanzu Service Mesh (formerly known as NSX Service Mesh)

Tanzu Service Mesh, built on VMware NSX, is an offering that delivers an enterprise-grade service mesh, built on top of a VMware-administrated Istio version.

When onboarding a new cluster on Tanzu Service Mesh, the service deploys a curated version of Istio signed and supported by VMware. This Istio deployment is the same as the upstream Istio in every way, but it also includes an agent that communicates with the Tanzu Service Mesh global control plane. Istio installation is not the most intuitive, but the onboarding process of Tanzu Service Mesh simplifies the process significantly.

Overview of Tanzu Service Mesh

The big difference and the value that comes with Tanzu Service Mesh (TSM) is its ability to support cross-cluster and cross-cloud use cases via Global Namespaces.

Global Namespaces (GNS)

Yep, another kind of a namespace, but the most exciting one! 🙂

A Global Namespace is a unique concept in Tanzu Service Mesh and connects resources and workloads that form the application into a virtual unit. Each GNS is an isolated domain that provides automatic service discovery and manages the following functions that are port of it, no matter where they are located:

  • Identity. Each global namespace has its own certificate authority (CA) that provisions identities for the resources inside that global namespace
  • Discovery (DNS). The global namespace controls how one resource can locate another and provides a registry.
  • Connectivity. The global namespace defines how communication can be established between resources and how traffic within the global namespace and external to the global namespace is routed between resources.
  • Security. The global namespace manages security for its resources. In particular, the global namespace can enforce that all traffic between the resources is encrypted using Mutual Transport Layer Security authentication (mTLS).
  • Observability. Tanzu Service Mesh aggregates telemetry data, such as metrics for services, clusters, and nodes, inside the global namespace.

Use Cases

The following diagram represents the global namespace concept and other pieces in a high-level architectural view. The components of one application are distributed in two different Kubernetes clusters: one of them is on-premises and the other in a public cloud. The Global Namespace creates a logical view of these application components and provides a set of basic services for the components.

Global Namespaces

If we take application continuity as another example for a use case, we would deploy an app in more than one cluster and possibly in a remote region for disaster recovery (DR), with a load balancer between the locations to direct traffic to both clusters. This would be an active-active scenario. With Tanzu Service Mesh, you could group the clusters into a Global Namespace and program it to automatically redirect traffic in case of a failure. 

In addition to the use case and support for multi-zone and multi-region high availability and disaster recovery, you can also provide resiliency with automated scaling based on defined Service-Level Objectives (SLO) for multi-cloud apps.

VMware Modern Apps Connectivity Solution  

In May 2021 VMware introduced a new solution that brings together the capabilities of Tanzu Service Mesh and NSX Advanced Load Balancer (NSX ALB, formerly Avi Networks) – not only for containers but also for VMs. While Istio’s Envoy only operates on layer 7, VMware provides layer 4 to layer 7 services with NSX (part of TSM) and NSX ALB, which includes L4 load balancing, ingress controllers, GSLB, WAF and end-to-end service visibility. 

This solution speeds the path to app modernization with connectivity and better security across hybrid environments and hybrid app architectures.

Multiple disjointed products, no end-to-end observability

 

 

 

 

 

 

Summary

One thing I can say for sure: The future for Tanzu Service Mesh is bright!

Many customers are looking for ways for offloading security (encryption, authentication, authorization) from an application to a service mesh.

One great example and use case from the financial services industry is crypto agility, where a “crypto service mesh” (a specialized service mesh) could be part of a new architecture, which provides quantum-safe certificates.

And when we offload encryption, calculation, authentication etc., then we may have other use cases for SmartNICs and  Project Monterey

To learn more about service mesh and the capabilities of Tanzu Service Mesh, I can recommend Service Mesh for Dummies written Niran Even-Chen, Oren Penso and Susan Wu.

Thank you for reading!