On everything but Kubernetes with Kelsey Hightower

In the tech world, Kelsey Hightower needs no introduction. Officially he is a Distinguished Engineer and Developer Advocate at Google Cloud and has been one of the key engineers behind the Kubernetes
project. Unofficially he has been an advocate of tech pragmatism, a role model, and the voice of reason in the industry for the past 20 years.

Regardless of his status in the industry, he has been an active supporter of developers worldwide, sharing his knowledge selflessly. He is the kind of person who would fly from the US to Europe to speak at the QED conference in Zadar, do a 3-hour-drive to answer questions at a meetup in another city, and then stay for more than an hour after to talk to people and answer their questions.

And, yes, agree to do an interview for ShiftMag before the meetup!

Right off the bat, I had to ask him to weigh in on the most recent micro-trend in the tech world – that of monoliths becoming cool again.

On monoliths vs. microservices and technology becoming like fashion

Kelsey: For me, it’s less about monolith vs. microservices. Words like monolith, cloud-native, or microservice become destinations from whatever we’re currently doing.

Some people were going on stages saying, “We’re doing microservices, that’s why we are good.” And other people would think – we could fix all problems at our company just by doing microservices.

It has become like fashion. Just like when you see nice clothes on the cover of the magazine, it looks beautiful, you want to look beautiful so you go and buy it. Technologies have become a fashion.

Kelsey Hightower

Regular people hear people from well known and innovative companies, look up to them, want to be like them, and want to try the same technologies those people are using. Nuance is lacking in these decisions and conversations on monoliths or microservices.

That’s how you end up with a company saying five years ago “microservices everything,” and today, they write a blog post saying that was too much and they had to walk some of that back because it was inefficient.

The reason it caused so much stir is because it’s Amazon. People tend to forget that Amazon is a big and diverse company. If you heard something from their serverless team, it doesn’t mean it’s the be-all and end-all, and all applications have to be serverless at some point. Now there is one group that says they’d tried serverless, and it wasn’t the most beneficial thing for what they were doing.

People were also confused because there was never a discussion on when serverless was not good. As a technologist, I try to be very balanced. Whenever I talk about something positive, I also talk about what it’s not suitable for.

The original problem was – you have this code base that has evolved over time. Maybe you were rushing, there are bugs, people come and go, and the code base you’re left with is fragile, and you want to get rid of it at some point. Just like when you have an old car that has to be repaired too often, you want to buy a new one. Many people just wanted to declare bankruptcy on their existing stack. And if someone called that existing stack a monolith, you wanted to go whatever the other side was, which was microservice. They thought that would fix all of their problems, so they will blindly go.

But people have been doing that for over a decade, and it’s not working! If you just do that, microservices will also suffer the same fate as the monolith.

People now feel relieved when they see their peers at Amazon admitting it’s not working. Wow, smart people are saying you don’t have to do it; they think maybe they were not crazy. It’s not just us, there are smart people out there that failed at adopting what everyone else is calling the best practice.

Kelsey Hightower

The industry needs that periodic reminder that microservices are not the best practice. It’s a trade-off, just like everything else. Some people are now relieved that microservices are not something they have to have on their roadmap, and they can stop chasing that fashion thing. And now they can back up their conversations with data – a team at Amazon failed at serverless, they walked it back, and they’ve saved 90%, and it got faster.

On companies “leaving the cloud”

Kelsey: We’re 100% at the same point when it comes to the cloud. Any technology, really.
People are often guilty of buying something they don’t use, and technology is no exception.

There is a premium on the cloud. If you don’t know how to turn it into your benefit, going to the cloud was probably the wrong decision in the first place. But again, it’s fashionable. There was lots of noise, and a lot of people just went with it without considering the complete picture.

Many people will go to the cloud and realize it was not a good decision and will reevaluate it. That should be a part of any engineering discussion if it hadn’t been a part of the discussion in the first place.

On Kubernetes

Kelsey: Kubernetes is one small tool in the big equation. People turn to Kubernetes with hope, thinking it will solve all of their infrastructure problems. And yes, for some people, adopting Kubernetes moves them ten years to the future of managing applications.

I don’t think about Kubernetes as the end-all-be-all for all of your needs. I like to say Kubernetes is the SDK for the cloud.

Kelsey Hightower

And you probably have other things to solve at your company than just the cloud. You have a website, mobile app, martech, data analysis, machine learning… so even if you did Kubernetes perfectly, it’s probably just 1% of your company’s needs. People get very excited about Kubernetes, but it’s just a small piece of the puzzle in the grand scheme of things.

On FOMO when it comes to tech

Kelsey: There has not been enough balance in the discussion. Today you hear microservice, microservice, DevOps, microservice, Kubernetes, buy this product to help you with your microservice. The discourse has never been – there are microservices, but you might not need them. People feel like they’re missing out if they’re not doing what everyone is talking about, no matter if that would be the right solution for their problem in the first place.

It’s like you having a cold and buying a simple cold medicine at the pharmacy and feeling you’re missing out because you didn’t get a heart or diabetes medicine like the person before you! You don’t need that solution if you don’t have that problem.

Many open-source products and technologies now have conferences, meetups, and books dedicated to them. People tend to attach their identity to a specific tool or technology and become too attached to it as the only right solution to all problems. I’ve met someone who had the Kubernetes logo tattooed!

I keep reminding engineers to think about fundamentals. Not whether they know how this or that new tool works, but what it actually does, to try and understand the problem that tool solves. When you get to fundamentals, you realize a lot of new tools and technologies fundamentally do the same thing, they’re maybe 10 % different than the other tools; we just call them by different names.

If you know the fundamentals, you will know how to work with any tool.

Kelsey Hightower

Just like the news or fashion, technology has become hype-driven. I choose to ignore a lot of things. I don’t want to get distracted. Don’t feel the FOMO. New stuff comes out every day; I take a look and, more often not, say it’s not for me. I focus and go deep.

On proliferation of dev tools

Kelsey: When you go to the hardware store, there are hundreds of tools, and it’s easy to get lost if you don’t know what you’re looking for. Luckily, I only go to the hardware store when I know exactly what kind of tool I need and what I want to do with it.

There are millions of people building software. All of them won’t be served by one thing. The same when you go to the grocery store, and there are 30 or more types of bread.

There are a lot of tools, but most of them focus on specific situations and use cases. Most of the tools first mature inside of a company or a team that has a problem, learns how to solve it, and then shares it as open source or go an make a company from it. Of course, people and companies that have similar problems will say, “This is amazing!”

If we consider all the permutations of all the software stacks, we end up with hundreds of thousands of attempts to build tools to solve those problems. Of course, venture capital is betting more on it because there is a market, and it’s valuable. The platforms have changed, the issues have changed, and there is an opportunity for new tools to show up to address those problems.

On learning fundamentals vs. tools

Kelsey: I started my career in Linux some 20 years ago, but Linux now looks roughly the same. The fundamentals are the same.

There is a lot of fear about the ever-increasing speed of innovation, cycles becoming shorter and shorter, technology becoming hype-driven, and engineers becoming lost and confused about what to learn and what tools and technologies to focus on. My advice is – to focus on the fundamentals. Specific technology or a particular tool is just a means to an end. Thinking about fundamentals means thinking about what that end is.

The number one fundamental every software engineer should possess is curiosity.

The secret of a successful career in tech is not about learning a specific tool. It’s about the willingness to learn a different tool when the time comes.

Kelsey Hightower

My first interview at Google was for the position of Linux system engineer, and I knew nothing about Linux! When they asked me about Linux, I said I knew nothing about Linux, but I knew about FreeBSD. Luckily, my interviewer actually had a FreeBSD tattoo and started asking questions about FreeBSD. But I knew fundamentals and was lucky that person took the time to get to know who I was as a person and if I knew fundamentals and not if I knew specific Linux commands.

When interviewing people, I didn’t care if they copied/pasted code from StackOverflow. Guess what the team does? I only cared if they would understand the code they’ve copy-pasted.

On open source and innovation

Kelsey: If we had let enterprise tech lead innovation, today we’d have a better mainframe!

Open source has to be the source of innovation because the industry needs innovation independent of enterprise needs. There has to be a no-limitation approach – I can use tools other companies have developed and even develop something on top of them. As open-source tools become widely adopted, they become industry standards and, in the end, adopted by enterprises as such.

We still haven’t fully figured out how to make open-source sustainable in the long run, but a lot of open-source is paid. Google has at least 1000 people working on open source, and a lot of big companies sponsor open source projects, but admittedly there are still people who maintain libraries used by thousands of companies and get nothing from it.
But open source is here to stay, and it has 30 years of proven track record of being the right model for innovation.

On ChatGPT leading to better code reviews

Kelsey: If you’re a software engineer and the point of your work is to write certain pieces of the same code each day or deploy specific code each day, ChatGPT will take your job.

Junior developers will use ChatGPT to do their jobs, and I don’t blame them – even senior developer copy/paste code from StackOverflow!

What’s the difference between people blindly importing libraries from StackOverflow and those using ChatGPT to write their code? There is no difference.

Kelsey Hightower

You have to ask yourself what kind of engineer you want to be or what kind of engineers you want to hire or work with, in the case of juniors. What’s the goal of their role? If the goal is to write the code and do it fast, then ChatGPT can do that easily. If the goal is to know what that code does and understand the fundamentals, then you must invest time to teach them.

ChatGPT makes code reviews even more important. That’s your chance to teach juniors fundamentals. And with ChatGPT taking the tedious and robotic parts of your job, you will have more time for code reviews!