devopsy.kinsta.cloud

Category: DevOps Practice

  • Technical Debt: Don’t Buy Buzzwords

    Technical Debt: Don’t Buy Buzzwords

    It is absolutely true that the only constant in IT is change. No sooner do a mass of us get the ‘next big new shiny thing’ implemented than people start telling us how much we need the next ‘next big new shiny thing.’ Often, that next big new shiny thing is actually helpful, and we feel (sooner or later) compelled to implement it. Sometimes, the next big new shiny thing is not very useful at all, and yet far too many of us implement it anyway.

    Not naming names here, but you’ve all got technical debt that I would classify as “bling” or “keeping up with the competition” functionality. It’s there; you’re paying for it and/or to maintain it, and yet it provides little value. Sometimes, you’re even forbidden from removing it because it is some exec’s pet project or some corner department is actually using it. You’d just have to replace this version of the next big new shiny thing with a different version.

    And I’m here to tell you: Stop. When considering new technology, the very first thing to do is build a list of the problems you are trying to solve and then describe scenarios where those problems crop up. Then compare the next big new shiny thing–be it features in an existing product or a new space/product completely–to how it solves real needs. People are the absolute worst about this with open source. “It’s free, so let’s try it out.” It. Is. Never. Free. And it is a rare team that tries it out and then removes it if it doesn’t work. Most of the time, they’re off to the next project too quickly to do that level of cleanup.

    SBOMs and SCA are ‘next big new shiny things’ of the recent past that actually help you clean up test/pilot garbage from the latest bout of next big new shiny things. So are containers since you can spin them up, play with the toys and then take them down. I am surprised at the number of teams out there who do not do this, but that’s changing pretty quickly. Use them; it’ll save a ton of cleanup time and a lot of technical debt.

    But most importantly, only buy what you absolutely need. We’ve been dropping an ever-increasing number of tools into the development environment for a decade, and those tools do not (yet) maintain themselves. There is infrastructure cost, possibly licensing cost and staff time. Don’t waste it; focus on what is literally most important.

    And that might mean putting your foot down. We in IT have been loathe to do that since Agile started, but telling a C-level that they don’t need an AI to create new drink recipes (or whatever the current generative AI boardroom craze is) is in the best interests of the company. Focus on systems that help do the work or that protect what does do the work.

    You’re still rocking it, so if rocking the boat a bit in the process causes problems, you might just be at the wrong company or in the wrong role. Achieve, but achieve meaningful results.

  • Dell Taps Microsoft to Simplify Hybrid Cloud Computing

    Dell Taps Microsoft to Simplify Hybrid Cloud Computing

    Dell Technologies, in collaboration with Microsoft, today unveiled a platform that tightly integrates an on-premises IT environment with the Azure cloud.

    Caitlin Gordon, vice president of multi-cloud product management for Dell Technologies, said the Dell APEX Cloud Platform for Microsoft Azure is the first instance of a hybrid cloud computing platform designed specifically to address that requirement using a Premier Solution of the Microsoft Azure Stack hyperconverged infrastructure (HCI) platform that Microsoft added to its portfolio today.

    The Premier Edition of Microsoft Azure Stack HCI makes available an instance of that platform that provides a more turnkey management experience than the existing editions, said Gordon.

    In the face of increased economic headwinds, more organizations are looking to lower the total cost of managing IT by reducing the number of control planes that need to be managed. Each platform that an IT team typically supports today has its own control plane that requires IT staff to manage it. Reducing the number of control planes creates an opportunity to reduce the total headcount currently required to manage multiple IT platforms.

    It also serves to streamline workflows in a way that enables DevOps teams to reduce the current level of friction encountered when managing multiple IT platforms, noted Gordon.

    At the core of Microsoft’s approach to hybrid cloud computing that Dell is embracing is Arc, a management framework that makes it possible to manage Azure cloud instances alongside on-premises IT environments. In terms of the ability to manage hybrid cloud computing environments, Microsoft is significantly more advanced than any other cloud service provider, said Gordon.

    It’s not clear whether IT organizations are embracing HCI platforms running an instance of the same core stack of software that Microsoft relies on to provide Azure services. If IT organizations expect to lower the cost of managing IT, there is no doubt they will need to modernize on-premises IT infrastructure. The older the platform, the more expensive it becomes to automate using various third-party frameworks.

    Regardless of the approach, IT teams need to reconcile the need to invest in automating workflows that span multiple IT platforms. Over time, those investments will reduce the total cost of IT, but getting the required funding to start that process will require IT teams to make a strong case for increasing the return on investment (ROI).

    In the meantime, the number of workloads running both in the cloud and at the network edge is only going to increase. At the same time, the bulk of existing workloads continue to run in local data center environments. Most IT teams will be required to find additional ways to automate the management of all those environments simply because the cost of adding additional IT staff to manage highly distributed computing environments as scale will otherwise be prohibitive.

    As such, the issues that IT teams are facing today may be a matter of not if the management of IT will become more automated but how soon.

  • Fortifying the Castle: A Quest to Secure the SDLC

    Fortifying the Castle: A Quest to Secure the SDLC

    Every business is a software business today. But as the pressure to churn out new applications and features grows, so do the chances of developers making mistakes. Tackling these challenges doesn’t just require more diligent developers, it requires continuous education across the software development life cycle (SDLC).

    To borrow a metaphor from Arthurian legend, it’s a never-ending battle against hidden risks and formidable adversaries. It will require security champions to share their wisdom and bring order to the kingdom.

    A Kingdom Under Siege

    These are dark times for those fighting the good fight. The threat landscape is a wild and unruly place where risk is everywhere, and adversaries often have the upper hand. They have the advantage of surprise and are masters at hiding in the shadows. But the threat is real. One vendor blocked over 146 billion threats last year alone.

    Many of these attacks take advantage of vulnerabilities in code. It’s a problem made more acute by the widespread use of open source components by today’s developer teams. One estimate suggested that last year alone, developers made 3.1 trillion requests for these components from the top four open source ecosystems. Yet many of these components contain vulnerabilities. According to the Linux Foundation, the average application development project features 49 vulnerabilities across 80 direct dependencies. Worse are the indirect dependencies that are far harder to track and, by some estimates, account for six in every seven project vulnerabilities.

    That makes software supply chain attacks and breaches far more likely, especially as threat actors are actively placing buggy components in upstream libraries with the hope they’ll be downloaded en masse. It’s also getting more likely because developers are coming under increasing pressure to deliver. It’s claimed that over half of developers handle a hundred times more code than they did a decade ago. And most are under pressure to write code faster. This increases the chance of mistakes happening, which in turn can cause significant financial and reputational damage.

    Fighting Back

    The answer to these mounting challenges has traditionally been to focus on “shifting left” or moving testing and scanning earlier in the SDLC. To ensure products are designed with security from the outset, it’s essential to follow “secure-by-design” principles. However, this is only half the picture. Scanning for vulnerabilities is certainly important, but even better is to ensure teams are building more robust code from the outset. Prevention is always cheaper and more effective than cure.

    This is where continuous secure coding education comes in. Continuous because technology and market demands are always changing. In this dynamic world full of risk, a one-and-done approach simply doesn’t cut it. Further, courses should be extended beyond the realm of the developer to every member of the SDLC team: From project management and UX specialists to QA, product management and beyond. All must share a common goal with a common responsibility to produce more secure code. Some will be security champions who share best practices with other stakeholders. But everyone must be pulling in the same direction.

    Time to Fortify the Castle

    So once the kingdom has assembled its diligent developers and security champions, what’s next? With the knowledge and skills imparted through continuous training, plus additional automated checks, real progress can be made to enhance security and resilience.

    If you’re familiar with the OWASP Top 10, you’ll recognize concerns such as server-side request forgery, misconfiguration, using vulnerable components and shortcomings in security logging, cryptography and software integrity. A stronger focus on foundational security practices like the principle of least privilege, separation of concerns and layered defense can mitigate these risks. Among the most prevalent threats are injection attacks, which include SQL injection and cross-site scripting. However, by using tools and having developers well-versed in strategies like input validation, parameterized queries, data cleansing and secure LDAP queries, these threats can be effectively addressed.

    Above all, it’s important to remember that everyone has a part to play in fortifying the castle, in protecting the kingdom from a mounting and formidable agglomeration of threats. That means, as a baseline, that everyone should be getting some form of continuous secure coding training. There’s no time to waste.

  • Atlassian Strengthens Jira Navigation and Integration

    Atlassian Strengthens Jira Navigation and Integration

    Atlassian today made it simpler to navigate the Jira Software and Jira Work Management project management applications as part of an ongoing effort to make it simpler for DevOps teams to collaborate with other stakeholders of application development projects.

    Megan Cook, head of product for Atlassian, said the ability to share release dates across multiple calendars, overviews that aggregate views of and summarize multiple projects along with command palette and importer tools make it simpler for, for example, marketing teams and other individuals outside of a DevOps team to keep track of application delivery schedules.

    In addition, Atlassian has tightened integration between Jira and Confluence, a wiki-based collaboration application, and a previously launched Atlassian Intelligence capability that infuses generative artificial intelligence (AI) capabilities will also soon be added to Jira Work Management alongside existing support for Jira. There will also be connectors for Jira Work Management to integrate with Atlassian Admin, Atlassian Analytics, Access and Data Lake offerings, along with advanced security features.

    Finally, Atlassian is adding support for a design tool developed by Figma that can now be directly installed in Jira.

    Collaboration between application development teams and the rest of the business is becoming more crucial as organizations increasingly realize how much they depend on software to drive revenue. One of the primary reasons Atlassian is investing in generative AI is to make it simpler for anyone to understand the status of any given project and the downstream impact any change to a delivery schedule is likely to have.

    Generative AI, of course, has already moved from being considered advanced technology to a set of capabilities that most end users will soon expect to be embedded within every application. One of the primary benefits generative AI provides is it makes a range of applications originally designed for specialists, such as a software engineering team, more accessible to a wider range of end users.

    It’s not clear how much generative AI will change the relationship between DevOps teams and the rest of the business, but with increased visibility, there should be a greater appreciation for the challenges developers and DevOps teams face. Any member of an organization should be able to plainly see, for example, why more resources need to be allocated to a specific project to ensure that an application is delivered on time.

    At the same time, application developers will find project management processes are about to become less disruptive as it becomes simpler to automatically import relevant data from the tools and platforms they use directly into a project management application such as Jira.

    One way or another, software engineers should expect that as generative AI continues to evolve, the divide between them and the rest of the business will narrow. There may be times when that level of additional scrutiny may feel burdensome, but on the whole, it should make it easier for DevOps teams to get the resources required to achieve any given goal. After all, the root cause of any given delay to a project will soon be plain for anyone to see.

  • 3 Steps to Secure Your CI/CD Pipelines

    3 Steps to Secure Your CI/CD Pipelines

    More and more software teams are waking up to the fact that their CI/CD pipelines are prone to risk. These pipelines often interface with various toolsets and automation, which may be prone to misconfigurations and abuse. This is not to mention the potential for insecure code being pushed through this funnel and external factors that threaten to circumvent the pipeline.

    In recent years, these risks produced some CI/CD tooling breaches—concerns that gained high-level attention recently after a joint CISA and the NSA alert about the importance of securing CI/CD pipelines. “This is something that moves the tectonic plates of the industry,” said Daniel Krivelevich, former founder of Cider Security and current CTO of AppSec at Palo Alto Networks.

    I reconnected with Krivelevich, the ‘godfather of CI/CD security,’ to reevaluate the CI/CD threat landscape and understand how IT should respond. According to Krivelevich, we’re now seeing more maturity around CI/CD security, both in terms of recognizing that these risks exist as well as emerging frameworks to help engineering teams respond. He shared a general three-step framework organizations can use to secure the CI/CD pipeline and surrounding areas, which we’ll explore below.

    The Evolving Threat Landscape

    The traditional approach to application security (AppSec) used to be simpler. Defenders could implement more standard controls to make their code more secure, said Krivelevich. However, throughout the years, the software engineering process has transformed dramatically. It’s become faster, dynamic and reliant upon third-party frameworks. “The entropy of the engineering ecosystem is very high,” he said.

    This paradigm shift has introduced a slew of new risks, which requires rethinking since most traditional security solutions deal solely with AppSec. “Software engineering is a big part of what makes the business tick,” said Daniel. Therefore, having a common language and understanding of this area is crucial to respond to evolving risks that threaten business operations.

    A Three-Step Framework For CI/CD Security

    Krivelevich is involved with creating the OWASP Top 10 CI/CD Security Risks; therefore, he has excellent insight into the types of vulnerabilities that most engineering practices and their CI/CD pipelines are facing. His three-step framework for CI/CD security, which Palo Alto Networks has applied in practice, looks to holistically secure not only the pipeline itself but also internal and external factors.

    1. Security in the Pipeline (SIP)

    SIP can be thought of as the traditional AppSec problem space. This involves ensuring developers are not shipping anything inherently insecure into production. Therefore, whatever code flows through the CI/CD pipeline must be vetted to ensure it has no security flaws or misconfigurations. Of course, this is easier said than done, given that teams are juggling more technologies and frameworks than ever, each of which has different knobs and requires unique security scanning capabilities.

    2. Security of the Pipeline (SOP)

    This area has to do with the security of the software delivery chain itself. Attackers may attempt to breach these pipelines by running malicious code within the pipeline or stealing credentials to CI/CD tools to harm the system. Poisoned dependencies, access management holes or insufficient credential hygiene could all be doorways to disrupting a CI/CD process. Therefore, SOP focuses on the security posture of the actual systems and tools that compromise the software delivery chain.

    3. Security Around the Pipeline (SAP)

    However, even if SIP and SOP are secure, what if hackers can bypass the pipeline altogether? That would render even a perfect set of controls null and void. Therefore, SAP is necessary to ensure that attackers can’t push code directly into production. It’s good to see the bigger picture so that everything that reaches production actually originates from the pipeline.

    To deploy SAP effectively, Krivelevich recommended leveraging both detective and preventative measures. You need detective measures to issue alerts when anomalies occur, such as an artifact deployed by a human account instead of a service account. You also need preventative measures that set the proper branch protection rules across all repositories. For instance, this could be a rule that no single developer can publish to production unless approved by two reviewers.

    The Role of AI in Software Security and CI/CD

    By using both detective and preventative measures, you can detect when settings are disabled or abused and have better configurations across all stages of the software delivery chain. But what other tactics can be used to secure CI/CD? For example, does machine learning have any merit in this area?

    Well, Krivelevich described AI as “both a blessing and a curse.” Attackers are already using AI to operate much faster and in a much more agile way. And unfortunately, he viewed the engineering ecosystem as the new path of least resistance. “I expect the power of AI will be used by sophisticated attackers who are motivated to get access to the ‘crown jewels’ by abusing the engineering ecosystem,” he said.

    On the defensive side, Daniel doesn’t see a specific opportunity for deploying AI to protect CI/CD. That being said, there’s a lot of potential for security builders to utilize AI to advance their efforts and accelerate the pace at which they detect anomalies, which could help respond more quickly to emerging threats.

    Final Thoughts on CI/CD Security

    The recent chatter around CI/CD threats appears to be garnering more attention around securing this niche area of agile software development. To thwart CI/CD attacks, it will be necessary to assess the settings of systems, understand their technical natures and analyze them against an attacker’s perspective, Krivelevich explained. Therefore, understanding what realistic attacks can be carried out will help build measures to correct these gaps.

    In doing so, the SIP, SOP and SAP descriptions serve as a solid reminder of what needs to be addressed when attempting to secure the software delivery process and the supply chain at large. Code that goes through the pipeline needs to be free from vulnerabilities, and the channel itself must be vetted for gaps that could be abused. We also need to consider the possible existential threats if the entire process can be undermined.

  • Digma Leverages ML to Bring Observability Insights to IDEs

    Digma Leverages ML to Bring Observability Insights to IDEs

    Digma has launched a namesake platform the provides developers with continuous feedback from observability data that surfaces directly within their integrated development environment (IDE).

    Digma CTO Roni Dover said the Digma Continuous Feedback platform leverages machine learning algorithms to enable developers to easily analyze their code at runtime to identify issues, anomalies and regressions. Digma Continuous Feedback removes the need to consult a separate dashboard that requires developers to log into an observability platform.

    In fact, the reason developers often don’t make use of the data that observability platforms provide to write better code is that it’s not readily accessible at the time they are writing code, noted Dover.

    In general, it’s become much easier to collect logs, metrics and traces by using open source OpenTelemetry agents that can be embedded within software libraries. The Digma Continuous Feedback platform applies machine learning algorithms to that data to provide developers with insights on improving code in real-time, said Dover.

    The ultimate goal is to make it simpler for IT teams to distinguish when, for example, a software component actually needs more memory or is simply inefficient, he added. Those insights can be applied to code written by developers or code generated by an AI platform.

    Whether code is written by a human or generated by a machine, quality is often in question. Developers with varying levels of experience will naturally write code that can differ substantially in quality and efficiency. At the same time, developers may be asked to fix code someone else wrote; the original author no longer works for the organization, noted Dover. In either use case, the Digma Continuous Feedback platform immediately surfaces issues that will enable organizations to set higher baselines for code quality, he added.

    That baseline is especially critical as more code starts to be generated by generative AI platforms based on general-purpose large language models (LLMs) trained using code samples of varying quality collected from across the web. Developers will be able to immediately determine any issues that may arise should they choose to incorporate that code within an application.

    Developers, of course, don’t deliberately set out to write bad code, but the tools that enable them to identify issues are not easily accessible. In fact, too many developers tend to view observability platforms designed for IT operations teams as being overly complex, noted Dover. The Digma Continuous Feedback platform takes that issue off the table by identifying issues without increasing the level of cognitive load developers are expected to carry, he added.

    Eventually, thanks to the rise of machine learning algorithms and generative AI platforms designed specifically to write high-quality code, the overall state of software engineering will improve. The issue is determining the best way to get the benefits these technologies provide directly to the developers who write code—an issue that is at the heart of so many DevOps challenges.

  • SolarWinds Adds Service Management Platform to Portfolio

    SolarWinds Adds Service Management Platform to Portfolio

    SolarWinds has added a service management capability to its portfolio as part of an effort to make it simpler for IT teams to align support services with specific functions.

    At the same time, SolarWinds has updated its SQL Sentry observability tool for databases and DataOps workflows to add query-level wait statistics along with a revamped web portal and dashboard for tracking the overall health of a database environment.

    SolarWinds Enterprise Service Management (ESM) makes it possible for IT teams to manage IT services based on the ticketing systems, knowledge bases, service portals and request catalogs available for specific departments such as marketing or human resources.

    Kevin Kline, senior staff technical marketing manager for SolarWinds, said that as IT management continues to evolve, there is a greater need to streamline and optimize workflows based on the insight from observability platforms. As a result, there is now a need to apply observability more broadly to include database platforms alongside DevOps and other IT workflows, he noted.

    The overall goal is to eliminate the blame game that results when IT platforms are managed in a more siloed fashion, added Kline.

    Most IT teams are still relying on monitoring tools to track a set of predefined metrics in the hope that an alert will enable them to proactively address an issue before it leads to a major disruption. However, as IT environments become more complex, there is a growing need for observability platforms so IT teams can launch queries and surface issues that predefined metrics aren’t likely to identify. Initially, observability platforms were embraced by DevOps teams, but it’s rapidly becoming apparent that this capability needs to be applied to every IT process. In effect, organizations are on the cusp of democratizing observability, noted Kline.

    Achieving that goal will also become simpler thanks to the rise of machine learning algorithms capable of predicting issues and generative artificial intelligence (AI) tools that will make it simpler to craft queries.

    In the meantime, there is already no shortage of observability platforms, but the SolarWinds approach is different in that, in addition to DevOps workflows, the company has integrated its platform with multiple database platforms to provide a more comprehensive approach, said Kline.

    It’s not clear just yet how observability platforms might impact the way IT teams are structured, but the need for specialists such as database administrators (DBAs) isn’t likely to go away anytime soon, noted Kline. Instead, the level of collaboration across various IT teams should substantially improve.

    In the meantime, IT teams might be well-advised to define an observability strategy today before multiple teams start implementing approaches that might be optimized for a relatively narrow range of use cases. After all, trying to reconcile insights generated by multiple observability platforms may very well defeat the purpose of investing in observability in the first place.

  • Why Data Silos Are Killing Your Developer Productivity

    Why Data Silos Are Killing Your Developer Productivity

    Every company is at risk of fostering data silos. In fact, a study conducted by Forrester Consulting for Airtable across employees in the U.S. and the UK revealed that, on average, knowledge workers spend 30% of their week looking for the information they require to do their job and the difficulty in finding and accessing data is the top reason why they feel disengaged from work. What causes essential data to be inaccessible in the workplace? We will explore the root of modern data silos, why they drain developers’ productivity and how to break away from these silos with better observability in your organization.

    What are Data Silos?

    A data silo is a collection of data held by a group that is not easily or fully accessible by other groups in the same organization.

    Data silos can be a byproduct of organizational structure. When different departments or business units in an organization operate independently, they develop their own way of collecting, storing and managing their data. The processes to access that data from other business units can be cumbersome or even nonexistent. Sometimes, the individuals responsible for the data will even be against sharing it for fear that it would be misused or misunderstood outside of their particular unit. The difficulty in accessing information then leads to independent data collection from other business units and ultimately creates other data silos and multiple sources of truth.

    Data silos can also happen during times of growth for an organization. New tools are necessary to support the growing needs of the business and are added to the list of tools already in use. Over time, this list grows, and systems that were designed to operate in isolation can create data silos by limiting the ability to integrate with other systems. A recent survey of marketing organizations by Emarsys showed that the surveyed organizations are using an average of 91 marketing cloud services. These 91 tools undoubtedly create data silos unless they are fully integrated together or into a central system.

    Why are Data Silos Killing Your Developer Productivity?

    Data silos aren’t only slowing your developers down by limiting their access to the data needed for development. They also put a lot of extra work on their plates. And it goes without saying that this additional time spent on data management reduces the time available for improving your product.

    Management of Redundant Data
    Multiple teams in the organization storing their data separately means increased workloads for developers, who need to update and maintain separate copies of the same data.

    Inconsistent Data Quality
    Data gaps or quality issues happen more frequently since different parts of the organization have their own standards for collecting, cleaning and validating data. This can lead to development delays or errors in the product.

    Time-Consuming Integrations
    Developers have to code a lot of integrations to connect all the different tools your organization uses and keep the data flowing between them.

    Inefficient Collaboration
    When different teams work in silos, the chances of misunderstanding are greater, leading to development delays and misaligned priorities.

    Difficulty in Data Governance
    Maintaining high standards of data privacy, security and compliance is time-consuming when the data is spread out in different silos and can create costly regulatory risks.

    Steps Leaders Can Take to Break Down Data Silos

    Fortunately, there are steps that you can take to break down the data silos in your organization, relieving your developers at the same time. Each step may have its own set of advantages and challenges, so the solutions you choose ultimately depend on your organization’s needs and objectives.

    Create a Unified Data Strategy
    Set clear goals and standards for data collection, storage, management and analysis at the company level. You should also implement data governance and security policies.

    Adjust the Culture
    Foster a culture of collaboration and data sharing across the company by encouraging teams to share data, insights, and best practices across different departments. You can achieve this through regular communication, training and incentives for cross-functional collaboration.

    Establish Cross-Functional Teams
    Bringing together members of different departments to collaborate on data-related projects can prove invaluable. These teams should have a shared understanding of the organization’s data strategy and should be empowered to make decisions about data collection, analysis and sharing.

    Invest in Data Integration and Interoperability
    Invest in tools and technologies that promote data integration and interoperability across different systems and departments. Adopt standard data formats, implement APIs and data connectors or use data integration platforms to make observability collaborative. Make sure that the tools you choose to add to your company have various native integration capabilities to avoid custom integrations as much as possible.

    Congrats, you now know all about data silos and how to break them down! The next step for you is to identify the data silos in your company and put a plan in place to get rid of them. Your employees and coworkers will thank you!

  • 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

    R&T Deposit Solutions
    New York, New York
    DevOps Engineer
    $145,000 to $175,000

    Indeed.com

    Caterpillar
    Chicago, Illinois
    DevOps Engineering Manager
    $141,000 to $178,000

    SimplyHired.com

    Takeda Pharmaceutical
    Boston
    Machine Learning Infrastructure/Platform Engineer
    $130,000 to $186,000

    LinkedIn

    M&T Bank
    Wilmington, Delaware
    DevOps Manager
    $123,000 to $206,000

    CareerBuilder.com

    Fidelity Investments
    Westlake, Texas
    DevOps Engineer
    $120,000 to $160,000