If you want more content like this, subscribe to my YouTube channel! youtube.com/clouddevengineering

Believe it or not, we're already halfway through the year! With time comes change and with change comes new skills to start thinking about. Because you shouldn't overload yourself with learning a million things at once, it's better to think about what the year will look like from a learning perspective for 4-5 topics.

The tech space is not a career that you can simply learn something once. Instead, you have to think about how to upskill yourself on a month-by-month basis. You don't have to sit in your room all day cranking away at code and neglecting your entire life. However, you have to understand what's changing in the tech space, what you can do to make an organization better (especially since engineers are now decision-makers), and how to keep yourself employed because the truth of the matter is people get laid off all of the time and can't find jobs because they didn't keep their skills up-to-date.

In this blog post, you'll learn about what the top 5 new trends are for DevOps coming up in 2022 and why they're important.

Infrastructure Automation

Although already popular, infrastructure-as-code and other coding-specific infrastructure methods are becoming even more popular. Because of the way the world is right now and has been for a few years, more and more organizations are trying to scale out to the cloud. Whether it be because offices are closed or perhaps it simply doesn't make sense to keep servers on-prem anymore, engineers need the ability to move faster to move/scale/re-create whatever is running on the old on-prem servers.

Infrastructure automation is the way of the cloud future. There are several tools out there, but the one that's absolutely on top right now is HashiCorps Terraform, which is an infrastructure-as-code tool written in HashiCorp Configuration Language (HCL) to define what you want cloud (and on-prem) infrastructure to look like.

To perform infrastructure automation, you must:

• Be comfortable writing code. You don't have to write the next Twitter. You simply have to be okay with learning how to automate.
• A source control system to store the code in (like GitHub).
• Help the business understand that although for years, infrastructure engineers weren't coders, times are changing and they are now. Everyone is a developer in today's world.

DevOps Security

Security is typically one of those aspects that is the absolute most neglected in any organization. In fact, Gene Kim (DevOps researcher), has said that for every 100 developers, there is 1 security engineer. When you think about it, those numbers are absolutely scary. Especially considering a lot of organizations would rather move fast and do the security later vs doing things right the first time.

However, times are changing. More people are working from home, more services are being run in the cloud, and more attacks are happening by the day. Because of that, the way an engineer writes software must be secure, but also, the way that software is being deployed to its destination must be secure (and the destination itself).

To start properly thinking about security, you must:

• Understand what security is. For example, the idea isn't to remove all risks, it's to mitigate as many as possible.
• Have proper cloud (and on-prem) vulnerability scanners available to scan any service you're using.
• Secure the code you're writing (perhaps infrastructure-as-code) with standard tests (unit/integration/mock/etc) and/or Policy-as-Code.

Chaos Engineering

Have you ever woken up at 2:00 AM because an application went down due to not being able to withstand some unexpected load? Or maybe the RAM on a server spiked and caused an alarm? The idea behind chaos engineering is to prevent this. Some organizations use it before an application is deployed and other organizations go a step further and use it in production.

It's a great way to find holes from a security/vulnerability perspective and have the help to predict when a system crash may occur. The whole idea behind Chaos Engineering is you want the ability to break a system on purpose so you can figure out why and how you were able to break it, ultimately making the system much better.

One of the best and most fun tools you can take a look at is Chaos Monkey created by Netflix, which is a Chaos Engineering tool. Please don't use it in your own production system until you've fully vetted the tool and management signs off on it.

To perform proper chaos engineering, you must:

• Understand that it's all about how to find weaknesses and holes in a system.
• Set a baseline for how you believe the system should work.
• Lots of testing is involved. It's very much R&D (Research and Development Engineering).

Engineers Are Now Decision Makers

The tech space is always evolving and constantly changing. There will never be a way around that, so one thing to keep in mind is you must be comfortable with change and have the ability to adapt. Because engineers are typically the curious type, learning new things is comfortable. However, for most people in management, it may not be their strong suit, especially if they don't have an engineering background and that's perfectly fine.

Because of that, management is starting to understand that they cannot simply come up with what a product or an environment should look like on their own and pass it down to the engineers to build. Instead, engineers must be involved in the decision-making process. Whether it's to go with one programming language or another for an application or which public cloud to choose. Engineers must be comfortable putting a manager hat on and diving into the decision-making.

This type of mindset from both engineers and management will make for an amazing environment and great innovations.

To have the ability to make decisions as an engineer, you must:

• Understand what the business actually does.
• Understand why the business does what it does.
• Combine your engineering abilities with a thought process that allows you to vet out scenarios.

Value Stream Management (VSM)

Measuring value from an engineer has always been somewhat difficult. In the way early days of coding, engineers would get bonuses and praise if they have "X" amount of lines of code. However, the tech world quickly learned that all that did was create technical debt. Ever since then, it's been a constant battle to think about how to measure value and more importantly, what value actually means.

With Value Stream Management, there are a ton of different ways to measure value. For example, you can see if pipelines are failing and why they're failing, then see what's making them fail. After that, you can get the analytics, percentages, and statistics of the pipeline. You can then measure the value that you're getting out of the pipeline, and if it's failing it won't be a lot, so you can go in and fix it based on how important it is.

There are a few deviations from VSM as well. For example, Value Stream Delivery, Value Stream Analytics, etc.. The important thing is to not get caught up in the buzzwords. Understand that it's all about measuring value.

To implement a proper VSM process, you must:

• Understand that "more" doesn't mean "more". You should always be thinking about quality over quantity. For example, if an engineer creates 10 pipelines, that's great, but are all of those pipelines passing? Having 5 pipelines that are passing instead of 7/10 pipelines failing is much better.
• Choose software that you're comfortable with. There are a lot of vendors in the VSM space, but some do VSM better than others. For example, some VSM providers will focus more on engineering and management collaboration while others will focus more on efficiency. For example - if pipelines are failing, why?
• Ensure that everyone knows this isn't meant to be a micromanagement implementation. With some VSM providers, you can go in and see what engineers are working on what branch, and which they're contributing to. This can get very "micro-managey" really quick, and that defeats the purpose of VSM.

Interested in learning more? Check out how you can contact me for consulting and advisory services! https://michaellevan.net/advisory_services/