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: Data centers cause climate change, and Meta is rolling out Precision Time Protocol. (more…)
Category: Application Performance Management/Monitoring
-
DevOps, Drought and Climate | Meta❤️PTP
-
How a Mature DevOps Practice Can Strengthen Competitive Advantage
Saman Pourkermani, practice lead, operations effectiveness, Inspirant Group, co-authored this article.
Software development and delivery has become an integral part of every aspect of a business and is no longer simply a support function. Nowadays, most of us, including those in business operations, know the anxieties of having to wait for specific environment release dates to deploy code for urgent fixes or updates to Dev, QA, UAT or production, which slows down productivity. Or worse, an environment has gone down with no backup environment. We all know systems have to be in place to ensure quality and security, but what makes some companies more successful than others when it comes to their DevOps operations?
Any organization that builds and delivers software applications and digital services can benefit fromDevOps. The main difference is the maturity of their DevOps culture and practices. Companies with mature DevOps practices and cultural philosophies are not only able to build and deliver applications faster than those with traditional DevOps practices, but also learn and innovate faster. Mature DevOps capabilities, tooling, and cultural philosophies enable faster innovation by automating and streamlining development, testing, deployment, and infrastructure management processes. The ability to outpace others from both a delivery and learning standpoint is a huge competitive advantage.
Most organizations understand this and as a result, have been heavily investing in maturing their DevOps capabilities and practices. However, most struggle to make meaningful progress to catch up to leading companies.
Why is That?
The most obvious reasons are resource constraints–budgetary, human and/or systems. Many companies have fixed budgets and must balance the tradeoffs between setting up an expensive infrastructure (equipped with yearly upgrades) with other business needs for short-term/long-term benefit gains.
We believe a company’s DevOps maturity is directly associated with and significantly impacted by how well and disciplined they are at making business prioritization and tradeoff decisions, picking what they will focus/work on and what they will not – ideally leaning out how much work they commit to completing.
It goes without saying that most companies that want to but don’t yet have mature DevOps practices have more work than they can handle, from setting up and documenting CI/CD processes to creating business continuity and disaster recovery plans to ensuring they have the right people for execution. These critical elements take time, effort, expertise, and budget to put together. While everyone wishes their teams could get it all done in a timely manner, the reality is that everyone has a finite amount of budget and capacity.
Quite often, progress on DevOps capabilities and automation gets sidelined in favor of ongoing customer delivery work. The trick is to establish a mechanism for balancing teams’ capacity allocation so that it includes a healthy mix of work focused on becoming more effective and efficient at delivery (e.g., maturing DevOps capabilities, improving architecture and design, etc.) and work to fulfill customer needs. In this way, a percentage of a team’s capacity can always be devoted to advancing DevOps delivery capabilities while the rest can be used to address customer requests.
How Can This be Accomplished?
Start With Culture. Culture is a critical factor when it comes to having a mature DevOps practice. Team members must fulfill their individual roles but also operate as a cohesive unit. The mindset of each team member must be focused on the greater good of the whole – not individuals. Has the team established a way of working together that fosters accountability along with encompassing growth and innovation?
Focus on Process. Progress cannot be made without identifying a clear, sensible process. For example, having a well-documented and executed CI/CD process is paramount to DevOps maturity to address all developer pain points and ensure a smooth deployment process. The key is having a documented process that establishes the team’s way of working and addresses the following: Are the right team members engaged? Are there special circumstances that need to be accounted for during the development/configuration/deployment processes? Does everyone have the same understanding of the process at each stage?
Automation and Tools. Have your processes been automated in a way that allows the DevOps practices to happen in the same way each time, without manual intervention? Do you have and know how to use the fundamental tools that all successful DevOps practices need (e.g., build and test code continuously, source control (e.g., GitLab), environment configuration management, performance measurement (e.g., load balancing))? Are deployment pain points adequately identified and addressed to prevent coding/release bottlenecks?
Business Prioritization and Trade-off Decisions. We believe this is the most important aspect of becoming a mature DevOps practice because it allows for progress over time. Balancing the teams’ capacity to include advancing DevOps delivery capabilities is critical for establishing and sustaining a competitive advantage. Optimizing your DevOps capabilities allows you to free up and capitalize on the time, talent and performance of your team members for learning and innovation.
As Jack Welch once stated, “The only sustainable competitive advantage is to learn faster than your competition and to be able to act on what you have learned.” When a software organization becomes too rigid without an adaptive DevOps edge, it will be left in the dust.
-
Data Centers IN SPAAACE | Discord GDPR Fine | AWS Fires Dead Wood
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 EU wants to put servers in orbit, a GDPR penalty for Discord, and Amazon has the hatchet out. (more…)
-
Cribl Simplifies Telemetry Data Analytics
Cribl today announced general availability of a search capability that makes it simpler to query observability data where it resides without having to first collect and centrally store it.
Nick Heudecker, senior director for market strategy for Cribl, said Cribl Search makes it possible to analyze telemetry data at its point of origin or when it is stored in a low-cost object storage platform to minimize costs.
As the volume of telemetry data being collected continues to grow, DevOps teams are struggling with ingesting it all. Cribl takes advantage of a platform it created to stream and normalize the collection of telemetry data. Cribl Search adds the ability to also query that data at the endpoint where it resides, said Heudecker.
While observability has always been a core tenet of DevOps, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and effort required to set up the pipelines necessary to transfer data to a platform for storage and analysis. The more data is collected, the greater storage costs become. Cribl is making a case for automating those tasks using a tier of software that abstracts data into a format that can be more easily collected and analyzed.
In general, observability is emerging as the next logical evolution of continuous monitoring. Existing monitoring tools enable DevOps teams to track specific pre-defined metrics. Observability platforms are intended to make it easier to query telemetry data to discover the root cause of an issue that is not being tracked by a set of pre-defined metrics.
It’s not clear yet whether IT organizations perceive observability to be an evolution of monitoring or a distinctly separate but complementary capability, but it’s apparent IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform used within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, it’s not uncommon for DevOps teams to spend hours correlating data from multiple tools to ascertain the root cause of a problem. Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge is finding a way to efficiently collect all that data, which in the past has often required a data engineer to build a pipeline spanning multiple sources of telemetry data.
One way or another, observability platforms should make it easier for DevOps teams to manage IT issues more proactively. The goal, as always, is to identify issues before they cause a major disruption. In that sense, it may be difficult to prove the ROI of deploying an observability platform. However, the best IT incident is always going to be the one that never happened or, at the very least, never escalated to a level of noticeable disruption.
-
OutSystems Acquires Ionic to Further Automate App Development
OutSystems this week revealed it has acquired Ionic, a provider of an open source framework that provides developers with a higher level of abstraction for building and deploying mobile and desktop applications.
OutSystems CTO Patrick Jean said Ionic will accelerate the company’s ongoing efforts to extend the reach of its platform for building low-code applications without developers having to worry about, for example, the screen size of the device an application is deployed on it because the framework automatically right-sizes it. Ionic, in effect, will provide an extension to the platform that OutSystems already uses to automate the building and deployment of low-code applications, he added.
In addition to its namesake user interface (UI) framework for building mobile applications that can run on multiple platforms, the Ionic portfolio also includes a tool for natively deploying web applications, dubbed Capacitor, and a toolchain for building web component-based design systems, dubbed Stencil. Collectively, these tools are used today by more than five million developers.
OutSystems plans to extend the capabilities of these tools to make it simpler to deploy applications on both mobile devices and desktop systems, said Jean. The overall goal is to reduce the cognitive load that developers currently carry when they need to build and deploy applications that run on multiple platforms, he added.That capability will prove critical as more individuals beyond professional developers become involved in building, deploying and updating applications, noted Jean. In fact, many of those developers are likely to be business people that only develop applications on a part-time basis, he added.
The percentage of applications being built using low-code tools has increased dramatically. Professional developers have embraced these tools and platforms alongside so-called citizen developers that are using them to build applications, as well. As the backlog of applications that needs to be built steadily increases, low-code platforms have played a crucial role in enabling developers to keep pace with the demand for new applications.
Less clear is the impact these low-code applications are having on DevOps workflows. On one hand, there are clearly more applications that need to be deployed than ever. At the same time, many of the DevOps and data modeling processes that once required, for example, a dedicated continuous integration/continuous delivery (CI/CD) platform are being embedded in the platforms provided by the vendors that create low-code tools.
Regardless of how low-code applications are deployed, the one thing that is certain is the pace of digital business transformation is being greatly accelerated by these tools and platforms. DevOps teams will soon need to put guardrails in place that enable developers with a wide range of experience and skillsets to securely deploy and update applications.
On the plus side, DevOps teams should also expect it to become easier to automate the delivery of low-code applications at levels of unprecedented scale. In fact, the issue going forward may not be whether IT can keep up with the needs of the business but whether the business can keep pace with the rate of innovation now being enabled.
-
SRE Survey Reveals Major Technical and Cultural Challenges
Catchpoint, in partnership with Blameless, today published an annual survey of 559 site reliability engineers (SREs) that found 59% of respondents didn’t view tool sprawl to be a major concern. Another 40% said tool sprawl is a moderate (33%) to serious problem (8%).
More than half of respondents said they build as much as 30% of the tools they use themselves, with more than half (54%) noting their organization tracks three or more different types of telemetry data to drive observability. The top three types of telemetry data collected are infrastructure (62%), application (58%) and network monitoring (55%) and, on average, the survey suggested the median toil level of SREs dropped 5% year-over-year.
Just under half of respondents (46%) also noted they saw no or low value from artificial intelligence for IT operations (AIOps) compared to 30% that have seen moderate to high value. Another 25% are still unsure.
Finally, the survey concluded that organizations that have adopted a “just culture”—where organizations ensure that incident reporting is not met with punitive measures—are 500% more likely to be Elite performers in terms of the DevOps Research and Assessment (DORA) metrics defined by Google.
Leo Vasilou, director of product marketing for Catchpoint, said that the survey results provided some insights into the challenges SREs face as they strike a balance between trying to achieve DevOps goals and the fact that hiring has become more constrained during an economic downturn.
That stress, however, has less to do with managing toolchains than it does ensuring that applications driving critical business processes are consistently available, he noted.
SREs have emerged as a distinct DevOps function in recent years, focused almost exclusively on programmatically managing the dependencies that exist between a wide range of applications and the underlying infrastructure upon which they depend. Optimizing applications in the cloud-native era has become more challenging because the number of dependencies that exist between the microservices that make up a modern distributed computing environment continues to exponentially increase. In many cases, applications are continually added to IT environments without a commensurate increase in the overall size of the SRE team.
Regardless of the economic climate, hiring and retaining SREs remains a challenge given the demand for IT professionals with those skills. Of course, there is no formal SRE certificate that is widely recognized so who qualifies to be an SRE tends to vary from one organization to the next. The one thing that is generally agreed upon is that SRE automate a wide range of tasks that would otherwise require multiple IT administrators to perform. Glassdoor also reports that, on average, an SRE makes north of about $125,000, which ranks among the highest salary level within any IT organization.
Each organization, depending on their geographic region, would need to determine how many IT administrators they could replace if they hired an SRE. That doesn’t mean IT administrators that rely on a wide range of graphical tools to manage IT tasks are going away any time soon, but as DevOps continues to evolve, the dynamics between SRE and IT administrators also will continue to evolve.
-
2023 Application Security Budgets on the Rise
A survey of 500 DevSecOps professionals in the U.S. found nearly three-quarters (73%) of organizations plan to increase investment in application security in 2023.
The survey, conducted by Wakefield Research on behalf of Invicti, a provider of dynamic application security testing (DAST) tools, also found 97% of DevSecOps teams said they ignored a real vulnerability at least once a month because they assumed it was a false positive.
Invicti CTO and head of security research Frank Catucci said that while it is apparent organizations are under pressure to improve the security of their software supply chains, the tools and processes used to discover vulnerabilities need to be revisited at a time when the security technical debt accrued in production environments is already massive.
Many DevOps teams have routinely shipped code with known vulnerabilities for years, noted Catucci. They are not only under pressure to improve the security of new applications but also remediate applications with known vulnerabilities already running in production environments, he added.
Cybersecurity teams have, of course, been identifying those vulnerabilities for years. The challenge is that the long list of vulnerabilities cybersecurity teams provide to DevSecOps teams tends to lack any context. As such, it becomes impossible for developers to prioritize their remediation efforts based on the actual severity of the vulnerabilities found. DAST tools help address that issue because they provide insights into vulnerabilities in applications already running in a production environment.
Application security, of course, has historically been problematic because many developers assume cybersecurity teams are securing the environments where applications are deployed. Most cybersecurity teams, however, allocate their budgets to tools and platforms they control and manage. Most of those tools and platforms are focused on security operations tasks that tend to have more to do with securing infrastructure rather than applications. The assumption is application development teams are responsible for securing the software that runs on those platforms. That disconnect is now finally being addressed as responsibility for application security shifts left to become an integral part of DevOps workflows.
The Invicti survey suggested that application security budget allocations are now catching up with that transition. In fact, the Invicti survey found that 100% of DevSecOps professionals are tracking the return on investment (ROI) on the application security tools and platforms they employ. Of course, measuring the effectiveness of any cybersecurity tool or platform has always been a challenge. It’s never quite clear whether a breach didn’t occur because a tool or platform was present or if it didn’t happen because of sheer luck and happenstance.
Regardless of the ROI achieved, however, it’s clear that cybercriminals are increasingly targeting software supply chains. The recent executive order issued by the Biden administration requiring federal agencies to review the security of their software supply chains got the attention of traditional enterprise IT organizations, as well. As such, the overall state of application security should steadily improve in the months and years ahead, as more funding is allocated to prevent vulnerabilities from finding their way into production environments in the first place.
-
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.
-
Mezmo Adds Observability Pipeline to Analyze DevOps Data
At the KubeCon + CloudNativeCon North America conference this week, Mezmo launched an Observability Pipeline platform that promises to make it simpler to manage, enrich and correlate machine data.
Previously known as LogDNA, Mezmo is expanding the scope of its reach to add the ability to augment and analyze data on top of its core log management platform. Over time, that capability will be extended to add support for metrics and traces using the open source OpenTelemetry agent software.
Mezmo CEO Tucker Callaway said the goal is to provide a framework for centralizing the flow of observability data that is now being generated by a wide range of sources across a DevOps workflow. It’s clear that DevOps teams require a means to enrich and correlate high volumes of data in motion that goes beyond simply pre-processing so it can be stored more cost-effectively, he added.
The Mezmo Observability Pipeline achieves that goal by ensuring the right data is flowing into the right systems in the right format for analysis, noted Callaway.
As the volume of data being collected by DevOps teams continues to dramatically increase the need to embrace a set of DataOps best practices is becoming more apparent. DataOps has emerged recently to describe a set of data engineering practices that applies many DevOps principles to the way data should be managed. Mezmo’s Observability Pipeline aims to make it simpler to apply DataOps best practices specifically to the data collected by DevOps teams.
Of course, each DevOps team will need to decide for themselves how much data they want or need to store long term. However, increasingly DevOps teams are holding onto data much longer as IT environments become more complex, noted Callaway. That creates a need to more efficiently analyze as much data as possible and store it more cost-effectively, he said. Those twin goals, however, often create a physics problem in the sense that they can be diametrically opposed.
In the longer term, it’s not quite clear how much DevOps teams are embracing observability. Most DevOps teams make use of monitoring tools that enable them to track a set of pre-defined metrics. Observability platforms promise to make it easier for DevOps teams to query a wide range of data types to discover potential issues before they disrupt an IT environment. The challenge is that many DevOps teams may not know what queries to form to discover those issues. It’s likely that, over time, machine learning algorithms will be increasingly applied to observability data to make it simpler to surface potential issues.
In the meantime, however, the need for DevOps teams to find ways to manage all the data being generated by multiple types of applications is becoming a higher priority. In fact, in the absence of any meaningful way to manage all that data, the benefits of an investment in an observability platform is likely to be limited, at best.
-
Making App Dev More Efficient
Applications of all kinds are continually popping up across various industries to help improve consumer customer experiences, provide entertainment, make certain tedious or error-prone tasks easier for workers and to help businesses improve their operations overall. In fact, there are over 5.4 million applications available across the Apple App and Google Play stores as of this year.
As more and more individuals and organizations turn to applications for various experiences and to drive enterprise efficiencies, we need to take stock of the process we deploy in application development.
The Inefficiencies of Application Development
Today, it is estimated that there are more than 26 million software developers worldwide. Each of these developers brings a unique combination of creativity and technology acumen to the organizations they work for and the applications they create. However, the current application development process in many enterprises is riddled with inefficiencies that often require these talented developers to focus on tedious, mundane, non-innovation-related tasks.
Technical Debt: Renowned programmer Ward Cunningham first introduced the concept of technical debt in 1992, stating, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” What many didn’t realize at the time was that technical debt would grow to be a major issue in software and application development years later. Recently, a new Scandinavian study found that developers dedicate 23% of their time, on average, to addressing technical debt. While this statistic alone should be alarming to enterprises—given their development teams are spending a quarter of their time on an issue that could have been avoided had a different approach been taken—the study also found that developers often have to introduce new technical debt in the process.
Maintenance: As with all technological equipment, applications require routine maintenance to ensure they remain working for the end user, provide ongoing value and are secure. However, unlike a car or kitchen appliance, applications see far more frequent updates from operating systems (OSes), cloud or hardware providers that need to be addressed by development teams. According to research from Stripe, developers spend more than 17 hours per week on maintenance issues like debugging or refactoring. For instance, take a look at Apple. From the time iOS 15 was released in June 2021 as a beta, there were more than a dozen updates made to the OS until early September 2022. That means that every single time the updates were released, developers had to spend time ensuring their applications were working correctly, were bug-free or complied with new security measures. When you add this to the fact that the average enterprise app has 110 third-party integrations, that is an extreme amount of maintenance.
The Reinvention of the Wheel: Of all the applications available today, many of them consist of the same foundational features and functionality—login, chat, social sharing, payments and more. What’s astonishing about this is that developers are frequently recreating each of these common features and functionalities from scratch every time they develop a new application.
It is clear that these tasks are highly inefficient, and it begs the question, “What can be done to address these inefficiencies?”
Prioritizing Innovation
It is not enough to just introduce some sort of technology in the hopes that it makes application development more efficient. It also requires an overall mindset change by enterprises. Yes, it is still of the utmost importance to get applications to market quickly and keep up with the pace of competition; however, innovation doesn’t have to be sacrificed to do so.
Innovation must be the key driver for enterprises and their development teams. Providing unique value and experiences to end users will truly set enterprises and their applications apart from the competition. But, the reality is that nearly 80% of technology leaders from around the world believe basic application maintenance and support are the biggest barriers to innovation.
Enterprises must be able to balance innovation, time-to-market and development processes that are free of technical debt and outrageous maintenance support.
Making Application Development More Efficient
One way in which enterprises can balance innovation, commercialization, and development is through an emerging approach to application development known as features-as-a-service (FaaS).
A FaaS approach to application development enables enterprises to implement an agile and accelerated engineering process—similar to that of low-code/no-code without the constraints often seen with those vendors and their functionality today—without sacrificing quality, code or time. More specifically, it combines pre-coded “commodity” features with continuous and automatic updates that empower development teams to spend their time and creative minds on innovation. In most cases, this approach can help enterprises bring applications to market within weeks instead of months and limits the headaches on the backend for development teams down the line.
As enterprises work through the fourth quarter of this year, I implore them to reconsider their development process at a fundamental level and bring innovation to the forefront before the beginning of 2023. Time and resources are of the essence, and something must be done now to address the inefficiencies of application development.