devopsy.kinsta.cloud

Category: News

  • Developers Continue to Prefer Remote Work

    Developers Continue to Prefer Remote Work

    A survey found 83% of developers are working remotely more than half of the time, with more than three-quarters (76%) reporting they have maintained or increased the frequency of remote work in the last year. In fact, three in five respondents (62%) work remotely at least 90% of the time.

    The survey, published by Netlify, a provider of a platform for building the front end of Web applications using the Jamstack framework, polled 6,544 developers in the Jamstack community and found more than half (55%) would quit their jobs if forced to return to an office.

    It’s not clear how much remote work has become a de facto requirement for organizations to attract and retain developer talent, but it’s clear that, in the wake of the COVID-19 pandemic, the dynamic between developers and the organizations that employ them has completely changed.

    Netlify CEO Mathias Biilmann said regardless of industry, it’s apparent that DevOps teams are going to continue to need to make adjustments to foster collaboration across distributed teams. Senior managers will find it increasingly challenging to manage workflows across a workforce that is also witnessing a lot of turnover, he noted. A third of survey respondents (33%) reported having changed jobs in the last year. It’s not clear how much a lack of interaction in the office might be impacting innovation, but at a time when demand for developer talent far exceeds the available supply, organizations will need to adjust to what appears to have become a permanent new reality.

    At the same time, the Netlify survey noted the pace at which emerging technologies are being embraced continues to rapidly evolve—perhaps because of rather than in spite of remote work. For example, the survey found 70% of developers reported using a serverless computing framework in the last year. Nearly half (47%) are also experimenting with edge dynamic sites, the survey found. It’s clear that company culture, at least in terms of technology adoption, plays a large role in attracting developer talent.

    Overall, 96% of survey respondents noted that JavaScript is their primary choice of programming language, with 21% of developers now specifically using TypeScript to build applications. The React framework for building applications, meanwhile, is being used by 71% of developers, with 47% reporting they employed the Next.js version of that framework. Other React frameworks gaining traction include Vite (32%), Sveltekit (15%), Astro (11%), Remix (10%) and SolidJS (6%).

    However, emerging Web3 technologies have yet to gain traction. While 7% to 10% of developers have tried out technologies such as cryptocurrencies and NFTs, only 3% reported using these technologies regularly. A total of 42% of developers either didn’t know what Web3 was or didn’t care about it, while 31% felt negatively about it, the survey found.

    Ultimately, the primary reason organizations invest in DevOps is to increase developer productivity. The challenge is that, as developers embrace more tools and platforms for building applications, the process of deploying those applications becomes more challenging to manage effectively. One way to achieve that goal is to separate frontend and backend software development processes to enable developers to focus more on writing code rather than managing the arcane processes required to deploy it.

  • OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

    OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

    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: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

  • Momento Launches Elastic Cloud Caching Service

    Momento Launches Elastic Cloud Caching Service

    Momento this week emerged from stealth to launch an elastic Serverless Cache platform that promises to improve the performance of applications running on databases deployed in the cloud while simultaneously reducing costs.

    Fresh from raising $15 million in seed funding, Momento CEO and co-founder Khawaja Shams said Serverless Cache gives IT teams access to a serverless computing framework for accessing cache memory that can be used to improve the interactivity of applications.

    Cache is, of course, already widely employed to improve the performance of applications running on databases in the cloud. However, organizations today are required to provision excess cache memory to address performance workload peaks. That approach, over time, conspires to increase the total cost of cloud computing, he noted.

    A serverless cache makes it possible to more easily share an elastic pool of memory that can be invoked in seconds via an application programming interface (API) that is itself invoked by adding five lines of code to an application. The Momento cache service can then handle millions of transactions per second that can be spread across multiple applications, said Shams.

    The Momento Serverless Cache service also automatically manages hot-keys, maintains high cache hit rates and keeps tail latencies low.

    Organizations that are already using Momento on either the Amazon Web Services (AWS) or Google Cloud Platform (GCP) include CBS, NTT Docomo and Wyze Labs, Shams said.

    In general, there’s a lot more scrutiny of cloud costs in the wake of the economic downturn, noted Shams. More IT teams are starting to take note of the fact that various cloud-native platforms enable them to more efficiently consume cloud resources, he added.

    The simple truth is that far too many organizations are managing cloud resources in much the same way they managed on-premises IT environments. Capacity is being dedicated to virtual machines to ensure application availability with even less regard for cost because the perception is that the cloud makes it easy to throw hardware resources at any issue. The challenge is the bill for those cloud resources tends to add up at the end of every month. Cloud database services, in fact, are among the most expensive to consume, noted Shams.

    It’s not clear how much organizations will optimize the consumption of cloud resources in the weeks and months ahead, but it’s clear more supervision is going to be required. Organizations have historically let developers provision resources in the name of agility with little to no regard for cost. Now that finance teams are looking to, at the very least, make sure cloud resources are optimally consumed, there will undoubtedly be more reviews of cloud spending patterns.

    In the meantime, many organizations may also decide to accelerate the rate at which they are embracing cloud-native technologies to optimize that spending. One of the more compelling attributes of Kubernetes clusters and serverless computing is they make it easier to scale compute resources up and down as required to eliminate the need to overprovision cloud infrastructure. The challenge, of course, is that the cost of acquiring and mastering those technologies remains significant.

  • Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

    Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

    Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

    Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

    Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

    One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

    In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

    In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

    It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

    One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

  • Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium this week added the ability to detect libraries and software packages with known vulnerabilities within a software bill of materials (SBOM) manifest that can then be used to automate remediation of endpoints running vulnerable code.

    Pete Constantine, senior vice president of product management for Tanium, said the Tanium Software Bill of Materials (SBOM) module provides IT teams with both the ability to discover where vulnerable code is running in real-time and automatically apply any required software patch.

    The Tanium SBOM tool examines the contents of individual files wherever they reside in IT environments to make it simpler to immediately discover where, for example, vulnerable instances of the Log4j log management software or OpenSSL software for securing communications are running. Today many IT teams are spending weeks trying to track down every potential instance of code each time a new vulnerability is discovered.

    Once those vulnerabilities are discovered, IT teams can then opt to use a Tanium Patch tool to remediate vulnerabilities or use other Tanium management tools to kill specific processes or uninstall applications, noted Constantine.

    Awareness of the need for SBOMs to secure software supply chains has increased sharply in the wake of a series of high-profile cybersecurity breaches. However, few organizations have the tools in place to operationalize the data collected in SBOMs that are essentially little more than a list of components employed to build an application. The goal is to enable IT teams to decide whether to go ahead and deploy an application based on the level of threat the vulnerabilities included represent.

    It’s unlikely that vulnerabilities will ever be completely eliminated from applications running in production environments, but it’s clear there is a need to be able to quickly identify issues based on the level of severity any vulnerability represents. The trouble is that an SBOM is only the first step toward achieving the level of remediation automation that is required to address vulnerabilities discovered in applications after they have been deployed.

    Hopefully, all the focus on securing software supply chains will lead to a narrowing of the divide that has historically existed between cybersecurity and application development teams. Developers still need to create patches to fix issues, but overall the number of vulnerabilities that find their way into production environments should decline as more organizations embrace DevSecOps best practices before applications are deployed.

    In the meantime, however, given how much developers today reuse code, the odds are good multiple vulnerabilities have already been widely propagated across an application environment. In fact, the amount of technical security debt that organizations face today is simply staggering when considering the total number of potential vulnerabilities that need to be remediated. In the absence of IT automation capabilities, it might take the better part of a decade to resolve all those vulnerabilities.

    On the plus side, however, the tools and platforms required to automate remediations are now integrated with SBOMs that, at the very least, make pinpointing where vulnerabilities are located easier. The challenge now is defining a set of end-to-end processes that make fixing all those vulnerabilities a much less arduous task for all concerned.

  • Pulumi Adds Deployment Capability to IaC Platform

    Pulumi Adds Deployment Capability to IaC Platform

    At the Pulumi Cloud Engineering Days event, Pulumi announced today it has added a code deployment capability to its Pulumi Cloud platform for managing infrastructure-as-code (IaC).

    Pulumi CEO Joe Duffy said Pulumi Deployments will make it possible for DevOps teams to provision infrastructure and deploy applications via a single Git commit that can be invoked via an application programming interface (API) or graphical tool.

    A Git Push to Deploy capability allows DevOps teams to connect to any Git repository to drive deployments for a given project path, push to any given branch and set up GitOps workflows such as pull request reviews. Deployment actions include both updates and destroys in addition to providing drift detection and remediation capabilities.

    The Deployments and Automation API Pulumi developed also enables ephemeral code review environments, automatic cleanup and deployment orchestrations across multiple cloud platforms using a library of templates Pulumi provides. In effect, Pulumi is now providing a GitOps workflow out of the box, said Duffy.

    Pulumi has already integrated these capabilities with GitHub and plans to add support for GitLab, Atlassian Bitbucket and other DevOps platforms. The goal is to make it possible for DevOps teams to effectively manage ten times the amount of cloud infrastructure resources per engineer using GitOps workflows than is currently possible relying on IaC tools such as Terraform, said Duffy.

    As an alternative to Terraform, the Pulumi platform has been gaining traction because it makes it possible to more easily centralize the management and provisioning of infrastructure using a set of embedded guardrails. One of the major issues enterprise IT organizations are encountering these days is the number of misconfigurations created when developers use tools like Terraform to provision infrastructure on their own. Those misconfigurations often lead to, for example, ports being left open and cybercriminals exfiltrating data. In the wake of a series of high-profile breaches, more organizations are now reviewing the security of their software supply chains including how infrastructure is provisioned by embedding policy-as-code into DevOps workflows.

    At the same, organizations are also keenly interested in increasing the productivity of DevOps teams during an economic downturn that limits the number of IT professionals an organization can afford to hire, added Duffy.

    Pulumi claims there are now more than 5 million users of its platform spanning more than 1,000 organizations. Less clear is the degree to which organizations are embracing GitOps workflows to unify deployments on IaC and application code. As platforms make it easier to make that transition, the number of organizations using a more opinionated approach to DevOps should steadily increase.

    In the meantime, DevOps teams are going to be required to find ways to build and deploy safer applications faster. Much of the focus in recent years has been on accelerating application deployments with little regard for cybersecurity. Those days are clearly now coming to an end.

  • Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy announced today it has tightened the integration between its automated deployment platform and GitHub Actions continuous integration/continuous deployment (CI/CD) platform.

    Harsh Sabikhi, senior vice president of revenue for Octopus Deploy, said GitHub Actions for Octopus Deploy v2 adds support for a push-build-information-action capability GitHub added to its platform that enables DevOps teams to track commits, builds and issues. That information is now also synchronized with a DevOps Insights tool from Octopus Deploy that surfaces metrics based on the DevOps Research and Assessment (DORA) metrics defined by Google.

    Other capabilities added to the integration include support for semantic versioning release tags within workflows, job summaries and a revamped user interface that makes GitHub easier to access from within Octopus Deploy.

    Sabikhi said that while GitHub Actions provides some deployment capabilities, the automation platform created by Octopus Deploy automates application release management across multiple clouds and on-premises IT environments. GitHub Actions is optimized for managing CI processes within the context of a Git-based workflow emanating from a cloud service managed by GitHub, he added.

    The integration with GitHub Actions makes it simpler to extend those Git-based workflows across multiple deployment platforms, noted Sabikhi.

    GitOps is, essentially, a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform.

    As organizations embrace GitOps, however, many are finding it advantageous to more loosely couple CI and CD platforms. Integrated CI/CD platforms have been around now for more than a decade, but few organizations have been able to truly automate the delivery of applications using those platforms. Platforms such as Octopus Deploy have been created from the ground up to specifically manage deployments of applications. In addition to GitHub Actions, Octopus Deploy also provides integrations with multiple other CI platforms to enable DevOps teams to mix and match CI platforms as they best see fit, said Sabikhi.

    It’s not clear how many DevOps teams are willing to acquire a separate CD platform, but as applications become more challenging to build and deploy in the cloud-native era many organizations are revisiting the DevOps processes they used to build and deploy monolithic applications. The challenge is many of them have spent years defining workflows based on legacy CI/CD platforms, so there is a lot of existing inertia that would need to be overcome when adopting a dedicated CD platform.

    It’s clear that CD is finally becoming more achievable using platforms that automate much of the process. Each DevOps team will need to decide how many staff they want to dedicate specifically to managing those CD platforms; the pace at which applications are being deployed should accelerate as application release management becomes more automated.

  • Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera today announced it has extended its platform for collecting DevOps intelligence to include support for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    Opsera CEO Kumar Chivukula said as GitHub Actions is adopted more widely, there is a growing need to provide greater visibility into Git-based workflows in real-time. A GitHub Actions Insights module for the Opsera platform makes it possible to track key performance indicators (KPIs) across those workflows, he added.

    The goal is to make it simpler to make data-driven decisions about how best to optimize those workflows by identifying bottlenecks, noted Chivukula.

    The Opsera platform surfaces that intelligence by scanning all repositories and branches, including commit history, and generating alerts and notifications whenever KPI thresholds or compliance requirements are exceeded. DevOps teams can also use the platform to assess their overall DevOps maturity using a set of DevOps Research and Assessment (DORA) metrics defined by Google. Going forward, Opsera also plans to start surfacing metrics based on the Supply chain Levels for Software Artifacts (SLSA) framework for securing software supply chains also defined by Google.

    Platforms such as Opsera make it possible to apply analytics to DevOps workflows as they become more complex. The number of dependencies that exist between various application modules, for example, makes it exceedingly difficult for DevOps teams to manually identify the impact a delay in one project might have on any number of other downstream projects.

    In addition, many organizations are keen to discover what best practices should be adopted by other application development teams.

    Finally, many developers tend to use a repository as a dumping ground for all kinds of software artifacts, noted Chivukula. DevOps teams need an intelligence tool that makes it possible to identify which of those artifacts are the most essential to the business, he added. Otherwise, manually combing through a repository looking for artifacts becomes the DevOps equivalent of looking for a needle in a haystack, noted Chivukula.

    GitOps is essentially a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform. It’s not clear how much traction GitHub Actions is gaining at the expense of other CI/CD platforms, but for organizations that are relatively new to DevOps and already using GitHub as a code repository, it presents a path of least resistance.

    Regardless of why organizations adopt a DevOps intelligence platform, the need to optimize workflow across toolchains is becoming more pressing during an economic downturn. It’s becoming more clear that the cost of an application delivery delay directly impacts the level of revenue an organization generates in the age of digital business transformation.

  • InfluxData Delivers Revamped Database for Real-Time Processing

    InfluxData Delivers Revamped Database for Real-Time Processing

    InfluxData has made good on a promise to deliver a next-generation time-series database that enables observability and monitoring tools used by DevOps teams to ingest high volumes of data more cost-efficiently.

    In addition, for the first time, the latest iteration of the InfluxDB database supports the de facto standard SQL query language. Developers can run unlimited time-series workloads and contextualize data by any dimension without restrictions using SQL or existing tools such as the InfluxDB application programming interface (API), Flux scripting language or the InfluxQL query language

    Brian Gilmore, director of internet-of-things (IoT) and emerging technologies for InfluxData, said InfluxDB is now based on a columnar engine, dubbed IOx, that leverages the open source Apache Arrow memory format and the Rust programming language accessed via a multi-tenant InfluxDB Cloud service that company manages on behalf of application developers. Use cases that require processing large volumes of data such as metrics, events, traces and other high cardinality data can now be queried in milliseconds, he noted.

    The goal is to make this latest incarnation of InfluxDB available via a managed cloud service before providing IT teams with a version they can install themselves.

    The arrival of a revamped InfluxDB architecture comes as the amount of data being generated across application environments continues to rapidly expand. Many DevOps teams are especially struggling with ways to process and store all the data being generated by cloud-native applications made up of microservices generating a steady stream of logs, metrics and traces.

    InfluxData, of course, has ambitions for its database that go beyond application development and deployment environments. Edge computing platforms, for example, will increasingly process and analyze data in real-time at the point where it is generated and consumed. Similarly, applications infused with machine and deep learning algorithms will require databases that can process data at scale. Regardless of the use case, however, it’s apparent more IT teams will be embracing DataOps best practices alongside DevOps to manage data as applications are deployed and continuously updated.

    It remains to be seen how many observability and monitoring tools might embrace this latest iteration of the InfluxDB database, but it’s clear DevOps teams should expect to see major advances as the underlying databases upon which these platforms depend continue to evolve. The goal is to ultimately eliminate the tradeoff that now often occurs between how much data is collected and analyzed versus the cost of processing and storing it.

    In the meantime, DevOps teams will need to decide whether they want to manage databases themselves as more managed services become easier to invoke in the age of the cloud. Most database selections these days are made by development teams that aren’t especially eager to take on the tasks normally performed by a database administrator. A managed service essentially outsources responsibility for managing a database to a services provider instead of requiring IT teams to hire a DBA themselves.

    One way or another, however, the speed at which data can now be processed in real-time should sharply reduce the need to rely on existing and cumbersome batch-oriented approaches to processing data.

  • Nobl9 Simplifies SLO Identification

    Nobl9 Simplifies SLO Identification

    Nobl9 today added a Replay capability to its service level objectives (SLO) management platform that makes it simpler to collect the historical data a DevOps team needs to get started.

    Nobl9 COO Kit Merker said Nobl9 Replay makes service level indicator (SLI) data instantly available in minutes using 30 days of historical data collected from observability and application performance monitoring (APM) platforms. Previously, DevOps teams would have had to wait as long as a month before the Nobl9 platform could collect enough spreadsheet data to create a graph that identified the relationship between various services.

    Nobl9 now enables historical data to be merged with data collected in real-time to allow DevOps teams to view SLO charts and generate reports shortly after creating an SLO within a Git-based workflow.

    Nobl9 is trying to spur greater adoption of SLOs by making available an open source SLO specification that defines a common interface for constructing them that has garnered support from Dynatrace, Sumo Logic and others. SLOs, of course, are not a new idea; they have been used as a metric to track the performance of IT services for decades. However, as more microservices-based applications are built and deployed, it’s becoming more challenging to maintain SLOs across applications that have many more dependencies than legacy monolithic applications.

    The Nobl9 platform is designed to enable DevOps teams to employ an SLO-as-code approach that makes it simpler to gather the metrics that confirm whether SLOs are being achieved.

    It’s not clear whether reliance on SLOs has waned over the years or if application environments simply became too complex to track meaningful metrics. A recent survey conducted by Dimensional Research on behalf of Nobl9, however, found a full 94% of respondents that have or plan to implement SLOs intend to map them directly to business operations, with 91% reporting they expect that effort to improve decision-making. More than 80% also said their organizations are planning to increase the use of SLOs, with 87% indicating SLOs should improve overall microservices performance.

    The issue is that most organizations have limited visibility into their IT environments. The survey found less than half of respondents (46%) had visibility into all their IT environments. Only 45% and 35% claim to have visibility into containers and microservices, respectively. More than three-quarters (78%) said hybrid clouds make observability more difficult, even though 45% said they already employed 11 or more observability and monitoring tools. Trying to track SLOs using tools such as Grafana dashboards that DevOps teams need to set up and maintain is simply too difficult, noted Merker.

    As applications are increasingly constructed using services that drive digital business transformation initiatives, it’s now only a matter of time before SLOs are more widely tracked. That will enable DevOps teams to not only ascertain their current level of performance but also more easily work toward achieving their actual performance goals, he added.

    The challenge is that defining an SLO in a highly dynamic application environment where services are added and replaced with much greater frequency is often a lot easier than maintaining it.