What Project Pacific Really means for VMware

This week at VMworld, VMware announced Project Pacific, Kubernetes built into vSphere. As a VMware employee I have been following and supporting this project for some time. In my opinion this innovation is right there next to vMotion and HA, a simple and elegant feature that transform VMware from so called legacy infrastructure to cloud native and beyond. In this post I will illustrate what this new feature really means for vSphere and the future of VMware and our partner ecosystem. Essentially, Project Pacific is about surfacing the Kubernetes API and constructs as native services built into ESXi and vCenter. You are probably thinking, but VMware has offered infrastructure API’s for a number of years, what is different here? To answer that, let’s review Infrastructure API’s VMware offers today:

  • vSphere API – Good API targeted at vSphere admins and partner solutions, not ideal for app developers as it requires a bit of understanding about vSphere Clusters, datastore, VM networks etc. also no native container support.
  • vCloud API – A bit better for app Developers as it abstracted things like clusters and data stores, still had to know a lot about OVF settings and proprietary VMware settings. Also required vCloud Director to be deployed and configured. No native container support.
  • vRealize Automation API – Closer to a true developer API, similar level of abstraction as vCloud API, still requires a bit of understanding of vRealize constructs like blueprints and custom properties. Also requires you to deploy and manage vRealize Automation. Some container support with Admiral.
  • vSphere Integrated Open Stack API – A widely adopted developer API, heavily used in Telco customers, integrates with native API calls with NSX Networking and Security. Does require you to install and manage Open stack on vSphere. No native container support.

Enter yet another API, ya I know, I get it, but stay tuned, this is a game changer.

Project Pacific API – A true developer API built on Kubernetes. The same Kubernetes API that is used on other non-vSphere platforms and Clouds. Built into vSphere, no additional components to install and manage. Oh and did I mention Project Pacific will also support VM’s? Yup, deploy VM’s and containers from the same API on vSphere.

Benefits to developers:

  • Use the same code and tools on-prem and in the cloud, even on non-vSphere clouds like AWS, Google and Azure. 👍
  • Startups can dramatically lower costs by using vSphere on-prem to stand up a developer cloud 👍
  • Build additional services on vSphere 👍
  • Use VMware Cloud on AWS for traditional workloads as well as Cloud Native 👍

Benefits to both Internal VMware and VMware Partners/Integrators

  • Consistent and non-proprietary infrastructure API 👍👍
  • Build AWS like services on-top of vSphere, for example Object Based Storage with Ceph, Functions as a Service with OpenFaaS, Serverless with Kubless 👍

Exciting times to be at VMware and proof that we still innovate from within vs. just buying startups. The next chapter starts today and I can’t wait to see what comes out of this historic innovation.

Remember sharing is caring!

8 Replies to “What Project Pacific Really means for VMware”

    • Not necessarily, PKS is a managed Kubernetes install, for example if your organization needs to maintain a certain release. Also Pivotal has been aquired by VMware so I imagine a lot of collaboration on both PKS and Pacific.

  1. Pingback: VMware Project Pacific – collection of materials – think-v

Leave a Reply to Iftach Bashan Cancel reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.