Since the launch of the PASⓇ for Kubernetes alpha, PivotalⓇ has seen massive interest in the product. The market is excited about a proven enterprise application platform running atop the infrastructure API of choice, KubernetesⓇ.
“We are intent on introducing that ‘CF Push’ experience to Kubernetes.” https://t.co/Lq31R4HsH1— Michael Coté (@cote) November 5, 2019
KubeConⓇ seemed like a good time to provide an update on our PAS for Kubernetes alpha progress. This post examines our approach and philosophy towards achieving general availability with PAS for Kubernetes. It includes a recap of planned investments and capabilities. Read on for details!
Many of the world’s largest businesses trust their most important apps to Pivotal Application Service.Ⓡ Healthcare companies. Retail leaders. Government agencies. Financial services. In each case, PAS offered the best tooling for getting apps to production quickly, at scale.
Have you seen those DevOps Research and Assessment (DORA) criteria? PAS dramatically improves your outcomes in each area. Those outcomes aren't something that comes from adopting raw infrastructure. That’s why we're bringing those outcomes to Kubernetes.
One of the criticisms of PAS you've given us is that it has a big infrastructure footprint. That's fair, as we've been VM-based and prioritized high availability over compact-ness. With Kubernetes, we can now containerize PAS itself. As a result, the product is easier to install, simpler to manage, and more cost effective to operate.
All the while, you keep the three things that are the biggest game-changers: a fully automated dev workflow to production, app-centric operations, and automated platform management. Let's look at those.
A Fully Automated Development Workflow to Production (or, cf push is Sacred)
If you ask the power users of PAS today, they will tell you it’s the best developer experience in the market.
As noted many times over,
cf push is indeed sacred.
Our initial developer experience in PAS for Kubernetes includes:
cf push. Of course this is the top item! We’re initially focused on LinuxⓇ buildpack-based and DockerⓇ-image-based apps.
App lifecycle management. The next best thing to do after pushing your app is to scale it out seamlessly, and PAS for Kubernetes enables the same smooth experience that PAS developers have come to expect.
App instance status and telemetry. You need to know the status and resource usage of your app instances; we bundle in app logs, metrics, and events.
Environment-variable-based service bindings. Of course you store config in the environment; it’s one of the 12-factor app principles! We've been conveying service bindings in those environment variables since the early days of Cloud FoundryⓇ, and that remains the same with PAS for Kubernetes.
A container environment consistent with existing PAS installations. Those apps that already run great on PAS shouldn't have any compatibility issues moving into their new Kubernetes-hosted container homes.
Pretty straightforward, right? Since PAS is already a magical build-run-wire experience for developers, we want to keep this just as it exists today.
App-centric Operations and Automated Platform Management: The Platform Ops Experience
PAS delivers remarkable platform efficiency; enterprises adopters enjoy a high level of automation. Platform updates and upgrades are performed with minimal impact to custom apps. It’s not easy to pull this off with distributed systems at scale, but it can be done. Just ask any PAS customer!
Clearly, this level of automation is a requirement for PAS for Kubernetes. And there are other guiding lights for us to follow. For example, the ideal product would bundle these familiar features:
App-instance isolation controls and resource limits. Kubernetes provides a rich, flexible toolkit of isolation controls for containerized workloads, and we're working to make it the same easy and robust multi-tenant experience we've had for years in PAS.
Permissions model (orgs, spaces, users, quotas, roles). Give every engineer the right level of access to do their job, and do it in a familiar way.
Registration of service brokers and exposure to orgs. You need a backing service to do anything interesting with your code. Service brokers, along with the aforementioned permissions model, make this a breeze at scale.
With PAS for Kubernetes, platform engineers will interact with PAS system components via the Kubernetes CLI and other tools as needed.
Platform teams are responsible for delivering outcomes for scale, stability, and security. In fact, these are three of “the Ss” we care most about!
Had the pleasure of talking with @cmcluck on stage here in Tokyo about elements of Tanzu. Craig now doing a deeper dive. “ @VMware Tanzu is not just about Kubernetes , it’s about completing story ... Speed,Security,Savings,Stability,Scalability” pic.twitter.com/vKWQAMHSc6— Ray O 'Farrell (@ray_ofarrell) November 11, 2019
What do you need from PAS for Kubernetes to run it in production? We figure these three attributes are good benchmarks.
Stability. Upgradability to subsequent versions of PAS for Kubernetes within acceptable SLOs for app and dev-facing API uptime. (Curious about SLOs and other site reliability engineering concepts? There’s a blog post for that.)
Scale. Our goal for an initial scalability milestone for the product is to satisfy the large majority of foundations in use today.
Security. For encryption in transit, mutual TLS to all PAS system components is a reasonable requirement.
A Word on API Compatibility
PAS for Kubernetes retains API-level compatibility with important Cloud Foundry components as well as Kubernetes itself. Our technical goals for GA include:
Continuity with the app developer experience and tooling. Continue to use the cf CLI and the Cloud Controller API just as you do today.
Continuity with existing deployment tools, while also accommodating Kubernetes-centric ones as they emerge. Operations Manager is an important control plane for Pivotal customers. Native support for Kubernetes primitives will ensure maximum flexibility to adopt new tools as they emerge from the community.
The adoption of Kubernetes as the infrastructure for both apps and system components. No surprise here; Kubernetes is the dominant API for cloud infrastructure.
Integration with the best open-source projects. The lines between Cloud Foundry and Kubernetes have happily blurred. For example, PAS today includes Istio and Envoy. Similarly, CF Buildpacks are evolving to feature kpack, a Kubernetes-native way to build containers from source code. It’s a winning strategy to curate the best open-source tech!
Experience teaches us that each platform component evolution is a little different. But these are the foundational technical principles for us in this scenario.
We're Working to Containerize Open Source Cloud Foundry Too
Over the past year, we've joined our fellow member companies in the Cloud Foundry Foundation to contribute to the Eirini Project, Cloud Foundry's gateway to Kubernetes. But that's just the beginning. Other core Cloud Foundry (CF) App Runtime component teams are getting in on the act, too:
The CAPI team is busy on two fronts. First, they are containerizing the Cloud Controller and other Cloud API components to run as Kubernetes workloads. These engineers are also integrating kpack with Cloud Controller as the Kubernetes way to build images with the next generation of buildpacks.
The CF Networking team is building brand-new components to translate Cloud Controller's route records into Istio resources that configure dynamic routing through Envoy.
Not to be outdone, the CF Identity team is also containerizing the UAA account and authentication server. They are optimizing the component to run behind a variety of load-balancers, not just the familiar Gorouter.
The Loggregator team is driving years of experience operating at scale into their new plans for logging and metric architecture, and is exploring how to integrate these plans into the logging services already built into Enterprise PKS.
We're excited to see this momentum building across all these component teams, and intend to bring this activity together in the community and within PAS for Kubernetes.
Request Early Access to PAS for Kubernetes Alpha
PAS for Kubernetes isn’t just the usual evolution of components to keep pace with the industry. It will also make the at-scale app platform more universally deployable.
Run your most important apps on PAS for Kubernetes, and achieve great outcomes wherever you desire: in the public cloud, at the edge, or in your data center.
CF Push was born at @VMware and its fun to watch its return as an industry leader in developer experience for container environments.— James Watters (@wattersjames) November 5, 2019
In the meantime, we’re cranking out new features and innovating on our current commercial product portfolio. Watch this recent webinar to learn about the newest features to Pivotal Platform. Stay tuned for more updates in the coming months!
SAFE HARBOR STATEMENT
This blog contains statements relating to Pivotal’s expectations, projections, beliefs and prospects which are "forward-looking statements” within the meaning of the federal securities laws and by their nature are uncertain. These include statements about upcoming releases of Enterprise PKS. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are also intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors, including but not limited to: (i) our limited operating history as an independent company, which makes it difficult to evaluate our prospects; (ii) the substantial losses we have incurred and the risks of not being able to generate sufficient revenue to achieve and sustain profitability; (iii) our future success depending in large part on the growth of our target markets; (iv) our future growth depending largely on Pivotal Cloud Foundry and our platform-related services; (v) our subscription revenue growth rate not being indicative of our future performance or ability to grow; (vi) our business and prospects being harmed if our customers do not renew their subscriptions or expand their use of our platform; (vii) any failure by us to compete effectively; (viii) our long and unpredictable sales cycles that vary seasonally and which can cause significant variation in the number and size of transactions that can close in a particular quarter; (ix) our lack of control of and inability to predict the future course of open-source technologies, including those used in Pivotal Cloud Foundry; and (x) any security or privacy breaches. All information set forth in this release is current as of the date of this release. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time in documents filed by us with the U.S. Securities and Exchange Commission (SEC), including our Annual Report on Form 10-K. Additional information will be made available in our quarterly report on Form 10-Q and other future reports that we may file with the SEC, which could cause actual results to vary from expectations. We disclaim any obligation to, and do not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.
This blog also contains statements which are intended to outline the general direction of certain of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract. Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an if and when available basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. Any purchasing decisions should only be based on features currently available. The development, release, and timing of any features or functionality described for Pivotal's offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.
© 2019 Pivotal Software, Inc. All rights reserved. Pivotal, Pivotal Application Service and PAS are trademarks and/or registered trademarks of Pivotal Software, Inc. in the United States and/or other countries. Kubernetes, Linux and Envoy are trademarks and/or registered trademarks of the Linux Foundation in the United States and/or other countries. Docker is a trademark and/or registered trademark of Docker, Inc. in the United States and/or other countries. Istio is a trademark and/or registered trademark of Google, Inc. in the United States and/or other countries. Windows is a trademark and/or registered trademark of Microsoft in the United States and/or other countries. Cloud Foundry is a trademark and/or registered trademark of the Cloud Foundry Foundation, Inc. in the United States and/or other countries.
About the AuthorFollow on Twitter Follow on Linkedin More Content by Eric Malm