Have you ever seen this meme?

Yeah, sure you have. It’s one of the most popular memes when everything is blowing up in an environment, in your head, or around you and you have to pretend it’s all good.

That’s “cloud-native” in today’s world.

Engineers are confused, there are a lot of tools doing the same thing, and no one knows which direction is up or what advice it takes.

In this blog post, I’ll help point you in the direction of the “why” and the “how” to make your life a bit easier when it comes to the cloud-native realm.

Too Much Confusion

First and foremost, plenty of engineers are confused in today’s cloud-native world, and it’s not their fault. There are too many chefs in the kitchen. Too much going on between vendors and conferences and clouds to even get a grasp on what’s right or what’s wrong.

If you google a question you may have, you’ll see ten different blog posts with ten different answers.

This is something that’s always been around in the tech space. There’s never one right answer. However, due to the velocity at which the cloud-native space is moving and the amount of tools/vendors that are arising, it’s causing more confusion.

As the world moves forward, we want more stuff faster (modern-day consumerism) and it’s rubbing off on the cloud-native space. We’re living in a time where we have the largest technology advancements and the most options, but as we’re all learning, that may not be a good thing.

For engineers who have been in the space for 7-10 years, there’s a trend happening. It’s almost like a 180 is occurring. For example, going from “cloud all of the things” to “hybrid cloud and on-prem is actually good”. Spoiler alert - we’ve been doing on-prem since the 70’s. In engineering, we’re simply doing what we were already doing.

For engineers that are new in the space (2-5 years in), how the cloud-native space is moving is causing a massive amount of confusion because it’s too much too fast. The engineers that have 7-10 years of experience are confused as well, but less so because they’re seeing the “trend” (the 180).

How about tools?

Too Many Tools

From a tools and vendors perspective, there are a lot… and by a lot, I mean a TON. Engineering has always had several tools, but it’s never been this congested.

As an example, think about Active Directory. For years, Active Directory was the de facto standard when it came to authentication and authorization. Now there are 10+ authentication and authorization tools/platforms along with things like RBAC and authentication tied into platforms/systems (cloud providers, Kubernetes, etc.).

In today’s world, there are 10+ tools for each category, and they all have a slight tweak that makes the tool stand out. Unfortunately, it’s typically never enough of a tweak to truly help you understand what tool you should use.

The problem with this approach is when humans have too many options, we’re naturally inclined to deny all options. If we have too much information coming at us, we become overwhelmed and want to run in the other direction.

That’s how the majority of engineers feel when hearing from vendors.

So, how do we fix all of this?

What’s The Fix?

The fix for both the confusion factor and the tools factor isn’t small and there will be major pushback, but it’s very doable.

Confusion Fix

First, let’s talk about reducing confusion. To reduce confusion when going into a new or existing cloud-native environment, ask yourself one question:

1. What’s the expected outcome?

This question is the only thing you need to remove confusion. Let’s talk about a scenario.

Engineer A gets super excited about all of the cool Kubernetes and cloud-native goodness they read on the socials. They see that Kubernetes is super popular and everyone is talking about it, so naturally Engineer A thinks that Kubernetes will solve all of the problems that they’re facing. So, what happens? Kubernetes gets implemented without truly understanding what’s necessary or what the expected outcome is and tech debt occurs.

Engineer B on the other hand doesn’t get swept up by the hype. They ask the main question - what’s the expected outcome? Now, as an engineer, it’s Engineer B’s responsibility to decipher the answer. If Engineer B is talking to a manager or someone in leadership, they may not get a technical answer. They’ll have to come up with the technical answer. They do however know what’s expected. Engineer B can then come up with a solution for the expected outcome. It may be Kubernetes or it may not.

Tools Fix

From a “tools fix” perspective, this is a tricky one. After all, every engineer can’t get together and boycott vendors from creating more tools… so how does the tool problem get fixed?

It’s a three-step approach.

First, identify the confusion fix. Understand the expected outcome.

Second, research the exact tools based on category for the expected outcome of the implementation you’re trying to do or the problem you’re trying to fix. You’re going to want to get other engineer's opinions, so Google around on various forums and see what engineers are saying that they use in their environment. Remember, their opinion isn’t set in stone, take it with a grain of salt. However, you’ll have a good starting point.

Third, out of the 5-7 tools you’ll end up narrowing down to, narrow it to 2-3 and test them vigorously. You should take a minimum of 3-4 days to evaluate the tools and see which one works best for you. They may do the same thing, but something as simple as “the installation here was way simpler” will be a night and day difference from a scalability perspective.

Wrapping Up

There’s a massive amount of confusion in today’s cloud-native world. Every engineer from junior level to mid to principal are feeling it. The good news is there are a few different ways to navigate the problem. Remember, always ask yourself one key question - “what’s the expected outcome?”.