Accessing the data you need can be overwhelming. Microsoft Azure VP Lachlan Evenson believes cloud services and Kubernetes can alleviate the complications in collecting, storing, and tracking data.
On the Open Source Data podcast, he said open source projects could be a big part of the solution to issues with data but that we need standards across all open source platforms to interact successfully.
I think, when we talk about open datasets, people want to have access and assurance who the data is from and that it hasn’t been interfered with or messed with. – Lachlan Evenson
Many of my guests on the podcast have talked about the importance of the open source data community and platforms like MySQL, MariaDB or Apache Cassandra®. But in my conversation with Evenson, he went deeper – or rather in between – to talk about how we access the data on these platforms.
He’s worked a lot on the challenges of managing microservices and the dependencies between them in order to prevent them from compromising data. Service meshes have been a key part of the solution.
“Service meshes are not only about access control and controlling where your traffic is routing across broad myriads of microservices. I think the most understated aspect is really having tools and a platform that you can query and introspect,” Evenson said.
His work in the service mesh ecosystem has focused on making it clear what will happen if you push one API or call another without knowing it’s been degraded. This involved collaborating with a wide range of providers in the field.
Joining Kubernetes and Cloud Foundry
When I was running the Cloud Foundry Foundation, much of my own work was focused on securing more transparency and reliable standards. We transferred the native service broker into an open IP project and then looked at containerization standards like Open Container Initiative (OCI), Container Network Interface (CNI) and Container Storage Interface (CSI) in order to create maximum flexibility. Like me, Evenson found that you don’t need a service mesh unless your system becomes more complex, say, with 50 or more services.
At Azure, Evenson found that customers needed a service mesh, they had a really hard time figuring out which service mesh to choose. They were challenged by the complex interfaces for various service meshes in particular, so he standardized common customer cases that worked across the service mesh ecosystem. This was the driver for the creation of SMI: the Service Mesh Interface.
Instead of creating new APIs or service meshes for each platform, SMI takes a unifying approach. Access policy, telemetry, error rates, traffic splitting and use cases like canary deployments were the most important areas in common use.
Evenson learned that a lot of people in the industry were not looking to create bespoke APIs in Kubernetes or their service mesh products. This made them rally around SMI.
“This lets them focus on the functionality and not the API design. It’s been incredibly rewarding to work with the community and have other tools and platforms integrate with SMI without us even knowing it,” Evenson said.
The best practice using Kubernetes in the cloud
Evenson has seen many ways of working with Kubernetes in the cloud and even co-wrote the book on Kubernetes Best Practices. So I had to ask him to share with us some of those best practices. He likes to focus on a single one – Focus on a single API customized to your needs. He said he hears a lot of talk about Kubernetes moving too fast. But as he sees it, it doesn’t really matter what Kubernetes version you’re using. If you just focus on the API you’re committed to, you know what you can get out of Kubernetes.
He thinks a lot of providers make it easy to get a Kubernetes cluster that hooks you into the benefits of different cloud providers and platforms. Sooner or later, with so many different platforms and updates, maintaining stability without data loss or platform degradation begins to beg the question of how many releases are feasible. But, with stable, custom-built APIs, programmers don’t have to worry about Kubernetes updates because they don’t need them.
So one of the great benefits of having custom resources and Kubernetes is you can model things and see the benefit immediately and meet that need. But I think that gives you an API where you can have a discussion within the community and get broad consensus about acceptance of this API. –Lachlan Evenson
Kubernetes coming of age
As Kubernetes is beginning to grow up, the Kubernetes community has been discussing the cadence of upgrades. Some think it should be slower, but Evenson believes that would just mean more new features in each upgrade which, in turn, would result in even more confusion.
This discussion is interesting because it is happening at the crossroads between cloud native, open source, and enterprise use. Of course, as long as you’re committed to using the same API with Kubernetes, you don’t need to take part in that discussion. But it’s an important one because bringing standards to the cloud means tackling many different problems, whether it be update frequency, service meshes, or how we model APIs.
Listen to the whole conversation between Lachlan Evenson and Sam Ramji and make sure to subscribe to the Open||Source||Data podcast so you never miss another episode.
About Lachlan Evenson
Lachlan Evenson has been a Principal Program Manager at Microsoft since 2017. He’s passionate about open source projects and communities. He has presented at OpenStack Summit in Tokyo and Vancouver, at KubeCon, Kubernetes v1 Launch, and at numerous open source community events. Evenson has also co-organized more than 900 meetup groups in the San Francisco Bay Area. Currently, he serves as a member of the OpenContrail Advisory Board and a governing member of the Cloud Native Computing Foundation.
Resources:
