Twitter github

Posts Tagged with “cncf”

Cloud Native Predictions for 2021 and Beyond

I hope everyone had a wonderful holiday break as the first couple weeks of January 2021 have been pretty wild, from insurrections to new COVID strains. In cloud native land, the CNCF recently released its annual report on all the work we accomplished last year. I recommend everyone take an opportunity to go through the report, we had a solid year given the wild pandemic circumstances.

https://twitter.com/CloudNativeFdn/status/1343914259177222145

As part of my job, I have a unique and privileged vantage point of cloud native trends given to all the member companies and developers I work with, so I figured I’d share my thoughts of where things will be going in 2021 and beyond:

Cloud Native IDEs

As a person who has spent a decent portion of his career working on developer tools inside the Eclipse Foundation, I am nothing but thrilled with the recent progress of the state of the art. The future will hold that the development lifecycle (code, build, debug) will happen mostly in the cloud versus your local Emacs or VSCode setup. You will end up getting a full dev environment setup for every pull request, pre-configured and connected to their own deployment to aid your development and debugging needs. A concrete example of this technology today is enabled via GitHub Codespaces and GitPod. While GitHub Codespaces is still in beta, you can try this experience live today with GitPod, using Prometheus as an example. In a minute or so, you have a completely live development environment with an editor and preview environment. The wild thing is that this development environment (workspace) is described in code and shareable with other developers on your team like any other code artifact.

In the end, I expect to see incredible innovation in the cloud native IDE space over the next year, especially as GitHub Codespaces enters out of beta and becomes more widely available so developers can experience this new concept and fall in love.

Kubernetes on the Edge

Kubernetes was born through usage across massive data centers but Kubernetes will evolve just like Linux did for new environments. What happened with Linux was that end users eventually stretched the kernel to support a variety of new deployment scenarios from mobile, embedded and more. I strongly believe Kubernetes will go through a similar evolution and we are already witnessing Telcos (and startups) explore Kubernetes as an edge platform through transforming VNFs into Cloud Native Network Functions (CNFs) along with open source projects like k3s, KubeEdge, k0s, LFEdge, Eclipse ioFog and more. The forces driving hyperscaler clouds to support telcos and the edge, combined with the ability to reuse cloud native software and build upon already a large ecosystem will cement Kubernetes as a dominant platform in edge computing over the next few years.

Cloud Native + Wasm

Web Assembly (Wasm) is a technology that is nascent but I expect it to become a growing utility and workload in the cloud native ecosystem especially as WASI matures and as Kubernetes is used more as an edge orchestrator as described previously. One use case is powering an extension mechanism, like what Envoy does with filters and LuaJIT. Instead of dealing with Lua directly, you can work with a smaller optimized runtime that supports a variety of programming languages. The Envoy project is currently in its journey in adopting Wasm and I expect a similar pattern to follow for any environment that scripting languages are a popular extension mechanism to be wholesale replaced by Wasm in the future.

On the Kubernetes front, there are projects like Krustlet from Microsoft that are exploring how a WASI-based runtime could be supported in Kubernetes. This shouldn’t be too surprising as Kubernetes is already being extended via CRDs and other mechanisms to run different types of workloads like VMs (KubeVirt) and more.

Also, if you’re new to Wasm, I recommend this new intro course from the Linux Foundation that goes over the space, along with the excellection documentation 

Rise of FinOps (CFM)

The coronavirus outbreak has accelerated the shift to cloud native. At least half of companies are accelerating their cloud plans amid the crisis… nearly 60% of respondents said cloud usage would exceed prior plans owing to the COVID-19 pandemic (State of the Cloud Report 2020). On top of that, Cloud Financial Management (or FinOps) is a growing issue and concern for many companies and honestly comes up in about half of my discussions the last six months with companies navigating their cloud native journey. You can also argue that cloud providers aren’t incentivized to make cloud financial management easier as that would make it easier for customers to spend less, however, the true pain is lack of open source innovation and standardization around cloud financial management in my opinion (all the clouds do cost management differently). In the CNCF context, there aren’t many open source projects trying to make FinOps easier, there is the KubeCost project but it’s fairly early days.

Also, the Linux Foundation recently launched the “FinOps Foundation” to help innovation in this space, they have some great introductory materials in this space. I expect to see a lot more open source projects and specifications in the FinOps space in the coming years.

More Rust in Cloud Native

Rust is still a young and niche programming language, especially if you look at programming language rankings from Redmonk as an example. However, my feeling is that you will see Rust in more cloud native projects over the coming year given that there are already a handful of CNCF projects taking advantage of Rust to it popping up in interesting infrastructure projects like the microvm Firecracker. While CNCF currently has a super majority of projects written in Golang, I expect Rust-based projects to be on par with Go-based ones in a couple of years as the Rust community matures.

GitOps + CD/PD Grows Significantly

GitOps is an operating model for cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for applications (originally coined by Alexis Richardson from Weaveworks fame). The most important aspect of GitOps is describing the desired system state versioned in Git via a declaration fashion, that essentially enables a complex set of system changes to be applied correctly and then verified (via a nice audit log enabled via Git and other tools). From a pragmatic standpoint, GitOps improves developer experience and with the growth of projects like Argo, GitLab, Flux and so on, I expect GitOps tools to hit the enterprise more this year. If you look at the data from say GitLab, GitOps is still a nascent practice where the majority of companies haven’t explored it yet but as more companies move to adopt cloud native software at scale, GitOps will naturally follow in my opinion. If you’re interested in learning more about this space, I recommend checking out the newly formed GitOps Working Group in CNCF.

Service Catalogs 2.0: Cloud Native Developer Dashboards

The concept of a service catalog isn’t a new thing, for some of us older folks that grew up in the ITIL era you may remember things such as CMDBs (the horror). However, with the rise of microservices and cloud native development, the ability to catalog services and index a variety of real time service metadata is paramount to drive developer automation. This can include using a service catalog to understand ownership to handle incident management, manage SLOs and more. 

In the future, you will see a trend towards developer dashboards that are not only a service catalog, but provide an ability to extend the dashboard through a variety of automation features all in one place. The canonical open source examples of this are Backstage and Clutch from Lyft, however, any company with a fairly modern cloud native deployment tends to have a platform infrastructure team that has tried to build something similar. As the open source developer dashboards mature with a large plug-in ecosystem, you’ll see accelerated adoption by platform engineering teams everywhere.

Cross Cloud Becomes More Real

Kubernetes and the cloud native movement have demonstrated that cloud native and multi cloud approaches are possible in production environments, the data is clear that “93% of enterprises have a strategy to use multiple providers like Microsoft Azure, Amazon Web Services, and Google Cloud” (State of the Cloud Report 2020). The fact that Kubernetes has matured over the years along with the cloud market, will hopefully unlock programmatic cross-cloud managed services. A concrete example of this approach is embodied in the Crossplane project that provides an open source cross cloud control plane taking advantage of the Kubernetes API extensibility to enable cross cloud workload management (see “GitLab Deploys the Crossplane Control Plane to Offer Multicloud Deployments”).

Mainstream eBPF

eBPF allows you to run programs in the Linux Kernel without changing the kernel code or loading a module, you can think of it as a sandboxed extension mechanism. eBPF has allowed a new generation of software to extend the behavior of the Linux kernel to support a variety of different things from improved networking, monitoring and security. The downside of eBPF historically is that it requires a modern kernel version to take advantage of it and for a long time, that just wasn’t a realistic option for many companies. However, things are changing and even newer versions of RHEL finally support eBPF so you will see more projects take advantage. If you look at the latest container report from Sysdig, you can see the adoption of Falco rising recently which although the report may be a bit biased from Sysdig, it is reflected in production usage. So stay tuned and look for more eBPF based projects in the future!

Finally, Happy 2021!

I have a few more predictions and trends to share especially around end user driven open source, service mesh cannibalization/standardization, Prometheus+OTel, KYC for securing the software supply chain and more but I’ll save that for more detailed posts, nine predictions are enough to kick off the new year! Anyways, thanks for reading and I hope to see everyone at KubeCon + CloudNativeCon EU in May 2021, registration is open!

Copenhagen: KubeCon and CloudNativeCon 2018 Takeaways

What a crazy week helping host our annual European community conference in Copenhagen… it’s been wild to see the community grow since the CNCF took over the stewardship of the conference (thank you Joseph Jacks, still remember those conversations we had in the early days):

I was also just blown away by the amount of CNCF ecosystem related jobs out there:

I have a few hours until I board my flight home so I figure I would share some of my take aways from the event in a series of tweets:

CNCF project adoption and the growth of the End User Community

The amount of end users I’ve bumped into at the conference was incredible, insurance companies, medical, automative, government, airlines, tax offices and more. In Dan Kohn’s keynote, he covered our official CNCF End User Community which was setup as a way to ensure End Users have a voice in CNCF governance:

CNCF has one of the largest, if not largest end user community membership of any open source foundation. I’m proud of what we built and mark my words, there will be a day when the number of official CNCF End Users will outnumber our vendors. Also, I was stoked to announce our first Top End User Award to Bloomberg showcasing one of our official end users using cloud native technology an interesting way:

If you’re using CNCF projects an interesting ways, I implore you to join our official End User Community so you have an official voice and more importantly, learn from other end users deploying CNCF projects.

May a thousand [kubernetes] operators bloom

In my opinion, one of the big themes of the conference was the rise of kubernetes operators. In Brandon Philips keynote, Red Hat (CoreOS) open sourced the Operator Framework which makes it easier to write and build operators:

At the conference itself, there were many projects and companies announcing operators for their project or product (see dotmesh, spark, NATS, vitess, etc), expect this trend to continue and explode over the next year, you can see the growing list of operators out there via awesome-operators repo.

CNCF is the center of open source serverless collaboration

The CNCF Serverless Working Group launched their first version of the CloudEvents project:

https://twitter.com/clemensv/status/992478395178119168

There was an incredible demo by Austen Collins showcasing the project across several cloud providers:

For an effort that started under a year ago, it’s nice to see Azure, Google, Oracle, IBM and other major cloud providers collaborate in the working group and support various open source serverless initiatives, I look forward to what they will do next:

CNCF 2020: Expanding ecosystem + Kubernetes: just run my code

Alexis Richardson gave a keynote outlining his thoughts on the future vision of CNCF which I found delightful for everyone who doesn’t attend every CNCF TOC meeting:

It’s not a surprise that I concur with a lot of these thoughts. In the bootstrapping days of CNCF, we were laying the foundation of projects required to bootstrap the ecosystem around Kubernetes and cloud native. The next step was increasing the reach of Kubernetes outside of just orchestration and focusing on technology areas as storage and security. The future of CNCF is all about increasing the mean time to developer satisfaction by improving the state of developer tooling. We need to get to the same point that developers are with Linux with Kubernetes, while super important foundational technology, developers don’t have to know the intimate details of how these systems work and instead stand on the shoulders of them to build their applications.

Another additional thing I’d like to mention that Alexis didn’t bring up formally.  One of my goals in CNCF is to ensure we build a sustainable ecosystem of projects, members and end users. As our ecosystem matures and some of our projects proverbially cross the chasm (we use the graduate parlance in CNCF)…

How do we ensure each of these parties are receiving value from their participation in the foundation? It’s something I think about on a daily basis as more CNCF projects get embedded everywhere, graduate and cross the chasm.

Kubernetes maturing and container standardization unlocks innovation

At the conference, Google open sourced gVisor as another approach to container runtimes which in my biased opinion is made possible due to OCI standardization efforts to allow this type of innovation without fear of breaking compatibility. As part of gVisor, runsc(like runc in OCI) provides an isolation boundary between the application and the host kernel and they have a ton of information in their README about the tradeoffs versus other container runtimes out there:

Conclusion

There are a lot more things to mention (e.g., rise of enovy and it becoming embedded everywhere, cloud native programming languages, chaos engineering) but I have to now board a flight home and get some sleep. Personally, I’m nothing but humbled by the growth of the community and conference the last few years, it’s been an honor helping build it out since the beginning. If you have any suggestions on improving the event or our community in anyway, please reach out via Twitter or shoot me an email:

We do listen to feedback and as an example, in Austin, people complained that the videos were taking too long to post and we aimed to have a quicker turn around this time and followed through with that in Copenhagen:

Thank you again for attending and see you in Shanghai and Seattle!

CNCF Annual Report for 2017 and Kubernetes Graduation

We recently published the first annual report for the Cloud Native Computing Foundation (CNCF) which encompassed our community’s work in 2017:

The CNCF is technically a little over two years old and it was about time we start publishing annual reports based on our progress. This is a well treaded path by other open source foundations out there like the Eclipse Foundation and Mozilla so we thank them for inspiration to be more transparent.

Another thing that we launched this week was the Cloud Native Landscape (interactive edition) and more importantly, the Cloud Native Trailmap which guides you through the journey of becoming cloud native by adopting different projects in the foundation.

Finally, it was fantastic for Kubernetes to be the first project to graduate from the CNCF.  What does this exactly mean? This is very akin to graduation in other open source foundations such as the ASF. Graduation here is really about confidence in CNCF development processes and really a stamp from the CNCF Technical Oversight Committee (TOC) on what is a sustainable, production ready and mature open source project  you can bet your business on. As projects mature in the CNCF in terms of following solid open source governance processes and become widely adopted, expect to see more projects graduating in the future.

Cloud Native and Serverless Landscape

For the last year or so, the CNCF has been exploring the intersection of cloud native and serverless through the CNCF Serverless WG:

As the first artifacts of the working group, we are happy to announce a whitepaper and landscape to bring some clarity to this early and evolving technology space. The CNCF Serverless WG is also working on a draft specification for describing event data in a common way to ease event declaration and delivery, focused on the serverless space. The goal is to eventually present this project to the CNCF TOC to formalize it as an official CNCF project:

We’re still early days, but in my opinion, serverless is one application/programming built on cloud native technology. There are some open source efforts out there for serverless but they tend to be focused on specific projects (e.g., OpenFaaS, kubeless) versus collaboration across cloud providers and startups. The CNCF is looking to enable collaboration/projects in this space that adhere to our values. What are our values? See these from our charter:

  • Fast is better than slow. The foundation enables projects to progress at high velocity to support aggressive adoption by users.
  • Open. The foundation is open and accessible, and operates independently of specific partisan interests. The foundation accepts all contributors based on the merit of their contributions, and the foundation’s technology must be available to all according to open source values. The technical community and its decisions shall be transparent.
  • Fair. The foundation will avoid undue influence, bad behavior or “pay-to-play” decision-making.
  • Strong technical identity. The foundation will achieve and maintain a high degree of its own technical identify that is shared across the projects.
  • Clear boundaries. The foundation shall establish clear goals, and in some cases, what the non-goals of the foundation are to allow projects to effectively co-exist, and to help the ecosystem understand where to focus for new innovation.
  • Scalable. Ability to support all scales of deployment, from small developer centric environments to the scale of enterprises and service providers. This implies that in some deployments some optional components may not be deployed, but the overall design and architecture should still be applicable.
  • Platform agnostic. The specifications developed will not be platform specific such that they can be implemented on a variety of architectures and operating systems.

Anyways, if you’re interested in this space, I highly recommend you attend the CNCF Serverless WG meetings which are public and currently happen on a weekly basis.

KubeCon CloudNativeCon 2017 Takeaways + 2018 Predictions

It was a crazy 2017 for me with 300,000 miles of business travel, but it was all worth it to experience every major cloud provider adopt Kubernetes in some fashion and grow our community to 14 projects total! Also, it was amazing to help host 4000+ people in Austin for KubeCon/CloudNativeCon, where it actually snowed!

I’d like to share some personal take aways I had from the conference (of course with accompanying tweets) that will serve as predictions for 2018:

Exciting Times for Boring Container Infrastructure!

One of the themes from the conference was that the Kubernetes community was working hard to make infrastructure boring. In my humble opinion, Kubernetes becomes something like “POSIX of the cloud” or “Linux of the Cloud” where Kubernetes is solidifying kernel space but the excitement should be in user space.

The Open Container Initiative (OCI) community also held a meeting where it celebrated its v1.0 release to make containers a bit more boring and standardized.

In 2018, look for the boring infrastructure pattern to continue, the OCI community is planning to make distribution a bit more boring via a proposed distribution API specification. I also predict that some of the specialized/boutique cloud providers who haven’t offered Kubernetes integration will do so finally in 2018.

CNCF + KubeCon and CloudNativeCon: Home of Open Infrastructure

CNCF has a community of independently governed projects, as of today which there are 14 of covering all parts of cloud native. There’s Prometheus which integrates beautifully with Kubernetes but also brings modern monitoring practices to environments outside of cloud native land too! There’s Envoy which is a cloud native edge and proxy, that integrates with Kubernetes through projects like Contour or Istio, however, Envoy can be used in any environment where a reverse proxy is used. gRPC is a universal RPC framework that can help you build services that run on Kubernetes or any environment for that matter! There are many other CNCF projects that have use cases outside of just purely a cloud native environment and we will see more of that usage grow over time to help companies in transition to a cloud native world.

In 2018, look for CNCF conferences continue to grow, expand locations (hello China) and truly become the main event for open source infrastructure. In Austin it was incredible to have talks and people from the Ansible to Eclipse to JVM to Openstack to Zephyr communities (and more). I can’t think of any other event that brings together open source infrastructure across all layers of the cloud native landscape.

Moving up the Stack: 2018 is Year of Service Meshes

Service meshes are fairly a new concept (I highly recommend this blog post by Matt Klein if you’re new to the concept) and will become the middleware of the cloud native world. In CNCF, we currently host Envoy and linkerd which helped poineer this space. In 2018, I expect more service mesh related projects to be open sourced along with more participation from traditional networking vendors. We will also see some of the projects in this space to mature with real production usage.

Cloud Native AI + Machine Learning: Kubeflow

In 2018, ML focused workloads and projects will find ways to integrate with Kubernetes to help scale and encourage portability of infrastructure. Just take a look at the kubeflow project which aims to make ML with Kubernetes easy, portable and scalable. Note, this doesn’t mean that AI/ML folks will have to become Kubernetes experts, all this means is that Kubernetes will be powering more AI/ML workloads (and potentially even sharing their existing cloud native infrastructure). I expect more startups to form in this space (see RiseML as an example), look to see a “cloud native” AI movement that focuses on portability of workloads.

Developer Experience Focus and Cloud Native Tooling

One of my favorite keynotes from KubeCon was Brendan Burns speaking about metaparticle.io, a standard library for cloud native applications. I completely agree with his premise that we need to democratize distributed systems development. Not everyone developer needs to know about Kubernetes the same way not every developer needs to understand POSIX. In 2018, we are going to see an explosion of open source “cloud native languages” that will offer multiple approaches to democratizing distributed systems development.

Also in 2018, I expect us to see growth in cloud native development environments (IDEs) to provide better developer experience. As an example, for those that were wondering why there was an Eclipse Foundation booth at KubeCon, they were demoing a technology called Eclipse Che which is a cloud native IDE framework (your workspace is composed of docker/container images). Che is a framework that helps you build Cloud Native IDEs too, for example, OpenShift.io is OpenShift integrated with Che to provide you a fully blown online development experience.

Finally in 2018, I expect the developer experience of installing Kubernetes applications improved, including the underlying technology for doing so. For example, the Service Catalog work and websites like kubeapps.com showcase what is possible in making it easier for people to install Kubernetes app/integrations, we’ll see this grow significantly in 2018. Also I predict that the Helm community will grow faster than it has before.

Diversity and Inclusion

One of my favorite take aways from the conference was the focus on diversity and inclusion within our community:

https://twitter.com/CloudNativeFdn/status/938435795022745600

We (thank you amazing diversity committee) raised $250,000 and helped over 100 diversity scholarship recipients attend KubeCon/CloudNativeCon in Austin. In 2018, I predict and truly hope some other event will match or beat this.

Anyways, after a crazy 2017, I can’t wait to grow our communities in 2018.

 

 

Cloud Native Computing Foundation 2 Years Later

A little over two years ago after five years of service at Twitter, I took the opportunity to build an open source foundation from scratch using some of the computing techniques we experimented with at Twitter:

https://twitter.com/cra/status/937460286210048000

I was initially excited about the idea because of my experience with open source foundations in previous lives, from being involved with the Eclipse Foundation, Linux Foundation, Apache Foundation plus part of the early discussions around OpenStack governance formation. I viewed this as an opportunity to learn from the lessons of other foundations and do something new and modern in the GitHub era, along with of course making our own mistakes. You really don’t get many opportunities to start an open source foundation from scratch that will impact the whole industry.

Stepping back, the original idea behind the Cloud Native Computing Foundation (CNCF) was to promote a method of computing (we call it cloud native) pioneered by internet scale giants such as Google, Twitter, Facebook and so on and bring it to the rest of the industry. If you looked inside these companies, you can see they were running services at scale, packaged in containers, orchestrated by some central system.

The first mission was to provide a neutral home for every major cloud provider supporting Kubernetes natively, kubernetes is truly the lingua franca of the cloud.

We still have a long way to go within CNCF to truly making cloud native computing ubiquitous across the industry, but I’m excited to see so many companies and individuals come together under CNCF to make this happen, especially as we have our largest annual gathering this week, KubeCon/CloudNativeCon. Personally, I’m nothing but thrilled to what the future holds and truly lucky to be serving our community under the auspices of the foundation.

A special thank you to Craig McLuckie, Sarah Novotny, Todd Moore, Ken Owens, Peixin Hou, Doug Davis, Jeffrey Borek, Jonathan Donaldson, Carl Trieloff, Chris Wright and many other folks that were at that CNCF first board meeting two years ago bootstrapping the foundation.

Top 6 Public Cloud Providers in CNCF

Last week, I had the pleasure of welcoming Oracle into the Cloud Native Computing Foundation (CNCF). This now marks the top 6 leading public cloud providers in the world are now part of the CNCF:

This also marks for the first time in the history of our industry that these leading cloud providers are working together in the same open source focused foundation to move the state of the art infrastructure forward.

Also last week I had the opportunity to bring in two new high quality cloud native projects into CNCF. Envoy is a high-performance open source edge and service proxy that makes the network transparent to applications. Jaeger is an open source distributed tracing system inspired by Google Dapper paper and OpenZipkin community. It can be used for tracing microservice-based architectures. Uber began deploying Jaeger internally in 2015. It is now integrated into thousands of microservices and recording thousands of traces every second.

 

Anyways, this is one of the reasons I enjoy working in open source today, bringing together diverse (and even competing) companies to build a better world by collaborating in the open!

AWS Joining CNCF

It’s been a little over a year and a half since I started to help build the Cloud Native Computing Foundation (CNCF) from scratch. One of our original goals was to build a modern open source foundation focused on a new form of cloud computing called “cloud native” (essentially think of microservices that run in containers that are orchestrated) and to get all the major cloud providers at the table to adopt this form of computing.

Last week, we were happy to welcome AWS to CNCF as a member and that now brings us to having the top five cloud providers in the world at the table committing to adopting and promoting cloud native computing:

First off, it’s always great to see an original vision of when we started CNCF come into reality, you can read more from Adrian Cockcroft why they decided to join CNCF and support cloud native computing.

Second, I think it’s great to see a company like Amazon expanding its open source efforts as they where one of the last large companies without a formal open source program. They recently started an official open source program office @AWSOpen under the leadership of Adrian Cockroft and Zaheda Borat and it’s been great to have them participate in the TODO Group too!

Anyways, always great to see large and impactful companies increase their commitment to open source. Now it’s interesting to think what large companies out there don’t have an official open source program or strategy (I’ll leave this as an exercise to the reader).

Become a Founding Kubernetes Certified Service Provider

In early September, CNCF will be announcing the founding class of Kubernetes Certified Service Providers (KCSPs). If your company provides professional services to support Kubernetes deployments, please consider signing up to become part of the founding class.

The main benefits of becoming a KCSP are:

  • Placement in a new section at the top of https://kubernetes.io/partners/
  • Monthly meetings with cloud native project leaders, TOC members,
    and representatives from the CNCF Governing Board
  • Access to leads from end users looking for support

Requirements are:

  • Three or more engineers who pass the Certified Kubernetes Administrator (CKA) exam
  • Demonstrable activity in the Kubernetes community including active contribution
  • A business model to support enterprise end users, including putting engineers at a customer site

The CKA exam is about to enter early release beta testing prior to the public release in September. It is an online, proctored, performance-based test that requires solving multiple issues from a command line. It takes 3 to 4 hours to complete, and costs $300, though a discount is available for beta testers to $100.

If your company is interested in becoming a KCSP, please do the following 4 things:

  1. Ensure that your company is listed at https://kubernetes.io/partners/
    and if not (or if the listing should be updated), please do so via the link
    at the top of that page.
  2. Have 3 or more of your Kubernetes experts sign up for the beta test at:
    https://docs.google.com/forms/d/e/1FAIpQLSd9-6nL5L3SzWIddCSPoKeuX_Pdq_KHI8C4mQzcUryP-gu0dQ/viewform
    .Please have them use their company email so we can properly associate
    them. Within a week, we will send beta test dates, a discount coupon code, and instructions to register and schedule.
  3. Register your interest in becoming a KCSP at this form: https://docs.google.com/forms/d/e/1FAIpQLSfai-zlNuvP-q0fz3jw89v3v4m_wYaF7tOBmNY0WoKsZgeQUQ/viewform
  4. If you are not already on it, and want to track progress of the certification program over time, please subscribe to the Kubernetes Certification Working Group list: https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg.

Questions or issues? Please email cncf-kcsp-support at lists.cncf.io

Thanks!

Cloud Native Computing Foundation and Kubernetes

Over the past few months I’ve been helping form an infrastructure focused open source foundation (from scratch) and acting as its interim Executive Director. I’m thrilled to announce that the Cloud Native Computing Foundation (CNCF) has accepted its first project, Kubernetes:

There’s a ton of work to do still around developing and evolving development processes, but I’m happy to have our first project which will collaborate with us to establish and evolve these processes (along with the other projects that get accepted).

In the end, it’s really been an adventure in setting up this new open source foundation and I definitely need to write a blog post on some of the lessons learned so far about the experience. I’m really looking forward to see the CNCF become a cloud native commons home for many projects, move the cloud native computing paradigm forward and define what it means to be an open source foundation in the modern GitHub era.