devopsy.kinsta.cloud

Tag: DevOps hiring

Culture a Stumbling Block to DevOps, DevSecOps

Organizations are struggling to improve DevSecOps practices as they confront a lack of cultural alignment and investment, according to a global Progress survey of more than 600 IT, security, application development and DevOps decision-makers.

Many companies are behind in achieving their DevOps and DevSecOps goals, with 73% of organizations saying they could be doing more.

More than three-quarters (76%) of respondents acknowledged they need to be more strategic about how they manage DevSecOps, and 17% said they still consider themselves at an exploratory and proof-of-concept stage.

Prashanth Nanjundappa, vice president of product management at Progress, said the most surprising finding was the evident contradiction between what organizations think is very important and their actual alignment, commitment or investment.

“While security is the number-one driver behind most DevOps and DevSecOps implementations, just 30% said they felt confident in the level of collaboration between security and development,” he added.

Meanwhile, 86% of respondents are experiencing challenges in their current approaches to security and 51% admitted that they don’t fully understand how security fits into DevSecOps.

Nanjundappa pointed out that company culture is, in fact, biggest barrier to DevOps and DevSecOps success.

“We found 71% of respondents agreed that culture is the biggest barrier to DevSecOps progress, yet only 16% were prioritizing culture as an area to optimize in the next 12 to 18 months,” he explained.

The study revealed the top business factors driving the adoption and evolution of DevOps inside their organizations included a focus on agility as well as reducing the business risk of quality, security and downtime or performance issues.

Organizations also recognized the need to implement DevOps to support a cloud mandate or their move to the cloud.

In addition, concerns about public cloud workloads, increasing regulatory requirements and concerns about financial impacts are driving how security around DevOps is approached.

“Organizations are juggling lots of priorities in how they manage security with key focus areas for security being digital marketing efforts, employee apps and customer-facing apps,” Nanjundappa said.

Challenges with security include prioritizing the development of external-facing capabilities over internal apps, the ability to secure different workloads using different development and delivery methods, meeting delivery deadlines and difficulties meeting audit requirements.

“Through the survey, we have seen some of the differences that stand out between organizations that have achieved higher maturity versus others,” he noted.

Some are related to cultural aspects and bring to the fore a focus on business agility through fast and frequent delivery of application capabilities, as well as using DevOps to better manage distributed and/or remote work environments.

Nanjundappa said among the best practices to ensure fruitful collaboration are stakeholder sponsorship on leadership for tools and outcomes aligned with the strategic direction of organizational goals.

“Let teams innovate at the grassroots level with regard to tools and processes to accomplish expected outcomes,” he explained. “Identify teams which have seen success, celebrate those successes and implement those processes across other teams in an iterative model.”

As organizations head into 2023 with a tight IT labor market persisting, Nanjundappa pointed out a key concern will be to find the talent they need to make these DevSecOps initiatives a reality.

“While it is ideal to hire pre-trained talent which fits their organizational needs, it will either be expensive or sometimes close to impossible for multiple reasons,” he said.

He recommended using a multi-pronged approach to bridging talent gap, which includes an on-ramp for hiring experienced key talent and reskilling through cross-pollination of experiences from different teams, including security, dev and ops.

Nanjundappa also advised upskilling existing teams with modern technologies, replacing legacy platforms and tech with cloud and cloud-native technologies and augmenting that with the right level of tools and processes, including policy-as-code and CI/CD.

November 21, 2022
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

Gridiron IT
McLean, Va.
DevOps Engineer
$195,292 to $205,031

Dice.com

Odyssey Information Services
Remote
Senior DevOps Engineer
Up to $150,000

ZipRecruiter

K&L Wine Merchants
San Francisco
DevOps Engineer
$125,000 to $150,000

LinkedIn

Compassion International
Remote
DevOps Specialist – Splunk
$111,930 to $139,910

SimplyHired

Zoom Video Communications
Virginia
DevOps Engineer
$97,920 to $181,170

November 21, 2022
Visually Staffing Your Developer Teams

Effective collaboration within developer teams is key to creating and improving any product, so who you choose to put on the team—and how it’s structured—can make a huge difference. There are many considerations that go into these decisions, and the challenge is even greater thanks to the widespread movement to a hybrid work environment. To make the process a bit easier and more transparent and to set teams up for success from the outset of each project, it can be helpful to use a visual approach to staffing.

Considerations When Assembling Your Team

When a general manager is assembling a team in professional sports, they must take into account personalities, abilities and leadership styles to make sure the team functions smoothly and can win games. There are similar considerations necessary when putting together a developer team.

For example, a team must have the right balance of expertise. Having a team that is loaded with frontend experience but little to no backend experience will likely prove problematic. Also, a team full of interns or entry-level engineers with few or no senior engineers won’t have the leadership and expertise needed to succeed.

Coding styles are also a major consideration when assembling teams. Some engineers may be “cowboy coders”—coders who aren’t afraid to take risks when developing a product. Other engineers, however, may suffer from “analysis paralysis,” spending too much time making sure the code is as perfect as possible. It’s important for teams to have a mix of these styles so the development process doesn’t lean too far in either direction and so the overall team has the right balance for the project at hand.

Using Visual Collaboration to Assemble Teams

As a development team leader, I’ve found staffing our teams using a visual approach—and visually collaborating within those teams—is invaluable. It makes it much easier to ensure we have the right expertise and coding style on the right teams while managing the fast-paced changes that are a reality in today’s business environment. And with the staffing for each project visualized, leaders and team members can easily see who leads the projects and how many people are on each team within those.

Managers or project leads should be able to see all of the relevant factors of staffing before making an informed decision on who should be on the team or if they need additional support. To begin visually staffing your teams, start with a diagram that—in addition to displaying which team each person is on—clearly shows each individual’s responsibility and flags if they’re new to the team. When decision-makers are able to see each of these factors at a glance, it helps them quickly determine if a team has a gap and needs additional support.

Caption: Here, team leaders can see team breakdowns, responsibilities and if someone is new to the team (Lucidchart)

To make visual staffing even more effective, you may want to get more granular in detail when viewing team structures. This could include labeling team members with relevant attributes such as title, seniority, location, etc. Therefore, if a team needs a senior engineer or someone who’s worked on similar projects, it’s possible to quickly drag their name on your diagram and place them on another team. With this method, teams can see how a new assembly of talent can work together and how this adjustment affects other teams.

Caption: Team leaders can identify personnel, job title and the reporting structure (Lucidchart)

We’re also able to diagram reporting structures. It’s important to know to whom each person reports and how many direct reports each leader has. This helps prevent burnout and ensures each manager has the bandwidth to lead their direct reports and be in touch with the needs of the team.

Once teams are created, work sessions, such as program increment (PI) planning meetings, will also benefit from a visual collaboration solution such as a virtual whiteboard. Before the recent predominance of hybrid and remote work, many planning meetings included in-person discussions in front of a physical whiteboard. Also, voting on decisions included physical, color-coated sticky notes which each person would place on the whiteboard to indicate their vote.

Caption: Developer teams can participate in virtual PI planning meetings for more seamless collaboration. (Lucidspark)

Using visual collaboration will help not only recreate this experience in a hybrid environment but also make it more effective and efficient. For example, working with a virtual whiteboard solution could improve a team’s experience with common project management tools, such as Jira. The right visual collaboration solution can allow teams to pull stories and display the latest project information for everyone to provide input directly within a collaborative space. The result is an ability for team leaders to create high-level plans with both real-time collaboration and asynchronous input from teams around the world—all while massively reducing the slow, manual steps that are so common with collaboration in front of a physical whiteboard. Those slow manual steps could include transferring stories from project management software onto physical cards, moving those cards around as discussions continue and then—once decisions are final—manually uploading new information back into Jira or another project management tool. With the amount of dependencies on developer teams today, removing these steps in favor of more efficient processes is invaluable.

Visually Staffing Your Teams

Staffing teams and enabling collaboration can be a smooth experience, even in a hybrid environment. I’ve found that visualizing how teams work together provides the clarity needed to make the best decisions. It also allows easy changes to team composition should it be necessary. Visually staffing teams allows team leaders to start developers off on the right foot and consistently work toward project goals from start to finish.

November 17, 2022
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

Bobcat Company
Bismarck, N.D.
Solutions Architect AWS and SecDevOps
$130,000 to $180,000

LinkedIn

Lenovo
Morrisville, N.C.
Software DevOps
$100,000 to $140,000

Monster.com

Softweb Solutions
Plano, Tex.
AWS Engineer
$100,000 to $140,000

Dice.com

Estuate
Remote
DevOps Engineer
$100,000+

Indeed.com

Landmark Global
Remote
DevOps Engineer
$90,000 to $105,000

October 31, 2022
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

Harnham
Remote
Senior DevOps Engineer
$160,000 to $180,000

Monster.com

Riley Consulting Services
Folsom, CA.
Senior Full-Stack .Net Developer
$150,000 to $180,000

LinkedIn

Flowhub
Remote
Senior DevOps Engineer
$140,000 to $160,000

Dice.com

Northrup Grumman
Aurora, Col.
Senior Principal DevOps Engineering Lead
$120,000 to $180,000

SimplyHired.com

OBMedia
Remote
Senior DevOps Engineer
$120,000 to $160,000

October 10, 2022
Solving the DevOps Labor Deficiency

We all know there’s a chronic imbalance when it comes to DevOps talent: High demand and limited supply. Look no further than a 2021 DevOps Institute report which found that while 60% of organizations are hiring for such roles, 64% of IT leaders have a tough time finding skilled DevOps professionals. And it’s not just the typical pandemic staff shortages that you’ve heard about. The shift to remote practices has fast-tracked digital transformation across industries, spiking demand for developers.

So what exactly is the state of the DevOps labor market? Is it only tough for companies, or for candidates too–and can automation help? In honor of Labor Day, we asked a few IT leaders about this classic labor conundrum.

Labor Barriers on Both Sides

Elisa Hebert, vice president of engineering operations at Fairwinds, observed that DevOps hiring is difficult for both the hiring company and the candidate. “Teams have been chronically short-staffed for the last couple of years due to the COVID-19 pandemic, which resulted in companies wanting to hire senior DevOps professionals who can operate more autonomously,” she explained. “If you toss in a need for specialization–we work exclusively with Kubernetes, for example–finding that level of domain knowledge combined with senior-level experience is really tough.”

On the flip side, she said the industry practice of requiring years of experience for junior-level positions makes it difficult for inexperienced talent to get hired: “It’s an impossible wheel that needs to stop.”

Automation to the Rescue … Or Not

You might be thinking, “Well, why isn’t automation helping with these shortages?” It’s true that DevOps automation can lighten developer workloads. Efficient collaboration between development and operations teams can reduce friction; faster feedback loops can accelerate deployment. Leaders can reduce the number of staff needed for tedious tasks while their engineers can focus on more fulfilling work.

All of this can help retention efforts by preventing burnout and promoting a healthier workplace. As Balakrishnan Viswanathan, vice president of cloud operations at Demandbase, said, “DevOps straddles two important pillars: Increasing development velocity and increasing release quality. Automation is key because otherwise, burnout is very high.”

So it’s no surprise that DevOps Institute’s Upskilling 2021: Enterprise DevOps Skills Report respondents rated automation as the most important skill domain. They ranked proficiency in automating continuous integration, continuous delivery, continuous deployment, continuous operation and support and DevSecOps as the most valuable knowledge.

But here’s where the automation solution runs into the DevOps labor problem: The need for DevOps practitioners skilled in automation vastly outweighs the availability. “From a DevOps perspective, there are very few people across the tech space who have operated production systems at scale and enabled automation to reduce the toil, making these skillsets extremely valuable in today’s market,” said Viswanathan.

DevOps Recruiting, Hiring, Retaining: What’s the Solution?

Given these challenges, how can companies improve automation and relieve their overworked engineers? Hebert said IT leaders should “create scaffolding.”

“Fairwinds has an engineering leadership team that is cross-functional (dev, platform, SRE, R&D, services, UI/UX) and plans strategy and tactical execution together,” she said. “We’re greater than the sum of our parts, so while departures are a mix of sad and happy, it doesn’t break us.” She also advised companies to revise their job descriptions and “take all the extra stuff out that isn’t actually critical to the job,” pointing out that women typically don’t apply for jobs unless they meet every criteria listed.

Marcus Merrell, vice president of technology strategy at Sauce Labs, mentioned Historically Black Colleges and Universities (HBCUs) as a talent source, reminding leaders that “an excellent, under-utilized resource for recruiting is HBCUs and non-profit organizations that focus on CS education for girls and people of color. These organizations produce thousands of graduates every year who uniformly have trouble getting hired.”

Viswanathan recommended that organizations provide more automation guidance. “One thing companies can start doing immediately is establishing thought leadership in an effort to showcase all the automation work that their DevOps teams are doing by developing content, whether blogs, articles or white papers.”

Finding the Right DevOps Opportunity

There’s no silver bullet for a beleaguered DevOps job seeker, but Merrell encouraged candidates to apply for positions even when they don’t possess every qualification listed. “For people who identify as female and people of color, try to remember that the job requirements are usually only looking for about a 60% to 70% match,” he said. “Remember that the job description is aspirational and that no company really expects to match this 100%.”

Hebert also advised looking beyond salary. “If a company can offer you an opportunity to grow your skills by working on interesting projects or with senior-level engineering talent that can mentor you, that’s an invaluable asset.”

Defining DevOps Labor Solutions Differently

Some organizations may be coming up short on both automation and adequate staffing right now, but incremental improvements can help the industry get there. And IT leaders believe we will get there. “As cloud adoption gains pace, the skill sets and labor force needed are expected to grow in lock step,” predicted Viswanathan. Until then, both the DevOps hiring manager and the DevOps candidate can take steps to meet each other in the middle.

September 2, 2022
How to Avoid Crappy Culture and Keep Engineers Happy

Software engineers know how much they are worth—everyone wants them and there aren’t enough of them to fill that demand. While the need for tech talent is greater than ever, the pandemic has shifted priorities for many engineers. And they’re not alone. It’s a reality shared with millions of others in a variety of fields around the world.

If the so-called Great Resignation has taught us anything, it’s that everyone is tired of crappy workplace culture. People are beginning to question why they’d stick around at a place where they don’t feel valued and supported. And for those companies not investing time and energy into their culture, good luck holding on to software engineers. They know their value!

In this uber-competitive environment, the best way to keep software engineers happy and make the company a desirable place to join may seem counterintuitive, but hear me out: Just back off. Trust engineers to do their jobs well.

Put in place the building blocks for a supportive environment where people feel comfortable taking risks and voicing their ideas—even contradictory ones—in positive ways. Then, get out of the way. Leaders have a responsibility to make these values stick and to hire people who fit them, even if that means not always picking the most qualified person available.

Don’t Be Afraid of “Dumb Ideas”

I’ll be the first to say it—I have a lot of dumb ideas. I’m thankful to have worked in places that encouraged me to share those ideas. It taught me to focus on building a company culture that values openness to new thought processes. Because you never know when something that might seem like a dumb idea could actually become the next big thing.

No one wants to feel shamed for speaking their mind. Encouraging people to share their ideas, even those that aren’t fully developed, fosters a sense of trust in the team and can lead to greater creativity and innovation. It also makes the company stronger by reducing stress on employees and avoiding negative outcomes like burnout and other health concerns that may ultimately lead to turnover.

Getting to this point of psychological safety in the workplace is not an easy process. It has to be highly intentional given the standards that are often at play in the professional world. For too long, people have been thought of as replaceable cogs in an organizational structure, not as humans with unique and valuable skills, talent and shortcomings.

It’s about recognizing that people are human and often want to feel authentic in how they work. That’s why it’s valuable to talk about new ideas to improve the company and its products, as well as talking about how you talk; set a defined standard for how important topics are discussed as a team.

Fostering a supportive culture doesn’t mean there aren’t disagreements. But there are ways to offer contrary opinions without being a jerk about it. This mutual respect between engineers allows people to look at things with a critical eye without hurting anyone’s feelings.

At CodeSee, we do a weekly product review. And this often leads to statements like “the product does this, but I wish it did this.” This isn’t a criticism of anyone, and everyone knows that. It’s everyone helping each other in the pursuit of making things better.

Don’t Hire Assholes

Instilling these values in a company is a rewarding experience that allows engineers to flourish. But none of that matters if they don’t also show up in the hiring process. The same things we place importance on in our day-to-day operations are top priorities in hiring: Humility, trust and self-reflection.

We’d rather have a decent engineer that fits our culture and embodies these values than a great engineer that isn’t supportive of others. We don’t subscribe to the idea that it’s OK to treat people like dirt just because you’re a genius.

These ethos show up in the questions asked to prospective employees. Two of our go-tos are fairly simple. We often ask interviewees to define three strengths and weaknesses. It’s a number that requires some real introspection and helps us see if a person knows where they could stand to improve and have identified personal growth strategies. We’ll also ask, “When we call previous managers, what will they have to say about you?”

These questions are meant to tease out some self-reflection, naturally. If they can put themselves in the shoes of their past managers, that shows a high level of self-awareness and empathy.

Surprisingly, these questions have gotten under the skin of more than a few applicants. I’ve actually had people yell at me, the person doing the interview, because they’ve been made to feel uncomfortable. Obviously, that kind of response told us everything we need to know.

Tools for Success

Institutional knowledge is an asset to any team. However, it puts additional strain on senior engineers, who are already stretched thin, to hold that information in their head and teach/explain it to less-experienced colleagues.

This is something that needs to change to free up senior engineers to focus more on the big picture. We can solve that with tools to visualize code and by investing in models that provide these models to engineers to improve training.

Today, many engineers spend 60% of their time reading code. What if we could reduce that to 40%? Or 20% or even 10%? If all our engineering talent spent 40% of their time doing other stuff, think about where we could be?

However, productivity tools can be a double-edged sword. Instead of giving more freedom and trust to software engineers, some companies are using technology to wring every last ounce of productivity out of the workforce, efforts that are surely doomed to fail by encouraging talented engineers to start planning their exit.

The bottom line is that everyone needs engineers. Losing at least some is inevitable. But if you are thoughtful about creating a supportive, innovative culture—and maintaining it—then it’s a lot easier to compete.

But it’s no simple task. Every decision you make—from who you hire to the products you build to the way you talk to each other in meetings—plays a role in shaping culture. Engineers will be compensated everywhere they go, so the best chance to get ahead is to build the best, least-crappy culture possible.

April 25, 2022
Best of 2021 – Hiring When You’re Not FAANG

As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the twentieth in our series of the Best of 2021.

Most of us are not FAANG, and we shouldn’t act like we are. Instead of using that, I’m going to use the term we used to use to refer to them: “Web Monsters”, which isn’t 100% accurate, but includes more than just the five FAANG members (Facebook, Amazon, Apple, Netflix and Google) for this article. At some point, we are going to need a new term. Web Monsters doesn’t clearly include Apple or Citi, but FAANG clearly excludes Citi and eBay. But this blog is about something else, so please accept my apologies for that lack of clarity. Assume that ‘Web Monster’ means “Big, popular high-tech company that pays well and looks good on a résumé.”

There are several angles to “Not Web Monsters” that we can address, but I’m mostly going to focus on DevOps hiring, with a nod to irrelevant sales/marketing techniques. Hiring is an easy target because Web Monsters offer resume-building, pay and benefits that are super attractive in the industry, so they can (right now, at least) reject 99% of applicants and still have a good selection of candidates to choose from. Most organizations cannot compete in even one of those areas, though a few can when it comes to salary and/or benefits.

We in IT have long had a bad habit of asking our applicants to be more qualified than the average employee. It’s pretty ridiculous at times; things like asking for a candidate to have more years of experience with a technology than the technology itself has actually existed. What happens when you ask for the impossible? Honest, qualified applicants self-select out, and only those who don’t realize the technology hasn’t been around that long and liars end up applying. That’s just bad hiring policy, even if you are a Web Monster. But at smaller organizations where each hire has a larger impact on the organization, it can be devastating.

It seems worse in DevOps. In fact, all of the hiring items listed here seem worse in DevOps because DevOps is actually a nightmare mish-mash of skill sets. No two people define the job the same because “the job” covers everything from cradle to grave for an application. There is no part of app dev that “DevOps” couldn’t touch. That’s problem number one. Define the responsibilities of the role clearly, don’t ask for everything that it could be. As a rule, an Ansible specialist is not going to be a DevSecOps expert, and you shouldn’t expect them to be. I think, at a minimum, we need to split hiring along my traditional emphasis lines… DevOps and DevOps. If you are writing code and using Checkmarx while GitLab is building the results and you configured it to roll out to test … you’re not a DevOps engineer, even though there’s a bit of ops in there. Your strengths need to be in development and app configuration. Your job description needs to focus on that.

Could there be roles that need it all? Yes, particularly in the SRE or chaos engineering space; I could see that. But they are certainly not entry-level roles, or even close. Knowledge in the breadth of technologies required to touch the entire DevOps toolchain is developed over years and with a healthy curiosity. And, of course, the person you are hiring should have a similar skill set to those doing the job today. Which is a good sanity check against the “Throw in the kitchen sink” syndrome.

Next up is take-home tests and shared coding during interviews. We know that you have a vested interest in landing the best people, but if you are doing coding exercises with people who are primarily DevOps, you are wasting everyone’s time. Most DevOps jobs are done with PowerScript and/or bash with YAML files. Other languages used occasionally have no more place in a core job interview than other occasional bits. “It’s about how you think” is a common refrain. I would argue that an assignment that takes an applicant hours to complete (or in several cases I know of, days) is not an efficient way to evaluate the way a prospective employee thinks. And, in at least one case, I’m pretty certain the interview solved an actual problem that employees didn’t—or couldn’t—solve. Ask the candidate questions about how they’d solve problem X. Ask them convoluted questions. They don’t need to get to code level to show you how they think.

And finally, my nod to bad marketing: Unless you actually are doing the volume of one of the Web Monsters, the fact that Facebook is a customer of vendor X is totally irrelevant. In fact, like the government, most vendors can mark one or more of the Web Monsters as their customers, just because Web Monsters are so big they try a lot of different tools across many different teams. So having them as a customer should be irrelevant, but if it isn’t considered irrelevant, should be expected.

The team you have today is rocking it. Hire more people like them. You know what works and what you need. Get back to customizing hiring processes to deliver more of what you need and stop over-asking. There are more great people out there looking for roles; don’t scare them off by asking for irrelevant experience. Stick to the core. What are they going to do daily? Require that, then probe for other useful items at interview time. And get more good peeps in the seats!

December 29, 2021
Best of 2021 – The ‘Great Resignation’ in DevOps? Bah, Humbug

As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the tenth in our series of the Best of 2021.

Like me, you have probably heard a lot about the “Great Resignation” lately. I’ll admit—at first I did not think it had anything to with tech jobs, especially not DevOps or cybersecurity jobs. After all, there aren’t many workers in those fields who aren’t well-paid (though, of course, when it comes to pay, it’s all relative).

When I first heard about the Great Resignation, I assumed it referred specifically to fast food workers or, perhaps, other restaurant, hospitality and retail industry jobs. You know—the kind in which people struggle to make $15 an hour. But then I began to hear it applied to better-paying tech jobs. Finally, I interviewed several executives who cited the Great Resignation as one reason that they were undermanned in key development, DevOps and cybersecurity positions.

I know what you are thinking: Tech execs will latch on to any excuse to explain why they are short-handed in these skilled positions. I agree with you, to a point. But I have had the chance to speak with several folks at some in-person conferences I’ve attended recently (It’s just not the same online!) and I began to see a trend. The almost mythical work-life balance/quality of life trend was back with a vengeance.

During the COVID-19 pandemic, many workers—even in highly compensated, challenging jobs like software development, DevOps, QA and cybersecurity—had actually changed their perspective as a result of working from home all those months. True, many of them had already been working from home. But they still had a “mothership” that they went to; however occasionally. They still gathered with coworkers at conferences or off-site meetings; they still were part of the “culture”. With COVID-19, despite the best efforts of HR teams and managers to foster and nourish that “culture”, it just wasn’t the same. Much the same way we fooled ourselves into thinking Zoom and Teams were as good as in-person, we thought that we could keep our teams tightly bound and drinking the company culture Kool-Aid.

In place of that corporate culture, when workers weren’t working (and it did take some time for many of them to learn how to use the on/off switch), they began to actually do other things. They spent time with their immediate families. They tried new hobbies, they started (and completed!) DIY projects and more. Lo and behold, they found there was life beyond code.

This radical notion of doing things that were not work-related was not solely due to a failure to pay these people enough money. It was not about letting them work with the tools of their choice. It wasn’t even about who they worked with. At the end of the day, it was because they discovered they had a life, and that they enjoyed that life.

I welcome this trend. I think it will mean less burnout and more productive humans, at the end of the day. Heck, we may even see birth rates rise and divorce rates fall. We may all live happily ever after.

When it comes to the Great Resignation, in the immortal words of John Belushi, “Bu-uut nooo.” Notwithstanding all of the above being true, I don’t think this is what’s leading developers, DevOps or cybersecurity folks to leave their jobs in droves. They are setting boundaries, yes, but they aren’t quitting just because of pay. No—they are leaving for the same reasons they did before. No sooner do they settle into their new jobs than they are being contacted by the ever-present recruiters offering them more money, more benefits and now more work-life balance. Add to this the growth in demand for these positions worsening an already understaffed market and there you have it. A shortage of workers to fill open positions. This convergence of circumstances makes it easier for them to hop from one job to the next, as well.

At the end of the day, we still don’t have enough software developers, DevOps folks, QA or cybersecurity talent. This is driving the market. But Great Resignation? Bah, humbug!

December 24, 2021
Best of 2021 – The Next Evolutions of DevOps

As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the seventh in our series of the Best of 2021.

As society continues to recover from the global COVID-19 pandemic and some semblance of normal starts to return, technology continues to move forward. The pandemic certainly changed what normal means and people, processes and technologies all have adapted and evolved to meet those challenges. The narrative that the pandemic caused of your organization’s digital transformation is true for many practitioners. With 2022 just around the corner, DevOps is on the cusp of maturation of previously bleeding-edge paradigms and a focus on engineering efficiency. Here are five DevOps evolutions you should keep an eye on going forward.

Engineering Efficiency is Front and Center

Engineering efficiency is a particularly broad umbrella term. At the foundational level, engineering efficiency focuses on making someone (for example, an engineer) more productive. There are a multitude of disciplines that intersect, from organizational design to engineering/developer experience. Engineering efficiency is increasingly critical for organizations today. The pandemic had two major impacts on the technology sector in terms of resources and staffing. The first, at the start of the pandemic, was the unprecedented and unpredictable availability of resources; physical locations were being shut down because of the medical severity of the pandemic and the “getting hit by a bus” factor was playing out in real life. Second, during the recovery period, the Great Resignation began, and with it, a fight for resources that has become increasingly intense. Both have meant that the availability of resources, especially ramped resources, is scarce.

The Spotify model of tribes/guilds of engineering resources is a promising evolution; folks can frequently move around, reducing the toil that engineering resources face and allowing for engineering resources to not only ramp up more quickly but also increasing engagement and retention. The industry continues to march toward standardization in areas that were typically bespoke, such as the release process, and I think we’ll see that continue to evolve, as well.

Git is Ubiquitous

Leveraging a source code management (SCM) solution used to be reserved for software engineers. But as the proliferation of “something-as-code” has touched multiple levels of the technology stack from networking, storage and, ultimately, a development pipeline, the march of operations-focused engineers adopting many of the traits of software engineers continues. Having iteration in your infrastructure stack with more ephemeral/disposable infrastructure is becoming the norm. Saving and packaging the multitude of configurations for the “something-as-code” source control is a natural area of evolution.

Building off of source control are the package managers—your Docker registries, Helm chart repositories, etc.—for more deployable artifacts; that said, getting those artifacts to production is a process. Because Git is becoming ubiquitous across the technology landscape, this leads to the continued adoption of GitOps. Since the seminal piece was written by Weaveworks in 2017 defining the GitOps paradigm, leveraging GitOps is seen as a viable paradigm for many organizations five years later, especially when starting with greenfield initiatives.

Kubernetes is No Longer Bleeding Edge

In 2022, Kubernetes will celebrate the eighth birthday of its first commits on GitHub. Taking a jog down technology memory lane, eight years before Kubernetes (in 2006), VMware was still a private company and it would be a few years before vSphere was even released (remember how it felt to run a workload on a virtual machine in 2014?). The Kubernetes ecosystem still moves quickly, but placing workloads on Kubernetes is not a novel concept anymore. As application infrastructure and architecture have adopted the Kubernetes way (in other words, being idempotent and ephemeral), there is maturity around running a suitable workload on Kubernetes.

Kubernetes by design is highly pluggable. If you do not like the opinion or implementation of something inside Kubernetes, you can replace that opinion. Don’t like how Kubernetes handles ingress traffic? Then choose from one of the many ingress controllers available today. That is just one example of dozens of pluggable areas. Because of this, Kubernetes is viewed as a dynamic, non-static resource. Using Kubernetes takes trial and error and getting your cluster to be robust, performant and reliable is an ongoing journey that requires ongoing iteration.

Authors Can Be the Enforcers

There is no question that in a modern software stack, we are inundated with data. The metrics soup and the continued science of and exploration of observability (metrics, traces, logs) provide us with a lot to work with. Making decisions, even automated ones, based on that data continues to be critical. With the rise of site reliability engineering (SRE) practices, reacting or anticipating spikes in usage, failures and even security-related items are par for the course for modern teams.

These decisions can be authored into policies that specific platforms understand, such as autoscaling rules for a cloud vendor or something like Open Policy Agent in the Kubernetes ecosystem. With so many items shifting left toward the development team, finding the right resource, skillset or institutional knowledge to author these rules can involve the input of several teams. Because of the rise of “something-as-code,” regardless of whether the author of these rules is a software engineer, DevOps engineer, platform engineer or anyone in between, that author has the ability to enforce.

Shifting Left … But Complexity Shifts Left, Too

The old adage is that complexity is like an abacus: You can shift complexity around, but it never really goes away. With the movement to shift responsibility left to development teams, this also means that associated complexity is shifting to the development teams. Modern platform engineering teams provide the infrastructure (compliant Kubernetes clusters) to teams and any workload that is run on those clusters is up to the development team that owns it. Typically, development teams then focus on features and functionality. Managing lots of non-functional requirements—and even core infrastructure requirements such as networking—can be a burden; think about how your organization would handle a service mesh.

If you are a DevOps or platform engineer, making your internal customers—your development teams—successful is a great goal to work toward. Crucial to this is disseminating expertise. This can be in the form of automation and education. A common practice with the DevSecOps movement is to have some sort of scanning step as part of the build or deployment process, disseminating the internals as far as how the scan is performed, what happens if something is found, etc. Gaining internal adoption is a journey and having a good developer experience built around clarity and stability are important.

Evolution in 2022

Even with all of the challenges, bumps and learnings that the last year has given us, technology continues to evolve and advance and even lower the barriers of entry to continually become more inclusive. Focusing on improving engineering efficiency and reducing toil will allow for more participation and lower the barriers to entry.

December 23, 2021