devopsy.kinsta.cloud

Category: Blogs

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted 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:

    Dice.com

    FICO
    New York, New York
    Senior Director of DevOps Enablement
    $140,000 to $220,000

    Indeed.com

    Cisco Systems
    Research Triangle Park, North Carolina
    DevOps Engineer
    $139,000 to $176,000

    SimplyHired.com

    Candid Health
    San Francisco, California
    DevOps/Infrastructure Engineer
    $121,000 to $154,000

    CareerBuilder.com

    CACI
    Springfield, Virginia
    DevOps/Cloud Engineer
    $110,000 to $180,000

    LinkedIn

    Cox Communications
    Atlanta, Georgia
    Lead DevOps Engineer
    $105,700 to $176,100

  • Back to the Office

    Back to the Office

  • Rebellion Against Changes to Open Source Terraform License Mounts

    Rebellion Against Changes to Open Source Terraform License Mounts

    A segment of the community that has embraced open source Terraform software, originally developed by HashiCorp to provision infrastructure as code (IaC), has published a manifesto calling on the company to reverse recent changes made to licenses that determine how the software can be used.

    If that demand is not met, the group plans to launch its own fork dubbed OpenTF under the terms of the previous license that governed the usage of Terraform.

    Pawel Hytry, CEO of Spacelift, a provider of a platform for orchestrating the management of multiple IaC tools, said the issue comes down to restrictions that Hashicorp has put in place restricting use within platforms that have embedded it, in addition to limitations on how Terraform can be used in production environments.

    HashiCorp is shifting from a Mozilla Public License v2.0 (MPL 2.0) to a Business Source License (BSL) v1.1 in all future releases of its software including Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant, as part of an effort to maintain maximum control over its intellectual property.

    This shift will have a chilling effect on Terraform innovation because fewer individuals and organizations will want to contribute to advancing the tool, said Hytry.

    However, Hytry added, historically HashiCorp has not been perceived as not being overly receptive to contributions from external developers, so the bulk of the code used to create Terraform has come from developers working for HashiCorp.

    It’s not clear to what degree this firestorm impacts DevOps teams, but the fragmentation of open source projects stemming from issues that come down to revenue streams is increasing as it becomes more difficult for vendors that create open source software to continue to increase the number of subscription services for the support they provide. Red Hat, for example, recently decided to no longer make the source code for the Red Hat Enterprise Linux (RHEL) edition of its operating system available. The decision led to Oracle, SUSE and CIQ pooling their resources to create a fork of RHEL that they promise will be compatible with future updates to RHEL.

    It remains to be seen how many vendors might throw their weight behind OpenTF. HashiCorp, in addition to having partners that built the business on the open source edition of Terraform, also has plenty of rivals that offer IaC tools.

    It may be a while before this conflict is resolved, but for now, the situation remains fluid, said Hytry. DevOps teams that make extensive use of Terraform will need to monitor events to make sure any future usage of Terraform complies with BSL terms that supporters of the manifesto claim are at this point too vague.

    In the meantime, organizations that rely on open source software should brace themselves for any abrupt changes to licensing terms that may be forthcoming in more challenging economic times. In fact, one of the hidden costs of using open source software is the different terms and conditions under which it is licensed. Resources to monitor each additional instance of open source software for compliance, with terms and conditions that are not always as simple or clear cut, need to be dedicated to a task that doesn’t make any meaningful contribution to return on investment.

  • Synopsys Taps NowSecure and Secure Code Warrior to Improve DevSecOps

    Synopsys Taps NowSecure and Secure Code Warrior to Improve DevSecOps

    Synopsys has partnered with NowSecure and Secure Code Warrior to enable organizations to better identify where they can improve DevSecOps best practices.

    Scott Johnson, senior director of product management for the Software Integrity Group at Synopsys, said the data captured by the application security testing tools can now more easily be used to identify ongoing issues that, for example, can be used to create better mobile application security tests using the NowSecure platform.

    That same data can also be fed into the online learning platform Secure Code Warrior provides to enable developers to improve their cybersecurity skills.

    Collectively, those observability capabilities will significantly reduce the overall level of application security risk that organizations today experience, noted Johnson.

    Secure Code Warrior CTO Matias Madou noted that improving the cybersecurity expertise of developers is more critical than ever. The more expertise they have the easier it becomes to remediate issues before and after applications are deployed in a production environment.

    That’s going to become an even more crucial requirement as the rate at which code is being written increases exponentially with the rise of artificial intelligence (AI). While AI can improve the quality of code being written, it’s also likely an AI platform trained using code collected from the internet is going to introduce vulnerabilities. This is because the code used to train an AI model, such as ChatGPT, from a quality perspective is inconsistent, he added.

    It’s not clear at what rate application security is improving due to the adoption of DevSecOps best practices, but as AI becomes more widely employed by developers a paradox is starting to emerge. There is no doubt vulnerabilities developers have inadvertently introduced are being eliminated by AI tools that surface examples of secure code for developers to copy and paste. However, not every example of code is completely devoid of risk, so there is going to be more code that needs to be scanned for vulnerabilities.

    This issue will become particularly problematic as regulations making organizations more accountable for application security will become law in the months ahead. Thanks to AI, there is no doubt organizations will be building and deploying applications containing vulnerabilities at much faster rates.

    The hope is that AI tools specifically trained to identify vulnerabilities will soon be embedded in the tools that developers and DevOps teams rely on to initially build and deploy applications. However, a gap is emerging between the pace at which AI tools are being used to build applications and the availability of tools using AI to first detect vulnerabilities and help automate the remediation process. As a result, application security issues, at least for the immediate future, will continue to bedevil DevOps teams.

    Unfortunately, given the insecure code that has already been deployed, it may be years before application security issues are resolved to the point where the current level of stress for all concerned is meaningfully reduced.

  • Survey Surfaces Shift in Digital Business Modernization Goals

    Survey Surfaces Shift in Digital Business Modernization Goals

    A survey of 600 senior IT decision makers found that enterprises plan to invest on average $33 million on IT modernization over the next 12 months to achieve digital business transformation initiatives that have shifted in the last few years.

    Conducted by Couchbase, a provider of NoSQL database platform, the survey also finds 60% of respondents identify their key modernization goal to be to improve business resilience and efficiency in the face of the evolving global economy. Well over half (58%) say that their projects have become more targeted towards specific business outcomes.

    More than three quarters (78%) also noted their main transformation priorities have changed in the last three years, with more than half noted their focus is now more on reacting to market changes and customer preferences to enable the organization to remain agile. Well over a third (38%) are focusing on tangible modernization projects that will provide immediate results. Only 22% said their priorities have stayed the same over the last three years.

    That focus on resiliency and efficiency represents a shift in modernization priorities that is being driven by a need to reduce the total cost of IT without introducing any additional risk to the business, says Jeff Morris, vice president of product marketing for Couchbase. That shift suggests organizations are looking to address outstanding technical debt that has been allowed to accrue over the past few years before investing in additional projects involving, for example, artificial intelligence (AI), he adds. “There’s more focus on cleaning up the mess,” says Morris.

    Pressure from developers to support agile development and innovation (44%), and empowering developers to build more applications to meet customer needs (44%) were, as a consequence, the top two drivers behind transformation projects, the survey finds.

    The top technologies organizations are investing in as a result are serverless computing (42%), edge computing and IoT (40%) and low- or no-code technologies (39%) followed by large language models (LLMs) for building artificial intelligence (AI) models.

    Overall, more than half (53%) of respondents said their organization is either on target (31%) or ahead of their planned progress (22%), with increased business resilience (57%) being the most common benefit from digital projects in the past 12 months. Well over half (54%) claimed to have made “significant” or better improvements to the end-user experience.

    The survey also notes, however, that, on average, organizations invested 14% of their digital transformation budgets in projects that failed, were canceled, or suffered significant delays. More than two-thirds (68%) said these failures, cancellations, and delays pushed back digital transformation goals by more than three months, with nearly a quarter (24%) admitting to delays of more than six months.

    However, well over a third (38%) noted they do not have a clear sense of the top priorities for new transformation projects. In addition, the survey funds nearly half of respondents (49%) reporting their chief financial officer (CFO) is managing budgets in more detail, with 37% noting that pressure to achieve transformation with less budget and staff resources has increased in the last 12 months. More than a third (35%) said their IT department is under more strain now than at any other point in the last five years.

    Modernization within the context of digital business transformation is, of course, no longer an event but rather a continuous never-ending process during which different priorities ebb and flow.

  • Sysdig Identifies Cyberattacks on GitLab Platforms Using Binaries

    Sysdig Identifies Cyberattacks on GitLab Platforms Using Binaries

    The Sysdig Threat Research Team (TRT) has uncovered this week that cyberattacks using binaries written in Go and .NET compromise instances of the on-premises editions of the GitLab continuous integration/continuous delivery (CI/CD) platform.

    Michael Clark, director of threat research for Sysdig, said most attacks against software supply chains employ scripts. Cybercriminals that appear to be based in Russia are using binaries to launch proxyjacking and cryptomining campaigns utilizing infrastructure resources used to host instances of GitLab.

    Cryptomining is the process used to validate cryptocurrency transactions. Proxyjacking involves reselling bandwidth to providers of proxyware services to allow someone to hide their physical location.

    The Sysdig research effort, dubbed LABRAT, also noted that the tactics and techniques used to launch attacks are reasonably sophisticated. In addition to using binaries, the cybercriminals also employ tools with undetected signatures, cross-platform malware designed to evade cybersecurity platforms, a command and control (C2) platform that bypasses firewalls and kernel-based rootkits to hide their presence. Furthermore, the attackers abused a legitimate service, TryCloudFlare, to obfuscate their C2 network.

    The attacker, still active, is also continuously updating their tools, which requires organizations running GitLab to track the tactics, techniques and procedures (TTP) being employed by the cyberattacker to keep their indicators of compromise (IoCs) list updated.

    Relative to the illicit revenue that might be gained from cryptojacking and proxyjacking, this cyberattack is noteworthy in its sophistication. What is less clear is the degree to which this attack might also be used to inject vulnerabilities into the software supply chains based on the GitLab platform.

    The one certain thing is that cybercriminals have developed more advanced capabilities for compromising software supply chains that are likely to be used to compromise multiple DevOps platforms.

    Fortunately, there’s a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The challenge is most efforts are still relatively nascent. As such, there isn’t a high enough appreciation for the lengths cybercriminals might go to compromise a software supply chain. The ability to inject malware that might one day find its way into any number of downstream applications makes a software supply chain a tempting target.

    Multiple legislative initiatives have been launched that eventually will require organizations to better secure software supply chains. As such, most DevOps teams would be well-advised to begin those efforts now. Some aspects of the proposals being debated today eventually will become law. Rather than trying to comply with a requirement, a more methodical approach to ensuring the security of software supply chains would create less stress for all concerned later.

    In the meantime, thanks to the adoption of DevSecOps best practices application security continues to steadily improve. The issue stands that those advances are not being made as quickly as cybercriminals are evolving new tactics and techniques.

  • Why Multi-Cloud Cost Optimization is Harder Than it Looks

    Why Multi-Cloud Cost Optimization is Harder Than it Looks

    If your business is like most businesses that use the cloud today, you’ve gone multi-cloud. Nine out of 10 large companies have already adopted multiple clouds, and IT analysts expect that even more businesses will embrace multi-cloud architectures over the next several years. Now, the challenge facing those companies is how to optimize spending across multiple clouds. Many will find that, despite common narratives suggesting that cost savings are an inherent benefit of multi-cloud architectures, reducing spending when using multiple clouds can be a lot harder than it looks.

    This is, fortunately, a challenge that can be conquered easily enough. Keep reading for tips on updating your cloud cost optimization strategy to support multiple clouds.

    Multiple Clouds Don’t Guarantee Reduced Cloud Cost

    Before diving into strategies for reducing spending when using multiple clouds, let me dispel a common myth about the relationship between multi-cloud architectures and spending.

    Contrary to popular belief, using multiple clouds doesn’t guarantee that your business will spend less overall in the cloud, or even make it very easy to do so. Although advocates of multi-cloud strategies often promote the idea that using multiple clouds makes it simpler to find the most cost-effective cloud services because you have a larger menu of offerings to choose from, the reality is that cost-saving is not a common outcome of going multi-cloud.

    Sure, in theory, having multiple clouds does give you more opportunities to reduce costs. But in actuality, migrating workloads between clouds typically takes significant time and effort. Given that most mainstream cloud services–like VM hosting and object storage–have been commoditized to the point that there are rarely major pricing differences between them, few businesses are actually going to migrate workloads back and forth between clouds on a frequent basis in order to save a few dollars.

    To Reduce Multi-Cloud Spending, Focus on Cloud Provider Relationships, not Workloads

    That said, adopting a multi-cloud strategy does place you in a position to reduce overall spending–but it’s not because you can migrate workloads between clouds. It’s because you can leverage relationships with multiple cloud providers to negotiate pricing reductions.

    If your teams are actively using multiple clouds, you have a strong ability to negotiate enterprise pricing deals with the providers of each of those clouds. Each provider that you work with will be eager to earn as much of your business as possible, and if they know that your company is already also using a competitor’s platform, they’ll probably be more forthcoming with discounts in exchange for a commitment on your part to run more of your workloads on their cloud.

    How to Keep Multi-Cloud Cost-Efficient – but Also Flexible

    The caveat is that if you want to retain the flexibility that a multi-cloud architecture nominally provides, it’s important not to over-commit to any single cloud provider. If you do, you may find yourself locked into one cloud for certain workloads due to pricing discounts that you’ve negotiated for those workloads with that cloud provider.

    An effective approach for finding the right balance between pricing discounts and flexibility is to decide which percentage of your overall cloud spending you want to avoid tying to a particular cloud. For example, you might decide that it makes sense to commit 30% of your spending to one cloud provider and 30% to another in exchange for pricing discounts that negotiate with each provider. But the remaining 40% of your cloud spending won’t be linked to enterprise agreements with cloud providers, so you’ll be free to spend it in whichever cloud you like.

    Maintain Workload Portability to Minimize Multi-Cloud Spending

    As you work to optimize multi-cloud spending, strive to adopt portable workload technologies, like containers in place of ones that are harder to migrate between clouds, like VMs.

    This is important not just because portable technologies help to maximize the flexibility of your multi-cloud strategy, but also because they give you more leverage when negotiating with cloud providers. The providers realize that some types of workloads are harder to migrate than others, and they’re less likely to offer serious pricing discounts if they know it’s going to be very difficult for you to move your workloads to a competitor.

    But if you can say, “70% of what we deploy runs in Kubernetes and can migrate from your managed Kubernetes environment to your competitor’s offering next week,” you’re in a much stronger negotiating position.

    Conclusion

    In short, don’t assume that simply adopting a multi-cloud architecture will yield enormous cost savings just because you can easily move workloads from one cloud to another to take advantage of pricing differences. In most cases, you can’t.

    What you can do, however, is leverage your relationships with competing cloud providers to negotiate discounted enterprise pricing agreements. And the more portable your workloads are, the better able you’ll be to obtain serious cost savings while simultaneously enjoying the flexibility and agility that multi-cloud architectures stand to offer.

  • Zenhub Brings Generative AI to Software Project Management

    Zenhub this week made available an edition of its project management platform for software engineering teams that makes use of generative artificial intelligence (AI) to summarize reports and identify bottlenecks to help streamline DevOps workflows.

    Aaron Upright, the co-founder of Zenhub, said the company plans to work with each Zenhub AI customer to enable them to securely use their personal data to train an AI model using the ChatGPT platform to make DevOps teams more productive.

    For example, DevOps teams will be able to use historical sprint data to identify bottlenecks more easily. Natural language processing (NLP) will also enable teams to reduce the impact of project label sprawl by making it easier to associate related projects regardless of naming conventions.

    Overall, the quality of data being collected will also improve story point estimations, noted Upright.

    It’s still early days as far as the usage of generative AI within the context of project management applications is concerned, but the potential AI has to transform the role of project managers is already apparent as more data is collected and analyzed by AI models. Rather than reacting to changes to project schedules as they occur, it should become easier for project managers to proactively surface issues that might have previously delayed or derailed a software development effort.

    Project managers should also be able to better track the return on investment (ROI) metrics for any given project as changes occur, added Upright.

    In theory, project managers augmented by AI models should be able to simultaneously manage more complex development efforts at levels of scale that previously would have been unachievable. The challenge is making sure project managers have visibility into the suggestions being made by AI platforms. Often when presented with conflicting data they will make up an inaccurate response, also known as a hallucination.

    However, the narrower the range of data used to train an AI model the more accurate it tends to become. The critical issue many organizations will initially face is vetting the quality of the data being used to train the AI model. In addition, organizations will also need to make sure that no biases have been inadvertently injected into an AI model because the data used to train it was either flawed or inaccurate.

    Ultimately, the amount of toil that project managers regularly experience should decline considerably as AI continues to advance. The expectation should be that AI will soon be pervasively applied across multiple project management applications. The race is now on to deliver on that promise.

    In the meantime, project managers might want to start assessing which tasks they perform daily that are likely to be automated. This will enable them to add higher levels of value by having the time needed to focus more on strategic imperatives. After all, every minute spent checking to see whether data is accurate is one less minute spent understanding what needs to be done to affect a better project management outcome.

  • 80% of Bosses ‘Regret’ Stopping WFH ¦ PSA: Disable STS!

    80% of Bosses ‘Regret’ Stopping WFH ¦ PSA: Disable STS!

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Rethinking return-to-office mandates and a ridiculous, ancient Windows bug. (more…)

  • Low-Code and AI: Friends or Foes?

    Low-Code and AI: Friends or Foes?

    The lines are becoming blurred between low-code and new artificial intelligence (AI). Historically, low-code/no-code platforms have introduced software development automation through graphical user interfaces, enabling professional and citizen developers alike to quickly build workflows and generate applications. But the rise of large language models (LLMs) represents an existential threat to the status quo of low-code development.

    So, are generative AI and low-code friends or foes? Since new generative AI can produce complex code in milliseconds given natural language prompts, the barrier to software development has never been lower. On the other hand, enterprises already have ingrained low-code practices and operations, which may stick around for a while. With that in mind, there are plenty of ways AI and low-code can coexist.

    Below, we’ll consider if AI and low-code are diametrically opposed tools or complementary forces. We’ll see how AI and low-code are merging and consider the benefits of using them in tandem.

    Unleashing the Power of AI

    LLMs, like OpenAI’s GPT-3.5 and GPT-4, can deliver impressive software generation capabilities, such as creating code snippets and even complete programs given natural language prompts. Because of these remarkable capabilities, it makes sense that low-code platforms should be a bit wary of AI.

    Artificial intelligence can actually deliver on some of the original promises of low-code, like software democratization, enhanced agility and filling the widening skills gap. “ChatGPT could allow users to make more significant changes to applications, potentially enabling organizations to achieve far more than with low-code and in half the time,” wrote Romy Hughes on DevOps.com.

    There are also plenty of ways LLMs could accelerate the DevOps side of the cloud-native equation. In addition to code generation, AI could help generate configuration manifests, run code tests and perform cybersecurity analysis. While AI can’t fully replace the nuance of human oversight, it can indeed automate more and more elements of the software development life cycle.

    Congruence Between Low-Code and AI

    Although it appears likely that AI will replace low-code, there are actually many opportunities for symbiosis between the two concepts. Rather than eradicate low-code platforms entirely, LLMs will likely become more embedded within them. We’ve already seen this occur as low-code providers like Mendix and OutSystems integrated ChatGPT connectors. Microsoft has also embedded ChatGPT into its Power Platform as well as integrated GPT-driven Copilots into various developer environments.

    “Low-code and AI on their own are powerful tools to increase enterprise efficiency and productivity,” said Dinesh Varadharajan, the chief product officer at Kissflow. “But there is potential for the combination of both to unlock game-changing automation for almost every industry. The power comes from the congruence between low-code/no-code and AI.”

    There is also the opportunity to train bespoke LLMs on the inner workings of specific software development platforms, which could generate fully-built templates upon natural language prompts. This would make the LLM more custom-built and relevant to the platform at hand and ease development fluidity. In addition to integrating existing LLMs, another potential synergy is that low-code solutions could help automate the training of new custom AI models.

    Tips to Keep In Mind

    As with any technology solution, the choices should be driven by concrete business outcomes. Start by defining the business objectives and let that determine the technological solutions to arrive at the outcomes you desire. In the context of low-code and AI, this might equate to deciding between which models to support.

    Next, enterprises must avoid risk when using low-code platforms. And on the AI side of the coin, platforms will have to navigate the data privacy and legal complications of using public LLMs. Like any new technology, AI and low-code will require governance, said Varadharajan. “Organizations should step in to standardize the tools, processes and DevOps cycles. Only certain AI-powered tools should be approved for development where there are agreeable security, privacy and IP protection agreements in place.”

    He also explained that a focus on change management would be paramount in reaping the benefits of both strategies. “I suspect that the greatest barrier to adoption and implementation will be change management,” he said. “Enterprise users are accustomed to certain ways of working and can be resistant to change, making them unlikely to embrace AI-powered low-code. Leaders should anticipate this and incorporate change management into their AI/low-code adoption strategy.”

    Closing The Semantic Gap

    Low-code came on the scene to help citizen developers create applications without requiring advanced technical experience. Yet, low-code still requires knowledge of the development platform as well as specific programming terminologies and formulas. But now, since generative AI behaves in response to natural language, it has the potential to instantly bypass this barrier.

    “Generative AI closes this semantic gap,” said Varadharajan. “Generative AI serves as a translator, and users no longer have to understand exactly how the system works.”

    As more AI pair programmers come onto the market, expectations are rising within all areas of software development, including low-code platforms, to integrate these advanced models. If leaders can navigate the technical change effectively, the outcomes will likely significantly increase agility and output.

    “Ultimately, all developers will end up saving time delegating repetitive tasks to these AI-powered pair programmers,” said Varadharajan.