Skip to content
The Kubernetes Developer Experience? episode artwork

Feb 27, 2022 27 min

The Kubernetes Developer Experience?

from The Enterprise AI Show Hosted by Cloudcast Media

Kubernetes won the container wars and continues to grow in use across many industries. But how did something that was about Cloud-native Applications gain traction without a developer experience? SHOW: 595 CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotw CHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS" SHOW SPONSORS: Teleport is the easiest, most secure way to access all your infrastructure Get started with Teleport CloudZero - Cloud Cost Intelligence for Engineering Teams Datadog Kubernetes Solution: Maximum Visibility into Container Environments Start monitoring the health and performance of your container environment with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt. SHOW NOTES: Kubernetes - The Documentary - Part 1 Kubernetes - The Documentary - Part 2 Software Defined Talk - Eps.344 - Kubernetes Documentary HOW DID KUBERNETES WIN WHEN IT STARTED FROM BEHIND? Listening to this week's SDT show, and remembering listening to SDT years ago, @cote comments about why Kubernetes "won" were always interesting. In essence it was late to market, was lacking in features vs. competitors (Mesos, Swarm, CF), and had a terrible user-experience...so how did it "win"? It all seems ass-backwards. HOW HAS KUBERNETES CONTINUED TO WIN, WITHOUT A DEVELOPER EXPERIENCE? Mesos, CF and Swarm were all single-vendor dominated projects, and many companies had concerns about another generation of vendor lock-in. This point is reasonably valid, but the companies that were using Mesos, CF and Swarm did all seem to love that technology. Mesos was primarily focused on big data workloads. For each new application-type, you needed to write (or use) another application-specific framework. So it was good at its niche, but couldn't easily be used for other types of apps. [Kubernetes eventually copied this model with CRDs]. Swarm was the easiest to use, but it wasn't very good technology and didn't scale. So it got pigeon-holed for smaller projects. CF focused on Java/SpringBoot, which is a big Enterprise opportunity. but CF was super complicated to set up. And CF never really embraced containers, so companies were weary of if they were missing this big trend (Docker). Kubernetes comes along and becomes the good-enough platform. It's not dominated by a single vendor. It natively supports Docker, it has some built-in usage patterns so it's easier than Mesos to add apps, it scales better than Swarm, and it can support Java/Spring or even legacy Java (lift-and-shift). And as Joe Beda says, you could use it natively or you could build some PaaS-y like features on top of it. FEEDBACK? Email: show at the cloudcast dot net Twitter: @thecloudcastnet FEEDBACK? Email: show @ the enterprise ai show dot com Bluesky: @TheEntAIShow.bsky.social Twitter/X: @TheEntAIShow Instagram: @TheEntAIShow

Episode details come from the podcast's RSS feed.

Embed this episode

Kubernetes won the container wars and continues to grow in use across many industries. But how did something that was about Cloud-native Applications gain traction without a developer experience? SHOW: 595 CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotw CHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS" SHOW SPONSORS: Teleport is the easiest, most secure way to access all your infrastructure Get started with Teleport CloudZero - Cloud Cost Intelligence for Engineering TeamsDatado...

Ready to play

The Kubernetes Developer Experience?

0:00 27:07

No transcript yet.

Requests help us decide what to transcribe next.

Frequently asked questions

How long is this episode of The Enterprise AI Show?

This episode is 27 minutes long.

When was this The Enterprise AI Show episode published?

This episode was published on February 27, 2022.

Can I download this The Enterprise AI Show episode?

Yes. Use the download control on the episode player to save the publisher-provided media file.