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 Kubernetes for Humans Podcast. My name is Itiel Shwartz, and today we have a special guest. Joshua, can you please introduce yourself?
Joshua Burgin: Hey everyone, nice to meet you. My name is Joshua Burgin, and I’m almost 50 years old—I turn 50 in two weeks. When I was in elementary school, they had computers, which was unusual at the time, so I started programming when I was seven on a computer called the Commodore PET or the Commodore 64. I started with BASIC and used cassette tapes to store my programs. I then taught myself Pascal and C on the Apple IIe and later assembler in high school, as they didn’t offer these courses. I went into college, and although computer science seemed interesting, it was quite theoretical. It wasn’t obvious that it was a career path, so I majored in philosophy.
Itiel Shwartz: I studied computer science and psychology, and there was a time when I wanted to pursue a master’s in psychology instead of computer science. In Israel, a second degree in something like social psychology doesn’t pay well, and I also love computers.
Joshua Burgin: Me too. Right after college, I got a job at a small internet startup that sold books online—sounds like a crazy idea back in 1997. You probably haven’t heard of them; they were called Amazon. They were a small startup; they didn’t make it.
Itiel Shwartz: So that’s where you got your first professional software development job, and you were doing what we now call platform engineering?
Joshua Burgin: Exactly. I was on a team building tools for other people. We built a content management system from scratch, pipelines, sandboxes, QA environments, and front ends—everything.
Itiel Shwartz: How many people were at Amazon back then? Were they selling mainly books, or was it more?
Joshua Burgin: When I started, Amazon only sold books, and I was the 42nd employee. We all sat on one floor of a building in downtown Seattle, not even in a nice part. The website was live, but very primitive. About a year after I started, we expanded from books into music and video. There was no AWS, Amazon Go, or any of the other things you see today. I was there for about three years, which we joke is like dog years—one year at Amazon is like seven years. We built a lot of technology that is conceptually similar to today, with distributed computing and separation of concerns, but everything was super primitive, hand-coded in Perl and shell scripts. There wasn’t anything like Kubernetes or even an internal developer platform.
Itiel Shwartz: How did you end up at Amazon out of all companies, and why did you leave?
Joshua Burgin: I went to school on the East Coast of the United States, in Pennsylvania, and got a job in a neighboring state, New Jersey, at a traditional enterprise software company outside Princeton University. All the cool companies were on the West Coast, so I applied to a few. I got interviews at Apple and Amazon, which I found through a newspaper ad. A friend from the programming community suggested I look into Amazon because I had the skills they wanted—HTML, C, Unix, shell scripting, and Lisp. I didn’t know anyone there, and my parents thought it was a terrible idea, but I promised them if it went out of business, I’d just go work at Microsoft, which was the big tech company in Seattle at the time.
Itiel Shwartz: You were at Amazon for three years. What was it like?
Joshua Burgin: It was crazy. We worked six or seven days a week, 12 hours a day, for three years straight. There was no on-call rotation, so if you owned something, you were on call for it. We carried Motorola pagers, and there was always something going wrong. After three years of that, the company had grown from 40 to 10,000 people, and I thought it was time to take a break. I founded a startup, which was the wrong moment because the dot-com bust happened. We raised $1.2 million in a Series A, but that was the last round we ever raised. I bounced around different startups, all of which exploded in different spectacular ways, and I learned a lot about picking better co-founders, VCs, and markets. Eventually, I ended up at another startup, Zynga, which became pretty big.
Itiel Shwartz: Zynga is interesting because most gaming companies work as separate studios with a lot of autonomy. What was it like being a platform engineer at Zynga?
Joshua Burgin: That’s exactly right. Most gaming companies grow through acquisition, and they don’t use a common underlying technology. Zynga had a corporate value called “Be Your Own CEO,” so each studio had its own CTO. When I joined, the company grew from a couple of hundred people to about 3,500. As the head of the platform team, I had to convince all these studios to use our technology. We had to prove that it was more operationally excellent, more secure, and that it could help them develop faster. Over time, we built things like on-call rotations, post-mortems, scalability improvements, and more. We also created an integration team to help studios adopt our platform.
Itiel Shwartz: Could you force them to use your platform, or did you have to convince them one by one?
Joshua Burgin: It was a mix. We had meetings with the CEO, and it was a constant debate. We could convince one studio, and then others would follow, but new studios would pop up, and we’d have to go through it all over again. It was inefficient in some ways, and I see that now at VMware. At Amazon, there was more top-down mandate, but even there, you’d find pockets where people did things differently, sometimes for good reasons. For example, at Zynga, we built things for Facebook and web gaming, but when mobile gaming took off, we were behind because we didn’t have experience in that area. It took us a while to catch up. The lesson for platform teams is not to mandate your internal audience to use your stuff just because you say so—sometimes, third-party products or doing it yourself is better.
Itiel Shwartz: So after Zynga, you went back to Amazon, but it was a very different Amazon from the one you left, right?
Joshua Burgin: Yes, I left in 2000 and came back in 2014, which Amazon calls being a “boomerang.” At the time, I held the record for the longest gap between stints at Amazon, but others have since surpassed it. When I came back, AWS was only a couple of thousand people. It was doing well but wasn’t the $80 billion a year company it is now. The pitch I got was that I could have any job I wanted, but really, they meant I could interview for a few jobs. I ended up working on EC2 Spot, which was a business that had gone sideways. It was an interesting challenge to figure out what was wrong and fix it, and that became the springboard for my almost eight years at AWS.
Itiel Shwartz: You were at AWS for almost eight years. Why did you leave, and what are you doing now?
Joshua Burgin: I had done a lot at AWS, and the CEO of VMware called me. They wanted someone with cloud and SaaS experience, which I had from AWS. I had worked with VMware as a big partner for AWS, and they asked me to work on their new modern applications business, like Tanzu Kubernetes, which sounded super interesting to me. It was an opportunity to transform the way a company works and work with enterprises in a different context. However, about six months after I joined, Broadcom announced its intention to acquire VMware, which has changed my role somewhat. There’s more integration planning now, and a little less Kubernetes and modern applications.
Itiel Shwartz: What do you see as the biggest challenge in the Kubernetes space right now?
Joshua Burgin: The biggest challenge is helping companies modernize their applications and migrate to Kubernetes. VMware’s history is all about modernizing applications. They created desktop virtualization in 1999 and server-based virtualization in the early 2000s, which made it possible for data center and systems engineers to deliver a platform internally. Now, people want to use containers to carve up their data centers even further, and we have a platform called Tanzu to help with that. Tanzu is modular, offering smart defaults for those just getting started, but also allowing for customization. This appeals to big companies trying to figure out how to do this while maintaining control.
Itiel Shwartz: Do companies need to be incentivized to use these platforms, or is it more of a mandate?
Joshua Burgin: It’s a mix. In some cases, like with the federal government, it’s all sticks—this is the platform you’re going to use because it’s certified and meets compliance standards. But in most enterprises, it’s a mix of carrots and sticks. People have been burned by platform engineering efforts in the past, so they’re cautious. They want modularity and the ability to move pieces over time. Security and developer onboarding are big carrots. For example, onboarding a new developer quickly can save a lot of time and make the platform more attractive. Another carrot is preventing data breaches by scanning for things like keys checked into GitHub.
Itiel Shwartz: Where do you see the industry going in the future?
Joshua Burgin: I think Kubernetes will continue to be successful because it’s open. In three years, we might be surprised by how little penetration there actually is, despite the excitement around it. There will be a huge proliferation in tooling to make things simpler, like container security, networking, and databases. Startups will try to make Kubernetes disappear for the average user by encapsulating all this technology into a platform that doesn’t require you to hire experts in every field. That’s where I think we’re going.
Itiel Shwartz: That’s a super interesting and probably accurate prediction. Thank you very much for your time; it’s been a pleasure.
Joshua Burgin: Thanks for having me.
[Music]
Joshua Burgin is a seasoned product and technology executive with a track record of building profitable businesses and high-performance teams in both startups and established companies. He specializes in growing diverse, mission-driven organizations who ship technology products that delight customers & deliver business results.
Currently, as the VP of Product & Strategy (https://octo.vmware.com/author/jburgin/) for VMware’s multi-billion-dollar Product & Cloud Services business, he leads initiatives in customer experience, software engineering consistency, onboarding, lifecycle management, devops, and security. Joshua also collaborates with the CEO, COO, CTO, and the senior leadership team to address operational, strategic, and corporate integration challenges.
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!