The entire Weaveworks team is super excited to announce that Cornelia Davis is joining us as CTO. Read on to learn more about Cornelia’s motivations, her history in cloud computing and where she sees Weaveworks and the rest of the industry going. Hint: there may be GitOps involved.
It is with great delight that today I announce I have joined Weaveworks as Chief Technology Officer. I want to share with you what drew me here, and what I see as the opportunity for Weaveworks and you, our users. For those of you who do not know me, I’d also like to introduce myself..
I’ve been involved with modern application platforms for more than 7 years, starting while I was a technologist looking at emerging technology at the EMC Corporation in the CTO’s office. Cloud Foundry (CF) was just being incubated at VMware (with involvement from our founder and CEO, Alexis Richardson). By the time Pivotal was spun out of EMC and VMware in April 2013, I was totally hooked. What was I hooked on? The opportunity that a fundamentally different type of platform represented.
Bringing Pivotal PaaS to Market
What if you could deliver capabilities that allowed application teams who are increasingly responsible for both development and operations to be self-sufficient, while keeping the enterprise protected in terms of compliance, security, cost control and more? Those capabilities could not only radically transform businesses, but could also change people’s lives in a material way. I was part of the team that brought the Pivotal PaaS to market. The best part of that was the opportunity to work with large enterprises who were able to achieve the very radical changes we were aiming for. It has truly been an honor.
And then came Kubernetes
Cloud Foundry, which the Pivotal PaaS is based on, is a platform that leverages two things that are also central to Kubernetes: containers and reconciliation loops. But there is one very important difference between these two things. In CF the use of containers and reconciliation loops are implementation details that are largely hidden from the end user. By contrast, Kubernetes exposes these as primitives - first class entities - that the users have direct access to. And so, when you configure a Kubernetes deployment you specify the container image that you want to run. You also have the ability to configure certain elements of the reconciliation loop that will care for instances of that container image.
With more than three decades as a computer scientist, I am well aware that one of the biggest and most important parts of what we do is to produce meaningful abstractions. You might argue that the abstractions that hide away the container and operational semantics are good. And you’d be right, as seen by the success of Cloud Foundry’s many enterprise customers from The Home Depot to JPMorgan Chase. But, and there’s often a “but”, the abstractions CF projected, and most importantly, the logic built into that platform was designed for a specific type of use case -- namely applications that generally followed cloud native patterns. I went so deep into these uses cases that I wrote a book on it: Cloud Native Patterns.
Addressing a wide array of use cases
There is no question that containers and reconciliation loops are extraordinarily useful primitives that can be used to address a much broader set of use cases.With Kubernetes exposing these primitives as first class entities, we now have the building blocks to construct the needed solutions. But how exactly do we do that construction? And what are we even constructing?
While working on Pivotal’s Kubernetes distribution for the last several years, I’ve formed some opinions:
- First, once you’ve deployed your Kubernetes cluster (using upstream Kubernetes - no forks!!!), you still need a lot more to make it useful. You need additional security policies applied, you need to add observability components, CICD pipelines and more.
- Next, you might need different types of Kubernetes cluster configurations for different use cases. For example, a cluster that is optimized to run cloud-native, web-services will not serve machine learning use cases very well.
- This leads us to the fact that inevitably we will need to run and maintain many clusters and manage many teams.
- And then there are additional capabilities needed by the application teams who are leveraging the Kubernetes cluster to deliver applications to consumers.
Reflecting on these items, a possible answer to the latter of the two questions from above is: what we’re constructing are Kubernetes-based platforms. You have likely heard Kelsey Hightower and many others say that Kubernetes is a platform for building platforms. In order for organizations to get the leverage they need from Kubernetes, they need to have for-purpose instances of platforms.
So then back to the first question: How do we do the construction?
That is why I’ve joined Weaveworks! In an enterprise setting, I believe that we best serve developers (or better put, application DevOps teams, but I’ll table that conversation for a future blog post) by providing them with for-purpose, Kubernetes-based platforms that are resilient, secure and that include the capabilities to serve their DevOps workflows. And we also need to provide platform teams with the tools to construct, operate and maintain fleets of these Kubernetes-based platforms. Doing all of this at scale requires a disciplined operational model like GitOps of which Weaveworks is the unquestionable leader. Simply put, at Weaveworks, I am going to have the chance to help engineer the platform builder I’ve been dreaming about for the last couple of years. And to top it all off, I get to build it with some of the most talented and dedicated individuals in the industry.
And that talent also includes you! One of the lessons I’ve learned from open source is that a diversity of viewpoints is a catalyst for innovation. I look forward to engaging with other vendors in the space. I especially look forward to hearing the challenges that folks in large enterprises are facing today and in identifying ways that our teams can work together. You can reach me on Twitter at @cdavisafc, in the slack channels: Weave Community , and Kubernetes and at firstname.lastname@example.org. I look forward to chatting with you soon.
“It was clear that Cornelia will bring the energy, and expertise needed to lead us into the next phase of the company. She understands the needs of our customers and with her deep understanding of the cloud can effectively help enterprises through the transition.” --Matthias Radestock, Weaveworks, Founder