Authored by Eamon Ryan, Staff Solutions Architect

I wanted to be sure to get my first post out early to promote the session I am co-presenting at VMworld US 2016 this year in Las Vegas – the session details are:

Pivotal and VMware: The Lowdown on the High Up – CNA7806
Thursday, Sep 01, 12:00 p.m. – 1:00 p.m.

You ask, “What have you done for me lately?”
Last year a number of integrations between Pivotal and VMware were showcased, but what indeed have we done for you lately? New products and advancements from VMware, Pivotal, and EMC have brought opportunities for fantastic joint solutions and use cases to be developed, growing capabilities beyond what was possible before, bringing enhanced speed, agility, and simplicity to developers and operations users alike, with unified governance and management.

I will be co-presenting alongside Alka Gupta – Senior Global Technical Alliance Manager at VMware, so come on by and learn about all the ins and outs of what Pivotal and VMware are doing jointly lately!

Learning outcomes:
• The 10,000-foot view of Pivotal and VMware as it stands today
• Pivotal Cloud Foundry and VMware Photon Platform (software bundle and native hybrid cloud)
• Pivotal Cloud Foundry and VMware NSX, vSAN, VMware vRealize Operations, vRealize Automation, and vRealize Code Stream
• Pivotal Cloud Foundry use cases for federation enterprise hybrid cloud
• How you can benefit and where your environment best fits in
• Real-world customer case studies showcasing the learnings and business advantages experienced along the way.

For more deep-dive sessions on specifics, check these two other sessions out:

Éamon Ryan




Introducing the Bigger and Better vSphere Integrated Containers

Last year at VMworld, we announced vSphere Integrated Containers, which allows you to deeply embed a container runtime into vSphere. It enables vSphere admins to provision a container images as a virtual machine, allowing them to extend all the enterprise capabilities of vSphere along with the plugins and products from our partners to work seamlessly with containers.

vSphere Integrated Containers was initially built using Project Bonneville and we used that early prototype to gather feedback from our customers through various early access programs. The learnings from these programs led us to a) update the product architecture to support a broader set of functionality and b) extend the vSphere Integrated Containers feature set by adding an enterprise container registry and a container management portal.

The new architecture for vSphere Integrated Containers is as follows:


vSphere Integrated Containers is now comprised of three main components, all of which are available as open source on github (links below):

The vSphere Integrated Containers Engine is a container runtime for vSphere, allowing developers familiar with Docker to develop in containers and deploy them alongside traditional VM-based workloads on vSphere clusters. These workloads can be managed through the vSphere UI in a way familiar to existing vSphere admins.

Harbor, the enterprise container registry, is an enterprise-class registry server that stores and distributes container images. Harbor extends the open source project Docker Distribution by adding the functionalities usually required by an enterprise, such as security, identity and management.

Admiral, the container management portal, provides a UI for developers and app teams to provision and manage containers, including retrieving stats and info about container instances. Cloud administrators will be able to manage container hosts and apply governance to its usage, including capacity quotas and approval workflows. When integrated with vRealize Automation, more advanced capabilities become available, such as deployment blueprints and enterprise-grade Containers-as-a-Service.

With these three capabilities, vSphere Integrated Containers will enable VMware customers to deliver a production-ready container solution to their developers and app teams. By leveraging their existing SDDC, customers will be able to run container-based applications alongside existing virtual machine based workloads in production without having to build out a separate, specialized container infrastructure stack. As an added benefit for customers and partners, vSphere Integrated Containers is modular. So, if your organization already has a container registry in production, you can use that registry with the other components of vSphere Integrated Containers.

We’re really excited about helping customers move containerized applications into production with vSphere Integrated Containers.  If you haven’t already, please check it out and sign up for the beta.  vSphere Integrated Containers is bigger and better than ever! Connect with us @cloudnativeapps on twitter!


Authored by Ryan Kelly, Staff Systems Engineer, Cloud Management

This year VMworld is back in Vegas and it is bigger than ever. While it is going to be a blast to be in Vegas there is a lot more to get excited about. As an employee I can’t register for sessions so that you all have first dibs. I can still attend if there is room. In no particular order here are my top 10 sessions that I want to attend. Notice they are not my own sessions.

If you are interested in any of my sessions here they are:



Authored by Randy Carson, Senior Systems Engineer

vic   PP

Check out  Cloud-Native Applications Hands of Labs that will be released at VMworld 2016, both are listed under HOL-1730.  If you are not attending VMworld, these labs will be available shortly after.  How is VMware offering container focused solutions?  Check them out.  USE-1 is all about VIC (vSphere Integrated Containers). See how easy it is to deploy container VMs in your current VMware infrastructure through the same Docker APIs.  Yes, in VIC we deploy docker images as tiny VMs. Why? Because you can use new developer friendly docker interfaces to manage applications while, at the same time, leveraging your enterprise class infrastructure.  Quickly enable your developers to start creating a container based application.   USE-2 is all about Photon Controller.  Want to create a micoservices based application?  Photon Controller is optimized for pure cloud-native application deployment.  Easily setup different clusters for your developers to run Kubernetes, Mesos, and Docker Swarm each in their own cluster but on the same vSphere hosts.   So come be a geek, bang at the CLI, build a NGINX application and learn how VMware can deliver the environment the developers are asking for.


Authored by Cormac Hogan, Senior Staff Engineer, Storage Product Marketing

PHOTON_square140As many regular reader will be aware, I’ve been spending a lot of time recently on VMware’s Cloud Native App solutions. This is due to an internal program available to VMware employees called a Take-3. A Take-3 is where employees can take 3 months out of their current role and try a new challenge in another part of the company. Once we launched VSAN 6.2 earlier this year, I thought this would be an opportune time to try something different. Thanks to the support from the management teams in both my Storage and Availability BU (SABU) and the Cloud Native Apps BU (CNABU),  I started my Take-3 at the beginning of May. This is when my CNA articles on VIC (vSphere Integrated Containers) and Photon Controller first started to appear. Only recently I was asked an interesting question – when would I use VIC and when would I use Photon Controller? That is a good question, as both products enable customer to use containers on VMware products and solutions. So let me see if I can provide some guidance, as I asked the same question from some of the guiding lights in the CNABU.

When to use VIC?

Lets talk about VIC first, and why customer might like to deploy container workloads on VIC rather than something like “container in a VM”. Just to recap, VIC allows customers to run “container as a VM” in the vSphere infrastructure, rather than “container in a VM”. It can be deployed directly to a standalone ESXi host, or it can be deployed to vCenter Server. This has some advantages over the “container in a VM” approach.

Reason 1 – Efficiency

Consider an example where you have a VM which runs a docker daemon and launches lots of containers. Customers will now connect to these containers via docker client. Assume that over a period of time, this VM uses up a significant mount (if not all) of its memory for containers and eventually these containers are shutdown. This does not allow the memory consumed by the VM on behalf of the containers go back into a shared pool of memory (on the hypervisor where the VM is run) for other uses. With VIC, since we are deploying containers as VMs and using ESXi/hypervisor memory resource management, we do not have this issue. To think of this another way:- containers are potentially short-lived, whereas the “container host” is long-lived, and as such can end up making very inefficient use of system resources from the perspective of the global pool.

Now there is a big caveat to this, and it is the question of container packing and life-cycle management. If the container host VMs are well-packed with containers, and you also have control over the life-cycle of the container host, then it can still be efficient. If however there is no way to predict container packing on the container host and if over-provisioning is the result, and you also have no control over the life-cycle of the container host, then you typically don’t get very good resource efficiency.

Reason 2 – Muti-tenancy

There is no multi-tenancy in Docker. Therefore if 50 developers all requested a “container” development environment, a vSphere admin would have to deploy 50 Virtual Machines, one per developer. With VIC, we have the concept of a VCH (Virtual Container Host) which controls access to a pool of vSphere resources. A VCH is designed to be single-tenant, just like a Docker endpoint. Both present you with a per-tenant container namespace. However, with VIC, one can create very many VCHs, each with their own pool of resources. These VCH (resource pools), whether built on a single ESX host or vCenter Server, can be assigned to individual developers.

One could consider now that the vSphere admin is doing CAAS – Containers as a Service.

The 50 developers example is as much about efficiency as it is about tenancy – the fact that you can only have one tenant per container host VM will force you down a path of creating a large silo composed of 50 container host VMs. In the case where we’re comparing ESXi with Linux on the same piece of hardware to run container workloads, ESXi has a big advantage in that you can install as many VCHs as you like.

Reason 3 – Reducing friction between vSphere/Infra Admin and developer

On the main goals of VIC was basically not to have the developer worry about networking and security infrastructure with containers. This particular reason is more about how VIC informs and clarifies the boundaries between the vSphere admin and the developer. To put it simply, a container host VM is like a mini-hypervisor. Give that to a developer and they’re then on the hook for patching, network virtualization, storage virtualization, packing etc. within the container host. The container host is then also a “black box” to the infra folks which can lead to mistakes being made. E.g. “Only certain workloads are allowed on this secure network”. The secure network is configured at the VM level. If the VM is a container host, its hard to control or audit the containers that are coming up and down in that VM and which have access to that secure network.

VIC removes any infra concerns from the consumer of a VCH and allows for much more fine-grained control over access to resources. With VIC, each container gets its very own vNIC.A vSphere admin can also monitor resources that are being consumed on a per container basis.

There is one other major differentiator here with regards to the separation of administrator and developer roles which relates to compliance and auditing tools, and a whole list of process and procedures they have to follow as they run their data center. Without VIC developers end up handing over large VMs that are essentially black boxes of “stuff happening” to the infra team. This may include the like of overlay networks between those “black boxes”. It’s likely that most of the existing tools that the infra team use for compliance, auditing, etc will not work.

With VIC there is a cleaner line of demarcation. Since all the containers are run as VMs. and the vSphere admin already has tools setup to take care of true operationalizing of VMs, then they inherit this capability with containers.

Reason 4 – Clustering

Up until very recently, Docker Swarm has been very primitive when compared to vSphere HA and DRS clustering techniques as the Docker Swarm placement algorithm was simply using round-robin. I’ll qualify this by saying that Docker just announced a new Swarm mechanism that uses Raft consensus rather than round-robin at DockerCon ’16. However, there is still no consideration given to resource utilization when doing container placement. VCH, through DRS, has intelligent clustering built-in by its very nature. There are also significant considerations in this area when it comes to rolling upgrades/maintenance mode, etc.

Reason  5 – May not be limited to Linux

Since VIC virtualizes at the hardware layer, any x86 compatible operating system is, in theory, eligible for the VIC container treatment, meaning that it’s not limited to Linux. This has yet to be confirmed however, and we will know more closer to GA.

Reason 6 — Manage both VM based apps and CNA apps in the same infra

This is probably the reason that resonates with folks who are already managing vSphere environments. What do you do when a developer asks you to manage this new, container based app? Do you stand up a new silo just to do this? With VIC, you do not need to. Now you can manage both VMs and containers via the same “single pane of glass”.

When to use Photon Controller?

Let’s now talk about when you might use Photon Controller. Photon Controller allows you to pool a bunch of ESXi hosts and use them for the deployment of VMs with the sole purpose of running containers.

Reason 1 – No vCenter Server

This is probably the primary reason. If your proposed “container” deployment will not include the management of VMs but is only focused on managing containers, then you do not need a vCenter Server. Photon Controller does not need a vCenter Server, only ESXi hosts.  And when we position a VMware container solution on “greenfield” sites, we shouldn’t have to be introducing an additional management framework on top of ESXi such as vCenter. The Photon Controller UI will provide the necessary views into this “container” only environment, albeit containers that run on virtual machines.

Reason 2 – ESXi

ESXi is a world-renowned, reliable, best-in-class hypervisor, with a proven track record. If you want to deploy containers in production, and wish to run them in virtual machines, isn’t ESXi the best choice for such as hypervisor? We hear from many developers that they already use the “free” version of ESXi for developing container applications as it allows them to run various container machines/VMs of differing flavours. Plus it also allows them to run different frameworks (Swarm, Kubernetes, Mesos). It would seem to make sense to have a way to manage and consume our flagship hypervisor product for containers at scale.

Reason 3 – Scale

This brings us nicely to our next reason. Photon Controller is not limited by vSphere constructs, such as cluster (which is currently limited to 64 ESXi hosts). There are no such artificial limits with Photon Controller, and you can have as many ESXi hosts as you like providing resources for your container workloads. We are talking about 100s to 1000s of ESXi hosts here.

Reason 4 – Multi-tenancy Resource Management

For those of you familiar with vCloud Director, Photon Controller has some similar constructs for handling multi-tenancy. We have the concept of tenants, and within tenants there is the concept of resource tickets and projects. This facilitates multi-tenancy for containers, and allows resources to be allocated on a per tenant basis, and then on a per-project basis for each tenant. There is also the concept of flavors, for both compute and disk, where resources allocation and sizing of containers can be managed.

Reason 5 – Quick start with cluster/orchestration frameworks

As many of my blog posts on Photon Controller has shown, you can very quickly stand up frameworks such as Kubernetes, Docker Swarm and Mesos using the Photon Controller construct of “Cluster”. This will allow you to get started very quickly on container based projects. On the flip side, if you are more interested in deploying these frameworks using traditional methods such as “docker-machine” or “kube-up”, these are also supported. Either way, deploying these frameworks is very straight forward and quick.


I hope this clarifies the difference between the VIC and Photon Controller projects that VMware is undertaking. There are of course other projects on-going, such as Photon OS. It seems that understanding the difference between VIC and Photon Controller is not quite intuitive, so hopefully this post helps to clarify this in a few ways. One thing that I do want to highlight is that Photon Controller is not a replacement for vCenter Server. It does not have all of the features or services that we associate with vCenter Server, e.g. SRM for DR, VDP for backup, etc.

Many thanks to Ben Corrie and Mike Hall of the VMware CNABU for taking some time out and providing me with some of their thoughts and ideas on the main differentiators between the two products.


Authored by Ryan Kelly, Staff Systems Engineer, Cloud Management


In no particular order, here are the top 10 labs that I want to take this year at VMworld

  • Cloud Operations With Photon Platform [SPL-1730-USE-2]– This lab will provide an introduction into the new operational models for cloud native applications. Users will set up a Private Cloud on the Photon Platform control plane and will deploy Cloud Applications using multiple application framework technologies, including Docker and Kubernetes.
  • DevOps-Ready IT with vRealize Code Stream [SPL-1706-SDC-2]– This lab will introduce you to vRealize Code Stream which provides release pipeline automation and continuous delivery for DevOps-ready IT. You will learn how to install and configure vRCS and execute a pipeline on a live application.
  • Introduction to vRealize Orchestrator [SPL-1721-SDC-5] – Learn how to use vRealize Orchestrator to simplify the automation of IT tasks. Explore the vRealize Orchestrator development environment and learn important development concepts by building and testing basic workflows.
  • vRealize Automation Extensibility [SPL-1721-USE-3]– his advanced lab explores how vRealize Automation leverages the new Event Broker to extend functionality with existing toolsets and workflows. Common extensibility scenarios include IP Address Management with Infoblox, ITSM tools, DNS and many more.
  • vCloud Network Functions Virtualization [SPL-1786-USE-1]– VMware vCloud NFV is a Network Functions Virtualization (NFV) services delivery, operations and management platform, developed for Communications Service Providers (CSPs). For this lab we have partnered with Cloudify and Athonet. We will demonstrate the end-to-end lifecycle of VNF management and orchestration  from installation and deployment through post-deployment, or in the telco industry terminolo
  • vSphere Automation API and SDK: Tech Preview [SPL-1710-SDC-5]– This Lab introduces you to vSphere Automation APIs and SDKs, which are new developer friendly, simplified interfaces that allow for Virtual Machine creation, modification and deletion via a consistent set of developer and automation tooling.
  • vRealize Operations Advanced Use Cases [SPL-1706-USE-4]– This Lab introduces some advanced vRealize Operations topics such as crafting your Policies, working with Super Metrics and Custom Dashboards, using the Alerting framework, and creating custom Views and Reports. We will also introduce the user to End Point Operations and the vRealize Operations API.
  • vRealize Automation 7 Basics [SPL-1721-USE-1]– This introductory lab demonstrates the features of vRealize Automation and is a great place to start to begin learning about the powerful capabilities and features of the solution.
  • vSphere Integrated Containers from A to Z [SPL-1730-USE-1]– This lab explores vSphere Integrated Containers (VIC) and it’s ability to combine the agility and application portability of Docker Linux containers with VMware’s industry-leading virtual infrastructure platform – a solution that provides unique isolation advantages along with improved container manageability.
  • vRealize Automation 7 Advanced [SPL-1721-USE-2]– This advanced lab covers the more complex service authoring capabilities of vRealize Automation including XaaS and Puppet, NSX integration and Application Authoring.

There you have it, maybe I will see you in a Lab next to me!

NOTE: These labs are delivered on a first-come, first-served basis and do not need to be scheduled in advance.


Sun., Aug. 28: 9am-7pm
Mon., Aug. 29: 10:30am-6pm
Tue., Aug. 30: 10:30am -6pm
Wed., Aug. 31: 8am-5pm
Thur., Sept. 1: 8am-3pm



Get Ready for Another Cloud-Native Packed VMworld!

CNA_cloud logo

VMworld is less than a week away.  And like last year, we’ve got a lot happening on the Cloud-Native front!  We’ll be providing updates and deep dives into vSphere Integrated Containers and Photon Platform, talking about what our other technologies are doing in this space (e.g. NSX, VSAN, vRealize), in addition to going deeper on DevOps, containers, CI/CD, and more.

But I may be getting a bit ahead of myself.  Some of you have a good understanding of what the “cloud native” space consists of, but many of you probably don’t.  So before getting into specifics, it’s important to understand why you should care about this space.  When we talk about “cloud native”, we’re really talking about the tools, technologies, and processes that enable a faster, more responsive organization that achieves a higher software delivery velocity.  As software becomes a bigger differentiator for businesses, those businesses that are quickest to release high quality software and react to users’ preferences will have a huge business advantage.  The latest State of DevOps Report 2016 clearly shows the impact of higher performing organizations:

  • Top performing IT organizations deploy 200 times more frequently than lower performing ones
  • They have three times lower change failure rates and when they do have failures, they recover 24 times faster
  • They spend 22 percent less time on unplanned work or rework

As you can see, these numbers are stunning and it should be clear that the sort of advantage a high performing IT organization can deliver really makes a difference between a successful and an unsuccessful business.  Achieving this high performance organization is everyone’s responsibility.  You shouldn’t assume that someone else will do it.  You should think about how you can drive this sort of change in your org!


And that’s what we’re here to help with.  We have a ton of content on all aspects of cloud-native at VMworld.  Let me walk you through what we have in store for VMworld:

  • Keynotes: Cloud-native will be featured throughout the first two days of keynotes at VMworld, but we’ll have a specific section on cloud-native during the day 2 keynote – Tuesday, Aug 30.  We will have some exciting updates on vSphere Integrated Containers and Photon Platform.
  • Breakout sessions: These are deeper dive sessions into a wide variety of topics.  VMworld has hundreds of breakout sessions over a course of four days throughout the conference and there are a few dozen of these sessions dedicated to cloud-native.  There are two specific tracks we’d like to call out:
    • Cloud-Native: the CNA track covers vSphere Integrated Containers, Photon Platform, Pivotal-VMware Cloud-Native Stack, DevOps, CI/CD, Open source, and much more!
    • DevOps : the DevOps track covers all aspects of DevOps, from basic 101 level overviews to deeper dives into specific use cases.  It also covers a broad range of technologies, allowing you to see how VMware’s technologies fit into a DevOps environment.
  • Hands-on labs (HOL): HOLs are where you can get very hands on (as the name suggests… :)) experience with a particular technology or product.  We have two HOLs specifically on cloud-native: one on vSphere Integrated Containers and one on Photon Platform.
  • Expo booths at Solutions Exchange: The expo booth is a great place to get a high level overview of our products as well as a forum to ask specific questions you may have.  We’ll have expo booths for vSphere Integrated Containers, Photon Platform, and the Pivotal-VMware Cloud-Native Stack (bundle of Pivotal Cloud Foundry and Photon Platform) at the VMware booth in the Solutions Exchange.
  • VMware {code} hackathon: A fun way to put what you’ve learned into practice is the hackathon from VMware {code}.  It’s not all cloud-native, but if you adapt cloud-native and DevOps practices, you could have an advantage!!

Finally, if you want everything CNA happening at VMworld in one convenient place, check out our field guide and connect with us @cloudnativeappsSo as you can see, there’s a tremendous amount to do at VMworld this year.  We’re really excited to share these updates with you next week in Vegas and have been working hard to pull everything together.  We look forward to seeing you there!


Authored by Ryan Kelly, Staff Systems Engineer, Cloud Management

     Many organizations are on a journey to adopt containers in some form or another. There are many options available on the market today and even VMware has multiple options for running containers. While containers are similar to virtual machines they come with their own obstacles and challenges to support them in production.

Graphic based on the original Tweet of @mfdii as seen here

In this session I will present the technical features of each solution and give some background on the goals of each of both stacks. I will also compare and contrast the features of both Photon Platform and vSphere Integrated containers and list the use cases that each one addresses. There will also be time to ask any questions that are on the top of your mind. Click here to sign up for this session or any other of my sessions.

Containers for the vSphere Admin


Updated Aug 24, 2016, added graphic attribution.


Authored by Emad Benjamin, Principal Architect, Global Services Advanced Architecture

Cloud-Native Apps_State of the Union

As per the above picture many have talked about Cloud Native Apps (CNA) but only few have done real implementations, and the time is now for this technology trend to become main-stream.  In this group discussion we will have an interactive session on what is cloud native, what scale it addresses, who are some of the adopters, and which direction this trend is forcing the market over the next few years.  It is an opportunity for you to ask the simplest of questions to the most complex ones, sometimes a simple question as “what is cloud native” can quickly turn into a complicated answer, and hence is the opportunity to discuss the wide variety of opinion that surrounds this.

In this talk we will highlight the elements of this rapidly moving phenomenon through our industry, a phenomenon of building platforms, not just business logic software but infrastructure as software. We humbly believe that the drive towards these platform solutions is due to the following fact: approximately half of new applications fail to meet their performance objectives, and almost all of these have 2.x more cloud capacity provisioned than what is actually needed. As developers/DevOps engineers we live with this fact every day, always chasing performance and feasible scalability, but never actually cementing it into a scientific equation where it is predictable, but rather it has always been trial based, and heavily prone to error. As a result we find ourselves delving with some interesting platforming patterns of this decade, and unfortunately we are lead to believe that such patterns as microservices, 3rd platforms, cloud native, and 12factor are mainly a change in coding patterns.  However, contrary to this popular belief, these patterns represent a major change in “deployment” approach, a change in how we deploy and structure code artifacts within applications runtimes, and how those application runtimes can leverage the underlying cloud capacity. These patterns are not code design patterns, but rather platform engineering patterns, with a drive to using APIs/Software to define application platform policies to manage scalability, availability and performance in a predictable manner.

In this session we give you an opportunity to come ask us any and all of your questions about cloud native and what it is going to mean for you as Ops and DevOps Engineer over the next few years, how the market is changing and how you will have to adapt to meet those challenges.

This session will be presented at VMworld 2016 – Las Vegas. Register here.


Authored by Martijn Baecke, Senior Systems Engineer

Digital Transformation? DevOps? Docker? What is this all about? Well this is exactly what we will discuss during our session “Running Docker on your existing Infrastructure with vSphere Integrated Containers”at VMworld. Over the last couple of years containers have taken the world by storm. Developers have started using them to package their application code. Containers have made their world a lot easier and flexible; but what runs in test / development at some point needs to go into production.

The question that then comes to mind is: How are you going to deploy that and how are we going to manage these new workloads? Should you build a new infrastructure specifically for containers? Do you want another silo to manage, maintain and update or do you run it on something that already works and that you’ve known for years? There is no need for a new infrastructure, you already have an infrastructure that works and that you know how to operate. To stay relevant, containers need to be part of your existing infrastructure; vSphere Integrated Containers is a means to that end.

In this session, we will outline the architecture of vSphere Integrated Containers, explain how it works and how it will help you to stay secure, while keeping control of your infrastructure resources. You can provide developers the containers that they want, but maintain the same way of working without the need to change your infrastructure. The best of both worlds!