devopsy.kinsta.cloud

Category: DevOps Practice

Five Great DevOps Jobs Opportunities

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

Our goal in these challenging economic times is to make it just that much 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 offered.

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

LinkedIn

Visa
Senior Director of DevOps Engineering
Bellevue, WA
$173,400 to 271,000

SimplyHired.com

Publicis Sapient
Dallas
DevOps Architect – Kubernetes
$140,000 to $180,000

Indeed.com

UBS
New York City
Software Engineer – DevOps
$135,000 to $165,000

Dice.com

NBC Universal
Englewood, NJ
Manager for DevOps Monitoring and Control
$130,000 to $170,000

CareerBuilder.com

BAE Systems
Nashua, NH
Software Engineering Tools DevOps Administrator
$112,142 to $191,070

April 22, 2024
Valkey is Rapidly Overtaking Redis

In March, Redis announced that it was dumping the open source BSD 3-clause license for its Redis in-memory key-value database, instead adopting a “source-available” Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1). That made both developers and users unhappy. So as open source people do, members of the community forked the code into Valkey with the support of The Linux Foundation. This move has proved much more popular than expected.

Madelyn Olson, an Amazon Web Services (AWS) software engineer and a Valkey maintainer, announced at the Open Source Summit in Seattle the availability of the first release, Valkey 7.2.5 GA. This release is based on the last open source version of Redis, 7.2.4. That’s good news, but it’s not big news. That’s what we expect from forks.

Rather, the important news is the immediate support for Valkey.

AWS, Ericsson, Google Cloud, Oracle and Verizon had all said they were supporting the fork. Now Alibaba Cloud, Aiven, Heroku and Percona are backing Valkey as well. I’ve seen many forks take off and overcome their parent projects – LibreOffice over OpenOffice comes to mind — but I’ve never seen one where so many Fortune 500 businesses spun on their heels to drop one project for another.

Olson said in her keynote speech, “These companies are planning to continue or even increase their contributions. Their support is needed for the long-term health and viability of the project. The community is thankful for their support, which will help keep the project open and keep our developers moving at the pace that our users demand.”

The Valkey fork’s maintainers have the technical chops needed to fulfill those business needs. As Olson pointed out, its technical leadership committee has 26 years of experience and over 1,000 commits to the open source project. Indeed, Tencent’s Binbin Zhu, a committee member, alone contributed almost a quarter of the open source Redis commits.

This response is not what Redis had in mind.

At the time of the fork, Redis CEO Rowan Trollope didn’t seem too worried. “The major cloud service providers have all benefited commercially from the Redis open source project, so it’s not surprising that they are launching a fork within a foundation,” he wrote. And he added, “Innovation has been and always will be the differentiating factor between the success of Redis and any alternative solution.”

With so many top maintainers now at Valkey, that assertion may be hard to pull off. As Heroku’s CTO Gail Frederick said during the conference, “With this group of experienced contributors and broad industry backing, Valkey is continuing the open source model that’s been transformative for developers everywhere.”

So many top Redis (the software) customers shifting to Valkey presents Redis (the company) with serious challenges. After all, Redis was the most popular database on AWS and by DB-Engine’s latest count, it’s the most popular key-value DBMS.

It appears that many of those customers are now on their way to Valkey.

Kyle Davis, an AWS senior developer advocate and former Redis employee, said, “AWS is committed to supporting open source Valkey for the long term. We are adding Valkey support to our ElastiCache and MemoryDB managed database services, which are built on open source Redis.”

Karan Singh, Oracle’s Director of Data and AI Product Management, wrote that “Oracle Cloud Infrastructure (OCI) Cache will continue supporting its current Redis 7.0-based service because the license changes don’t impact it.” However, Oracle is dropping the name Redis from its offering and is “working on integrating Valkey support into the OCI Cache service to ensure our unique in-memory database offerings on OCI continue to benefit from open source advancements, enhancing value for our customers.”

Empirical data suggests users are also moving away from Redis. Peter Zaitsev, Percona CEO, noted that DB-Engine is already showing a drop of interest in Redis.

Redis’s move attracted a lot of snarkiness. For example, Corey Quinn, chief cloud economist at The Duckbill Group, an AWS analyst firm, tweeted, “Good morning to everyone except the thieves at Redis. You didn’t build it; you stole it from the community. If you want it from the ones who built it, it’s called Valkey.”

What we’re seeing here is not open source fans copping an attitude. It’s companies and developers alike making a major move away from Redis.

Photo credit: Happy Lee on Unsplash

April 19, 2024
GitLab Adds AI Chat Interface to Increase DevOps Productivity

GitLab this week announced the general availability of GitLab Duo Chat, a natural language interface through which DevOps teams can invoke generative artificial intelligence (AI) to generate code, create tests and access summarizations of code. It is available as an add-on to the GitLab Duo Pro AI framework, which the company is embedding across its DevOps platforms. GitLab Duo Chat can be invoked via the GitLab user interface or GitLab’s web integrated development environment (IDE) in addition to third-party IDEs, including VS Code and the IDE provided by JetBrains.

Over the last few years, GitLab has been working with Google to embed a range of AI capabilities into its core platform. With the addition of GitLab Duo Chat, these are now more accessible.

As part of that effort, GitLab is also now adding privacy controls for GitLab Premium and Ultimate customers. These enable organizations to control sensitive data at the project, group, and subgroup levels to address security and compliance concerns.

David DeSanto, chief product officer for GitLab, said as AI capabilities become more accessible, the pace at which applications can be built and deployed is about to significantly accelerate. The most immediate impact should be a reduction in the number of instances where builds fail to deploy because the quality of the code used to construct them has improved, he added.

AI should make it easier for subject matter experts who have little software engineering expertise to participate in the application development process, noted DeSanto.

The immediate challenge DevOps teams will encounter is to determine how best to employ the prompts to generate code and tests within the context of their existing DevOps workflows. Over time, however, as the reasoning engines embedded within the large language models (LLMs) that are at the core genAI platforms improve, it will become feasible to automate a series of actions involving multiple tasks, DeSanto noted.

In the meantime, DevOps teams should start determining which manual tasks might be automated using a generative AI platform. In many organizations, there are still numerous bottlenecks in DevOps workflows that conspire to slow down the pace of application development.

AI platforms are unlikely to eliminate the need for application developers and software engineers any time soon. However, many scripts that DevOps teams have historically written themselves will soon be written and tested by machines. DevOps teams will soon find themselves supervising the development of more applications that, in addition to being constructed faster than ever, are less troublesome to update and maintain without having to add a small army of software engineers. The tradeoff is the overall size of the codebases that DevOps teams will be expected to manage is about to substantially increase, noted DeSanto.

In an era where organizations are more dependent than ever on software, the demand for applications already exceeds the ability of DevOps teams to address. AI should enable DevOps team to build and deploy applications at a level of scale that only a couple of years ago would have seemed unimaginable.

Photo credit: Ondrej Supitar on Unsplash

April 19, 2024
Exploring Low/No-Code Platforms, GenAI, Copilots and Code Generators

The emergence of low/no-code platforms is challenging traditional notions of coding expertise. Gone are the days when coding was an exclusive skill set reserved for a knowledgeable few. Low/no-code platforms have democratized software development. They empower individuals from non-IT or technical backgrounds to translate their business ideas into applications without the need to master complex programming languages.

These low/no-code platforms, with their user-friendly drag-and-drop interfaces and pre-built components, have simplified application development. Imagine building a smart home application with just a few clicks and drags — low/no-code platforms are making it possible.

Add generative artificial intelligence (Gen AI) into the mix, and the new development practices change the field remarkably.

The Impact of Gen AI on Low-Code Platforms

Expect low-code platforms to evolve further, becoming more intelligent, adaptable and seamlessly integrated into the software development lifecycle. There will be a shift towards platforms that use Gen AI to understand user intent, automate routine tasks and generate complex code snippets.

Gartner predicts that, by 2026, over 80% of enterprises will use GenAI APIs and models or deploy GenAI-enabled applications in production environments, up from less than 5% in early 2023.

Combining low-code and Gen AI will empower developers by automating routine tasks and allowing them to focus on high-level logic and creativity. Gen AI acts as a multiplier that can accelerate and optimize developmental operations.
McKinsey estimates that generative AI could add $2.6 trillion to $4.4 trillion annually to the global economy by 2040.

Another Tool: AI Copilots and Code Generators

Another promising application for AI large language models (LLMs) is AI-powered assistants. Enter copilots and code generators — AI assistants that take the hassle out of coding.

While low/no-code platforms have transformed application development, copilots and code generators add an extra layer of efficiency.

AI copilots use a chat interface to simplify coding through a chat interface, where developers articulate their code requirements in natural language prompts, and the copilot generates the code accordingly. These assistants provide real-time assistance, offering contextual suggestions and code snippets, and they can anticipate potential bugs. Moreover, they can explain code blocks, generate unit tests and propose bug fixes, which enhances the coding process.
AI copilots are like trusted assistants, ready to aid you with specific coding tasks or generate complex code – and they do it swiftly.

The Big Question

As a result of low/no-code platforms gaining traction, the skill sets required in the tech industry will transform. Gone are the days when proficiency in multiple programming languages was a must-have.

With low/no-code tools taking center stage, does this mean coding is becoming obsolete?

A big no.

While basic programming knowledge remains valuable, it’s no longer the sole requirement for building innovative applications. With low/no-code platforms democratizing application development, individuals from diverse backgrounds can leverage technology to create impactful solutions.

Do GenAI, copilots, and code generators render low/no-code platforms obsolete?

Again, no.

While GenAI, copilots, and code generators excel at certain specific tasks, low/no-code platforms offer a holistic solution, combining visual interface design, database integration and more. They’re the Swiss army knives of development, catering to a wide range of needs beyond just code generation.

Gen AI, copilots and code generators are not here to replace low/no-code platforms or traditional coding practices. Instead, they are positioned to complement and enhance them. The fusion of these technologies holds great promise in simplifying software development, boosting efficiency, and unlocking new avenues for innovation.

The Final Word

With better code suggestions and automated testing capabilities, low/no-code platforms deliver high-quality solutions that meet the demands of today’s tech-savvy users.

With the thrilling combination of low/no-code platforms and GenAI, the future of software development is promising. While these advancements may disrupt traditional coding, they also present opportunities for innovation and creativity.

It’s time for us to embrace this change and build a brighter tomorrow, one line of code — or lack thereof — at a time.

April 18, 2024
CDF Survey Surfaces DevOps Progress and Challenges

A global survey of more than 10,000 developers conducted by the Continuous Delivery Foundation (CDF) finds 83% of developers are involved in DevOps-related activities, with a third (33%) actively using continuous integrations tools, monitoring tools to track infrastructure performance and testing applications for security vulnerabilities.

Revealed today at the cdcon event, another 29% of respondents said they were actively involved in continuous delivery/deployment. The most widely used DevOps tools and platforms are source control management (29%) and issue tracking (28%), but only (21%) said they build continuous integration/continuous delivery (CI/CD) pipelines.

According to Mark Waite, community manager for CloudBees, the survey results said that while DevOps practices are widespread there is a clear need for organizations to achieve higher levels of maturity given the uneven adoption of best practices. For example, only a quarter (25%) of respondents said they programmatically manage infrastructure.

Overall, the survey suggests that organizations are on a DevOps journey that results in specific DevOps practices being adopted to meet unique requirements versus adopting a set of standards that are universally applied, Waite noted.

For example, the survey finds only 14% of respondents implement code changes daily, while another 17% require less than a week. More than two-thirds (68%) require a week or more, the survey finds. Similarly, only 9% deploy code multiple times a day, while another 20% are somewhere from once per hour to once per week. Only 11% said they could restore a service in less than an hour.

Those percentages have remained relatively consistent for the three years the CDF has been conducting this survey. However, the survey indicates that organizations that use managed CI/CD platforms are slightly more productive than organizations managing these platforms themselves. However, the report also notes that organizations using multiple CI/CD platforms tend to be less productive than those that have standardized on a single platform.

It’s not clear to what degree organizations are coping with the rise of platform engineering. The methodology, meant to manage DevOps workflows at scale, is standardizing DevOps tools and platforms. Historically, each DevOps team has tended to prefer whichever tools and platforms it selects, but over time multiple platforms can result in both higher levels of friction and increased costs.

Ultimately, no one-size approach to DevOps fits every organization. The one thing organizations that are committed to DevOps share is a commitment to higher levels of automation. In fact, with the rise of artificial intelligence (AI) the next era of DevOps is dawning.

In the meantime, finding and retaining software engineers remains an issue. There has been an ongoing effort to shift more responsibility for IT operations toward developers. However, as the cognitive load placed on developers increases, the amount of time they have to write code decreases. Not every developer writes code 100% of the time, but the less time developers spend focused on code the less productive they will be in terms of the amount of code that make it into a production environment. The challenge, as always, is striking the right DevOps balance.

Photo credit: Marc A on Unsplash

April 16, 2024
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud provides a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted, as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it just that much 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 offered.

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

CareerBuilder.com

EY
Austin TX
Cloud DevOps Manager
$169,500

LinkedIn

The Phoenix Group
New York City
DevOps Engineer
$140,000 to $150,000

SimplyHired.com

Northrup Grumman
Bellevue, NE
Manager DevOps Engineering 2
$131,200 to $196,800

Dice.com

GovCIO
Alexandria, VA
DevOps Engineer (AWS)
$110,000 to $140,000

Indeed.com

Northwestern Mutual
Milwaukee, WI
Senior DevOps Engineer
$108,568 to $194,350

Photo credit: Dan Crile on Unsplash

April 15, 2024
Securing Open Source Software, the Cyber Resilience Act Way

The Eclipse Foundation and other open source organizations are working towards implementing the European Union’s Cyber Resilience Act’s software development security requirements.

If anyone still doubted that we need to do a better job of securing open source software, the recent XZ backdoor security backdoor incident was a loud alarm. The European Union (EU) figured this out a while back. In its Cyber Resilience Act (CRA), it asked the open source community to establish common specifications for secure software development. The Eclipse Foundation and a host of other leading open source organizations, including the Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation and the Rust Foundation, are up for the challenge.

The Eclipse Foundation is spearheading the effort to create a unified framework for secure software development. The foundations and allies are doing this via a new working group, established under the Eclipse Foundation Specification Process.

The collaboration is spurred by more than regulatory compliance. In an era where open source software is pivotal to modern society, the imperative for safety, reliability and security in software has never been more critical. As Arpit Joshipura, the Linux Foundation‘s senior VP of networking, said at the Open Source Summit Europe in Bilbao, Spain, last year, “We must look at the end goal. The end goal for all of us is the same. We want to secure software, and we want to secure open source software.”

This process won’t be easy. It will be a highly technical standardization journey. The project will start with the current security policies and procedures of the open source foundations involved. The final result will be process specifications, which will be made freely available under a liberal specification copyright license and a royalty-free patent license.

The Eclipse Foundation and friends aren’t the only ones working on such security efforts. For example, the Open Source Security Foundation (OpenSSF) working group and the Open Source Consumption Manifesto (OSCM) are also working on building best security practices into open source software supply chains.

Under the CRA, the legal person—which is not the same as a flesh-and-blood person reading this story—responsible for these new policies and their implementation will be known as the “Open Source Software Steward.” This will be a heck of a job.

Leaving aside the code and technical issues, the open source groups must work with traditional standards organizations. Historically, neither kind of group has worked well with one other. To make matters worse, standard organization governance models don’t even have a way of dealing with open source groups. Indeed, for the fruits of this effort to make it into regulation, it will require going through the formal standardization processes of at least one of the European Standards Organizations.

This is going to be so much fun!

Adding insult to injury, setting technology standards usually takes years, and the CRA requires developers to have something in place by 2027. Good luck with that!

“There is an enormous amount of work that will need to be done over the next three years to implement the CRA,” Eclipse Foundation executive director Mike Milinkovich said. “It’s the first law anywhere regulating the software industry as a whole. The implications of this go far beyond the open source community and will impact startups and small enterprises as well as global industry players.”

Despite the challenges, the initiative represents a crucial step forward. The working group is optimistic about laying the groundwork for cybersecurity standards that can serve both the open source and proprietary software realms.

I wish them luck. They’ll need it.

April 10, 2024
Hashicorp Versus OpenTofu Gets Ugly

When HashiCorp dumped its open-source Mozilla license for the Business Source License (BSL 1.1) for its flagship program, infrastructure as code (IaC) tool Terraform, many Terraform developers and partners were ticked off. As open source developers are wont to do in such situations, they created a Terraform fork, called OpenTofu.

So far, that’s business as usual when a company shifts a project away from open source. Things heated up, though, when the Linux Foundation announced it would support the new fork. Now, the conflict between HashiCorp and OpenTofu is starting to boil, as HashiCorp accused OpenTofu of “not respecting the terms of its BSL license governing its Terraform codebase.”

Them’s fighting words!

OpenTofu replied, “OpenTofu vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code.” The organization added, “HashiCorp may be conflating code that it had previously been open-sourced under the MPL and more recently developed code it published under the BSL.” And, OpenTofu says, it will “issue a written response providing a more detailed explanation of its position.”

So, what is this code in question? Neither Hashicorp nor Terraform is saying, quite yet. However, it appears to be a “removed block” automation process that enables Terraform to manage resource deletion.

Matt Asay, MongoDB‘s VP of Developer Relations, revealed this accusation. He accused OpenTofu of lifting the “removed block” code, which was released under the BSL a few months after the OpenTofu fork was created. “The tell? OpenTofu took this BUSL-licensed HashiCorp code, removed the headers, and tried to instead relicense it under the Mozilla Public License (MPL 2.0),” Asay wrote.

Oh, it’s on now.

Even before news of the legally threatening message emerged, prominent open source leaders attacked Asay’s claim. Bryan Cantrill, the hyper-cloud Oxide Computer co-founder and CTO, claimed, “This is an extraordinarily serious accusation – and the cited files frankly don’t substantiate it.”

Cantrill is far from alone in thinking that there is insufficient evidence to justify the accusation that OpenTofu has stolen any code. Until we have harder evidence, the issue will remain a case of “He said, she said.”

Chris Aniszczyk, the CTO of the Cloud Native Computing Foundation (CNCF), a Linux Foundation-related organization, doesn’t think it’s a good look for HashiCorp. He said it’s “embarrassing to see a company light all of its hard-earned developer reputation on fire, on top of attacking open source.”

Dan Lorenc, CEO and co-founder of Chainguard, a software supply chain security company, warns this could be the start of something big and ugly in software development circles. “I don’t have any philosophical or ethical issues with source-available licenses, but their proponents are going to have to address these cease-and-desist threats,” he wrote. “Developers working in OSS (OSI/FSF approved licenses) are going to be prevented from engaging with or even looking at source-available projects completely to prevent the risk of lawsuits. It’s just too risky to pretend otherwise.”

Lorenc adds, “There’s no gradual transition here, it’s going to be a hard fork in communities if these lawsuit threats keep continuing. And I know which community I’d bet on sticking around.”

I lived through the SCO-Linux copyright wars. I think I know who will win, too.

Photo credit: Quino Al on Unsplash

April 9, 2024
Your AI Might be Lying to You

Simple tests can demonstrate how an AI can respond to and modify responses — a useful exercise for developers and DevOps who want to use these tools for activities like code or script generation.

While I was playing with generative AI for a hobby project – as most of us have – I discovered that in a few cases, it was stubbornly against following my explicit instructions. It wasn’t anything controversial. It was just that I was using a system that used math one way, and the AI was insistent in presenting results of the same category from a different subsystem. Even when told the steps to generate valid results, the AI tool got hung up on the name of the subsystem and “substituted” an invalid subsystem of the same name. It would say “Oh yeah, got you. Here: “ and then present what I’d just told it was factually incorrect. So I started pushing the edges and found a large number of instances where this type of confusion occurred.

In my hobby, I can take the time and calculate the bit I need separately, then insert it. In a professional setting, that is less than optimal. I mean, if we cut a dozen hours off a project and have to invest an hour fixing bits like this, it is still a massive win. The problem is that we have to know about the issue in order to fix it. But the system – where most of these issues are concerned – blindly does it, and doesn’t tell you. That’s so even where it knows it is not obeying your instructions.

Sometimes it’s okay to agree with the forced decisions of the AI’s designers. But an employee wouldn’t have a job long if, when told, “Do this task in exactly this manner” came back and said, “Yeah, your instructions didn’t fit my world-view, so I did something else; look at this great solution!” AI only gets a little more patience as long as it allows you to correct it quickly. And so far in our tests (except for the hobbyist issue above), we could convince it to do what we said, not what the AI designers said was “better.”

So here is the minimum test you need to run on any code generator to determine if it is doing what you ask, or what its AI designers programmed it to do.

Ask your AI to generate a simple dynamic website, in your language of choice. In one iteration, ask it to optimize for lines of code. Most will not; they know better, they think. Then after code generation, ask the tool if this is the fewest lines of code that solve the problem in that language. It will then give you the answer you actually asked for. Now repeat this exercise for readability. Use specific languages, frameworks, and libraries you might have as standards.

For simple problems, generative AI does generate usable code. I see AI in coding as being like an extension of libraries: a quicker way to solve common problems. But we still need to be cautious. When one major generative AI tool was asked to generate that simple webpage, it gave us four source files and said this was “an” answer. I had asked for the most efficient answer, optimized for minimum lines of code. As you might guess, we laughed at four source files to throw up a webpage that accepts a name and spits out “Hello [[name]]”. (This was our simple, dynamic test case). When I asked it, “Is this the fewest lines of code?” the tool promptly presented me with the answer you would expect. It was a single file, and then it scolded me that this was not the most readable. I never once mentioned readability to this tool, I mentioned optimized for minimum lines of code. But on the third iteration, it gave me the optimal answer for the dynamic example, and on the second the optimum answer for a simple webpage to display “hello world” non-interactively.

As I alluded to above, getting bad answers is not a deal breaker with AI, but you should be aware of the weaknesses in your chosen tool, and which tool you choose should certainly be informed about what level of manipulation the designers are engaged in, so staff can be on the lookout for suboptimal solutions (suboptimal in terms of organizational needs, which is the only “optimal solution” that matters).

So run that test along with your more functional tests, and keep kicking rear. If we can use generative AI for development and testing streamlining, we absolutely should, but we need to remember that it is just another automation tool, and sometimes less trustworthy than other tools.

April 8, 2024
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud provides a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted, as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it just that much 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 offered.

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

CareerBuilder.com

Insight Global
Chantilly, VA
Cloud DevOps Engineer
$140,000

Indeed.com

General Motors
Warren, MI
Senior DevOps Engineer
$128,900 to $232,900

SimplyHired.com

Maxar Technologies
Springfield, VA
DevOps Engineer
$131,000 to $219,000

Dice.com

Adobe
San Jose, CA
DevOps Engineer
$124,000 to $234,000

LinkedIn

Ascendion
Seattle, WA
DevOps/Platform Engineer
$100,000 to $135,000

April 8, 2024