A customer of mine asked me a few days ago: “Is it not possible to get NSX Security features without the network virtualization capabilities?”. I wrote it already in my blog “VMware is Becoming a Leading Cybersecurity Vendor” that you do not NSX’s network virtualization editions or capabilities if you are only interested in “firewalling” or NSX security features.
If you google “nsx security”, you will not find much. But there is a knowledge base article that describes the NSX Security capabilities from the “Distributed Firewall” product line: Product offerings for NSX-T 3.2 Security (87077).
Believe it or not, there are customers that haven’t started their zero-trust or “micro-segmentation” journey yet. Segmentation is about preventing lateral (east-west) movement. The idea is to divide the data center infrastructure into smaller security zones and that the traffic between the zones (and between workloads) is inspected based on the organization’s defined policies.
If you are one of them and want to deliver east-west traffic introspection using distributed firewalls, then these NSX Security editions are relevant for you:
VMware NSX Distributed Firewall
NSX Distributed Firewall (DFW)
NSX DFW with Threat Prevention
NSX DFW with Advanced Threat Prevention
VMware NSX Gateway Firewall
NSX Gateway Firewall (GFW)
NSX Gateway Firewall with Threat Prevention
NSX Gateway Firewall with Advanced Threat Prevention
Network Detection and Response
Network Detection and Response (standalone on-premises offering)
The NSX Distributed Firewall is a hypervisor kernel-embedded stateful firewall that lets you create access control policies based on vCenter objects like datacenters and clusters, virtual machine names and tags, IP/VLAN/VXLAN addresses, as well as user group identity from Active Directory.
If a VM gets vMotioned to another physical host, you do not need to rewrite any firewall rules.
The distributed nature of the firewall provides a scale-out architecture that automatically extends firewall capacity when additional hosts are added to a data center.
Should you be interested in “firewalling” only, want to implement access controls for east-west traffic (micro-segmentation) only, but do not need threat prevention (TP) capabilities, then “NSX Distributed Firewall Edition” is perfect for you.
So, which features does the NSX DFW edition include?
The NSX DFW edition comes with these capabilities:
L2 – L4 firewalling
L7 Application Identity-based firewalling
User Identity-based firewalling
NSX Intelligence (flow visualization and policy recommendation)
Aria Operations for Logs (formerly known as vRealize Log Insight)
What is the difference between NSX DFW and NSX DFW with TP?
With “NSX DFW with TP”, you would get the following additional features:
Distributed Intrusion Detection Services (IDS)
Distributed Behavioral IDS
Distributed Intrusion Prevention Service (IPS)
Distributed IDS Event Forwarding to NDR
Where does the NSX Distributed Firewall sit?
This question comes up a lot because customers understand that this is not an agent-based solution but something that is built into the VMware ESXi hypervisor.
The NSX DFW sits in the virtual patch cable, between the VM and the virtual distributed switch (VDS):
Note: Prior to NSX-T Data Center 3.2, VMs must have their vNIC connected to an NSX overlay or VLAN segment to be DFW-protected. In NSX-T Data Center 3.2, distributed firewall protects workloads that are natively connected to a VDS distributed port group (DVPG).
VMware NSX Gateway Firewall
The NSX Gateway Firewall extends the advanced threat prevention (ATP) capabilities of the NSX Distributed Firewall to physical workloads in your private cloud. It is a software-only, L2 – L7 firewall that includes capabilities such as IDS and IPS, URL filtering and malware detection as well as routing and VPN functionality.
If you are not interested in ATP capabilities yet, you can start with the “NSX Gateway Firewall” edition. What is the difference between all NSX GFW editions?
The NSX GFW can be deployed as a virtual machine or with an ISO image that can run on a physical server and it shares the same management console as the NSX Distributed Firewall.
Today, more than ever, both humans and machines consume or process data. We, humans, consume data through multiple applications that are hosted in different clouds from different devices like smartphones, laptops, and tablets. Companies are building applications that need to look good and work well on any platform/device.
At the same time, developers are building new applications following cloud-native principles. A cloud-native architecture is a design pattern for applications that are built for the cloud. Most cloud-native apps are organized as microservices which are used to break up larger applications into loosely coupled units that can be managed by smaller teams. Resilience and scale are achieved through horizontal scaling, distributed processing, and automated placement of failed components.
Different people have a different understanding of “cloud-native” and the chances are high that you will get different answers. Let us look at the official definition from CNCF:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
12-Factor App
A widely accepted methodology for building cloud-based applications is the “Twelve-Factor Application”. It uses declarative formats for automation to minimize time and costs. It should offer maximum portability between execution environments and be suitable for the deployment on modern cloud platforms. The 12-factor methodology can be applied with any programming language and may use any combination of backing servers (caching, queuing, databases).
Interestingly, we now see other factors like API-first, telemetry, and security complementing this list.
While doing research for my book about “workload mobility and application portability”, I saw the term “API-first” many times.
Then I started to remember that VMware acquired Mesh7 a while ago and they announced Tanzu Service Mesh Enterprise last year at VMworld Europe (now known as VMware Explore). API security was even one of their main topics during the networking & security solutions keynote presented by Tom Gillis.
That is why I thought it is time to better understand this topic and write a piece about APIs. Let us start with some basics first.
What is an API?
An application programming interface (API) is a way for two or more software components to communicate with each other using a set of defined protocols and definitions. APIs are here to make the developer’s life easier.
I bet you have seen parts of Google Maps already embedded in different websites when you were looking for a specific business or restaurant location. Most websites and developers would use Google Maps in this case, because it just makes sense for us, right? That is why Google exposes the Google Maps API so developers can embed Google Maps objects very easily in a standardized way. Or have you seen anyone who wants to develop their own version of Google Maps?
In the case of enterprises, APIs are a very elegant way to share data with customers or other external users. Such public APIs like Google Maps APIs can be used by partners who then can access your data. And we all know that data is the new oil. Companies can make a lot of money today by sharing their data.
Even when using private APIs (internal use only), you decide who can access your API and data. This is one of the reasons why API security and API management become more important. You want to provide secure access when sensitive data is being exposed.
What is an API Gateway?
For microservices-based apps, it makes sense to implement an API gateway, because it can act as a single entry point for all API calls made to your system. And it doesn’t matter if your system/application is hosted on-premises, in the public cloud, or a combination of both. The API gateway takes care of the request (API call) and returns the requested data.
API gateways can also handle other tasks like authentication, rate management, and statistics. This is important for example when you want to monetize some of your APIs by offering a service to consumers or other companies.
What is Spring Cloud Gateway for VMware Tanzu?
Spring Cloud Gateway for VMware Tanzu provides a simple way to route internal and external API requests to application services that expose APIs. This solution is based on the open-source Spring Cloud Gateway project and provides a library for building API gateways on top of Spring and Java.
Because it is intended that Spring Cloud Gateway sits between a requester and the resource that is being requested, it is in the position to intercept, analyze and modify requests.
Revitalize Legacy Apps with APIs
Before we had microservices, there were monolithic applications. An all-in-one application architecture, where all services are installed on the same virtual machine and depend on each other.
There are multiple reasons why such a monolith cannot be broken up into smaller pieces and modernized. Sometimes it’s not (technically) possible, not worth it, or it just takes too long. Hence many companies still use such monolithic (legacy) applications. The best example here is the mainframe which often still runs business-critical applications.
I always thought that my customers only have two options when modernizing applications:
Start from scratch (throw the old app away)
Refactor/Rewrite an application
Rewriting an application needs time and costs money. Imagine that you would refactor 50 of your applications, split these monoliths up in microservices, connect these hundreds or thousands of microservices, and at the same time must take care of security (e.g., vulnerabilities).
So, what are you going to do now?
APIs seem to provide a very cost-effective way to integrate some of the older applications with newer ones. With this approach, one can abstract away the data and services from the underlying (legacy) application infrastructure. APIs can extend the life of a legacy application and could be the start of a phased application modernization approach.
Tanzu Service Mesh Enterprise
At the moment, we only have an API gateway that sits in front of our microservices. Multiple (micro)services in an aggregated fashion create the API you want to expose to your internal or external customers. The question now is, how you do plan to expose this API when your microservices are distributed over one or more private or public clouds?
When we talk about APIs, we talk about data in motion. That is why we must secure this data that is sent from its source to any location. And you want to secure the application and data without increasing the application latency and decreasing the user’s experience.
API Security. API security is achieved through API vulnerability detection and mitigation, API baselining, and API drift detection (including API parameters and schema validation)
Personally Identifiable Information (PII) segmentation and detection. PII data is segmented using attribute-based access control (ABAC) and is detected via proper PII data detection and tracking, and end-user detection mechanisms.
API Security Visibility. API security is monitored using API discovery, security posture dashboards, and rich event auditing.
Final Words
APIs are used to connect different applications. They are also used to aggregate services or functions that can be consumed by other businesses or partners. Modern and containerized applications bring a large number of APIs with them, that can be hosted in any cloud.
With Spring Cloud Gateway and Tanzu Service Mesh Enterprise, VMware can deliver application connectivity services that enable improved developer experience and more secure operations.
It took me almost a year to realize the strengths of these (combined) products and why VMware for example acquired Mesh7. But it makes sense to me now. Even I do not completely understand all the key features of Spring Cloud Gateway and Tanzu Service Mesh.
Learn why AWS developers love VMware Cloud on AWS and want to present it to their internal platform team.
I had booth duty at the AWS Swiss Cloud Day 2022 and had the chance to finally talk to people that normally do not talk to VMware folks like me. I believe I had not a single infrastructure or cloud architect talking to me the whole day and I have been approached by Linux administrators and developers only. After I explained to them our partnership and capabilities with AWS, they were mind blown!
“Michael, what is VMware’s business with AWS?”
“Why are you here at the event, you are only a hypervisor company, right?“
“Haha, what are you guys doing here?“
“What is the reason for VMware coming here? You are a competitor of AWS, no?“
Developers don’t want to do ops
Look, the developers did not know, that I have no developer background and spent most of my time with data centers. I already built true hybrid clouds almost 10 years ago before we had all the different hyperscalers and providers like Amazon Web Services. After I passed the AWS Solutions Architect Associate and AWS Developer Associate exams a few months ago, I finally understood better how complex software development and cloud migrations must be.
It is said that developers do not want to deal with operational concerns. And other developers want to understand the production environment to make sure that their code work. Additionally, we have the shift-left approach that puts more pressure on the developer’s shoulders, they do not have time for ops.
But after talking to a few developers, I had a light-bulb moment and the following truths came to the surface:
Developers had no clue how VMware can ease some of their pain
Developers liked my talk about infrastructure and ops
I need to bring more business cards to such events!!!
Developers are interested in infrastructure
Remember the questions from above? To answer the questions about VMware’s relevance or relationship with AWS, I used the first 2min to explain VMware Cloud on AWS to them. Yes, I started talking about infrastructure and not about Tanzu, developer experience, our open source projects, and contributions, or Tanzu Labs. The people visiting us at the booth were impressed that VMware and AWS have even specialists only focusing on this solution. Still, they were not convinced yet that VMware can do something good for them.
Okay, I got it. So what? What is the value?
How would someone with a VMware background answer such a question? Most of us usually see this situation as the right moment to talk about use cases like:
Data center exit or refresh (infrastructure modernization)
Burst Capacity
Low latency to AWS native services
Application modernization
Cloud migrations
So, which of these use cases are relevant and important to developers?
The developer’s story
The developers confirmed some statements of mine:
Cloud migrations take long and are not easy
Lift & shift migrations involve a lot of manual tasks
They either have to refactor their app on-premises first and then move to the public cloud or start from scratch on AWS
I say it again, software development is complex. Developers need to modernize existing applications on-premises and then migrate them somehow to AWS because you cannot always start from scratch.
Imagine this: You have an application that was deployed and operated for years in your data centers. Most probably you don’t even understand all the dependencies and configurations anymore since the years have passed. Maybe you are not even the guy who initially developed this application.
Note: The only thing that can be assumed, is, that your infrastructure is most likely running on a VMware-based cloud.
Now you need to start modernizing this application, which takes months or even years. When you are done with your task, you have to figure out how to bring this application over to AWS. Because you had to spend all your time refactoring this application, there was no time to build new AWS skills. At least not during normal office hours.
Lift and shift is easy, right?
Nope. When it would be easy, why does the migration in most cases take longer than expected and cost more than expected? When you have to exit a data center for any reason and need to bring some of your workloads over to a public cloud like AWS, then a lift and shift approach is the best and fastest approach. But somehow organizations do not see much value in using this approach during their cloud adoption. At least not with VMware.
But if a consulting firm or AWS themselves tell the customer, that lift and shift is a good idea, their customers suddenly see the benefit even if they have to add millions to their estimated budget. Consulting firms are not cheap, and neither are lift and shift projects with different underlying technologies like having VMware as the source site on-premises and AWS (or any other public cloud provider) as the destination. But hey, good for your company if they have this extra money.
Lift and shift brings no innovation
Different organizations have different agendas and goals. For some, solely running their virtual machines and containers, and using cloud native services is enough for them – no matter the costs. Others expect that economies of scale bring the necessary cost advantages over time while they implement and deliver innovation.
That is why some companies see lift and shift as the approach, which brings no innovation. It is complex, not easy, takes longer, costs more and in the end, you don’t use cloud native services (yet).
It is time now to change the perspective and narrative because I get why you think that lift and shift brings no innovation.
Forget Lift and Shift – Do Lift and Learn
So, our use case here is application modernization. A developer needs to modernize and migrate an application, ideally at the same time. No wonder why some of you may think that lift and shift brings no innovation: because you modernize later.
Developers struggle. They struggle very much. After I explained VMware Cloud on AWS and mentioned, that a lift and learn approach is the better way that makes their life much easier, they asked me for my business card. It took less than 24h until I received my first two e-mails to organize a meeting.
Give developers more time.
Developers and ops teams need to have enough time to skill up, to learn and understand the new things. You have to break and fix things first in the new world before you can truly understand it. They loved the idea of lift and learn:
Lift and shift your applications first with VMware Cloud on AWS. A true hybrid cloud approach, where the technology format is the same (on-prem and on AWS), will speed up your cloud adoption timeline and therefore save costs. Your workload now runs in the public cloud. Check!
Since the cloud migration didn’t take 12 months, but more something like 3-4 months, your developers can use the additional time to learn and understand how to build things on AWS! The developers are happy because they have less pressure now and can play around with new stuff.
After they have understood the new world, they can start modernizing different parts of the application. What has started with a legacy/traditional application, becomes a hybrid application and eventually a fully modernized app over time.
The stepping stone to becoming cloud native
Some of you may think now that VMware and its solution with VMC on AWS is just a temporary solution before going completely, cloud native. Let us take a step back again quickly.
When I joined VMware in 2018, they talked about 70mio workloads running on their platform. This year at VMware Explore (formerly VMworld) they showed several 85mio VMware-based workloads. This is proof to me, that:
the cloud adoption does not happen as fast as expected,
on-premises data centers and VMware is not legacy,
VMware is more than only a “hypervisor” company,
cloud native and container-based workloads do not always make sense and
virtual machines are still going to exist for a while.
These are some pointers to why AWS has this partnership with VMware. As you can see, VMware is very strategic and relevant and should be part of every cloud and application modernization conversation.
Call to action
Just because a lot of people say that developers do not care about ops and are not interested in talking to “infrastructure guys” like me, does not mean that this statement/assumption is true. My conversations from AWS Swiss Cloud Day 2022 clearly showed that developers need to know more about the options and value that companies like VMware can bring to the table.
Do not let developers only talk to developers. Do lift and learn.
Last year at VMworld 2021, VMware mentioned and announced a lot of (new) projects they are working on. What happened to them and which new VMware projects have been mentioned this year at VMware Explore so far?
Project Ensemble – VMware Aria Hub
VMware unveiled their unified multi-cloud management portfolio called VMware Aria, which provides a set of end-to-end solutions for managing the cost, performance, configuration, and delivery of infrastructure and cloud native applications.
VMware Aria is anchored by VMware Aria Hub (formerly known as Project Ensemble), which provides centralized views and controls to manage the entire multi-cloud environment, and leverages VMware Aria Graph to provide a common definition of applications, resources, roles, and accounts.
VMware Aria Graph provides a single source of truth that is updated in near-real time. Other solutions on the market were designed in a slower moving era, primarily for change management processes and asset tracking. By contrast, VMware Aria Graph is designed expressly for cloud-native operations.
Project Arctic has been introduced last year as a Technology Preview and was described as “the next step in the evolution of vSphere in a multi-cloud world”. What has started with the idea of bringing VMware Cloud services closer to vSphere, has evolved to a even more interesting and enterprise-ready version called vSphere+ and vSAN+. It includes developer services that consist of the Tanzu Kubernetes Grid runtime, Tanzu Mission Control Essentials and NSX Advanced Load Balancer Essentials. VMware is going to add more and more VMware Cloud add-on services in the future. Additionally, VMware even introduced VMware Cloud Foundation+.
Project Iris – Application Transformer for VMware Tanzu
VMware mentioned Project Iris very briefly last year at VMworld. In February 2022, Project Iris became generally available and is since then known as Application Transformer for VMware Tanzu.
Project Northstar
At VMware Explore on day 1, VMware introduced Project Northstar, which will provide customers a centralized cloud console that gives them instant access to networking and security services, such as network and security policy controls, Network Detection and Response (NDR), NSX Intelligence, Advanced Load Balancing (ALB), Web Application Firewall (WAF), and HCX. Project Northstar will be able to apply consistent networking and security policies across private cloud, hybrid cloud, and multi-cloud environments.
At VMware Explore on day 1,VMware unveiled Project Watch, a new approach to multi-cloud networking and security that will provide advanced app-to-app policy controls to help with continuous risk and compliance assessment. In technology preview, Project Watch will help network security and compliance teams to continuously observe, assess, and dynamically mitigate risk and compliance problems in composite multi-cloud applications.
Project Trinidad
Also announced at VMware Explore day 1 and further explained at day 2, Project Trinidad extends VMware’s API security and analytics by deploying sensors on Kubernetes clusters and uses machine learning with business logic inference to detect anomalous behavior in east-west traffic between microservices.
Project Trinidad just dropped from @vmwocto xLabs! This project is near and dear to my heart! (Happy Independence Day 🇹🇹!!! 😉)
Project Narrows introduces a unique addition to Harbor, allowing end users to assess the security posture of Kubernetes clusters at runtime. Images previously undetected, will be scanned at the time of introduction to a cluster, so vulnerabilities can now be caught, images may be flagged, and workloads quarantined.
Project Narrows adding dynamic scanning to your software supply chain with Harbor is critical. It allows greater awareness and control of your running workloads than the traditional method of simply updating and storing workloads.
VMware is open sourcing the initial capabilities of Project Narrows on GitHub as the Cloud Native Security Inspector (CNSI) Project.
Also introduced on day 2, Project Keswick is about simplifying edge deployments at scale. It comes as an xLabs project coming out of the Advanced Technology Group in VMware’s Office of the CTO.
A Keswick deployment is entirely automated and uses Git as a single source of truth for a declarative way to manage your infrastructure and applications through desired state configuration enabled by GitOps. This ensures the infrastructure and applications running at the edge are always exactly what they need to be.
At VMware Explore 2022 day 2, VMware demonstrated what they believe to be the world’s first quantum-safe multi-cloud application!
VMware developed and presented Project Newcastle, a policy-based framework enabling and orchestrating cryptographic transition in modern applications.
Integrated with Tanzu Service Mesh, Project Newcastle gives users greater insight into the cryptography in their applications. But that’s not all — as a platform for cryptographic agility, Project Newcastle automates the process of reconfiguring an application’s cryptography to comply with user-defined policies and industry standards.
Closing Comment
Which VMware projects excite you the most? I’m definitely going with Project Ensemble (Aria Hub) and Project Newcastle!
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.
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.
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 canadapt 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.
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.
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.
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.
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):
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:
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 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.
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.
Currently working as a Lead Solution Architect for VMware Switzerland and focus on some of the largest and most strategic customers. Additionally, I am part of VMware's Office of the CTO Global Field and Industry team in the role of a CTO Ambassador. I also engage with the VMware community as a co-leader of the Swiss German VMUG and became a VMware vExpert PRO in 2022. Opinions are my own.
VMware CMTY Podcast #607 – VMware Cloud Foundation
VMware CMTY Podcast #546 – VMware Carbon Black Cloud Workload
