devopsy.kinsta.cloud

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 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

    SiriusXM
    Associate Director for Software Delivery
    Deerfield Beach, Florida
    $157,000 or $250,000

    SimplyHired

    Nagarro
    Remote
    Senior Staff Engineer – DevOps
    $155,000 to $196,000

    Dice.com

    Engage Partners
    Davie, Florida
    DevOps Architect
    $130,000 to $160,000

    Indeed.com

    ServiceNow
    Orlando, Florida
    Staff DevSecOps Engineer
    $114,000 to $144,000

    Monster.com

    Swift Group
    Fort Belvoir, Virginia
    DevOps Engineer
    $80,000 to $180,000

  • New Relic Report Surfaces Spike in Amazon JDK Usage

    New Relic Report Surfaces Spike in Amazon JDK Usage

    An analysis of the Java applications observed by New Relic showed nearly one-third of organizations (31%) are using the Amazon Java development kit (JDK) compared to 28% using the Oracle JDK as more Java applications are built and deployed in the cloud.

    The report also found the number of Java applications running in containers is remaining steady year-over-year at 70%.

    Overall, the report published last week found more than 56% of applications are now using Java 11 in production, followed by Java 8 at nearly 33%. However, more than 9% of applications are now based on Java 17, representing a 430% growth rate.

    Jemiah Sius, director of developer relations for New Relic, said it’s clear that Java 17 is starting to gain traction in production environments. This is happening at a faster rate than previous releases of the venerable programming language as more cloud-native applications based on containers are being built and deployed, noted Sius.

    Regardless of the version of Java, it doesn’t appear developers are moving away from Java as they build cloud-native applications, noted Sius. Rather than requiring developers to learn a new programming language, it’s simply been more cost-effective to enable them to continue building applications using a programming language they already know.

    Java, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under open source licenses. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications being modernized. As a result, most organizations will continue to deploy Java applications everywhere from the network edge to the cloud.

    New Relic, of course, is betting that as more cloud-native applications are deployed, the need for an observability platform that addresses the needs of developers and IT operations teams alike will become more apparent.

    In general, most organizations are still in the early stages of achieving full-stack observability. A recent New Relic survey found only 27% of respondents have achieved full-stack observability and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.

    On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    The expectation is that that augmenting DevOps teams with observability tools and platforms that are increasingly being infused with artificial intelligence (AI) will reduce outages, even as cloud-native applications make IT environments even more complex than they already are. The issue is, however, those application environments are becoming more complex at a rate that is far exceeding the pace at which observability platforms are currently being adopted.

  • Mezmo Adds Free Community Plan for Managing Observability Data

    Mezmo Adds Free Community Plan for Managing Observability Data

    Mezmo this week added a free trial and a community plan for the Mezmo Telemetry Pipeline service to make it simpler for DevOps teams to store and manage the large amounts of telemetry data they are collecting.

    Mezmo CEO Tucker Callaway said as more DevOps teams embrace observability to minimize disruptions to application environments, they are struggling to manage the explosion of data being created. The Mezmo platform makes it possible to apply data engineering best practices to manage that data using a set of drag-and-drop visual tools, he added. A set of data transformation tools also makes it simpler to extract metrics embedded in the logs, summarize events and metrics and then forward those metrics to downstream platforms for analysis.

    The free edition of the platform makes it possible for organizations to begin to apply those capabilities without any upfront costs required, noted Callaway.

    It’s not clear to what degree DevOps teams may need to add data engineering to manage all the telemetry data being collected. It’s already apparent that the cost of storing and managing all that data is becoming a significant issue as more applications are instrumented. In fact, it’s nearly impossible to manage cloud-native applications without being able to observe interactions between the microservices used to construct them.

    Log management has always been a challenge, but with the addition of traces, the amount of telemetry data being collected to surface metrics has increased. The Mezmo platform makes it possible to set a daily or monthly hard limit on the volume of logs stored or, alternatively, set soft daily or monthly quotas that can apply throttling logic to ensure mission-critical log data will continue to flow.

    DevOps teams can also make use of soft limits to reallocate storage resources from one team to another based on how much log data might be generated for a specific amount of time.

    Reducing storage costs has naturally become a higher priority during challenging economic times, so there’s a lot more pressure for DevOps teams to be more efficient. Finance teams are reducing costs by, for example, applying quotas to the amount of storage resources being made available to individual DevOps teams. The days when cloud storage resources were made available indiscriminately are over.

    It’s not clear how quickly DevOps teams are embracing observability, but it is certain that relying on predefined metrics to monitor IT environments is no longer sufficient. DevOps teams need to be able to query telemetry data to, for example, identify bottlenecks that are often created by dependencies between microservices. The issue is striking a balance between the amount of data being collected and the cost of storing it all.

    Regardless of approach, observability is rapidly becoming a requirement for DevOps teams to succeed. In fact, there is already no shortage of observability platforms to choose from. The issue is that not every observability platform provider is equally concerned about the cost of storing all the data being collected.

  • Majority of Organizations Report Benefits From Low-Code Platforms

    Majority of Organizations Report Benefits From Low-Code Platforms

    Some IT departments are feeling the strain amid recent economic downturns. 2023 has already seen a disproportionately high degree of layoffs in the tech sector. As a result, there aren’t always enough software developers available to meet the demand. This has led some organizations to turn to new ways to upkeep morale and reduce burnout, retain productivity and do more with less.

    Low-code development is one solution that could help tackle rising application backlogs. Low-code/no-code platforms use reusable components to help engineers (and citizen developers) construct functional applications and internal workflows. Many teams report they are using low-code to rapidly deliver new features. A recent study from Microsoft found that 89% of CIOs and IT pros said low-code is effective in increasing efficiency.

    Microsoft Power Platform recently sponsored a study that surveyed 2,000 IT CIOs and IT professionals on their use of low-code platforms. According to the report, users benefitted from these platforms by modernizing legacy IT, improving efficiency and reducing costs, among other areas. Below, I’ll review some key takeaways from the Microsoft study and compare them with other perspectives.

    The Benefits of Low-Code Development

    The report showcased a slew of benefits from the use of low-code platforms. One is modernizing legacy applications—87% of CIOs and IT pros said low-code is very useful in helping their organizations modernize legacy applications. Solving the technical debt issue is top-of-mind, since 69% of IT leaders identified technical debt as a threat to innovation. Another key benefit is efficiency. The study found that developer efficiency with these platforms significantly increases over time, averaging 62% over three years.

    Low-code platforms are also a prime area to insert artificial intelligence and more automation into the software development process. Microsoft, which recently announced it was integrating ChatGPT into its Power Platform, reported that 87% of CIOs and IT pros said increased AI and automation embedded into low-code platforms would help them better use the full set of capabilities.

    Finally, a significant benefit is cost reduction. A full 87% of those surveyed said low-code is effective in helping reduce costs. These solutions could accelerate the completion of the software backlog, increasing efficiency and lowering the resources required to deliver. This comes at a time when cost optimization is critical to avoid rising cloud fees.

    How Are Companies Working With Low-Code?

    So, how are development teams actually working with these platforms? One common use case is improving data processes by streamlining integrations and having a centralized repository. In fact, 86% of CIOs and IT pros said low-code helped their organizations generate more accurate insights from their data. These data-driven insights have been used to help better serve customers and internal stakeholders.

    For example, ÖBB, an Austrian rail operator, leveraged a low-code platform to synchronize data and automate customer service inquiries with virtual agents. Other case studies report using Microsoft Power Platform for migration from legacy systems and reduced document processing lead time.

    Looking outside of the Microsoft report, however, not everyone is fully on board the low-code bandwagon. For example, the CEO of StackOverflow has expressed reservations because low-code platforms ultimately have a ceiling. With low-code, there’s a limit on customization, making it a less-than-ideal fit for experienced developers or technology-specific companies. Organizations must also mitigate the potential security repercussions of allowing business users to create applications, requiring new governance and policies. Low-code platform users may also fall victim to vendor lock-in and uneasy data retrieval—underscoring the need for open platforms with programmatic access.

    The Advantages of Low-Code Platforms

    Low-code solutions are a viable option to help clear items from the IT backlog, automate tedious processes and free up engineers to focus on more pressing matters. Some low-code/no-code tools also help democratize application development to those with different skill sets, thus bringing in new users to the development arena. And interest in low-code continues to pick up—Markets and Markets forecast a compound annual growth rate (CAGR) in the low-code development industry platform market of 28.1% to reach $45.5 billion by 2025.

    Naturally, the findings and case studies in this particular report are a bit skewed toward the benefits of using the Microsoft Power Platform. Nonetheless, it serves as an indication of the various advantages of low-code platforms. For more insights, you can read the full report here on the Microsoft Power Platform blog.

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp is adding templates and collaboration tools to make it easier to access generative artificial intelligence platforms such as ChatGPT from within its project management application.

    Haris Butt, head of product design for ClickUp, said ClickUp AI now includes pre-built department-specific prompts that any product managers, developers or designers can easily access rather than having to develop prompt engineering skills to engage a generative AI platform more effectively.

    The templates, for example, make it simpler to produce summaries of project timelines in addition to the ability to automatically generate a whiteboard that lists tasks that need to be finished to complete a project.

    In the longer term, ClickUp is also moving toward developing its own large language model (LLM) using its own data to provide a generative AI experience specifically optimized for project management, added Butt.

    ClickUp is embedding AI into project management applications as part of an effort to eliminate drudgery, added Butt. One of the primary issues that makes project management challenging is that navigating workflows can be challenging, especially for stakeholders that might not be as well versed in, for example, how a Gantt chart flows.

    It’s still early days as far as generative AI is concerned, but it’s already apparent that a wide range of templates are being developed to make it simpler to invoke these platforms. The need for project managers to become well-versed in all the nuances of prompt engineering techniques to optimize generative AI queries is likely to be limited.

    In fact, the general expectation is that every application will eventually include templates for invoking generative AI capabilities. Less clear is the impact that should have on productivity. In the case of DevOps teams, however, many tedious project management tasks should become increasingly automated.

    Generative AI will, of course, soon be employed across the entire DevOps workflow. Many of the tasks that have historically conspired to make DevOps processes tedious will be automated. In fact, many application developers are already using AI to test and review code. DevOps teams that have historically advocated ruthless approaches to automation are likely to be at the forefront of AI adoption.

    There are, of course, concerns about the accuracy of generative AI platforms such as ChatGPT that have been trained using data that hasn’t always been verified. As a result, it’s possible that some of the results being surfaced by these platforms should be reviewed by humans before being acted on. However, LLMs trained on narrower ranges of validated data will soon become commonplace. As those AI advances are made, the accuracy of generative AI platforms that are optimized for specific use cases will increase.

    In the meantime, DevOps teams should be more concerned about being left behind than about how generative AI impacts their employment prospects. There is no doubt generative AI will transform DevOps workflows along with a wide range of processes. The issue now is determining where DevOps teams can add value—and where machines can’t—in an era where IT environments are becoming more complex with each passing day.

  • Device42 Brings Power and Carbon Emission Tracking to IT Asset Management

    Device42 Brings Power and Carbon Emission Tracking to IT Asset Management

    Device42 today made available a power and CO2 Summary Dashboard to its agentless platform that employs machine learning algorithms to discover and track IT assets.

    Raj Jalan, Device42 CEO, said the dashboard makes it possible for IT teams to combine the tracking of assets and associated dependencies with a capability that enables them to reduce power consumption costs and levels of carbon emissions.

    It’s not clear yet how carbon emission tracking will be integrating into IT management frameworks, but as sustainability becomes a more pressing issue, it’s only a matter of time before IT teams will be required to monitor power consumption and associated carbon emissions more closely, said Jalan.

    The Device42 dashboard simplifies that task by identifying carbon emissions by location, business unit, vendor or application. Armed with that data, it then becomes possible to consolidate servers and applications or move workloads to more efficient platforms, added Jalan.

    Arguably, the biggest challenge when it comes to managing IT infrastructure is the number of organizations that are still using spreadsheets to do so. The Device42 approach to discovery and assessment uses the application programming interfaces (APIs) exposed by cloud services providers and IT vendors. Once mapped, it then becomes possible for IT teams to use a search function to uncover, for example, dependencies between multiple services.

    In theory, it should be possible for DevOps teams to also programmatically implement policies based on the Device 42 data to move workloads in way that reduce IT infrastructure costs. Over the years, many organizations have lost track of how workloads have been deployed in, for example, cloud computing environments—only to discover a surprise expense at the end of the month.

    In fact, one of the hottest segments of IT these days is the emergence of financial operations (FinOps) as a discipline to control cloud computing costs. Fundamentally, FinOps is the discipline that promotes a shared responsibility for an organization’s cloud computing infrastructure and costs. Rather than having disparate procurement teams working in silos to identify and approve costs, business, financial and IT leaders establish policies and best practices for usage that are programmatically enforced.

    It’s still early days as far as the adoption of FinOps is concerned, but adding that capability first requires a deep appreciation for what IT assets are being used to run which workloads. From there, it then becomes possible to not only optimize usage but also reduce both electricity costs and carbon emissions.

    Of course, the tracking of carbon emissions right now is a bigger issue in Europe and elsewhere than it is in the U.S. However, a global framework for trading carbon credits is now impacting IT teams as organizations look to minimize their carbon footprints. Sustainability has become an economic issue.

    In the meantime, DevOps teams should expect that soon, power consumption and carbon emissions will be added to the list of metrics they are measured on.

  • Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    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: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)

  • InfluxData Makes Processing Observability Data at Scale More Efficient

    InfluxData Makes Processing Observability Data at Scale More Efficient

    InfluxData today made available an update to its open source time series database that can now analyze metric, event and trace data in a single datastore with unlimited cardinality in terms of how they are aggregated.

    The company is now making available a single-tenant instance of InfluxDB as a managed service alongside its already-existing multi-tenant cloud service that is based on a serverless architecture.

    Finally, InfluxData also announced that later this year it will make available InfluxDB 3.0 Clustered and InfluxDB 3.0 Edge to provide a curated version of the database that organizations can deploy themselves where they best see fit.

    InfluxData CEO Evan Kaplan said InfluxDB has been developed to support a wide range of emerging applications that require access to time series data, including the observability platforms core to DevOps workflows that require visibility into metrics, events and trace data.

    Over the past three years, InfluxDB has been revamped to run on a columnar engine, dubbed IOx, that leverages the open source Apache Arrow memory format and written in the Rust programming language. Kaplan said that approach makes it possible to continuously ingest, transform and analyze hundreds of millions of time series data points per second without limitations.

    At the same time, InfluxDB takes advantage of high compression object storage to reduce the total cost of storing all that data. It also provides interoperability with Open Data Architecture (ODA) to integrate with data lakes based on open source platforms such as DataFusion, Flight SQL and Parquet that are being advanced by the Apache Software Foundation.

    The arrival of version 3.0 of InfluxDB comes as many DevOps teams are starting to struggle with the amount of observability data being generated. DevOps teams want to be able to move beyond monitoring a set of pre-defined metrics and query data in a way that enables them to surface anomalies indicative of a potential issue before there is a major disruption to an application service.

    One of the major challenges today is the tradeoff between how much data is collected and analyzed versus the cost of processing and storing it. InfluxDB provides a mechanism for analyzing high cardinality data involving metrics, events and traces cost-effectively.

    Observability is, of course, only one of several use cases for a time series database capable of processing data in near-real-time. As organizations embrace digital business transformation initiatives, they need to be able to process data in near-real-time at the point where it is being created and consumed. Those applications won’t necessarily replace existing applications based on batch-oriented processing but, over time, they create two distinct classes of applications that process data in fundamentally different ways. The challenge, as always, will be defining the DevOps workflows required to manage applications running on multiple distinct types of architectures.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.