Category: Features

  • 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 as part of an effort to better serve our audience.

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

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

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

    Monster.com

    AppZen
    San Jose, California
    Software Engineer
    $165,000 to $190,000

    Indeed.com

    Safeway
    Pleasanton, California
    Lead DevOps Engineer
    $147,500 to $206,600

    Dice.com

    Amazee Global Ventures, Inc.
    Broomfield, Colorado
    DevOps Engineer
    $140,000 to $150,000

    SimplyHired

    WEX, Inc.
    Remote
    DevOps Engineer
    $127,000 to $169,000

    LinkedIn

    Apple
    Newport Beach, California
    Site Reliability Engineer/DevOps
    $115,000 to $177,000

  • Lineaje Unfurls Platform for Creating and Managing SBOMs

    Lineaje Unfurls Platform for Creating and Managing SBOMs

    Lineaje this week unfurled a platform for creating and managing the software bills of materials (SBOMs) that are increasingly mandated by enterprise IT organizations and government agencies.

    Fresh from raising $7 million in seed funding, Lineaje CEO Javed Hasan said the SBOM360 platform provides a simpler way to manage all the SBOMs that will soon inundate organizations.

    The SBOM360 platform makes it possible to use a search engine to discover all the components of an application and all the dependencies that exist within it, including vulnerabilities, and indicators of compromise (IOCs) in seconds, said Hasan. The company then adds fingerprinting technology that enables the platform to attest to the authenticity of the entire software supply chain, he added.

    While there is no shortage of tools for creating SBOMs, there are not as many platforms that enable DevOps teams to both create and manage them. In the wake of an executive order issued by the Biden administration requiring federal agencies to have an SBOM for all the software they use, interest in SBOMs to better secure software supply chains has significantly increased. However, very few organizations have a process in place that enables them to operationalize all the SBOMs that might be created.

    More challenging still, the pace at which software is being updated has accelerated to the point where many SBOMs are likely to be outdated. The only way to keep pace with that rate of change is to rely on a platform designed from the ground up to dynamically create SBOMs in seconds, noted Hasan.

    Finally, IT organizations are now being held more accountable for legacy software often polluted with vulnerabilities that need to be remediated, he added. As such, organizations need a tool that makes it simpler to identify vulnerabilities within the context of an SBOM.

    It’s not clear whether greater awareness of the need for SBOMs is translating into concrete action, but the expectation is that more organizations will soon be following the lead of the federal government by requiring them. That shift will naturally bring a lot of additional pressure to bear on DevOps teams. Historically, organizations tended to allow developers to aggregate software components without always checking to see if they are compromised. Cybercriminals are becoming increasingly more adept at injecting malware into software components in the hope that malware will find its way into any number of downstream applications.

    Regardless of the approach an organization takes to better secure software supply chains, more rigor is being applied to how software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on open source software downloaded from a repository, are now at an end. The expectation now is the developer will be held accountable for the integrity of all components used within an application as organizations move to implement additional processes to more rigorously review code before it is deployed in a production environment.

  • flox Unveils More Accessible Instance of Nix Framework

    flox Unveils More Accessible Instance of Nix Framework

    This week, flox launched a more opinionated implementation of the open source Nix framework that programmatically automates package management and system configuration.

    Fresh from raising an additional $16.5 million in funding, flox CEO Ron Efroni said the company will also make an enterprise edition of its namesake flox framework available later this year.

    The Nix framework has been available since 2003 and provides DevOps teams with a portable, fully isolated development, test and production environment along with a catalog and tools for managing software packages. There are more than 5,000 contributors to the platform, but Nix is based on a unique programming language that many DevOps teams have found challenging to master.

    The flox framework provides a higher layer of abstraction for invoking Nix, and provides a set of guardrails to make the framework more accessible to a wider range of DevOps teams, said Efroni.

    That approach will make it easier to share development environments and packages across teams, machines, individual developers and entire organizations. The framework also provides visibility into the software bill of materials (SBOM) for applications used in production environments to enable real-time vulnerability management and detection without scanning, noted Efroni. That capability makes it easier to discover dependencies spanning multiple architectures; many organizations today still try to track dependencies using spreadsheets and tools that don’t serve to make DevSecOps processes simpler to manage, he added.

    It’s not clear how many organizations are using Nix today, but Efroni said that as software development management continues to become more complex across multiple platforms and architectures, there is a clear need for a different approach to enabling portability at scale. The biggest obstacle is overcoming the psychological biases many DevOps teams have developed toward Nix over the last two decades, he noted. A more opinionated framework should reduce the overall fear factor associated with Nix, noted Efroni.

    Regardless of the frameworks employed, it’s become apparent that DevOps teams are struggling under the weight of all the code they must manage, much of it written in multiple programming languages. Many organizations that embraced DevOps early are now finding the platforms they deployed have become challenging to manage and maintain. As application environments become more complex, there is a need to modernize DevOps workflows. Less clear is whether those efforts might be focused on, for example, containers and serverless computing frameworks versus a framework such as flox that is designed to span multiple architectures and platforms.

    It might be a while before IT organizations develop a unified approach to application development and deployment, given all the preferences of individual development teams. However, with the rise of platform engineering, it’s apparent more organizations are trying to strike a balance between developer freedom and the need to reduce the total cost of DevOps. That cost continues to rise as additional software architectures and platforms are employed.

    In the meantime, flox plans to contribute to both Nix and its own more opinionated version of the framework in the hopes of one day making it easier to achieve that goal.

  • Atlassian Extends Scope of Jira Project Management Portfolio

    Atlassian Extends Scope of Jira Project Management Portfolio

    At the Atlassian Presents: Unleash event today, Atlassian announced it is adding a Jira Product Discovery application to its portfolio. Jira Product Discovery makes it easier for organizations to keep track of the ideas that drive software development initiatives.

    At the same time, Atlassian is making available Jira workflow and toolchain templates to make it simpler for software development teams to extend the scope and reach of the project management software they use to track those projects. Rather than each organization developing these templates, Atlassian is now providing them in a way that allows organizations to customize and extend them as they see fit.

    Finally, Atlassian also announced that an existing Jira Work Management tool will be made available for free through March 2024.

    Megan Cook, head of product for software teams at Atlassian, said these additions will make it easier for organizations to collaborate around software development projects that businesses increasingly depend on to drive revenue. The overall goal is to make it easier for multiple stakeholders of the projects to more easily collaborate with software developers that rely on Jira to manage those projects, she added.

    These latest offerings are part of an ongoing Atlassian effort to enable organizations to simplify collaboration and enable organizations to embrace value stream management (VSM) without having to acquire a dedicated platform. In some cases, organizations may decide to adopt a dedicated VSM platform, but a project management application should make it simpler for everyone in an organization to keep track of how software development projects are impacting the business, noted Cook.

    It’s not clear just how many businesses are aligning their internal processes around DevOps workflows, but as more of them realize how dependent they are on software, there is a clear need to collaborate more efficiently with software development teams. In fact, many organizations are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices. In some instances, updates to software are now being delivered faster than many businesses can absorb given the impact those changes have on digital processes.

    The irony is many business executives used to routinely complain about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. There may even come a day when organizations will need to restructure as the walls that once separated various fiefdoms become more porous.

    One way or another, the way organizations are managed is evolving in the digital age. Organizations are employing software to pivot more frequently as business conditions evolve. Each new idea can not only be tracked but also quickly evaluated for feasibility given the level of software development resources required, noted Cook. The challenge and the opportunity is as much about changing the culture of an organization as it is about modernizing the processes used to build and deploy software.

  • Report Affirms Continued AWS Cloud Dominance

    Report Affirms Continued AWS Cloud Dominance

    A report published this week by Wiz, a provider of a cloud security platform, found more than half of organizations (57%) are using multiple clouds, with 22% currently using three or more platforms.

    However, the report also noted that 72% of all workloads are running on the Amazon Web Services (AWS) cloud. Among organizations that have more than one cloud platform, Microsoft Azure (41%) is the most common secondary platform (41%), while Google Cloud Platform (GCP) is the most used tertiary platform among organizations employing two or more clouds (44%).

    The report also noted 9% of AWS customers use managed database servers, compared to 87% in GCP and 82% in Azure. However, over 91% of companies also have non-managed database servers running in a cloud. In total, only 6% of companies use managed database servers exclusively, compared to 90% using a mix of managed and non-managed database servers, the report finds.

    The most widely deployed databases are PostgreSQL, Redis and MySQL, with 90% of organizations running at least one instance of a PostgreSQL server.

    Scott Piper, principal cloud security researcher for Wiz, said the report makes it clear that despite gains by Microsoft and Google, AWS remains the most dominant cloud service provider. Even after a decade, rival cloud service providers have not been able to overcome the first-mover advantage that AWS continues to enjoy. In many cases, a second or third cloud is being employed only because a single development team preferred it or an IT team assumed responsibility for it when their company acquired another organization using it, noted Piper.

    However, while most organizations have multiple accounts per cloud service provider, the report also found that the bulk of the application workloads are managed via only a handful of accounts, he added. That suggests more organizations are subject to higher levels of disruption in the event of an outage than many of them may realize, said Piper.

    One of the reasons so many organizations have a narrow range of accounts, of course, is they simply don’t have enough personnel. In fact, a general skills shortage also tends to limit the number of cloud platforms organizations might otherwise employ.

    Multiple cloud platforms also tend to exacerbate cybersecurity challenges. With the introduction of each additional cloud service, the overall size of the attack surface that needs to be defended expands. The Wiz report found 47% of organizations have at least one database or storage bucket publicly exposed to the internet. It can take less than 13 hours for cybercriminals to discover and access an exposed bucket with a guessable name, noted Piper.

    More challenging still are the number of application programming interfaces (APIs) that need to be secured as cloud service providers continue to add new services, he added.

    Ideally, organizations should be adopting a framework to harden privileges, encryption, authentication and connectivity and improve hygiene, otherwise known as PEACH, said Piper.

    Regardless of the approach to cloud computing, it’s apparent there’s still a long way to go before organizations are ready to embrace hybrid cloud computing spanning multiple clouds.

  • Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome this week made available an integration for the continuous integration/continuous delivery (CI/CD) platform from CircleCI that promises to make it simpler to secure mobile applications before they are deployed.

    As a provider of a platform for securing mobile applications running on iOS and Android platforms, Appdome provides a runtime application self-protection (RASP) platform that, among other capabilities, provides code obfuscation, mobile data encryption, jailbreak detection, root detection, man-in-the-middle attack prevention, on-device anti-malware, anti-fraud, anti-cheat and anti-bot capabilities.

    The platform is now integrated with the Circle CI/CD platform via the Orb framework created by CircleCI to simplify integrations with third-party tools.

    Karen Hsu, senior vice president of mobile DevOps and security solutions for Appdome, said the Appdome Build_2Secure Orb for CircleCI is an example of a series of integrations the company plans to make involving DevOps tools and platform that will make it easier to apply DevSecOps best practices to the deployment of mobile applications. That’s critical because it’s not uncommon for teams using different DevOps platforms and tools to be involved in the development of the same application, she noted.

    A recent Appdome survey suggested consumers are about to force the DevSecOps issue for providers of mobile applications regardless of how mature their processes are. A full 94% of respondents said they would promote a brand if the mobile apps protected them versus 68% that said they’d abandon brands that offered no protection.

    Securing mobile applications is especially challenging because once an application is compromised, it’s relatively trivial for cybercriminals to also inject malicious code into other applications running on a mobile device. There are no automated remediation capabilities, so the best defense is to isolate applications in a way that prevents malware from executing in the first place, noted Hsu. At a time when it’s already clear cybercriminals will be using artificial intelligence (AI) platforms to launch attacks, organizations will not have the time required to remediate vulnerabilities before malware is activated, she added.

    That Appdome approach provides the added benefit of reducing tensions between developers and cybersecurity teams that otherwise would be requesting immediate fixes to mobile applications that have been compromised, noted Hsu. As more mobile applications are built and deployed, the overall goal should be to enable both teams to work collaboratively together without unnecessarily disrupting each other’s workflow, added Hsu.

    It’s not clear what percentage of the applications being built and deployed today are destined to run on mobile devices, but securing those applications clearly presents some unique challenges. Many of those applications are deployed on consumer-grade devices attached to wireless networks that are not especially secure. Cybercriminals are increasingly targeting these devices not only to access sensitive data but also because they often provide a gateway through which the rest of an IT environment can be compromised.

    The simple truth of the matter is, sadly, DevOps teams need to assume that most mobile applications are going to be running in the cybersecurity equivalent of a hostile environment where the odds are considerably stacked against them.

  • Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    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: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

  • Cisco Bets on OpenTelemetry to Advance Observability

    Cisco Bets on OpenTelemetry to Advance Observability

    Cisco today announced a technology preview of a Cisco Full-Stack Observability Platform based on instances of open source OpenTelemetry agent software being advanced by the Cloud Native Computing Foundation (CNCF) to collect metrics, event, logs and distributed traces. The Cisco Full-Stack Observability platform will be available in June 2023.

    The platform, announced at a Cisco Live EMEA event in Amsterdam, Netherlands, will combine the capabilities of multiple Cisco platforms and technologies into a single offering.

    At the same time, the company also announced the bidirectional integration between its existing Cisco AppDynamics application life cycle management (ALM) tool and the Cisco ThousandEyes network monitoring platform beginning in April.

    Finally, Cisco is making available a Business Risk Observability offering to provide business risk scoring. Business Risk Observability combines capabilities of its Kenna Risk Meter tool—gained when Cisco acquired Kenna Security in 2021—with the ability to monitor business transactions through Cisco AppDynamics to provide better visibility into application security. In addition, Cisco has integrated its Panoptica application programming interface (API) management security tool and the Talos threat intelligence platform within the Business Risk Observability Platform.

    Carlos Pereira, a Cisco fellow and chief architect for strategy, incubation and applications at Cisco, said Cisco is moving to narrow the historic divide between application development and cybersecurity teams to enable organizations to adopt DevSecOps best practices and make it simpler to prioritize the remediation of vulnerabilities that are likely to have the most impact on the business.

    Like most providers of observability platforms, Cisco is betting that more applications will be instrumented as OpenTelemetry software continues to mature. Cisco is now the single largest contributor to this project, noted Pereira.

    OpenTelemetry will also play a critical role in improving application security as more applications become instrumented, he noted. In fact, a recent Cisco AppDynamics survey found more than three-quarters of respondents (76%) believed that DevSecOps is essential for organizations to effectively protect against a multi-stage security attack. However, only 43% reported their organization had started implementing DevSecOps workflows.

    Observability, of course, has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that make it simple to investigate anomalies indicative of an issue that could disrupt an application environment. Most of those observability platforms are infusing those platforms with machine learning algorithms to surface those anomalies as part of an effort to augment the capabilities of a DevOps team.

    Regardless of the approach to observability, many organizations will soon be trying to determine whether to rely on existing monitoring tools that make it possible to track pre-defined metrics. In some cases, there may still be a need for that legacy approach to managing IT. Still, in other instances, it may be possible to rationalize some of those platforms in favor of a more advanced approach that relies on a more advanced approach to achieving observability.

  • 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 as part of an effort to better serve our audience.

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

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

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

    LinkedIn

    Apple
    San Diego, California
    Site Reliability Engineer (SRE) – Video
    $115,000 to $217,500

    SimplyHired

    ScientiaMobile
    Reston, Virginia
    Senior DevOps Engineer
    $110,000 to $150,000

    Monster.com

    Larsen & Toubro Infotech Ltd.
    Farmington, Connecticut
    DevOps Engineer
    $110,000 to $130,000

    Indeed.com

    TherapyNotes.com
    Remote
    Senior DevOps Engineer
    $105,000 to $155,000

    Dice.com

    MRoads
    Dallas, Texas
    Platform Engineer – SRE
    $100,000 to $120,000

  • Blameless Integrates Incident Management Platform With Opsgenie

    Blameless Integrates Incident Management Platform With Opsgenie

    Blameless this week announced it has integrated its namesake incident management solution with the Opsgenie alerting platform from Atlassian.

    Aaron Lober, director of product marketing for Blameless, said the Blameless platform is now integrated with both Opsgenie and PagerDuty, the two most widely used platforms for managing alerts.

    Blameless provides an incident management platform that normalizes data collected from a wide range of DevOps tools and platforms to determine how best to respond to different incident classes. Armed with those insights, it then becomes possible to quickly assemble the best team to respond to an event, said Lober.

    That capability reduces stress because Blameless also surfaces recommendations for resolving incidents based on the data it has collected, he added.

    The Blameless platform is tailored to organizations that have hired site reliability engineers (SREs) to manage IT operations using DevOps best practices, noted Lober. The overarching goal is to eliminate rote processes that, over time, conspire to burn out incident management teams that often experience high turnover rates, he added.

    Opsgenie has been connected to the Blameless platform via the service catalog and alerting functions. Blameless users responding to or managing an incident can escalate issues to any teams defined within Opsgenie. The service catalog and alerting data generated throughout the life cycle of an incident is automatically captured and stored on the Blameless Incident Timeline. That capability makes it possible to identify appropriate service owners and the escalation protocol that was followed by that team. Blameless can also display the actual user name of each responder that has been notified.

    When accessing Blameless via Slack or Microsoft Teams, Opsgenie can automate both when an incident channel is created and pre-select relevant services that should be made available. Alerts can also be manually triggered using commands from the Blameless chatbot for those who prefer to trigger alerts from within Slack or Teams themselves.

    As IT environments become increasingly more complex, more organizations are making a concerted effort to apply DevOps best  practices to incident management. The goal is to reduce downtime and increase overall resiliency at a time when organizations are more dependent on software than ever. As part of that effort, IT teams should identify the repetitive processes that span multiple incidents and then move to automate as many as possible.

    In the longer term, it’s not clear what impact artificial intelligence (AI) will have on incident management. At some point, though, IT teams should expect their efforts to be augmented by machine learning algorithms capable of identifying issues before they balloon into a major crisis. However, there will always be some human intervention required to manage incidents for the foreseeable future, noted Lober.

    In the meantime, most IT teams should continue to expect the unexpected at a time when IT environments have never been more dynamic and change multiple times a day.