WTF Are Cloud Native Engineers (and What Do They Do)?

WTF is a Cloud Native engineer?

I have heard that question so many times I decided to write this post so I can send the link the next time somebody asks me that question.

I guess that’s something you learn when you’ve worked with technology for over 20 years, as I have: Don’t write an email, write a post that you can share. 

I first had that question myself, when I saw the Container Solutions ad on Stack Overflow looking for a Cloud Native engineer. I remember reading about the technical skills needed and the technology involved, and that got my attention right away. But there’s more, a lot more, than ‘just’ technology.

Technical Skills

One of the things that appealed to me the most, was the lack of a specific tech stack required in the ad. Whoever has worked in technology for more than six months knows that whatever you’re working on today, might not be around next year. 

Also, assuming that a specific amount of time with a technology will give you some sort of seniority is also nonsense, as some big well-known corp found out in July 2020.

Let’s go through the items pointed out in the Container Solutions ad I saw in Stack Overflow, shall we?

• Background in development and/or operations. Check
• An understanding of best practices and patterns in software development. (See? Foundations, not specific software or languages). Check.
• Experience with CI/CD (no specific vendor). Check.
• Infrastructure provisioning. (Didn’t have great experience, only some knowledge of it.)
• Experience in either public or private cloud. Check.
• Understanding and exposure to Kubernetes. Check.

The last item is the only one that actually mentions some specific technology. And I believe, in this case, it makes sense. I think containers are the right way of deploying applications, and right now, Kubernetes is the de facto leader in orchestrating those containers.

Will it be around in 10 years? I don’t know, but most probably the foundations and principles that made Kubernetes so popular will outlive its name.

Wanted: Soft Skills

There were actually no soft skills mentioned in the ad, but during the recruiting process you could tell they were looking for some particular soft skills. Actually, in one of the interviews with a psychologist—yes, the company uses psychologists in its hiring process—she told me right away. 

Here are some of the soft skills I think a Cloud Native Engineer should have:

•  Interpersonal skills. We work with customers, interact with partners, colleagues, and sometimes the ‘competition’. You need to be able to communicate with everybody.
• Curiosity. Have you seen the CNCF Landscape diagram? There’s a lot to learn, so you better like learning new things. 
• Problem solving. I’m not saying you should not ask for help when you need it, but working in a remote-first environment, people might not be there to help you until tomorrow, or the next day—and that could be too late. 
• Humility. Again, if you’ve seen the CNCF landscape, there’s a big chance somebody will ask you for something you don’t know. But there are a lot of clever people at CS willing to help. Ping anybody on Slack and you most certainly end up in a call with somebody trying to help you.
• Willingness to help. You could be that person being pinged.

What Do Cloud Native Engineers Do?

Cloud Native Engineers at Container Solutions are always looking for ways of helping our customers have a smooth transition into a Cloud Native paradigm. Most of the time, it means introducing technology, design patterns, or concepts they might not be aware of. A strong and common misconception is thinking that being Cloud Native means packaging your app into a container and spinning it in a Kubernetes cluster. And that’s not even close—you can read more here about WTF is Cloud Native.

Here’s an example of what I’ve been doing:

A couple of months ago, I started working for a customer who needed to bring one of their teams (responsible for six applications) into the cloud. It was a ‘lift and shift’ project, but also required introducing some new concepts to the team, like pipelines for infrastructure provisioning with Terraform, and some scripting (for now) for automated application installation and configuration. 

I was very familiar with scripting, especially in this case where we’re using PowerShell, had some experience with Jenkins, and had some knowledge of Terraform. 

The project had already started when I joined and it had a tight schedule, so I didn’t have the proper onboarding process where you can take your time to go over the documentation (when available) and explore the existing configuration. So some of those soft skills I mentioned before kicked in. 

I had to get the credentials needed to access the repo and the existent, yet very limited, Continuous Delivery pipeline. Once I got somehow familiar with the pipeline, I had to make the needed adjustments for the required infrastructure. At the same time, other people were trying different configuration settings on the machines I had provisioned, so a lot of communication was needed for not running over each other’s work. 

It was one of those classic projects where the system had been working for years on existing on-premise infrastructure and nobody knew the exact software and/or hardware requirements. So there was a lot of gathering information, and asking for the ‘right’ documents, tool versions, and extra components needed.

That project is almost over and I’m very happy with the results; the team is also happy with what we achieved in so little time. In the next week or so, the system will be live in the new infrastructure. 

What’s in it for their customers? If something bad happens, everything can be spun up again in little to no time.

The magic of automation!

Conclusion

Oddly enough, the most required assets you’ll need to become a Cloud Native Engineer are your soft skills, as I mentioned before. Technology comes and goes, but it will be your willingness to learn that will keep you up to date. 

Being a CNE is not about knowing all the buzzwords or impressing people with acronyms—my colleague Jon Gold recently wrote a great post about how to adjust your communication to the right audience. What is true, however, is that every new technology or product is meant to solve a particular problem, so you’ll have to know what it is for, what problem you're trying to solve… and I just love that. 

Photo by Zan on Unsplash