Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
Itiel Shwartz: Hello everyone, and welcome back to another episode of the Kubernetes for Humans podcast. I’m Itiel Shwartz, and today with me on the show is Adrian Cockcroft. Adrian, can you please introduce yourself?
Adrian Cockcroft: Hi there, I’m Adrian Cockcroft, and it’s great to be here. I’ve had a long career—too much to discuss in one go. I retired from AWS about a year and a half ago, so now I’m doing consulting and advisory work, and I’m semi-retired. That’s my current role.
Itiel Shwartz: Let’s dive into your background and how you got started. You’ve worked at Sun, eBay, Netflix, AWS, and you were a board member for the CNCF. It’s been quite an interesting career. How did it all start?
Adrian Cockcroft: Right at the beginning, my father was programming computers in the 1960s. He was a statistician working at a local university in the 70s, and my school had a link to that. So, when I was in high school in the 1970s, I started programming. I ended up doing a physics and electronics degree and built a little control system—a small robot—for my final project. I then joined a consulting company, building real-time engineering systems. We bought some Sun workstations, and I was administering them as well. I call that early DevOps—I was a sysadmin one day a week and a developer the other four days. In 1988, I joined Sun in the UK, spent six years in the field, and then moved to corporate in California, where I spent almost a decade in various parts of engineering and product marketing. I was on the performance team in particular and wrote a book on Solaris Performance Tuning, which a lot of people have read. That book led to me becoming a Distinguished Engineer at Sun.
Itiel Shwartz: Writing down what you know is a good career hack!
Adrian Cockcroft: Exactly. Then, in 2004, Sun was shrinking and laid off large divisions, including the one I was in. I went to eBay for a few years, helped them during their hyper-growth phase, and worked with eBay Research Labs on a few interesting things. After that, I went to Netflix for seven years, initially on personalization, and then worked on the cloud migration starting around 2010. Later, I joined Battery Ventures and visited Israel a few times to meet with the team there. In 2016, I joined AWS to help build an open-source community engagement team. One of the first things we did was write an internal document suggesting that AWS should join the CNCF and engage directly with Kubernetes rather than trying to figure out what to do about it. Arun Gupta and I wrote it, got it approved, and I became the original board member for AWS in the CNCF. After a while, I moved on to sustainability-related things, and eventually, I retired.
Itiel Shwartz: AWS wasn’t really known for being an open-source advocate, at least in the early days. Microsoft, for example, made a big transition from a closed-source approach to becoming a champion of open source. AWS, on the other hand, seemed more focused on how to utilize open source to make money. You mentioned that AWS joined the CNCF and started embracing Kubernetes. Why did that happen, and how did you convince the folks at AWS? Wasn’t open source not really part of AWS’s DNA?
Adrian Cockcroft: That was the position when I joined AWS. They had a team focused on using open source correctly and ensuring licensing was done right, but there was no budget for sponsoring anything. The team I put together had a budget to engage with communities, which paid for events like KubeCon and OSCON. We started consistently showing up at conferences with a proper engagement plan, created the AWS Open Twitter handle, the blog, and organized GitHub. This started in late 2016, and by 2017, we had hired a team and were engaging with people, convincing internal teams to open-source things properly. We also worked on smoothing relationships with open-source companies that were unhappy with AWS.
Itiel Shwartz: It’s interesting what you said about Elastic and AWS now being in a better place. There was that big license change by Elastic aimed at AWS, right?
Adrian Cockcroft: Yes, the business relationship is generally better now. Open-source companies hopefully have figured out how to leverage cloud providers to build their businesses rather than seeing them as direct competition. Initially, there was a good business in the data center, and cloud was small, so companies didn’t care about the cloud. But as the focus shifted to the cloud, open-source companies had to figure out how to run a service. Companies like MongoDB, with their Atlas service on AWS, have figured out how to leverage AWS as a marketing channel. There was definitely a transition period where there was a lot of tension, but we managed to smooth things over.
Itiel Shwartz: Inside AWS, why did the transition happen? Why did they change their perspective on open source?
Adrian Cockcroft: In 2016, there was a realization that something needed to be done. I had run the Netflix Open Source program, and although I didn’t join AWS specifically to run this, they asked if I could take it on. They funded the team and budgeted for conferences, and I hired about eight people. AWS is not one thing; every service team is its own little world, so it took time to get everyone on board. But overall, it worked out well.
Itiel Shwartz: What are your thoughts on platform engineering? Is it the new DevOps, or is everyone just jumping on the bandwagon?
Adrian Cockcroft: About a year ago, platform engineering became a buzzword. It’s an old concept; people have been building platforms for a long time. Two things brought it to prominence: Kubernetes is complicated, so you need a team to focus on it, and vendors started marketing platform engineering products. Also, the book Team Topologies gave a useful definition of platform teams. The first principle I set out is that it isn’t one platform—it’s layers of platforms. A large organization will have multiple platform teams, each specialized in different areas. Platforms evolve and typically move up the stack, gaining higher-level capabilities and losing lower-level ones to other platforms underneath them.
Itiel Shwartz: What do you mean by “moving up the stack”? What’s the ideal state for a platform team?
Adrian Cockcroft: If you’re using a platform, you always want it to do more. Anything you’re doing repeatedly on top of a platform will likely end up in the platform. The platform is an abstraction that makes whatever’s underneath easier to use. Over time, you find ways to push common tasks into the platform. For example, at Netflix, we built a platform over AWS, but as AWS added functionality, we moved some features down into AWS. So, platforms should be seen as something that evolves, not as a fixed entity.
Itiel Shwartz: What are platform teams doing wrong? Are there common mistakes?
Adrian Cockcroft: There’s a difference between an in-house platform and a commercial one. In-house platforms should be as simple and easy to maintain as possible. Commercial platforms, on the other hand, aim to capture as much value as possible, so they tend to get thicker and include more features. Commercial platforms also have to be very stable to keep customers, whereas internal platforms can be more nimble and don’t need to maintain the same level of backward compatibility.
Itiel Shwartz: Has Kubernetes changed anything around platform engineering?
Adrian Cockcroft: Kubernetes provides a venue where lots of different pieces of the platform can be integrated. It has a nice stability progression, where something can start as a basic feature, then move to incubation, and eventually become a core CNCF project. Open-source projects tend to reach a point where adoption becomes more important than new features. At that stage, they often move into a community like CNCF or Apache, where they can gain broader support and stick around longer.
Itiel Shwartz: Where is platform engineering going? What trends do you see in the industry?
Adrian Cockcroft: A lot of investment is going into AI and deep learning systems, which are big, expensive machines. Managing these systems efficiently is becoming more important, both for training and inference. This area is moving very fast, much faster than Kubernetes ever did. Sustainability is also a big focus. These systems are power-hungry, so optimizing their energy use is crucial. I’m involved in the Green Software Foundation, working on standardizing metrics for cloud providers to help optimize energy use. Projects like Kepler, which tracks the carbon footprint of Kubernetes workloads, are really interesting. It’s important to measure and optimize the sustainability of our computing resources.
Itiel Shwartz: What’s driving the focus on sustainability? Is it just about saving money, or is there more to it?
Adrian Cockcroft: It’s a combination of factors. People do care, especially those with young children who are concerned about the future. There are also regulatory requirements, particularly in the EU and parts of the US, where companies have to report their carbon footprint. From a business perspective, being able to market your products as green is important. The supply chain also plays a role; companies need to know the carbon footprint of their products and those they buy. The manufacturing of silicon, for example, has a significant carbon footprint, and decarbonizing the production process is a challenge that will take time.
Itiel Shwartz: That’s really interesting. Anything else you’d like to add before we wrap up?
Adrian Cockcroft: That’s about it. If anyone is interested in sustainability, the Green Software Foundation is quite active, and the work we’re doing on real-time cloud metrics is all publicly available on GitHub. I’ll be at the NVIDIA conference soon to learn more about AI and L
LMs. Other than that, I’m enjoying retirement and doing a bit of advisory work on the side.
Itiel Shwartz: Thanks so much, Adrian, for being a great guest on the show. If anyone is at the NVIDIA conference, look for Adrian. I’ll be at KubeCon in a week, but I guess you won’t be there?
Adrian Cockcroft: No, I won’t be there this time.
Itiel Shwartz: Thanks a lot, and goodbye, everyone.
[Music]
Adrian Cockcroft has played an instrumental role in shaping the modern cloud computing landscape, particularly through his contributions at Netflix and later at Amazon Web Services (AWS). With a background in computer science, Cockcroft’s career has spanned various roles, including developer, architect, and executive positions, where his insights into scalable, resilient systems design have had a profound impact.
At Netflix, Cockcroft was the Cloud Architect responsible for leading the company’s migration to a fully cloud-based architecture. This pioneering work not only helped Netflix scale its services to millions of users worldwide but also served as a case study for many other organizations transitioning to the cloud. His approach emphasized the importance of microservices architecture, continuous deployment, and automation to achieve reliability, scalability, and agility.
After Netflix, Cockcroft joined AWS as Vice President of Cloud Architecture Strategy. In this role, he has been instrumental in guiding AWS customers and the industry at large on best practices for cloud adoption and optimization. His expertise in cloud computing, DevOps practices, and microservices architecture has made him a highly respected figure in the tech community.
Cockcroft is also known for his contributions to open source and for being an advocate for the adoption of cloud-native technologies. He frequently shares his knowledge and insights through speaking engagements at technology conferences, blog posts, and social media, making complex concepts accessible to a broader audience.
Throughout his career, Cockcroft has been recognized as a forward-thinker and a key influencer in the cloud computing domain, helping shape the strategies of some of the most significant players in the tech industry. His work continues to inspire many in the field of software engineering, DevOps, and cloud architecture.
Itiel Shwartz is CTO and co-founder of Komodor, a company building the next-gen Kubernetes management platform for Engineers.
Worked at eBay, Forter, and Rookout as the first developer.
Backend & Infra developer turned ‘DevOps’, an avid public speaker who loves talking about infrastructure, Kubernetes, Python observability, and the evolution of R&D culture. He is also the host of the Kubernetes for Humans Podcast.
Please note: This transcript was generated using automatic transcription software. While we strive for accuracy, there may be slight discrepancies between the text and the audio. For the most precise understanding, we recommend listening to the podcast episode
Share:
Podcasts
and start using Komodor in seconds!