Matt Turner: I've been using Istio since the start, version 0.1

Less than one week until DevExperience, so it is time to meet another amazing speaker. Today we want you to meet Matt Turner, Software Engineer at Tetrate, who will have an awesome talk about The Life of a Packet Through Istio. Until the day of the conference, you can read this very nice interview with Matt Turner for our blog!

DevExperience: Let's explain a little what is it that you do exactly and how does a normal day looks like for you! What advice do you have for someone who wants to do what you do?

Matt Turner: I'm CTO at a Native Wave, a cloud-native consultancy in London. A normal day for me is very varied, which I love! Sometimes I'm working with our customers helping them get the most out of the whole cloud-native landscape, sometimes I'm back in the office diving deep into a certain technology to keep up with the constant changes in our industry.

DevExperience: What is a service mesh and why should we use one? What problem does it solve? And is it something related only to Kubernetes?

Matt Turner: A Service Mesh is a collection of proxies working together to help microservices communicate. You can think of it like a smarter network; it lets you transparently see, secure, and control the traffic between your services. It can increase resilience, encryption, etc. Services Meshes aren't just for Kubernetes either - although they're normally easiest to operate in a k8s cluster, they can be used between docker containers, VMs, or even bare metal machines.

DevExperience: How did you end up knowing so many things about Istio? And why do you think it is a better choice than other service meshes for Kubernetes?

Matt Turner: I've been using Istio since the start, version 0.1. Over all that time you pick lots of things up! I worked on Istio projects at JetStack, and I worked for a while with Tetrate, a service mesh startup. I think everyone should make their own choice of Service Mesh. Istio has many many features and can do advanced things, but each product has its advantages depending on your circumstances.

DevExperience: It seems that now Kubernetes is the default choice for container orchestration and a lot of companies are going to adopt it. But 4-5 years ago almost nobody knew about it. What happened it between?

Matt Turner: Yes that's really interesting. I remember the Linux vs BSD wars - there wasn't an obvious winner there for years, but Kubernetes has become dominant very fast. I think there's been a combination of factors - people want to move to the cloud, and run at higher scale than before. Kubernetes came along at the right time, is well-engineered and easy to use.

DevExperience: For a company moving now to Kubernetes, what do you think their first steps should be? What should they look after launching their first kubernetes cluster live?

Matt Turner: I would definitely recommend taking it one step at a time. You can start with a proof-of-concept on a managed Kubernetes cluster, to learn the technology. Then chose one product team that the platform team can work with very closely for an initial deployment - this provides invaluable feedback on the user experience of the system you're building. Then invite everyone else to the party!

DevExperience: Go also gained a lot of adoption in the past years and probably the most important projects of today are built with it (like docker, terraform, kubernetes). Why do you think it is so popular? And should we start learning it?

Matt Turner: I think Go is the same story as Docker and Kubernetes - it's easy to use, has good documentation, examples, and tools. It also has some features that make it nice for lower-level programming, but there's other really interesting systems languages out there too like Rust and Elixir.

DevExperience: If you were an architect for a new platform would you go for serverless or microservices on kubernetes or maybe a monolith?

Matt Turner: Maybe a combination of all three! There's definitely an argument to use each one where it's appropriate - maybe serverless for input and event handling, and some more traditional services doing the heavy lifting on the back end. True monoliths always end up slowing you down; when you have more than say 8 people trying to work on one codebase, or tens of thousands of lines of code in a project. I'd even recommend against prototyping using a monolith, because you never find the time to go back and do things right!

DevExperience: What are your expectations for DevExperience? And what should people expect from your talk during the conference?

Matt Turner: My expectations of DevExperience are very high ;) The line up of speakers looks amazing; I'm sure I'll learn a lot from attending them. My talk is pretty advanced, so people can expect a really deep dive into the internals of a Service Mesh on a Kubernetes cluster.