Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Keynote: Keep It Simple - A Human Approach to Coping with Complexity - Hannah Foxwell

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Sponsored Keynote: Keep It Simple - A Human Approach to Coping with Complexity - Hannah Foxwell, Director – Platform Services, VMware Pivotal Labs

We humans are simple creatures. Our focus is finite. Wrestling with complexity can overwhelm and demotivate even the smartest engineers, but there are ways we can make life a little easier. In this talk Hannah will propose a human approach to coping with complexity—something we all need to consider when building successful engineering teams—and will share how to begin applying user-centric design to reduce the cognitive load on developers.

https://sched.co/Zh39

A

Hi everyone I'm hannah, and today I'm going to talk about building successful platform teams, but first, let's reflect on why we need a platform delivering software is hard. A successful platform makes it easier for development teams to deliver apps to production and an unsuccessful platform can make it really difficult.

A

Today, I'm going to tell you a story of two very different platforms: meet clara clara is a solo platform engineer embedded in a newly formed application team at really big co. Clara loves a challenge and experimenting with new technologies. She has a simple kubernetes platform stood up in no time she integrates some monitoring tools, hooks up their deployment, pipelines and hacks together. A couple of integrations, the dev team are delighted.

A

Platform is a success, and people have noticed. Other teams want some of this container goodness, but this platform doesn't work for them. They have some strict security controls and they need higher availability.

A

Really bigco needs a really big platform. A new team is formed and they set about designing the one true platform. They thought it would be easy, but building a platform for everyone is more complex than they expected.

A

They're under pressure there's a really big investment and, of course, a really big deadline, they're behind schedule and suffering from analysis paralysis. They need to speed up, but adding more people to the team only seems to slow things down.

A

Adding people to a team feels like an obvious way to add capacity, but, as we add more people, we exponentially increase the communication overhead for the group and everyone is less productive.

A

The really big platform project has a really big team: they've missed their really big deadline and used their really big budget. This is now a really big problem.

A

I wonder if this sounds familiar to any of you. The platform I spoke about first had some early success, but it's been difficult replicating that success at a larger scale, and it doesn't feel right for every application team to build their own custom platform.

A

So how can we structure our teams in a way that scales creating a central platform team? Can work really? Well if you approach it in the right way. The platform team here are providing a service to their users. The application teams, the application team, have a clear mission. They want to build an amazing product and a valuable service for their users, and the platform team's mission is exactly the same.

A

It's just that users who are different their users are the application developers and, of course, they can themselves are consuming a platform to build their platform, there's an infrastructure platform being provided by either an internal team or a cloud provider, and guess what their mission is exactly the same too.

A

So let me tell you another story about how to scale a platform by keeping things simple. Ethan is a product manager of a small team with big ambitions.

A

He knows that to build a valuable product, you need to get to know your users, so he starts by identifying some early adopters partnering, with his early adopters. Ethan is able to reduce the scope of his mvp, his minimum viable platform with a clear, short-term goal. The platform engineers can focus on building and it's amazing how quickly they make progress.

A

So what happens next well ethan continues to build out a feature roadmap for the platform and identifies new cohorts of apps that can come on board. It doesn't meet everyone's needs yet, but momentum is growing with more users. They can't collaborate with everyone in the same way they did with the early adopters. The communication overhead is becoming a problem and the platform team are worried about becoming a bottleneck.

A

They need to think about becoming more like platform as a service and less like platform as a silo.

A

They still provide a valuable service, but they do this by providing documentation, templates, defaults and tools, so their users can solve their own problems.

A

They use automation to stay on top of their manual work as the platform grows and scales. They make sure they always have time for feature delivery by measuring and capping their toil at 50 percent.

A

By adopting these practices and by putting people at the heart of their process, they've been able to scale their success, it's easy for us as technologists to spend most of our time thinking about how we scale our systems and architecture and not enough time. Thinking about how we scale our teams, our ability to scale. Our teams is constrained by our human capacity for cognitive work, communication and relationships as humans. There's very real limitations on how we optimize our clusters.

A

I want you to have big ambitions for your platform, but I recommend taking small steps to get there by partnering, with early adopters, managing your platform as a product and building towards platform as a service, not platform as a silo.

A

Remember folks, you're human, not superhuman, so keep it simple. Thank you check out tanzu.vmware.com to learn more about modern app development and delivery. Thanks.