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!

 

Application Modernization and Multi-Cloud Portability with VMware Tanzu

Application Modernization and Multi-Cloud Portability with VMware Tanzu

It was 2019 when VMware announced Tanzu and Project Pacific. A lot has happened since then and almost everyone is talking about application modernization nowadays. With my strong IT infrastructure background, I had to learn a lot of new things to survive initial conversations with application owners, developers and software architects. And in the same time VMware’s Kubernetes offering grew and became very complex – not only for customers, but for everyone I believe. 🙂

I already wrote about VMware’s vision with Tanzu: To put a consistent “Kubernetes grid” over any cloud

This is the simple message and value hidden behind the much larger topics when discussing application modernization and application/data portability across clouds.

The goal of this article is to give you a better understanding about the real value of VMware Tanzu and to explain that it’s less about Kubernetes and the Kubernetes integration with vSphere.

Application Modernization

Before we can talk about the modernization of applications or the different migration approaches like:

  • Retain – Optimize and retain existing apps, as-is
  • Rehost/Migration (lift & shift) – Move an application to the public cloud without making any changes
  • Replatform (lift and reshape) – Put apps in containers and run in Kubernetes. Move apps to the public cloud
  • Rebuild and Refactor – Rewrite apps using cloud native technologies
  • Retire – Retire traditional apps and convert to new SaaS apps

…we need to have a look at the palette of our applications:

  • Web Apps – Apache Tomcat, Nginx, Java
  • SQL Databases – MySQL, Oracle DB, PostgreSQL
  • NoSQL Databases – MongoDB, Cassandra, Prometheus, Couchbase, Redis
  • Big Data – Splunk, Elasticsearch, ELK stack, Greenplum, Kafka, Hadoop

In an app modernization discussion, we very quickly start to classify applications as microservices or monoliths. From an infrastructure point of view you look at apps differently and call them “stateless” (web apps) or “stateful” (SQL, NoSQL, Big Data) apps.

And with Kubernetes we are trying to overcome the challenges, which come with the stateful applications related to app modernization:

  • What does modernization really mean?
  • How do I define “modernization”?
  • What is the benefit by modernizing applications?
  • What are the tools? What are my options?

What has changed? Why is everyone talking about modernization? Why are we talking so much about Kubernetes and cloud native? Why now?

To understand the benefits (and challenges) of app modernization, we can start looking at the definition from IBM for a “modern app”:

“Application modernization is the process of taking existing legacy applications and modernizing their platform infrastructure, internal architecture, and/or features. Much of the discussion around application modernization today is focused on monolithic, on-premises applications—typically updated and maintained using waterfall development processes—and how those applications can be brought into cloud architecture and release patterns, namely microservices

Modern applications are collections of microservices, which are light, fault tolerant and small. 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.

Note: App modernization can also mean, that you must move your application from .NET Framework to .NET Core.

I have a customer, that is just getting started with the app modernization topic and has hundreds of Windows applications based on the .NET Framework. Porting an existing .NET app to .NET Core requires some work, but is the general recommendation for the future. This would also give you the option to run your .NET Core apps on Windows, Linux and macOS (and not only on Windows).

A modern application is something than can run on bare-metal, VMs, public cloud and containers, and that easily integrates with any component of your infrastructure. It must be something, that is elastic. Something, that can grow and shrink depending on the load and usage. Since it is something that needs to be able to adapt, it must be agile and therefore portable.

Cloud Native Architectures and Modern Designs

If I ask my VMware colleagues from our so-called MAPBU (Modern Application Platform Business Unit) how customers can achieve application portability, the answer is always: “Cloud Native!”

Many organizations and people see cloud native as going to Kubernetes. But cloud native is so much more than the provisioning and orchestration of containers with Kubernetes. It’s a about collaboration, DevOps, internal processes and supply chains, observability/self-healing, continuous delivery/deployment and cloud infrastructure.

There are so many definitions around “cloud native”, that Kamal Arora from Amazon Web Services and others wrote the book “Cloud Native Architecture“, which describes a maturity model. This model helps you to understand, that cloud native is more a journey than only restrictive definition.

Cloud Native Maturity Model

The adoption of cloud services and applying an application-centric design are very important, but the book also mentions that security and scalability rely on automation. And this for example could bring the requirement for Infrastructure as Code (IaC).

In the past, virtualization – moving from bare-metal to vSphere – didn’t force organizations to modernize their applications. The application didn’t need to change and VMware abstracted and emulated the bare-metal server. So, the transition (P2V) of an application was very smooth and not complicated.

And this is what has changed today. We have new architectures, new technologies and new clouds running with different technology stacks. We have Kubernetes as framework, which requires applications to be redesigned for these platforms.

That is the reason why enterprises have to modernize their applications.

One of the “five R’s” mentioned above is the lift and shift approach. If you don’t want or need to modernize some of your applications, but move to the public cloud in an easy, fast and cost efficient way, have a look at VMware’ hybrid cloud extension (HCX).

In this article I focus more on the replatform and refactor approaches in a multi-cloud world.

Kubernetize and productize your applications

Assuming that you also define Kubernetes as the standard to orchestrate your containers where your microservices are running in, usually the next decision would be about the Kubernetes “product” (on-prem, OpenShift, public cloud).

Looking at the current CNCF Cloud Native Landscape, we can count over 50 storage vendors and over 20 networks vendors providing cloud native storage and networking solutions for containers and Kubernetes.

Talking to my customers, most of them mention the storage and network integration as one of their big challenges with Kubernetes. Their concern is about performance, resiliency, different storage and network patterns, automation, data protection/replication, scalability and cloud portability.

Why do organizations need portability?

There are many use cases and requirements that portability (infrastructure independence) becomes relevant. Maybe it’s about a hardware refresh or data center evacuation, to avoid vendor/cloud lock-in, not enough performance with the current infrastructure or it could be about dev/test environments, where resources are deployed and consumed on-demand.

Multi-Cloud Application Portability with VMware Tanzu

To explore the value of Tanzu, I would like to start by setting the scene with the following customer use case:

In this case the customer is following a cloud-appropriate approach to define which cloud is the right landing zone for their applications. They decided to develop new applications in the public cloud and use the native services from Azure and AWS. The customers still has hundreds of legacy applications (monoliths) on-premises and didn’t decide yet, if they want to follow a “lift and shift and then modernize” approach to migrate a number applications to the public cloud.

Multi-Cloud App Portability

But some of their application owners already gave the feedback, that their applications are not allowed to be hosted in the public cloud, have to stay on-premises and need to be modernized locally.

At the same time the IT architecture team receives the feedback from other application owners, that the journey to the public cloud is great on paper, but brings huge operational challenges with it. So, IT operations asks the architecture team if they can do something about that problem.

Both cloud operations for Azure and AWS teams deliver a different quality of their services, changes and deployments take longer with one of their public clouds, they have problems with overlapping networks, different storage performance characteristics and APIs.

Another challenge is the role-based access to the different clouds, Kubernetes clusters and APIs. There is no central log aggregation and no observability (intelligent monitoring & alerting). Traffic distribution and load balancing are also other items on this list.

Because of the feedback from operations to architecture, IT engineering received the task to define a multi-cloud strategy, that solves this operational complexity.

Notes: These are the regular multi-cloud challenges, where clouds are the new silos and enterprises have different teams with different expertise using different management and security tools.

This is the time when VMware’s multi-cloud approach Tanzu become very interesting for such customers.

Consistent Infrastructure and Management

The first discussion point here would be the infrastructure. It’s important, that the different private and public clouds are not handled and seen as silos. VMware’s approach is to connect all the clouds with the same underlying technology stack based on VMware Cloud Foundation.

Beside the fact, that lift and shift migrations would be very easy now, this approach brings two very important advantages for the containerized workloads and the cloud infrastructure in general. It solves the challenge with the huge storage and networking ecosystem available for Kubernetes workloads by using vSAN and NSX Data Center in any of the existing clouds. Storage and networking and security are now integrated and consistent.

For existing workloads running natively in public clouds, customers can use NSX Cloud, which uses the same management plane and control plane as NSX Data Center. That’s another major step forward.

Using consistent infrastructure enables customers for consistent operations and automation.

Consistent Application Platform and Developer Experience

Looking at organization’s application and container platforms, achieving consistent infrastructure is not required, but obviously very helpful in terms of operational and cost efficiency.

To provide a consistent developer experience and to abstract the underlying application or Kubernetes platform, you would follow the same VMware approach as always: to put a layer on top.

Here the solution is called Tanzu Kubernetes Grid (TKG), that provides a consistent, upstream-compatible implementation of Kubernetes, that is tested, signed and supported by VMware.

A Tanzu Kubernetes cluster is an opinionated installation of Kubernetes open-source software that is built and supported by VMware. In all the offerings, you provision and use Tanzu Kubernetes clusters in a declarative manner that is familiar to Kubernetes operators and developers. The different Tanzu Kubernetes Grid offerings provision and manage Tanzu Kubernetes clusters on different platforms, in ways that are designed to be as similar as possible, but that are subtly different.

VMware Tanzu Kubernetes Grid (TKG aka TKGm)

Tanzu Kubernetes Grid can be deployed across software-defined datacenters (SDDC) and public cloud environments, including vSphere, Microsoft Azure, and Amazon EC2. I would assume, that the Google Cloud is a roadmap item.

TKG allows you to run Kubernetes with consistency and makes it available to your developers as a utility, just like the electricity grid. TKG provides the services such as networking, authentication, ingress control, and logging that a production Kubernetes environment requires.

This TKG version is also known as TKGm for “TKG multi-cloud”.

VMware Tanzu Kubernetes Grid Service (TKGS aka vSphere with Tanzu)

TKGS is the option vSphere admins want to hear about first, because it allows you to turn a vSphere cluster to a platform running Kubernetes workloads in dedicated resources pools. TKGS is the thing that was known as “Project Pacific” in the past.

Once enabled on a vSphere cluster, vSphere with Tanzu creates a Kubernetes control plane directly in the hypervisor layer. You can then run Kubernetes containers by deploying vSphere Pods, or you can create upstream Kubernetes clusters through the VMware Tanzu Kubernetes Grid Service and run your applications inside these clusters.

VMware Tanzu Mission Control (TMC)

In our use case before, we have AKS and EKS for running Kubernetes clusters in the public cloud.

The VMware solution for multi-cluster Kubernetes management across clouds is called Tanzu Mission Control, which is a centralized management platform for the consistency and security the IT engineering team was looking for.

Available through VMware Cloud Services as SaaS offering, TMC provides IT operators with a single control point to provide their developers self-service access to Kubernetes clusters.

TMC also provides cluster lifecycle management for TKG clusters across environment such as vSphere, AWS and Azure.

It allows you to bring the clusters you already have in the public clouds or other environments (with Rancher or OpenShift for example) under one roof via the attachment of conformant Kubernetes clusters.

Not only do you gain global visibility across clusters, teams and clouds, but you also get centralized authentication and authorization, consistent policy management and data protection functionalities.

VMware Tanzu Observability by Wavefront (TO)

Tanzu Observability extends the basic observability provided by TMC with enterprise-grade observability and analytics.

Wavefront by VMware helps Tanzu operators, DevOps teams, and developers get metrics-driven insights into the real-time performance of their custom code, Tanzu platform and its underlying components. Wavefront proactively detects and alerts on production issues and improves agility in code releases.

TO is also a SaaS-based platform, that can handle the high-scale requirements of cloud native applications.

VMware Tanzu Service Mesh (TSM)

Tanzu Service Mesh, formerly known as NSX Service Mesh, provides consistent connectivity and security for microservices across all clouds and Kubernetes clusters. TSM can be installed in TKG clusters and third-party Kubernetes-conformant clusters.

Organizations that are using or looking at the popular Calico cloud native networking option for their Kubernetes ecosystem often consider an integration with Istio (Service Mesh) to connect services and to secure the communication between these services.

The combination of Calico and Istio can be replaced by TSM, which is built on VMware NSX for networking and that uses an Istio data plane abstraction. This version of Istio is signed and supported by VMware and is the same as the upstream version. TSM brings enterprise-grade support for Istio and a simplified installation process.

One of the primary constructs of Tanzu Service Mesh is the concept of a Global Namespace (GNS). GNS allows developers using Tanzu Service Mesh, regardless of where they are, to connect application services without having to specify (or even know) any underlying infrastructure details, as all of that is done automatically. With the power of this abstraction, your application microservices can “live” anywhere, in any cloud, allowing you to make placement decisions based on application and organizational requirements—not infrastructure constraints.

Note: On the 18th of March 2021 VMware announced the acquisition of Mesh7 and the integration of Mesh7’s contextual API behavior security solution with Tanzu Service Mesh to simplify DevSecOps.

Tanzu Editions

The VMware Tanzu portfolio comes with three different editions: Basic, Standard, Advanced

Tanzu Basic enables the straightforward implementation of Kubernetes in vSphere so that vSphere admins can leverage familiar tools used for managing VMs when managing clusters = TKGS

Tanzu Standard provides multi-cloud support, enabling Kubernetes deployment across on-premises, public cloud, and edge environments. In addition, Tanzu Standard includes a centralized multi-cluster SaaS control plane for a more consistent and efficient operation of clusters across environments = TKGS + TKGm + TMC

Tanzu Advanced builds on Tanzu Standard to simplify and secure the container lifecycle, enabling teams to accelerate the delivery of modern apps at scale across clouds. It adds a comprehensive global control plane with observability and service mesh, consolidated Kubernetes ingress services, data services, container catalog, and automated container builds = TKG (TKGS & TKGm) + TMC + TO + TSM + MUCH MORE

Tanzu Data Services

Another topic to reduce dependencies and avoid vendor lock-in would be Tanzu Data Services – a separate part of the Tanzu portfolio with on-demand caching (Tanzu Gemfire), messaging (Tanzu RabbitMQ) and database software (Tanzu SQL & Tanzu Greenplum) products.

Bringing all together

As always, I’m trying to summarize and simplify things where needed and I hope it helped you to better understand the value and capabilities of VMware Tanzu.

There are so many more products available in the Tanzu portfolio, that help you to build, run, manage, connect and protect your applications.

If you would like to know more about application and cloud transformation make sure to attend the 45 minute VMware event on March 31 (Americas) or April 1 (EMEA/APJ)!

Data Center as a Service based on VMware Cloud Foundation

Data Center as a Service based on VMware Cloud Foundation

IT organizations are looking for consistent operations, which is enabled by consistent infrastructure. Public cloud providers like AWS and Microsoft offer an extension of their cloud infrastructure and native services to the private cloud and edge, which is also known as Data Center as a Service.

Amazon Web Services (AWS) provides a fully managed service with AWS Outposts, that offers AWS infrastructure, AWS services, APIs and their tools to any data center or on-premises facility.

Microsoft has Azure Stack is even working on a new Azure Stack hybrid cloud solution that is codenamed “Fiji” to provide the ability to run Azure as a managed local cloud.

What do these offerings have in common or why would customers choose one (or even both) of these hybrid cloud options?

They bring the public cloud operation model to the private cloud or edge in form of one or more racks and servers provided as a fully managed service.

AWS Outposts (generally available since December 2019) and Azure Stack Fiji (in development) provide the following:

  • Extension of the public cloud services to the private cloud and edge
  • Consistent infrastructure with consistent operations
  • Local processing of data (e.g., analytics at the data source)
  • Local data residency (governance and security)
  • Low latency access to on-premises systems
  • Local migrations and modernization of applications with local system interdependencies
  • Build, run and manage on-premises applications using existing and familiar services and tools
  • Modernize applications on-prem resp. at the edge
  • Prescriptive infrastructure and vendor managed lifecycle and maintenance (racks and servers)
  • Creation of different physical pools and clusters depending on your compute and storage needs (different form factors)
  • Same licensing and pricing options on-premises (like in the public cloud)

The pretty new AWS Outposts or the future Azure Stack Fiji solution are also called “Local Cloud as a Service” (LCaaS) or “Data Center as a Service” and meant to be consumed and delivered in the on-prem data center or at the edge. It’s about bringing the public cloud to your data center or edge location.

The next phase of cloud transformations is about the “edge” of an enterprise cloud and we know today that private and hybrid cloud strategies are critical for the implementation of IT infrastructure and the operation of it.

If you come from VMware’s standpoint, then it’s not about extending the public cloud to the local data centers. It’s about extending your VMware-based private cloud to the edge or the public cloud.

This article focuses on the local (private) cloud as a service options from VMware, not the public cloud offerings.

In case you would like to know more about VMware’s multi-cloud strategy, which is about running the VMware Cloud Foundation stack on top of a public cloud like AWS, Azure or Google, please check some of my recent posts.

Features and Technologies

Before I describe the different VMware LCaaS offerings based on VMware Cloud Foundation, let me show and explain the different features and technologies my customers ask about when they plan to build a private cloud with public cloud characteristics in mind.

I work with customers from different verticals like

  • finance
  • fast-moving consumer goods
  • manufacturing
  • transportation (travel)

which are hosting IT infrastructure in multiple data centers all over the world including hundreds of smaller locations. My customers belong to different vertical markets, but are looking for the same features and technologies when it comes to edge computing and delivering a managed cloud on-premises. 

Compute and Storage. They are looking for pre-validated and standardized configuration offerings to meet their (application) needs. Most of them describe hardware blueprints with t-shirts sizes (small, medium, large). These different servers or instances provide different options and attributes, which should provide enough CPU, RAM, storage and networking capacity based on their needs. Usually you’ll find terms like “general purpose”, “compute optimized” or “memory optimized” node types or instances.

Networking. Most of my customers look for the possibility to extend their current network (aka elastic or cloud-scale networking) to any other cloud. They prefer a way to use the existing network and security policies and to provide software-defined networking (SDN) services like routing, firewalling and IDS/IPS, load balancing – also known as virtualized network functions (VNF). Service providers are also looking at network function virtualization (NFV), which includes emerging technologies like 5G and IoT. As cloud native or containerized applications become more important, service providers also discuss containerized network functions (CNF).

Services. Applications consist of one or many (micro-)services. All my conversations are application-centric and focus on the different application components. Most of my discussions are about containers, databases and video/data analytics at the edge.

Security. Customers, that are running workloads in the public cloud, are familiar with the shared responsibility model. The difference between public cloud and local cloud as a service offering is the physical security (racks, servers, network transits, data center access etc.).

Scalability and Elasticity. IT providers want to provide the simplicity and agility on-prem as their customers (the business) would expect it from a public cloud provider. Scalability is about a planned level of capacity that can grow or shrink as needed.

Resource Pooling and Sharing. Larger enterprises and service providers are interested in creating dedicated workload domains and resource clusters, but also look for a way to provide infrastructure multi-tenancy.

The challenge for today’s IT teams is, that edge locations are not often well defined. And these IT teams need an efficient way to manage different infrastructure sizes (can range from 2 nodes up to 16 or 24 nodes), for sometimes up to 400 edge locations.

Rethinking Private Clouds

Organizations have two choices when it comes to the deployment of a private cloud extension to the edge. They could continue using the current approach, which includes the design, deployment and operation of their own private cloud. Another pretty new option would be the subscription of a predefined “Data Center as a Service” offering.

Enterprises need to develop and implement a cloud strategy to support the existing workloads, which are still mostly running on VMware vSphere, and build something, which is vendor and cloud-agnostic. Something, that provides a (public) cloud exit strategy at the same time.

If you decide to go for AWS Outposts or the coming Azure Stack Fiji solution, which for sure are great options, how would you migrate or evacuate workloads to another cloud and technology stack?

VMware Cloud on Dell EMC

At VMworld 2019 VMware announced the general availability of VMware Cloud on Dell EMC (VMC on Dell EMC). In 2018 introduced as “Project Dimension”, the idea behind this concept was to deliver a (public) cloud experience to customers on-premises. Give customers the best of two worlds:

The simplicity, flexibility and cost model of the public cloud with the security and control of your private cloud infrastructure.

VMware Cloud on Dell EMC

Initially, Project Dimension was focused primarily on edge use cases and was not optimized for larger data centers.

Note: This has changed with the introduction of the 2nd generation of VMC on Dell EMC in May 2020 to support different density and performance use cases.

VMC on Dell EMC is a VMware-managed service offering with these components:

  • A software-defined data center based von VMware Cloud Foundation (VCF) running on Dell EMC VxRail
    • ESXi, vSAN, NSX, vCenter Server
    • HCX Advanced
  • Dell servers, management & ToR switches, racks, UPS
    • Standby VxRail node for expansion (unlicensed)
    • Option for half or full-height rack
  • Multiple cluster support in a single rack
    • Clusters start with a minimum of 3 nodes (not 4 as you would expect from a regular VCF deployment)
  • VMware SD-WAN (formerly known as VeloCloud) appliances for remote management purposes only at the moment
  • Customer self-service provisioning through cloud.vmware.com
  • Maintenance, patching and upgrades of the SDDC performed by VMware
  • Maintenance, patching and upgrades of the Dell hardware performed by VMware (Dell provides firmware, drivers and BIOS updates)
  • 1- or 3-year term subscription commitment (like with VMC on AWS)

There is no “one size fits all” when it comes to hosting workloads at the edge and in your data centers. VMC on Dell EMC provides also different hardware node types, which should match with your defined t-shirt sizes (blueprints).

VMC on Dell EMC HW Node Types

If we talk about at a small edge location with a maximum of 5 server nodes, you would go for a half-height rack. The full-height rack can host up to 24 nodes (8 clusters). Currently, the largest instance type would be a good match for high density, storage hungry workloads such as VDI deployments, databases or video analytics.

As HCX is part of the offering, you have the right tool and license included to migrate workloads between vSphere-based private and public clouds.

The following is a list of some VMworld 2020 breakout sessions presented by subject matter experts and focused on VMware Cloud on Dell EMC:

HCP1831: Building a successful VDI solution with VMware Cloud on Dell EMC – Andrew Nielsen, Sr. Director, Workload and Technical Marketing, VMware

HCP1802: Extend Hybrid Cloud to the Edge and Data Center with VMware Cloud on Dell EMC – Varun Chhabra, VP Product Marketing, Dell

HCP1834: Second-Generation VMware Cloud on Dell EMC, Explained by Product Experts – Neeraj Patalay, Product Manager, VMware

VMware Cloud Foundation and HPE Synergy with HPE GreenLake

At VMworld 2019 VMware announced that VMware Cloud Foundation will be offered in HPE’s GreenLake program running on HPE Synergy composable infrastructure (Hybrid Cloud as a Service). This gives VMware customers the opportunity to build a fully managed private cloud with the public cloud benefits in an on-premises environment.

HPE’s vision is built on a single platform that can span across multiple clouds and GreenLake brings the cloud consumption model to joint HPE and VMware customers.

Today, this solution is fully supported and sold by HPE. In case you want to know more, have a look at the VMworld 2020 session Simplify IT with HPE GreenLake Cloud Services and VMware from Erik Vogel, Global VP, Customer Experience, HPE GreenLake, Hewlett Packard Enterprise.

VMC on AWS Outposts

If you are an AWS customer and look for a consistent hybrid cloud experience, then you would consider AWS Outposts.

There is also VMware variant of AWS Outposts available for customers, who already run their on-premises workloads on VMware vSphere or in a cloud vSphere-based environment running on top of the AWS global infrastructure (called VMC on AWS).

VMware Cloud on AWS Outposts is a  on-premises as-a-service offering based on VMware Cloud Foundation. It integrates VMware’s software-defined data center software, including vSphere, vSAN and
NSX. Ths Cloud Foundation stack runs on dedicated elastic Amazon EC2 bare-metal infrastructure, delivered on-premises with optimized access to local and remote AWS services.

VMC on AWS Outposts

Key capabilities and use cases:

  • Use familiar VMware tools and skillsets
  • No need to rewrite applications while migrating workloads
  • Direct access to local and native AWS services
  • Service is sold, operated and supported by VMware
  • VMware as the single point of primary contact for support needs, supplemented by AWS for hardware shipping, installation and configuration
  • Host-level HA with automated failover to VMware Cloud on AWS
  • Resilient applications required to work in the event of WAN link downtime
  • Application modernization with access to local and native AWS services
  • 1- or 3-year term subscription commitment
  • 42U AWS Outposts rack, fully assembled and installed by AWS (including ToR switches)
  • Minimum cluster size of 3 nodes (plus 1 dark node)
  • Current cluster maximum of 16 nodes

Currently, VMware is running a VMware Cloud on AWS Outposts Beta program, that lets you try the pre-release software on AWS Outposts infrastructure. An early access program should start in the first half of 2021, which can be considered as a customer paid proof of concept intended for new workloads only (no migrations).

VMware on Azure Stack

To date there are no plans communicated by Microsoft or VMware to make Azure VMware Solution, the vSphere-based cloud offering running on top of Azure, available on-premises on the current or future Azure Stack family.

VMware on Google Anthos

To date there are no plans communicated by Google or VMware to make Google Cloud VMware Engine, the vSphere-based cloud offering running on top of the Google Cloud Platform (GCP), available on-premises.

The only known supported combination of a Google Cloud offering running VMware on-premises is Google Anthos (Google Kubernetes Engine on-prem).

Multi-Cloud Application Portability

Multi-cloud is now the dominant cloud strategy and many of my customers are maintaining a vSphere-based cloud on-premises and use at least two of the big three public clouds (AWS, Azure, Google).

Following a cloud-appropriate approach, customers are inspecting each application and decide which cloud (private or public) would be the best to run this application on. VMware gives customers the option to run the Cloud Foundation technology stack in any cloud, which doesn’t mean, that customers at the same time are not going cloud-native and still add AWS and Azure to the mix.

How can I achieve application portability in a multi-cloud environment when the underlying platform and technology formats differ from each other?

This is a question I hear a lot. Kubernetes is seen as THE container orchestration tool, which at the same time can abstract multiple public clouds and the complexity that comes with them.

A lot of people also believe that Kubernetes is enough to provide application portability and figure out later, that they have to use different Kubernetes APIs and management consoles for every cloud and Kubernetes (e.g., Rancher, Azure, AWS, Google, RedHat OpenShift etc.) flavor they work with.

That’s the moment we have to talk about VMware Tanzu and how it can simplify things for you.

The Tanzu portfolio provides the next generation the building blocks and steps for modernizing your existing workloads while providing capabilities of Kubernetes. Additionally, Tanzu also has broad support for containerization across the entire application lifecycle.

Tanzu gives you the possibility to build, run, manage, connect and protect applications and to achieve multi-cloud application portability with a consistent platform over any cloud – the so-called “Kubernetes grid”.

Note: I’m not talking about the product “Tanzu Kubernetes Grid” here!

I’m talking about the philosophy to put a virtual application service layer over your multi-cloud architecture, which provides a consistent application platform.

Tanzu Mission Control is a product under the Tanzu umbrella that provides central management and governance of containers and clusters across data centers, public clouds, and edge.

Conclusion

Enterprises must be able to extend the value of their cloud investments to the edge of the organization.

The edge is just one piece of a bigger picture and customers are looking for a hybrid cloud approach in a multi-cloud world.

Solutions like VMware Cloud on Dell EMC or running VCF on HPE Synergy with HPE Greenlake are only the first steps towards innovation in the private cloud and to bring the cost and operation model from the public cloud to the enterprises on-premises.

IT organizations are rather looking for ways to consume services in the future and care less about building the infrastructure or services by themselves.

The two most important differentiators for selecting an as-a-service infrastructure solution provider will be the provider’s ability to enable easy/consistent connectivity and the provider’s established software partner portfolio.

In cases where IT organizations want to host a self-managed data center or local cloud, you can expect, that VMware is going to provide a new and appropriate licensing model for it.

VMware Carbon Black Cloud Workload – Agentless Protection for vSphere Workloads

VMware Carbon Black Cloud Workload – Agentless Protection for vSphere Workloads

At VMworld 2020 VMware announced Carbon Black Cloud Workload (CBC Workload) as part of their intrinsic security approach.

For me, this was the biggest and most important announcement from this year’s VMworld. It is a new offering, which is relevant for every vSphere customer out there – even the small and medium enterprises, which maybe still just rely on ESXi and vCenter only for their environment.

CBC Workload introduces protection for workloads in private and public clouds. For vSphere, there is no additional agent installation needed, because the Carbon Black sensor (agent) is built into vSphere. That’s why you may hear that this solution is “agentless”.

Carbon Black Cloud Workload Bundles

This cloud-native (SaaS) solution provides foundational workload hardening and vulnerability management combined with prevention, detection and response capabilities to protect workloads running in virtualized private cloud and hybrid cloud environments.

Carbon Black Cloud Workload Protection Bundles

Note: Customers, that are using vSphere and VMware Horizon, should take a look at Workspace Security VDI, which has also been announced at VMworld 2020. A single-vendor solution with the combination of VMware Horizon and Carbon Black.

If you would like to know more about the interoperability of Carbon Black and Horizon, have a look at KB79180.

Carbon Black Cloud Workload Overview

Customers and partners have now the possibility to provide a workload security solution for Windows and Linux virtual machines. The complete system requirements can be found here.

“You can enable Carbon Black in your data center with an easy one-click deployment. To minimize your deployment efforts, a lightweight Carbon Black launcher is made available with VMware Tools. Carbon Black launcher must be available on the Windows and Linux VMs.”

Carbon Black enable via vCenter

Carbon Black Cloud Workload consists of a few key components that interact with each other:

CBC Workload Components

You must first deploy an on-premises OVF/OVA template for the Carbon Black Cloud Workload appliance (4 vCPU, 4GB RAM, 41GB storage) that connects the Carbon Black Cloud to the vCenter Server through a registration process. After the registration is complete, the Carbon Black Cloud Workload appliance deploys the Carbon Black Cloud Workload plug-in and collects the inventory from the vCenter Server.

The plug-in provides visibility into processes and network connections running on a virtual machine.

As a vCenter Server administrator, you want to have visibility of known vulnerabilities in your environment to understand your security posture and schedule maintenance windows for patching and remediation. With the help of vulnerability assessment, you can proactively minimize the risk in your environment. You can now monitor known vulnerabilities from the Carbon Black Cloud Workload plug-in:

vSphere Client Carbon Black

The infosec guys in your company would do the vulnerability assessment from the CBC console:

CBC Vulnerabilities

Carbon Black Cloud Workload protection provides vSphere administrators a full inventory, appliance health and vulnerability reporting from one console, the already well-known vSphere Client.

Carbon Black vSphere Client Summary

Cybersecurity Requirements

According to the NIST Cybersecurity Framework the security lifecycle is made of five functions:

  1. Identify – Cloud & Service Context, Dynamic Asset Visibility, Compliance & Standards, Cloud Risk Management
  2. Protect – Services / API Defined, Cloud Access Control, Network Integrity, Data Security, Change Control & Guardrails
  3. Detect – Cloud-Speed, Inter-connected Services, Events & Anomalies, Continuous Monitoring
  4. Respond – DevOps Collaboration, Real-time Notifications, Automated Actions, Response as Code
  5. Recover – Templates / Code Review, Shift Left / Pipeline, Exceptions and Verification

Workload Security Lifecycle

CBC Workload focuses on identifying the risks with workload visibility and vulnerability management, which are part of the “Workload Essentials” edition.

If you would like to prevent malicious activities to protect your workloads and replace your existing legacy anti-virus (AV) solution, then “Workload Advanced” would be the right edition for you as it includes Next-Gen AV (NGAV).

Behavioral EDR (Endpoint Detection & Response), also part of the “Advanced” bundle, belongs to “detect & respond” of the security lifecycle.

Workload Security for Kubernetes

Carbon Black Guardrails and Runtime Security

You just learned that Carbon Black Cloud gives workload protection for virtualized Windows or Linux virtual machines running on vSphere. What about container security for Kubernetes?

In May 2020 VMware officially closed its acquisition of Octarine, a SaaS security platform for protecting containers and Kubernetes. VMware bought Octarine to enable Carbon Black to secure applications running in Kubernetes.

Traditional security is no longer relevant for the security of Kubernetes, because Kubernetes is so powerful and hence risky, networking is very complex and a total different game, because static IPs and ports are no longer relevant. And you need a new security approach which is compatible with IT’s organizational shift from traditional to a DevSecOps approach.

VMware’s solution covers the whole lifecycle of the application from building the container to the app running in production. It is a two-part solution with the first one being “Guardrails“. It is able to scan container images for vulnerabilities and Kubernetes manifests for any misconfigurations.

Carbon Black Cloud Guardrails Module

The second part is runtime protection. When the workloads are deployed in production, the Carbon Black security agent is able to detect malicious activities.

Carbon Black Cloud Runtime Module 

Let’s have a look at the different features the Kubernetes “Guardrails” provide for each phase of the application:

  • Build: Image vulnerability scanning, Kubernetes configuration hardening
  • Deploy: Policy governance, compliance reporting, visibility and hardening
  • Operate: Threat detection and response, anomaly detection and least privilege runtime, event monitoring

And these were the key capabilities and benefits, which have been mentioned at VMworld 2020 for “Guardrails”:

Carbon Black Kubernetes Guardrails Features

For “runtime” security the following key capabilities and benefits were mentioned:

  • Visibility of network traffic
  • Coverage of workloads and hosts activity
  • Network policy management
  • Threat detection
  • Anomaly detection
  • Egress security
  • SIEM integration

Customers will be able to have visibility of all the workloads running in the local or cloud-native production clusters and how they interact with each other. They will also see which services are exposed to ingress traffic, which services are exiting the cluster and where this egress traffic is going to. It is also going to be visible which communication is encrypted and what type of encryption is used.

Note: The Carbon Black Cloud module for hardening and securing Kubernetes workloads is expected to be generally available until the end of 2020.

The launch of Carbon Black Workload was the first important step to let the intrinsic security vision become more a reality (after VMware acquired Carbon Black). Moving on with Kubernetes and bringing new container security capabilities is going to be the next big move forward, that VMware can become a major security provider. 

Stay tuned for more security announcements!

Additional Resources

If you would like to know more about Carbon Black Cloud Workload and security for Kubernetes, have a look at:

Azure VMware Solution

Azure VMware Solution

Update May 2020:

On May 4th Microsoft announced the preview (and the “next evolution”) of Azure VMware Solution which is now a first-party offering service designed, built and supported my Microsoft and endorsed by VMware. This is an entirely new service entirely delivered and supported by Microsoft and does not replace the current AVS solution/service by CloudSimple at this time. This is truly just a Microsoft technology offering and has also nothing to do with a Virtustream branded Azure VMware Solution offering. Short: A way cleaner offering and service with a contract only between Microsoft and VMware.

— Original Text below —

Since Dell Technologies World 2019 it’s clear: VMware and Microsoft are not frenemies anymore!

Dell Technologies and Microsoft announced an expanded partnership which should help customers and provide them more choice and flexibility for their future digital workspace projects or cloud integrations.

One result and announcement of this new partnership is the still pretty new offering called “Azure VMware Solution” (AVS). Other people and websites may also call it “Azure VMware Solution by Virtustream” or “Azure VMware Solution by CloudSimple”.

AVS is a Microsoft first-party offering. Meaning, that it’s sold and supported by Microsoft, NOT VMware. This is one very important difference if you compare it with VMC on AWS. The operation, development and delivery are done by a VMware Cloud Verified and Metal-as-a-Service VCPP (VMware Cloud Provider Program) partner; CloudSimple or Virtustream (subsidiary of Dell Technologies). AVS is fully supported and verified by VMware.

VMware Metal-as-a-Service Authorized partners Virtustream and CloudSimple run the latest VMware software-defined data center technology, ensuring customers enjoy the same benefits of a consistent infrastructure and consistent operations in the cloud as they achieve in their own physical data center, while allowing customers to also access the capabilities of Microsoft Azure.

So, why would someone like Microsoft run VMware’s Cloud Foundation (VCF) stack on Azure? The answer is quite simple. VMware has over 500’000 customers and an estimated number of 70mio VMs which are mostly running on-premises. Microsoft’s doesn’t care if virtual machines (VMs) are running on vSphere, they care about Azure and the consumption in the end. AVS is just another form of Azure, Microsoft says. I would say it’s very unlikely that a customer moves on to Azure native once they are onboarded via Azure VMware Solution.

Microsoft would like to see some of the 70mio running on their platform, no matter if it’s VCF on top of their Azure servers. Customers should get the option to move to the Azure cloud, using Azure native services (e.g. Azure NetApp Files, Azure databases etc.), but give them the choice and flexibility to use their existing technology stack, ecosystem and tools (e.g. automation or operation) they are familiar with – the whole or some part of the VCF coupled with products from the vRealize Suite. Plus, other VMware 3rd party integrations they might have for data protection or backup. This is one unique specialty – Microsoft says – that there is no restricted functionality as you may experience in other VMware clouds.

Azure VMware Solutions Components

From VMware’s perspective most of our customers are already Microsoft customers as well. In addition to that VMware’s vision is to provide the freedom of choice and flexibility, same like Microsoft, but it one small difference: to be cloud and infrastructure agnostic. This vision says that VMware doesn’t care if you run your workloads on-prem, on AWS, Azure or GCP (or even at a VCPP partner’s cloud) as long it’s running on the VCF stack. Cloud is not a choice or destination anymore, it has become an operation model.

And to keep it an operation model without having a new silo and the vendor lock-in, it makes totally sense to use VMware’s VCF on top of AWS, Azure, Google Cloud, Oracle, Alibaba Cloud or any other VCPP partners. This ensures that customers have the choice and flexibility they are looking for, coupled with the new and maybe still surprising “new” or “special” public cloud. If your vision is also about workload mobility on any cloud, then VMware is the right choice and partner!

Use Cases

What are the reasons to move to Azure and use Azure VMware Solution?

If you don’t want to scale up or scale out your own infrastructure and would like to get additional capacity almost instantly, then speed is definitely one reason. Microsoft can spin up a new AVS SDDC under 60min, which is impressive. How is this possible? With automation! This proves that VMware Cloud Foundation is the new data center operating system of the future and that automation is a key design requirement. If you would like to experience nearly the same speed and work with the same principles as public cloud provider do, then VCF is the way to go.

The rest of the use cases or reasons are in general the same if we talk about cloud. If it’s not only speed, then agility, (burstable) capacity, expansion in a new geography, DRaaS or for app modernization reasons using cloud native services.

Microsoft Licenses

What I have learned from this MS Ignite recording, is, that you can bring your existing MS licenses to AVS and that you don’t have to buy them AGAIN. In any other cloud this is not the case.

This information can be found here as well:

Beginning October 1, 2019, on-premises licenses purchased without Software Assurance and mobility rights cannot be deployed with dedicated hosted cloud services offered by the following public cloud providers: Microsoft, Alibaba, Amazon (including VMware Cloud on AWS), and Google. They will be referred to as “Listed Providers”.

Regions

If you check the Azure documentation, you’ll see that AVS is only available in US East and West Azure regions, but should be available in Western Europe “in the near future”. In the YouTube video above Microsoft was showing this slide which shows their global rollout strategy and the planned availability for Q2 2020:

Azure VMware Solutions Regions 2020

According to the Azure regions website Azure VMware Solution is available at the following locations and countries in Europe:

Azure VMware Solutions by Azure RegionSo, North Europe (UK) is expected for H2 2020 and AVS is already available in the West Europe Azure region. Since no information available about the Swiss regions, even the slide from the MS Ignite recording may suggest the availability until May 2020, it’s very unlikely that AVS will be available in Zurich or Geneva before 2021.

Azure VMware Solution Components

You need at least three hosts to get started with the AVS service and you can scale up to 16 hosts per cluster with a SLA of 99.9%. More information about the available node specifications for your region can be found here. At the moment CloudSimple offers the following host types:

  • CS28 node: CPU:2x 2.2 GHz, total 28 cores, 48 HT. RAM: 256 GB. Storage: 1600 GB NVMe cache, 5760 GB data (All-Flash). Network: 4x25Gbe NIC
  • CS36 node: CPU 2x 2.3 GHz, total 36 cores, 72 HT. RAM: 512 GB. Storage: 3200 GB NVMe cache 11520 GB data (All-Flash). Network: 4x25Gbe NIC
  • CS36m node (only option for West Europe): CPU 2x 2.3 GHz, total 36 cores, 72 HT. RAM: 576 GB. Storage: 3200 GB NVMe cache 13360 GB data (All-Flash). Network: 4x25Gbe NIC

I think it’s clear that the used hypervisor is vSphere and that it’s maintained by Microsoft and not by VMware. There is no host-level access, but Microsoft gives you the possibility of a special “just in time” privileges access (root access) feature, which allows to install necessary software bits you might need – for example for 3rd party software integrations.

The storage infrastructure is based on vSAN with an all-flash persistent storage and a NVMe cache storage. More capacity can be made available by adding additional nodes or use Azure offerings which can be added to VMs directly.

Networking and security are based on NSX-T which fully supports micro segmentation.

To offer choice, Microsoft gives you the option to manage and see your AVS VMware infrastructure via vCenter or Azure Resource Manager (ARM). The ARM integration will allow you to create, start, stop and delete virtual machines and is not meant to replace existing VMware tools.

Microsoft support is your single point of contact and CloudSimple contacts VMware if needed.

Connectivity Options

CloudSimple provides the following connectivity options to connect to your AVS region network:

Depending on the connectivity option you have different ways to bring your VMs to your AVS private cloud:

How do I get started?

You have to contact your Microsoft account manager or business development manager if would like to know more. But VMware account representatives are also available to support you. If you want to learn more, check https://aka.ms/startavs.

Can I burn my existing Azure Credits?

Yes. Customers with Azure credits can use them through Azure VMware Solution.