When people think of Cisco, they may not think of cloud native and open source software (OSS), and that’s completely understandable. Cisco is a large company with many different projects and initiatives — historically in the networking space. Some of those Cisco projects and initiatives that don’t get nearly enough credit are cloud native open source projects. With over 200 OSS projects to its credit, Cisco has long been a prominent and significant sponsor and contributor to open source. In this series, we aim to shed some light on what Cisco is doing in the cloud native and open sources spaces, starting with one very cool project: Nasp.
As environments grow more and more complex, the challenge to manage the communications between the applications and services in those environments grows larger, too. These days it’s not uncommon to have multiple services written in different languages, where a team might spend more time localizing a problem rather than fixing it altogether. If that sounds like you, a service mesh might be what you’re looking for. At its most basic level, a service mesh is a mechanism for managing the communications between applications and services. It does this by creating a dedicated infrastructure layer to abstract away some of the complexities of managing inter-service connectivity. There are many different versions of service mesh, but most of them require sidecar proxies in order to extend their capabilities to, most often, cloud-based environments. Sidecar proxies are separate helper applications that run beside an application in order to house communication functionality (think of sidecars like a sidecar on a motorcycle).
Service mesh is gaining more and more adoption in the cloud native space, but many real-world environments require more than simply connecting cloud native applications to each other. In fact, if you’re reading this, it’s likely that you have some “traditional” monolithic applications somewhere in your environments. That’s not a bad thing. In the Cloud Unfiltered podcast, Kelsey Hightower discussed his view on the 'microservices versus monolith' issue. He noted it's important to use the right architecture for the right use case. Microservices may be trendy right now, but that doesn't mean that they suit every application or use case; the use case should dictate the architecture, not trends. With that in mind, the technological gap in linking traditional applications with cloud-based microservice environments is substantially large.
An alternative is Nasp, a lightweight library that expands service mesh capabilities, specifically to non-cloud environments, such as mobile devices, IoT and Edge Devices, and VMs, without the added complexity of sidecar proxies. Nasp isn’t designed to be a complete service mesh replacement. It can be powerful tool to extend a service mesh’s existing capabilities to primarily (although, not limited to — and we’ll get to that in a second) non-cloud environments. In this blog, I’ll walk through the reason for the creation of Nasp, along with some key use cases that we see for the project.
Feedback from Calisti customers showed a need to connect non-cloud environments to cloud-based service mesh without the added burden of a sidecar. Again, chances are you have some of those “traditional” environments, and if you have a service mesh in use for your cloud-based environments, wouldn’t you like to extend those enhanced security, observability, and networking, benefits to your “traditional” environments, too? We’re betting that you would. That’s why we created Nasp.
Eliminating Sidecars
We’re not going to go too deep into this area (check out Márton Sereg’s blog on the introduction of Nasp), but it’s necessary to explain why we created a sidecarless solution. Although there are advantages to the sidecar model in cloud-based environments, there are distinct disadvantages. In cloud-based environments, sidecars can take up valuable compute resources and add complexity, especially at scale. It is important to reiterate that there are also advantages to the sidecar model for cloud-based environments, and our intentions aren’t to push you one way or another. Open source is all about the freedom to use the right tool for the job. But because sidecars often don’t workin non-cloud environments, Nasp was designed to be sidecarless.
In order to eliminate the need for sidecars, Nasp offers the most common functionality of a sidecar proxy including:
- Identity and network traffic security using mutual TLS
- Automatic traffic management features, like HTTP, or gRPC load balancing
- Transparent observability of network traffic, especially standard Istio metrics
- Dynamic configuration through xDS support
Nasp is an extension and isn’t meant to be a replacement for service meshes. That said, a reader may notice that there is some technological overlap with sidecarless service meshes due to the elimination of sidecars in Nasp. While on the surface this is true, Nasp is different from a true service mesh in that it is lifecycle-bound with the application. Technically, nothing is preventing a setup where all cloud-based applications in an environment are utilizing Nasp instead of a sidecar. Let’s check out some key use cases that we see fit for Nasp.
Further adding to its flexibility and potential use cases, Nasp can run both inside and outside a Kubernetes cluster. Pictured is Nasp running outside of a Kubernetes cluster, using Heimdall.
Use Cases
Traditional VMs and cloud migration
As mentioned, Nasp is well-suited for “traditional” applications that live outside of Kubernetes. Let’s say you’re trying to migrate a payment application from a traditional VM to Kubernetes. In this process, you’d ideally want that application to have as many commonalities with Kubernetes as possible. You could use Istio and an Envoy proxy, but that would overly complicate things, and cause extra work resulting from the maintenance of a proxy in a non-Kubernetes environment. This is the perfect use case for Nasp because it would extend service mesh to your VM environment, without the complications of maintaining a proxy in a non-Kubernetes environment.
Mobile applications
Mobile applications are continuing to explode in popularity and usage. Therefore, it is becoming necessary to provide mobile environments with the same level of services as cloud-based environments. Let’s use an example to reinforce our point: you’re developing one of those new-fangled fitness applications for iOS. You’re hyped to release that new application, and you’d like to extend some of the functionality of service mesh to gain proper metrics about how users are using their new fitness application. You ask your co-worker for help, and he says that the problem with your request is that a sidecar cannot be deployed in front of an iOS or Android application due to how mobile applications are distributed to the end user, so any attempt to extend capabilities to mobile applications must be sidecarless. Nasp creates the perfect solution for this scenario as well, since it is distributed as a library, can provide advanced networking capabilities to mobile, and can be connected to an Istio service mesh.
IoT and edge devices
I had an IoT cappuccino maker once (and I am not too proud to admit it), so let’s use that as an example. Any IoT device presents yet another attack vector for malicious behavior, and you don’t want someone’s personal financial information hacked into from their new coffee maker (which might sound outlandish, but can actually happen). To that end, extending the security benefits of service mesh for your IoT environment might be a great solution. In this scenario, you could also technically use a sidecar to extend service mesh benefits to your coffee maker’s software, but you aren’t working in a Kubernetes environment so activities related to maintaining a proxy can’t be automated. Nasp is the perfect tool for this instance, again extending service mesh capabilities without the need for a sidecar.
Cloud environments
As discussed earlier in this blog, on a technical level, nothing stops a user from running Nasp in any cloud-based application, using it to create a kind of sidecarless service mesh, bound by application life-cycle. In a smaller team of developers, this is a good solution. For example, say you’ve got a small team of 8-10 developers who are responsible for creating and maintaining inventory- management applications. These applications live in the cloud and on top of Kubernetes. Since it’s a small team, it’s unlikely that one person is specifically responsible for administering service mesh. While running a sidecar in a cloud-based environment might sound easy in theory, it can still provide complications and in our example, this small team is responsible for everything from debugging to updates. In our scenario, Nasp provides an ideal solution as it eliminates the complications presented by sidecars while keeping architecture as simple as possible.
The use cases for Nasp are almost limitless. Right now, in order to use Nasp the user will have to include Nasp in their application code as a library. This change isn’t intrusive and most of the functionality is transparent to developers. Going forward, we have plans to implement aspects of Nasp inside the operating-system kernel. We plan on releasing more content on how you can get started with Nasp, but for now, we encourage you to check out the quick start guide on Nasp’s GitHub repository
Learn more
We encourage you to give Nasp a try, contribute, submit feature requests and ideas, and check out the Getting Started guide. We also encourage you to join our Slack community, follow @CiscoOpen Twitter, and subscribe to our Dev.to feed for more open source blogs. We’d also be interested in knowing any other uses cases that you may have for Nasp. Be sure to let us know in the comments below!
Top comments (0)