devopsy.kinsta.cloud

Author: Mike Vizard

  • Nebulon Unveils Hybrid Cloud Computing Platform

    Nebulon Unveils Hybrid Cloud Computing Platform

    Nebulon has emerged from stealth to launch a hybrid cloud computing platform that enables workloads to be processed in the cloud while data continues to be stored on a local application server.

    Company COO Craig Nunes said the Cloud-Defined Storage platform employs PCIe cards embedded with a Nebulon Services Processing Unit (SPU) based on an ASIC to connect local storage systems to a cloud-based control plane dubbed Nebulon ON that can span Amazon Web Services (AWS) and Google Cloud Platform (GCP) services.

    The PCIe card is installed in an application server residing in a local data center, where it connects to solid-state drives (SSDs) installed on the server. The Nebulon SPU offloads compression, encryption, deduplication, erasure coding, snapshots and data mirroring.

    The Nebulon SPU also transmits storage, server and application metrics to Nebulon ON, where machine learning algorithms are applied to surface recommendations to improve performance.

    Nunes said both Hewlett Packard Enterprise (HPE) and Supermicro have already agreed to resell the Cloud-Defined Storage platform.

    At its core, the Cloud-Defined Storage platform takes hyperconverged infrastructure (HCI) to another level. Instead of combining compute and storage in a local data center, however, compute processing is shifted to the cloud, said Nunes. That approach, he noted, makes it possible to take advantage of inexpensive compute resources in the cloud without losing control over data.

    In addition, Nunes noted, the Cloud-Defined Storage platform ensures application service levels are maintained while reducing costs by eliminating the need to transfer massive amounts of data into and out of the public cloud.

    Organizations that work within highly regulated industries can now take advantage of cloud resources while continuing to meet compliance requirements, he added.

    Finally, the Nebulon Cloud-Defined Storage platform can support both monolithic and microservices-based applications regardless of the type of virtual machine or container employed.

    At a time when many organizations are under increased pressure to reduce the total cost of IT, there’s a lot more interest in ways to leverage cloud computing to reduce costs. However, for many organizations, moving data into the cloud is problematic for a host of performance, security and compliance issues.

    A hybrid cloud computing architecture that doesn’t require data to be stored or moved into and out of a cloud could provide a way for organizations to re-evaluate their overall cloud computing strategies. Organizations beyond those in highly regulated industries could conclude they would prefer to retain control over their data.

    Cloud service providers are, of course, banking on massive amounts of data being stored in the cloud. They have long argued that as the amount of data stored in the cloud exponentially increases, the more sense it makes to deploy applications in the cloud as close as possible to that data. Each new application deployed in the cloud then increases the amount of data gravity that cloud exerts on other application deployment decisions.

    It’s not likely hybrid cloud platforms such as the Nebulon Cloud-Defined Storage system will completely reverse that trend. However, it does signal that data gravity in the cloud may not be as inexorable a force as many cloud service providers have long assumed.

  • Eclipse Foundation Touts Jakarta Progress

    Eclipse Foundation Touts Jakarta Progress

    The Eclipse Foundation today published the results of survey of 2,180 software developers that finds over half of respondents (55%) have adopted Java/Jakarta EE 8.

    In addition, the Eclipse Foundation is making available an update to the Jakarta Enterprise Edition (EE) specification that will move away from the javax namespace to embrace jakarta namespaces for all components.

    Jakarta EE 8 is essentially Java EE 8, which Oracle agreed would become open source software when it transferred ownership last year to the Eclipse Foundation. The transition from Java EE to Jakarta nomenclature remains a work in process.

    The Eclipse Foundation finds the use of Java technologies is in a state of flux across the board. For example, adoption of Java 11 now stands at 28%, while Java 14 adoption is at 11%, according to the survey. That compares to 64% that are still employing Java 8.

    Spring/Spring Boot at 44% adoption continues to be the leading framework for building cloud-native applications, compared to 35% using Jakarta EE and 16% for Red Hat Quarkus, a framework that runs natively on Kubernetes.

    Usage of Eclipse Che, an open source integrated development environment (IDE) for building applications on Kubernetes, now stands at 11%, the survey also finds.

    Mike Milinkovich, executive director of the Eclipse Foundation, said it’s clear organizations are now employing multiple frameworks to build Java applications, given a 13% drop in reliance on Spring/Spring Boot from last year’s survey results.

    However, the survey also finds that overall, the use of Java to build microservice applications has declined to 39% from 43% during the same period. That drop may reflect both the complexity of building microservices-based applications, given the fact that 25% of survey respondents said they are using Java to build monolithic applications, said Milinkovich.

    At the same time, some organizations may be opting to lift and shift existing monolithic Java applications into the cloud in response to the COVID-19 pandemic, he said, noting once redeployed, those organizations may then opt to modernize those applications using microservices.

    With access to many local data centers limited during the pandemic, many organizations may have decided the most prudent option was to lift and shift Java applications as they are than re-engineer them first, he added.

    There are currently 12 frameworks officially that are compatible with Jakarta EE 8, which Milinkovich said is indicative of the continued relevance of Java technologies for building applications both inside and out of the cloud. Now that Java is available as open source software, the level of innovation surrounding Java platforms will also accelerate, he said.

    There is still a large base of developers that rely on Java and by extension Jakarta to build enterprise applications. However, IT organizations now routinely employ a wide range of programming languages and platforms to build applications. Java is still the most dominant when it comes to building backend applications; however, many organizations are still evaluating their options when it comes to building cloud-native applications on platforms such as Kubernetes.

    Java in all its forms will, of course, be around for a long time to come. The only real question is how much organizations will continue to rely on it, in an IT world that continues to transform.

  • ServiceNow Acquires Sweagle to Advance DevOps Agenda

    ServiceNow Acquires Sweagle to Advance DevOps Agenda

    ServiceNow has acquired Sweagle, a provider of a repository for collecting configuration data that makes it easier to manage IT environments at scale.

    RJ Jainendra, vice president and general manager of DevOps and IT business management at ServiceNow, said Sweagle advances the DevOps initiative his company launched last year by providing a way for IT teams to more easily share configurations created by a variety of tools within a single repository. Those configurations can then be vetted to make sure DevOps teams are not reusing configuration that might be propagating a cybersecurity vulnerability, he said.

    Sweagle is essentially a modern implementation of a configuration management database (CMDB). It will be revamped to have the same look and feel of a ServiceNow application once the deal formally closes in the early part of the third quarter, Jainendra added.

    ServiceNow also plans to integrate Sweagle with its Service Graph, which enables teams to visually track metrics across a service spanning multiple platforms.

    Jainendra said as IT teams deploy applications it’s not uncommon for them to track more than 50,000 data configurations. Sweagle provides an opportunity to bring some order to what historically is a set of IT processes that are becoming more complex as organizations embrace microservices based on containers and serverless computing frameworks.

    Sweagle complements a DevOps initiative ServiceNow launched late last year through which the company is providing increased visibility into DevOps processes to IT service desk staff. ServiceNow DevOps collects metrics from various DevOps platforms that can be analyzed alongside the metrics ServiceNow surfaces using an ITIL-based framework accessed via a software-as-a-service (SaaS) platform.

    Ultimately, ServiceNow doesn’t anticipate DevOps replacing ITIL as much as it sees both approaches creating a need for IT teams to strike a balance across disparate styles of managing IT, each of which places different levels of emphasis on agility and stability, Jainendra noted.

    Naturally, each IT organization will need to determine how best to balance those conflicting goals. In many cases, organizations will decide to manage applications very differently from the underlying IT infrastructure on which they are deployed.

    Regardless of approach, IT organizations have never been under more pressure. In the wake of the COVID-19 pandemic more applications are moving into the cloud to achieve flexibility and resiliency. At the same time, more application code is being pushed out to the network edge. As IT becomes complicated, many organizations are mixing and matching best ITIL and DevOps practices as they best see fit.

    As is the case with any philosophy, there are proponents of DevOps and ITIL frameworks that are not given to compromise. However, most IT organizations tend to gravitate to the middle ground. In the wake of the current economic downturn, it’s probable there will be an even larger inclination toward compromise. After all, the rate at which applications are moving into the cloud is accelerating. However, most of those applications are now being accessed by devices that are more distributed than ever now that more people are working from home.

  • CNCF Elevates SPIFFE Spec to Secure App Services

    CNCF Elevates SPIFFE Spec to Secure App Services

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) announced that the open source Secure Production Identity Framework For Everyone (SPIFFE) specification and the SPIFFE Runtime Environment (SPIRE) have become incubation-level hosted projects.

    Andrew Harding, SPIRE maintainer and a principal software engineer at Hewlett Packard Enterprise (HPE), said the elevation of a potential standard to authenticate software services using cryptographic identities that are platform-agnostic could go a long way toward advancing the adoption of best DevSecOps practices.

    At the core of SPIFFE specification are short-lived cryptographic identity documents known as SVIDs that are invoked via an application programming interface (API). Workloads employ an SVID when authenticating to other workloads by establishing a TLS connection or by signing and verifying a JSON web token (JWT).

    Previously a sandbox level project, the SPIFFE specification is designed to reduce reliance on hard-coded secrets to authenticate application services, Harding said. Instead, developers will be able to more easily invoke multi-factor authentication to issue and verify identities for any type of application service. Each service is given its own identity, he noted.

    Amazon, Bloomberg, Google, HPE, Pinterest, Square, TransferWise and Uber are all contributors to SPIFFE. Since joining the CNCF last year contributors to SPIRE have added support for Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Kubernetes and bare-metal servers.

    SPIFFE and SPIRE are designed to work across both monolithic and microservices-based applications. The latter are not likely to completely replace the former anytime soon, so IT organizations need a consistent approach to authentication regardless of how an application is built, noted Harding. SPIFFE and SPIRE together enable an IT organization to implement a zero-trust architecture spanning multiple applications, he said.

    Ultimately, Harding said the goal is to enable better application security without compromising flexibility. As an added benefit, SPIFFE and SPIRE don’t require developers to share application secrets to enable interoperability between services running on different platforms. That’s because SPIRE doesn’t generate SPIFFE identities that can be used to authenticate to other systems nor does it store existing keys such as a database password on behalf of a workload. Each SVID generated is unique to the service use case.

    As the number of services and platforms being employed continues to increase, it’s not practical to continue to rely on approaches to authentication that rely on hard coding. The level of dependency that exists between services requires a more frictionless approach to authentication.

    It may be a very long time before reliance on tokens such as passwords disappear. However, it’s clear specifications such as SPIFFE, in the long run, will transform application security. The challenge now is not only getting developers to appreciate a new approach but also convincing skeptical cybersecurity teams that long have relied on some form of hard or soft token to secure applications. Given the number of times those tokens are misplaced or lost, there are more than a few IT help desk professionals wishing tokens would become obsolete sooner than later.

  • HashiCorp Unfurls Cloud Platform for Managed Services

    HashiCorp today at its online HashiConf Digital event launched HashiCorp Cloud Platform (HCP), through which it intends to make all of its software available as a fully managed service.

    At the same time, HashiCorp announced a public beta of an update to HashiCorp Terraform, a curated instance of an open source tool for configuring IT infrastructure that adds additional workflow capabilities.

    Finally, an update to Nomad, a cluster manager and scheduler for containerized application environments, adds support for multiple clusters as well as the Container Network Interface (CNI) specification defined by the Cloud Native Computing Foundation (CNCF).

    Rob Genova, director of product marketing for cloud services at HashiCorp, said although the company previously made some of its offering available as a managed service, HCP will serve as a foundation on which HashiCorp will manage updates to its software on behalf of end customers.

    The first managed service on HCP, now available in private beta, is an instance of the Consul service mesh deployed on Amazon Web Services (AWS), which will be followed by an instance of Vault, secrets management software developed HashiCorp, that will also be deployed on AWS.

    At the core of HCP is a HashiCorp Virtual Network (HVN), which offers a common abstraction across cloud providers around an isolated single-tenant network. Each HVN can have multiple services deployed within it. In the future, HashiCorp is promising HVN will enable peering across cloud providers and cross-provider clustering of its software. Support for additional cloud services will be added based on customer demand, added Genova.

    HCP will be offered on a pay-as-you-go pricing model to minimize upfront costs, which Genova said should make Consul and other HCP services more accessible to smaller teams and organizations. Costs will increase only when workloads scale. Both development and production pricing options will be made available, he said.

    HashiCorp already provides access to hosted instances of Consul and Terraform, which it will continue to offer alongside HCP, Genova added.

    Genova said it’s become apparent more organizations would prefer to have HashiCorp manage Consul, Vault, Terraform and Nomad on their behalf. At a time when many organizations have limited IT resources, Genova said many organizations want to devote the bulk of their limited internal resources to building and deploying applications rather than the infrastructure required to maintain them.

    It’s not clear how many organizations will opt to rely more on managed services in the wake of the economic downturn brought on by the COVID-19 pandemic. At a time when many organizations are either reducing or freezing headcount, all options are being considered. Many internal IT teams may occasionally employ a managed service to extend their own capabilities. In other cases, developers may bypass an IT operations team altogether.

    In the wake of the pandemic, Genova noted more organizations simply want to deploy resources in the cloud to ensure availability while gaining increased flexibility.

    Regardless of the path chosen, the days when IT teams felt more compelled to do everything themselves are, for better or worse, changing utterly.

  • SolarWinds Extends APM Reach to Infrastructure

    SolarWinds Extends APM Reach to Infrastructure

    SolarWinds has updated its application performance management (APM) platform to provide more visibility into the IT infrastructure on which applications depend.

    Jim Hansen, vice president of products for application management at SolarWinds, said the AppOptics service map within SolarWinds APM Suite now enables DevOps teams to visualize dynamic relationships between services and their dependencies. IT teams can view metrics such as average latency, requests per minute, error rate and CPU usage as time series data within a service trace topology.

    DevOps teams can view which services and dependencies are causing resource constraints, surface unknown dependencies and misconfigurations in services and determine how business transactions are flowing across application services, said Hansen. The goal is to make it easier to conduct root cause analysis at a time when the dependencies between software and infrastructure have never been greater or complex.

    Hansen noted that in the wake of the economic downturn brought on by the COVID-19 pandemic there is a lot more interest in reducing the total cost of IT. In many cases, IT teams today are relying on separate tools to monitor applications and IT infrastructure, which often not only results in higher costs but also fails to provide enough context, he said.

    At the same time, responsibilities within IT teams are converging. According to a recent survey of 227 IT professionals in North America conducted by SolarWinds, 54% of respondents said they are spending more time managing applications and services than infrastructure and hardware. The survey also notes there are more IT teams than ever using log analytics (58%) and tracing (24%).

    SolarWinds has also added a web transaction recorder to its Pingdom monitoring tool to capture how an end user interacts with a web application without requiring developers to write and deploy scripts. The recorder captures each step made during a transaction and automatically translates the information into a script that can automatically play back, said Hansen.

    Finally. SolarWinds has enhanced its Loggly tool, adding the ability to automate indexing and parsing to deliver time to value faster, he said.

    Hansen said SolarWinds via its software-as-a-service (SaaS) platform, is trying to make APM simultaneously more affordable and accessible. The challenge is making it possible for IT teams to apply APM services more broadly even when consumption of those services scales up and down in ways that are not always predictable, noted Hansen.

    There are no shortages of options when it comes to APM platforms these days, and most are accessed via SaaS platforms. SolarWinds has been making the case for an APM service that costs substantially less than rivals while providing most of the functionality required by the average IT team. Many teams have limited their adoption of APM platforms to only their most mission-critical because of the cost involved. As APM services become more affordable, there should be a corresponding increase in reliance on APM services at a time when IT is becoming more complex to manage daily.

  • Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint has extended its platform for managing software delivery to include the ability to analyze historical events to facility team reviews as well as more accurately predict where bottlenecks are likely to emerge based on the past performance of the DevOps team.

    Company CEO Jeff Haynie said the company’s namesake software is employed today mainly to identify existing software development bottlenecks. Pinpoint is now making greater use of machine learning algorithms and advanced analytics to surface additional insights and recommendations, he said.

    Designed to collect data from multiple tools and platforms spanning a DevOps process, Pinpoint automates most of the tedious tasks associated with collecting the metrics required to manage a distributed development team, Haynie said. With more developers working from home in the wake of the COVID-19 pandemic, that ability to collect metrics automatically also plays a key role in allowing application development managers to set more meaningful agendas for meetings that now occur via videoconference rather than in a physical conference room.

    In effect, the application development process can no longer be managed by simply walking around the office to find out what everyone is working on, he noted.

    The analytics should also serve to make events, otherwise known as ceremonies, more meaningful because they can include metrics detailing what was actually required to achieve a specific goal, he added.

    Ultimately, the goal for any DevOps team should not be to simply write more code faster. IT leaders need to make sure the right code is being delivered at the right time to ensure application development projects stay on track.

    Providers of various DevOps platforms have been investing in tools to manage the software delivery process. However, each of those offerings is optimized for a specific platform. The Pinpoint dashboard can be integrated with any platform, including Azure Team Foundation Server (TFS), GitLab, GitHub and Bitbucket. Assignments made in Pinpoint can also then be automatically reflected in these platforms as well as project management applications such as Jira, said Haynie.

    One of the biggest issues with software engineering is that, from a business perspective, it’s been a “black box” that has made it difficult to plan. The more dependent a business is on software, the more problematic that issue becomes. Many issues could be avoided if only there was more visibility into how software development resources are being applied when and where. In fact, as more organizations prioritize digital business transformation in the wake of the COVID-19 pandemic, the more critical it becomes to maximize use of limited software development resources.

    Of course, organizations have been trying to manage software development projects using spreadsheets and project management applications for decades. The tools are not likely to be replaced anytime soon simply because of the level of process inertia attached to them within most organizations. However, given the current state of application development, it should be apparent those tools are not enough to get the job done on time.

  • DevOps Deeper Dive: IT Terminology Matters

    DevOps Deeper Dive: IT Terminology Matters

    Much like any other profession, the IT industry does not exist in a vacuum. Social upheaval will have as much impact on IT professionals as it does on any other. As conversations concerning race relations become more heated and, hopefully, elevated, many in the IT industry are reconsidering the use of terminology such as master/slave to describe the relationship between applications and devices.

    GitHub this week announced this week it will be changing the term “master” as it is applied to its repository to a neutral term. Use of the phrase master/slave as a means to describe relationships between software and hardware has been employed since the very early days of IT. In fact, some would note the concept of slavery stretches back to the dawn of time.

    Nevertheless, too many of the terms used in IT evoke a sense of domination that reflects a white, male view of the world, said Dr. Shuli Goodman, executive director of LF Energy, an arm of the Linux Foundation committed to combating climate change by modernizing the power grid using open source software.

    “Language reflects our mental models,” she said.

    The IT industry in general would be better off embracing, for example, biological models rather than terminology that suggests domination and submissiveness, noted Goodman.

    Even IBM, which provides some of the oldest and most venerable platforms in the industry, is open to having this conversation.

    The company is committed to recognizing the experiences of everyone in the IT community, said Sanjay Chandru, director of IBM Z DevOps.

    “If that means we need to have a conversation about terminology, we’re open to that,” he said. “Personally, I think GitHub did the right thing.”

    The time to make a mental shift might never be better, said JFrog CEO Shlomi Ben Haim. The IT industry is transitioning toward a more distributed approach to computing that relies less on centralization. As more workloads shift to the edge, IT environments will need frameworks that span everything from the edge to the cloud, he said.

    As a result, the IT industry as a whole is shifting more toward a peer-to-peer relationship between software and hardware, he added. “We need IT to be more flexible.”

    The history of IT is marked by pendulum swings between centralized and distributed computing. Arguably, the rise of cloud computing represented a shift back toward a more centralized approach to computing that has a lot in common with the way mainframes were deployed and managed more than 50 years ago.

    PCs, on the other hand, were at the forefront of a wave of distributed computing that in many cases simply became too unwieldy to manage. Cloud computing afforded IT organizations an opportunity to centralize the management of workloads. However, with the rise of edge computing, workloads might soon be more distributed than ever.

    As is often the case when it comes to IT trends, it’s likely new terminology will soon emerge to describe the relationship between highly distributed instances of software and hardware. Hopefully, more perspective will be brought to bear not only on what those terms mean from a technical perspective but also how they might be perceived both inside IT and socially.

  • CD Foundation Touts Spinnaker CD Progress

    CD Foundation Touts Spinnaker CD Progress

    At an online Spinnaker Live event today, the Continuous Delivery (CD) Foundation revealed the open source CD platform is gaining significant momentum since being contributed by Netflix late last year.

    There were on average 842 merged pull Spinnaker requests a month in the first quarter of 2020. A total of 1,183 contributors participated in the project in the last year, with 40% of those contributors participating in the first quarter. Since the first quarter, the project has added at least two new contributors a week.

    Rosalind Benoit, chair of the CD Foundation Outreach Committee and director of community at Armory, a provider of an enterprise edition of Spinnaker, said the bulk of the increased contributions to Spinnaker are coming from Amazon Web Services (AWS), which the cloud service provider is already employing to orchestrate software delivery across multiple platforms.

    Benoit said Spinnaker represents an effort to finally address CD issues that have been difficult for most organizations to solve. While continuous integration (CI) is a solved problem, Benoit says CD remains problematic. Each platform code is deployed on within enterprise IT environments is a snowflake; as such, not much progress has been made toward automating the delivery of code across different platforms, said Benoit.

    The goal for Spinnaker is to create a foundation for CD that will achieve groundswell support that was achieved for Kubernetes by the Cloud Native Computing Foundation (CNCF), she noted. Both the CD Foundation and CNCF are arms of the Linux Foundation.

    Last year, the CD Foundation was launched to advance development and adoption of Spinnaker alongside Jenkins, an open source CI/CD platform; Jenkins X, an opinionated open source CI/CD platform for Kubernetes; and Tekton, an open source project and specification for creating CI/CD components.

    While many DevOps teams have attempted to address CD challenges using Jenkins, progress has been uneven at best. Spinnaker was built by Netflix specifically to automate software delivery across multiple clouds using a framework that can be integrated with any CI tool. As such, it serves to provide a clearer line between where CI ends and CD begins.

    Historically, most application code is pushed from a CI tool out to a deployment platform. As Spinnaker and other cloud-native platforms such as Kubernetes continue to evolve, the process of pulling images from CI tools to achieve CD goals will become much more automated.

    It’s not clear just how much depth of support for Spinnaker there is among providers of DevOps platforms. Members of the CD Foundation in addition to Armory include CloudBees, CircleCI, Google, Huawei, IBM, JFrog, Netflix, GitLab, Harness, Puppet, Rancher Labs, Red Hat, SAP and Sysdig. AWS has yet to formally join the CD Foundation. However, few of these vendors have detailed how they intend to incorporate Spinnaker in their respective platforms.

    In the meantime, DevOps teams should be paying close attention to how best CD practices will evolve alongside existing CI processes because it’s clear the next major phase of their continuing DevOps adventure is only now just beginning.

  • Rookout Extends Reach of Debugging Platform to On-Prem

    Rookout Extends Reach of Debugging Platform to On-Prem

    Rookout, a provider of a software-as-a-service (SaaS) platform designed to simplify the debugging of applications, has extended the reach of its tools into on-premises IT environments.

    Company CTO Liran Haimovitch said its new Data On-Prem capability extends the reach of a bytecode manipulation capability developed by Rookout to insert a snapshot capture of a specific line of code to an on-premises IT environment. This eliminates the need for DevOps teams to upload code and associated data to the Rookout platform manually.

    The Data On-Prem capability is made available via a software development kit (SDK) provided by Rookout, he said.

    Legacy approaches to debugging code are essentially broken because the processes employed to fix code are too cumbersome, said Haimovitch. Rookout is designed to collect full-stack data without requiring code to stop running or impact code execution. That approach allows developers to debug live code on the Rookout platform and then reinsert the code into their applications.

    Haimovitch said Rookout is making a case for transforming how application debugging is addressed within a DevOps process. Rather than relying on tools that need to be tightly integrated and maintained within a continuous integration/continuous deployment (CI/CD) pipeline, it will be easier for developers to debug live code on the Rookout platform, said Haimovitch.

    That approach will enable DevOps teams to go well beyond simple observability to embrace true understandability of how applications work down to individual lines of code, he added.

    Debugging applications has always been problematic. In an ideal world, developers would have a much better handle on what bugs need to be fixed earlier rather than later. By making it easier to debug live code, the number of issues that developers could address before an application is deployed in a production environment should increase. It may never be possible to address every issue before an application is deployed; however, the number of critical issues theoretically should decline. Many code issues go unaddressed simply because the effort required to debug that code is too great. Many developers too often put off fixing those issues until the next update usually because they are rushing to meet a delivery deadline.

    At the very least, developers should repeat the same mistakes less often as they work to debug live code.

    Regardless of how the debugging issue is addressed, issues within code in the age of microservices are starting to have a bigger impact. An issue within a line of code in a single microservice can have a cascading impact on all other elements of an application that depend on that microservice.

    Debugging application code is never going to be enjoyable. The challenge is finding a way to make the entire process less painful. There may come a day soon when machine and deep learning algorithms help automate much of the debugging process. In the meantime, DevOps teams might want to re-evaluate existing approaches to debugging code that clearly leave much to be desired.