How Service Meshes Found a Former Space Dust Researcher
KubeCon + CloudNativeCon and InfluxData sponsored this podcast.
How Service Meshes Found a Former Space Dust Researcher
Very early in his career as a student, Andrew Jenkins was studying space dust and other payloads for the U.S. Laboratory for Atmospheric and Space Physics as part of a NASA contract. It was there while working on communication protocols “almost from the physical layer” that he began to shift his attention to the software side.
Monitoring, observability, logging and other capabilities that are increasingly essential for software production pipelines today could have already been put to use over 15 years ago when Jenkins was working for NASA. However, at that time, service meshes had yet to be developed — while Kubernetes, microservices and even DevOps were yet to come as well.
After working as a graduate research assistant developing software for the International Space Station at the University of Colorado Boulder, Jenkins continued to shift “further and further up into the software side of things.” He began to see, after joining F5 Networks in 2013, how platforms could be used for application deliveries of load balancing, security and other tasks for cloud applications. By the time Aspen Mesh was formed in 2017 as a spinoff from F5, Jenkins had begun to develop true service mesh platforms to manage data traffic as part of a shift to Kubernetes clusters and the service-to-service communications in microservices. In other words, it is possible to say service meshes found Jenkins.
“And so this really sort of elevated the importance of communication because what used to maybe just be one function call inside of your application, was now through network traffic,” Jenkins said.
The necessity and further evolution of cloud meshes for Kubernetes deployment was central to Jenkins discussion during this episode of The New Stack Makers podcast.
Service meshes and their deployments, of course, are new and their capabilities continue to evolve. Much of the ongoing development work for service mesh platforms is in response to customer demands. As an example of a sought-out capability, observability has emerged as key service mesh requirement and it remains in active development as mesh providers continue to add improvements. “The most important part is to get that kind of observability resiliency into the service mesh. “The first little thing is the application developers get to apply on these layers somewhere beneath them to take care of that security, observability and resiliency sort of thing,” Jenkins said. “And so then the way that that works becomes kind of like an aspect of your platform and that may change. It may even be owned by a different team.”
Jenkins used TCP stack layer development as an analogy. “It’s almost like the TCP stack in your operating system where you don’t really think about the TCP stack when you’re writing code. There are a lot of really smart software I’m sure, if you think really hard out of a TCP stack, to go faster, be better, be more secure and all that sort of stuff, but when you’re in the application space, you sort of just consume that as a layer beneath,” Jenkins said. “And that’s where, I think, service mesh is headed: it’s first getting that concept that, ‘hey, it’s just this thing underneath that provides this functionality and like, just rely on it.’ And then over time, the implementation details can sort of evolve and change without disrupting the applications.”
Jenkins likened the adoption of service meshes to that of TCP, which removed the need for “developers never spend time working on reassembling packets.”
“I hope service meshes become the [default] way to deal with distributed tracing or certificate rotation. So, if you have an application, and you want it to be secure, you have to deal with all these certs, keys, etc.,” Jenkins said. “It’s not impossible, but when you have microservices, you do not have to do it a whole lot more times. And so that’s why you get this better bang for the buck by pushing that down into that service mesh layer where it’s, even though it’s not impossible, it’s just one more thing, you don’t have to repeat it all the time.”
Also, service meshes should also become more widely popular for canary testing of microservices deployments. “Maybe you want to add in distributed tracing but you don’t have to go all at once,” Jenkins said. “And the evolution path is important because most users are going to be sort of incrementally getting towards using a service mesh.”
In this Edition:
1:32: Services meshes.
10:55: The overall evolution and path to service mesh.
15:17: Tracing and logging.
17:28: Canaries.
22:20: ‘Going to Kubernetes requires a service mesh.’
30:29: YAML files.
AspenMesh and CloudBees, which manages Jenkins, are sponsors of The New Stack.
Feature image from Pixabay.
