Building APIs to Interact with Data in a Cloud-Native Ecosystem
How do we create free and open data sets that are trustworthy? Open source cloud services and Kubernetes can help. We talked to Microsoft Azure’s Principal Program Manager, Lachlan Evenson, on standards for accessing data in cloud-native environments and best practices for using Kubernetes on the cloud.
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.
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 has 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.
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 when 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.
