DEV Community: Chris Lentricchia 🤙

We Don’t Bite! How to Overcome Imposter Syndrome to Foster a Culture of Open and Judgement-Free Learning

Chris Lentricchia 🤙 — Wed, 13 Sep 2023 14:42:14 +0000

With KubeCon North America around the corner, I’m reminded of the great opportunity for learning and self-improvement presented by attending the world’s premier cloud native event. Attending KubeCon is like having a completely new hard drive wired into your brain – it’s a mecca for learning. Although now in its eith year, KubeCon still remains an attraction for many first-time attendees, students, and people looking to dive deeper into cloud native. According to the Cloud Native Computing Foundation’s transparency report from KubeCon NA 2022, 61% of attendees were first-time attendees. While I’ve always made a point of offering advice to our newer cloud native citizens on how to approach learning at KubeCon, I’ve never documented my thoughts on how to approach learning within the cloud native ecosphere. In this article, I’m going to break down a few simple mantras and rules that you can use to adopt a mindset and a culture of judgement-free learning in order to get outside of your own head, grow as human being, and get the most of your cloud native experiences – even if you aren’t attending KubeCon. This article pertains to learning cloud native technologies but contains universal truths that are applicable to learning in general.

You are no more-or-less capable of learning anything than the next person

Because your own strength is unequal to the task, do not assume that it is beyond the powers of man; but if anything is within the powers and province of man, believe that it is within your own compass also. - Marcus Aurelius

If another human being has learned something, you are equally capable of doing so. Statistically speaking, most of us are of average intelligence, and with certain extremely rare exceptions, nobody is born with the capability for knowing more-or-less than others. The only reason someone has gotten experienced in a specific area is likely because they’ve spent a lot of time with it. For instance, if someone has been attending KubeCon for multiple years, they’re likely going to be more experienced in the cloud native space than a person who is a newcomer. There’s no fancy degree, course, or magic pill, that makes someone eminently more qualified to understand a concept over another person. My first tip to anyone looking to learn and expand their horizons as a human being, is to always remember that you are capable of learning anything that the next person is capable of learning. By keeping this lesson first-and-foremost in your mind when approaching cloud native learning, you can build the confidence to start developing and asking questions, no matter your background.

If someone ever judges you for asking a question, that’s on them, not you.

If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. – George Bernard Shaw

Often, I see newcomers to tech conferences or companies who may be afraid or embarrassed to ask questions for fear of asking something that they think is elementary, “stupid” or obvious, and then getting judged for it. Firstly, the vast majority of people at KubeCon, or in the cloud native community in general, will be flattered that you found them to be a reliable source of knowledge and will gladly answer your question to the best of their abilities. Chances are whomever you are asking that elementary or “stupid” question to, has had has the same question at one point themselves. They may have had the question a long time ago - or it may have been more recently, but chances are they had the same question that you do. And maybe they even figured it out themselves because they were too embarrassed to ask, too!

Understand that there is no human who knows everything or has the answers to every problem – they might act like they do, but they don’t; they’re a human just like you. Not knowing something is not a representation of yourself or how smart you are. Chances are that you also know something the other person doesn’t. Asking a question is simply asking for an exchange of knowledge about a particular topic. That said, if someone judges you for asking any question, it's really not your problem; go find someone else who will answer your question without judgement. I promise - it’s not you.

It’s not that you can’t understand a concept, it’s that you haven’t found someone who can explain it in a way that makes sense to you

Effective teaching may be the hardest job there is. – William Glasser

Being able to effectively convey ideas to another human is a brutally difficult job. Teaching not only involves having cardinal knowledge of the topic itself, but being able to relay that knowledge in a way that resonates with the individual receiving the knowledge. People learn in a variety of different ways. Some people learn better from pictures and diagrams, some people learn by being hands-on, and yet others learn from verbal communication. For example, if someone asked me to explain Kubernetes, I might say that Kubernetes is like a road. On that road, there are cars that we call “containers” and passengers inside those cars that we call “applications”. That explanation makes sense to me, but to someone else, it might lead to more confusion because they might be looking for more contextual details. That doesn’t make either of us wrong, or not smart, it makes us human – and although all humans are fundamentally the same, we are also slightly different. In that way, you can think of a teacher-student relationship as two pieces of pipe, where both pieces must precisely fit together in order to start the flow of inflation. Some people may have pipes made of steel; others of PVC; some with larger diameters; and some with smaller diameters. You can understand anything you put your mind to, you just have to find the right fit to help you understand. My third and last tip for learning and self-improvement is that humans learn differently, and you need to find someone who can explain things to you in a way that fits your learning style.

Parting thoughts

The mind can either be your best friend or your worst enemy. It is the only one that can hold you back in life. By remembering these three mantras, hopefully you can unblock your own mind to make your KubeCon North America experience more fruitful. Even if you aren’t attending KubeCon and instead learning from a distance, you can start your leaning by joining CNCF slack and OutShift by Cisco slack .

Extending Sidecarless Service Mesh to Non-Cloud Environments with Nasp

Chris Lentricchia 🤙 — Wed, 21 Jun 2023 17:37:41 +0000

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!