Cloud native and why simplicity matters

Hello, and welcome to today's talk, Cloud Native and Why Simplicity Matters. I'm Catherine Paganini, head of marketing and community at Buoyant, the creator of Linkerd, and I'm also the co-chair of the business value subcommittee and tech contributor strategy.

Today, I want to talk about the importance of simplicity. For technology, simplicity is a theme you can take all the way from the underlying implementation details to the educational material surrounding it. Explaining complex concepts in simple terms is one of my passions and one of the reasons I initiated the CNCF glossary along with some other resources I would like to introduce today.

But first, let's see how we got here. You probably know this already, but let's look back for a minute. About 15 years ago, we started to see a move from hardware data centers to the cloud, and suddenly a whole new world of possibilities opened up.

And to take advantage of the elasticity and economy of scale of the cloud, forward-thinking companies started to create technologies that would allow us to easily scale apps up and down, adapting to demand. Docker kicked off the container revolution, the first container orchestrators started to appear, Kubernetes was introduced, and an entire ecosystem around it started to grow. Cloud native was born.

And once companies realized the true advantages of the cloud, there was no going back. The only questions that remained was how do I take full advantage of it, should I lift and shift my application or should I re-architect it for this new environment?

That's when we saw a push towards adopting cloud native technologies. A few years ago, only the most forward-thinking companies were adopting them. Today, most companies that are providing some type of service digitally have or are actively modernizing their applications. And that typically takes the form of adopting containers, Kubernetes, and building a next-generation cloud native platform.

And these platforms are modular. Kelsey Hightower once famously said that Kubernetes is a platform for building platforms. And the cloud native approach is the polar opposite from the previously all-in-one solution. To build a platform, you need to combine lots of different independent pieces. You need a container orchestrator, a service mesh, a continuous delivery tool, and so on. And that brings a new set of challenges.

And for once, the flexibility of this approach means it's very easy to end up with a complex solution, and the composability of this approach means it's very easy for complexity to escalate. Each piece in itself can be complex, and when you join them together, that complexity can just escalate. And today, the cloud native space is somewhat notorious for its complexity. Okay. So how do you overcome this? The answer is a focus and commitment to simplicity. But what does it mean? And is that even possible? After all, simplicity is not the first thing that comes to mind when you think about cloud native.

Simple does not mean easy. While easy means it requires little effort, simple means it does one thing well. You can understand it. It follows clear rules. It has a clear scope. Riding a bike is simple and easy. Participating in the Tour de France is simple but really hard. And just like racing, cloud native can be hard but simple. It may require time and effort to master, but it's clear and straightforward to execute as long as you've got the training and understand its rules. What we want to avoid is technology and content for that matter that is hard and complex. And that simplicity means that something is understandable, is really critical, and it's something I will be talking about a little bit more in a little bit.

Okay. I assume most are here to talk about technology. So let's start with that.

Simplicity in technology doesn't only make an engineer's life easier. It has real security implications. The more complex, the more likely human error will occur. Humans are the issue, not the technology. But the consequences are real. And while not always fully avoidable, it is important to go with simplicity whenever possible.

I worked for Buoyant, the creator of Linkerd. However, everything I say here applies to every other piece in your stack. For those who don't know it, Lingerie is a graduated service mesh. So what is a service mesh? A service mesh automatically adds a proxy most commonly as a sidecar next to every service adding security, observability, and reliability features at a platform level. And service meshes are known for their complexity. But the number one reason why people adopt Linkerd, at least that's what they tell us, is because they want something simple.

So how do we do that?

Service mesh is set at a very sensitive part of your stack, the data plane, which makes simplicity even more important. And instead of solving multiple problems, Linkerd focuses only on service mesh-related concerns. It's always tempting to build more and more features that do cool stuff. But the more you broaden out, the more configuration you'll need. And the more configuration you'll need, the more likely someone will make a mistake. And when it comes to your infrastructure, that is especially dangerous.

Simplicity means doing one thing and doing it well while minimizing configuration and fine tuning. And that focused approach is really important in a platform that is composed of numerous pieces of software. Remember, we are talking about modular platforms in which each piece has one specific task. If each piece adds a little bit of complexity, you will end up with a highly complex platform. The less configuration you need, the easier it will be to manage the platform overall. So select your modules wisely.

But how do you do that?

Before selecting any piece of software, ask yourself these three questions.

What problem are you trying to solve? If the tool can do much more than you need and will need, you will be introducing unnecessary complexity. Remember, additional features have an overhead cost. If you don't need it in your system, go with a simpler solution. If there is one, of course.

What is the operational cost of adopting this? How much human time will you end up babysitting it? Is it fragile? Is it resilient? Even open source can end up being very expensive.

And what is the conceptual surface area? How hard is it to understand whether it is behaving the way it should? Does it build on top of things that are already in your ecosystem? Or is it introducing its own new set of primitives? By the way, service meshes are notorious for this.

Now let's talk about education material and the importance of simplicity.

For something to be simple, it must be understandable. And before anyone can even start to adopt Cloud Native, they need to understand it. Not only technologists, but also the leadership team. Those who will ultimately approve an engineering project.

And why the latter is so critical became really clear this past holiday season when we witnessed the Southwest meltdown. Airlines used to be airlines. Today they need to be tech companies that happen to sell flights. And that's the case for most industries today. And that kind of failure, what we saw with Southwest, is what happens when the leadership team does not understand the technology their business is built on.

What does it mean for the C-suite?

Suddenly it is business critical for executives to understand technology, at least on a high level. But most executives have never really been exposed to it until today's digital transformation era. And now you have engineering suddenly asking for millions of dollars to migrate their system to Kubernetes. But nothing is broken. So why do we need to spend so much money again? Clearly a lot of catch up is needed before you can have a productive tech discussion with them. And today I'll share some resources that will hopefully help bridge that gap.

But first let's talk about how I got into this. When I started working at a Kubernetes company, I really struggled to find resources I could understand. Everything was written for a technical audience and assumed a lot of context I didn't have. Our engineering team wasn't able to help either. While incredibly patient and willing to take the time to explain it to me, they just didn't understand how much I didn't know.

And at some point I had enough. I read a book about computer science, an introduction to computer science and then one on distributed systems and everything started to make a lot more sense. I began building the context needed to understand cloud native. Without context to anchor all that new information, it's nearly impossible to understand what cloud native is about. And note, this may be the same thing that's happening when you're talking to your leadership team. If they don't remember what you told them last time, they may not have been able to retain that information. It may not be a lack of attention or interest. It may just be a lack of context. Anyways, a lot has happened since then and I even started writing intro articles for the NewsStack to help people like me make sense of cloud native. And that's when I realized that engineers, too, were craving easy and simple content.

Long story short, I got in touch with the CNCF because I thought they should own this type of content. Until then, the CNCF was only focusing on highly technical content, but a lot has changed since the CNCF foundation. In the early days, only the most technologically advanced companies and most highly skilled engineers were interested in the topic. But today, we're seeing broad adoption with lots of people who need to understand it. However, the available content does not reflect that need yet.

With that in mind, we built the business value subcommittee to create resources that help technical and non-technical people understand these concepts. All resources are GitHub based and anyone can contribute and submit changes. And all of these resources have one thing in common. We want to make the cloud native space as a whole, which is notorious for its complexity, simpler for people by making it easier to understand. And I welcome everyone today to join us if this sounds interesting.

Okay. And today, we'll discuss the cloud native glossary, the landscape guide, the project summary table, and the soon to come cloud native learning journey.

To understand any technical article, you first need to understand the concepts. Starting with the glossary was the first logical step. So how did we apply simplicity here?

First, we use simple language, free from buzzwords. Our goal is to provide a minimal viable definition. At least from a technical point of view. If a technical detail is not needed to understand the concept, we'll skip it. We really don't want to overcomplicate things. But we don't want to save on examples and context. Those things make understanding it easier after all. And then we include examples from daily life, like your Netflix account or Google apps. Things that anyone who uses technology can understand.

And then we break each definition to three sections to keep contributors but also ourselves on track. You'll see what it is, the problem it addresses and how it helps. We thought it was silly to keep the section headers and remove them. But we realized without them, it was hard to keep focus on each section. What it is started to blur into the problem it addresses and how it helps. And we lost the clear separation that was so helpful. For instance, the problem it addresses should focus on the problem, not the solution. Sounds obvious, right? But most people start talking about how the technology solves the issue instead of talking about the problem. We the maintainers fell into the same trap, too, by the way, especially early on. In short, we were losing our simplicity focus.

Okay. Now let's talk about the landscape guide. This piece has been public for a while. But the landscape is so full of information that very few people notice there is a little toggle here. So let's hope this talk helps address that a little bit. When you click on that, you will get to this guide. And as you probably all know, everyone complains about how complex and overwhelming the landscape is. And this guide breaks each section down and dives into each category explaining what it is using the same simplicity principles. Simple language, examples people can relate to, skipping unnecessary details.

I'm not going to go into details here, but please check it out.

The project summary table is our latest project, but still a work in progress. Also overwhelmed by the landscape, a service provider pointed out how challenging it is to identify which projects could be relevant to their clients. The landscape can be very confusing. Each project is listed in one category, but not all projects in that category are comparable. While they solve similar problems, they may differ significantly. And some projects don't really fit anywhere and are added to the next best category.

So for someone researching open source, you have the landscape, you have the individual websites, and then you have deep dives like workshops and webinars. There is no vendor neutral overview.

So how do you know which projects are relevant?

Understanding which projects are apples, what you need, and which ones are oranges, similar but not really what you're looking for, does take a lot of time. And the project summary table addresses that very issue. It allows users to compare all projects in one category side by side. You get the same information for each project, which makes the comparison a lot easier. Please keep in mind, we're still working progress. You see lots of white space here. A lot of projects have not submitted their information yet. But once it's populated, you will see a side by side comparison where you see description, maturity model, descriptive tags, and the tags are a great way to understand what a project is about, free from marketing speech, use cases and so on. And the goal is to provide end users with an easy and simple way to identify which projects they should evaluate.

Okay. It's great to have all these resources. But when you're new to Cloud Native, or if you want to educate a colleague or your leadership team, where do you start?

There's so much content out there. And the resources I presented today and lots of other resources are scattered all over the internet. People might find them by chance or not at all. That's why we decided to build a Cloud Native learning journey that outlines a recommended list of CNCF resources, starting with content that doesn't require any previous knowledge, a one on one section, and that gets increasingly more advanced.

What we want to provide is a clear learning path versus having people stumble around trying to find the right content for where they're at in their journey. That's not there yet, but it's coming soon, so look out for that.

Okay. Summing it up. Simplicity is hard and requires a lot of discipline. But it's incredibly powerful. Cloud Native is complex enough. You have all these different modules. You need to understand each piece of it. You need to make sure they all work together. You need to ensure that the leadership team understands why these expensive projects are so important. And because of this complexity, we really need to keep it as simple as possible.

In technology, it means project maintainers and software vendors must focus on the problem at hand and stay laser focused. Each piece in the stack has a very specific function. And in content, and I need to stick to that. And in content, it means staying focused on what the piece is trying to achieve and focus on simple language, provide examples the reader can relate to and leave unnecessary details out. These are two sides of the same coin.

And ultimately, the Cloud Native space can only be successful to the extent that we provide simplicity, not complexity, to its adopters. Okay. So that's it. If you're interested in service meshes, please don't miss tomorrow's session by my colleague Jason Morgan. He's a great speaker and it will be a lot of fun. And please join the business valley subcommittee if you would like to help build these resources. I'll be around the Buoyant stand or Linkerd if you want to chat about this. Thank you so much for your time, and I hope to see you in the hall.