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: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (more…)
A survey of 900 application testing professionals conducted by PractiTest, a provider of a platform for managing testing tools, suggested the number of organizations that have dedicated testing teams is declining at a steady rate.
The survey found a 15% decrease in organizations with dedicated testing teams that have six or more members. At the same time, however, the survey found only 18% of respondents reported that all testing is done by individuals that are not part of a dedicated testing team.
Joel Montvelisky, test specialist and chief solution architect at PractiTest, said that shift indicates that more organizations are steadily incorporating testing within DevOps workflows. In fact, more than 60% of respondents said DevOps and Agile processes led to teams being more organized and stable, with two-thirds (66%) reporting that development teams were releasing features more frequently with more functionality.
However, only 38% of respondents said they were active participants in a continuous integration/continuous delivery (CI/CD) workflow. A full 90% said they needed to coach or train other members within the team and just over half (54%) reported that estimations of the time required for development and testing were accurate.
Two-thirds also said collaboration with developers is also improved when applying DevOps processes, with more than half reporting fewer serious bugs made it into production. More than half also said they monitor software in production and deployment environments. The number of testers who defined themselves as engineers has gone up by 14% year-over-year. However, only 44% report that automation has replaced 50% or more of their manual testing efforts.
A full 95% or more of survey respondents identified application programming interface (API) testing, Agile methodologies, functional testing and scripting as high on their list of priorities. In contrast, big data testing, internet of things (IoT) testing and machine learning/artificial intelligence (AI) testing were cited as important or very important by only 60% of respondents.
Finally, about a third of survey respondents noted that non-testers are now involved in testing activities.
Montvelisky said the PractiTest survey makes it clear that while developers are a little more involved in testing than they were a few years ago, organizations still relied on testing specialists that are becoming more integrated into DevOps workflows. This is especially important as more organizations launch digital business transformation initiatives that require them to build software using the same types of DevOps processes that independent software vendors (ISVs) employ.
It’s still too early to say just how far testing might shift left toward developers, but as testing becomes more automated—thanks, in part, to increased reliance on AI—the types of tests that will be conducted by a dedicated testing team will evolve. In fact, it’s unlikely automation will eliminate the need for those teams any time soon. Rather, testers will be augmented by AI technologies that will help them to keep pace with the accelerated rate of application development enabled by wider adoption of DevOps best practices within organizations both large and small.
The rise of remote workforces, cryptocurrencies and super-sized data centers brings to the forefront a concern in tech development that doesn’t get enough attention: The impact of computing and advanced technologies on the environment.
About six months into the pandemic, people began to notice cleaner air, clearer water and an overall calming effect on the environment in the reduced presence of industry. Memes were created and widely circulated that suggested maybe we were the problem after all.
That lasted for about six weeks before cabin fever set in, and we became impatient and ready to get back to business as usual.
In the time between the last quarter of 2020 and the sudden waxing and waning of NFTs, a few timid voices again raised concerns about the impact of super-computing and other technologies on the environment. Those concerns eventually became muffled amidst socioeconomic and political turmoil, fears about inflation, staff shortages and logistical issues surrounding supply chain disruption.
App development tried to fill some of those gaps and new data centers appeared as we struggled to find our footing again in a post-pandemic world.
While environmental issues have been a matter of growing concern for decades, the past few years have put a particularly intense focus on the issue, with entire industries growing up around everything from climate-friendly investing to carbon offsets, and more. The environmental impact of technology has become an issue yet unresolved in spite of a growing focus on sustainability.
The typical DevOps journey focuses mainly on how app development will impact an organization. Rarely does it address how development impacts the environment.
In addition to factors like improving time-to-market, reducing human error, debugging and making financial resource management more efficient, part of your DevOps strategy should include ways to reduce your carbon footprint and impact on the planet.
First, it helps to understand exactly how technology affects the climate and depletes natural resources so you can incorporate sustainable development into your plan in a meaningful way.
Even relatively passive use of technology, like video streaming and remote collaboration, for example, has the potential to consume more power than entire countries. Add up all of the hours of Netflix, Zoom meetings and other remote activities and ponder the implications.
To become part of the solution, it’s important to do more than just invest in green businesses. Here are some steps you can take to clean up your DevOps process and become part of the solution rather than contributing to the problem.
Software engineering and DevOps are increasingly embracing new territory and emphasizing sustainable engineering. The first step in the right direction is to become aware of how power and resources are consumed during your development cycle.
Consider:
In the realm of sustainable engineering, the process can be broken down into three categories: Technical, operational and environmental. The goal is to balance these aspects to monitor and optimize the development process and do the least amount of damage possible.
Once you’ve identified areas of risk and set goals for sustainable software engineering, use the results to create and enforce a set of development best practices that better support environmentally responsible design and production. If you need some help or ideas, you can model your own initiatives after these emerging standardization principles.
In 2021, more than 200 countries signed the Glasgow Climate Pact, solidifying their commitment to reducing their carbon footprint and resultant environmental damage from tech development and use. The conference brought together stakeholders from businesses, government agencies and others to share information and create standards and best practices for sustainable computing and tech development.
Tech giants like Google, Amazon, and Microsoft are creating tools to help DevOps and IT monitor and measure the environmental impact of everything from cloud computing to app development. Seek out and incorporate these tools into your own set of best practices or work on creating your own solutions.
Tech development is intended to improve our quality of life and reshape how we conduct business. There’s no reason that intention shouldn’t extend to the world in which we live and engage in commerce.
The first step toward combating climate change without negatively impacting development is understanding how technology affects our environment. Then, we can make informed decisions that support responsible, sustainable DevOps.
Microsoft’s Azure DevOps Server is emerging as one of the most popular cloud application development environments. Like most continuous integration/continuous delivery (CI/CD) platforms, it provides features such as version control, reporting, project management, automated builds, and testing. It covers all aspects of the application life cycle and enables DevOps. Here’s a closer look at this cloud computing environment.
Azure DevOps provides a number of different developer services that allow DevOps teams to plan work, collaborate on code development and build and deploy applications. It is highly collaborative and brings together developers, project managers and individual contributors to develop software. It allows organizations to create and improve products much faster than with traditional software development approaches.
Teams can work in the cloud using Azure DevOps Services or on-premises using Azure DevOps Server.
The cloud offering, Azure DevOps Services, is a scalable, reliable and globally available hosted service. It’s backed by a 99.9% SLA, is monitored by Microsoft’s 24/7 operations team and is available in local data centers around the world.
The on-premises offering, Azure DevOps Server, is built on a SQL Server back end. The on-premises version is preferable when organizations need their data to stay within their network or when they want access to SQL Server reporting services that integrate with Azure DevOps Server data and tools.
Although both offerings provide the same essential services, Azure DevOps Services offers some added benefits:
There are also some other key differences depending on your organization’s or your team’s needs. These can also be helpful if you’re migrating from on-premises to the cloud:
Although Azure DevOps Services is a hosted version of Azure DevOps Server, there are some feature differences. Some Server features aren’t supported in Services; for example, Azure DevOps Services doesn’t integrate with SQL Server Analysis Services to support reporting. Process customization and reporting also differ in their support.
Azure DevOps provides integrated features that can be accessed through a web browser or an IDE client. One or more of the following standalone services can be used based on your organization’s business needs:
Use of the following collaboration tools is also supported:
Azure DevOps supports adding extensions and integrating with other popular services, such as Campfire, Slack, Trello, UserVoice and more. In addition, DevOps teams can also develop their own custom extensions.
Azure DevOps Services supports integration with GitHub and GitHub Enterprise Server code repositories. Azure DevOps Server supports integration with GitHub Enterprise Server repositories.
When you sign up for Azure DevOps, you must first register an organization, project and version control type. DevOps teams can create multiple projects and differentiate them with separate names and access permissions. Projects can be set to public or private. Teams can also use Azure Boards for collaboration and project management, and can also configure use of Agile practices. After setting up your team, you can use the platform to begin deploying your applications to Azure.
In addition to a collaborative environment, Azure DevOps provides access to an Azure Pipeline service that supports multiple languages and platforms. The Azure DevOps pipeline is a set of services that are grouped into individual projects.
Additionally, Azure Test Plans feature facilitates automated testing. It is also possible to set up deployment pipelines with different components for multiple applications.
Azure Pipeline can track work status, manage backlogs and create custom reports. With the help of the Azure DevOps pipeline, developers can create, manage and deploy their projects in a single environment. With this solution, DevOps teams will have a single point of contact and can communicate with each other.
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: CSS-Tricks gets bought by DigitalOcean, Peloton pedals while its business burns, and Arm lays off up to 15% of staff. (more…)
It appears that, in many IT environments, observability is becoming too much of a good thing. A global survey of more than 315 IT executives, cloud application architects, DevOps professionals and site reliability engineers (SRE) conducted by Dimensional Research on behalf of log data management platform provider Era Software, found 96% are witnessing an explosion of log data.
The survey also found 79% of respondents reported the overall cost of observability and log management will skyrocket in 2022 if current tools don’t evolve.
More than three-quarters of respondents (78%) also noted attempts to manage volumes of log data have had mixed or unwanted results such as an inability to access data. Nearly two-thirds (65%) are also evaluating their observability options while the other 41% are considering it.
Stela Udovicic, senior vice president of marketing for Era Software, said the survey makes it clear that as organizations rely more on logs to analyze IT events, the cost of storing all that log data is becoming a significant challenge. Overall, the survey finds usage of observability tools and platforms has jumped by 180% as IT teams struggle to manage increasingly complex IT environments.
On the plus side, more business users are benefiting from log data. A full 83% of respondents report that business stakeholders outside of IT use insights from log data, with 96% reporting log data is being used to solve business problems.
Observability has always been a core tenet of DevOps best practices, but achieving it has always been a challenge. Monitoring tools are designed to consume predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. However, whenever there is an issue, it can still take days, sometimes weeks, to discover the root cause of an issue through what amounts to a process of elimination.
In contrast, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without relying solely on a limited set of metrics that have been predefined to monitor a specific process or function. DevOps teams can employ queries to interrogate data in a way that makes it easier to discover the root cause of an issue. Observability platforms correlate events in a way that makes it easier for analytics tools to identify anomalous behavior indicative of an IT issue.
The issue that arises is that IT teams need to find a way to store all the data generated by the logs they need to analyze. Each IT team can, of course, could reduce the amount of log data they retain. However, there is always a concern that in the event of an incident critical log data won’t be available.
Udovicic said most IT organizations have historically viewed storing log data as a necessary evil. The primary issue most of them encounter is the simple fact that log data is not easy to work with, she noted.
Regardless of how organizations view log data, the amount of it that needs to be managed will only increase as DevOps workflows become more mature. The issue IT teams need to come to terms with now is finding a way to minimize the cost of storing it all.
DevOps has been with us long enough now that there is a lot of legacy DevOps stuff running in all of the places I have eyes into. Ignoring items that are not actually working; those pieces that pose a serious security threat because they house vulnerabilities that have been fixed—there is a lot of “It just works,” piping in place and even a bit of “We’ve always done it that way.”
Considering DevOps is still often pushed as “the inevitable new hotness” by marketers, I find this interesting; the fact that DevOps is now the de facto standard across enterprises is a topic for another day. I want to talk about the stuff running quietly, relieving you of the need or desire to think about it while focusing on issues that do need you to think about them.
But that type of thing is exactly what created the need for DevOps in the first place. DevOps came in like a wrecking ball and forced you to look at the unnecessary steps that had built up around the items in the organization/culture/infrastructure, often around these very “This is just how we do it,” or “That ain’t broke, let’s look at this other thing, instead,” attitudes.
At Ingrained Tech, we have scripts that run our backups to the cloud. They are part of a fully automated process; we designed them to make sure our system of what gets backed up and when highly adaptable. The system runs like a champ every night unless we tell it not to.
Our cloud storage provider has come a long way since we first used their API to get the data up there and wrote those scripts. In fact, customers like us are the reason the provider keeps backward compatibility with those APIs. Which means it is time for us to revisit, use the newest APIs and see which of the many, many new features we want to take advantage of. “Good enough” is just that. The system isn’t broken—we get viable backups out of it (which we needed not too many months ago, so we know we get good backups), but we’re not getting maximum value out of it; we had to do a bit of hoop-jumping to get the data set back up the way we wanted.
Our simple backup routines are nothing compared to similar “good enough” arrangements I’ve seen in larger companies. “Good enough” arrangements that are creating larger and larger speed bumps that sometimes resemble the exact environment that made the huge gains of early DevOps implementations inevitable.
Take a look at your infrastructure and toolchains with a critical eye. Look for low-hanging fruit, and knock out some of the baggage that has built up. Schedule some process renewal days, where a team member or two specifically looks at everything in the environment with a critical eye, and see what they propose.
And keep rocking it. Speed bumps or not, you’re making the apps and infrastructure that keeps the entire company running. Remember that, and keep a smile on your face while you’re solving recurring problems.
A recent cloud observability survey found nearly two-thirds (64%) of respondents reported the adoption of public clouds has made it more difficult to achieve observability. Nearly half of respondents (48%) said they now consider providing real-time insights into application/infrastructure environments to be a top priority.
The survey polled 357 IT professionals and was conducted by Enterprise Strategy Group (ESG) on behalf of Yotascale, a provider of cost optimization tools for cloud computing environments.
Yotascale CEO Asim Razzaq said that attaining and maintaining observability becomes more challenging with each new cloud platform adopted. The survey found that 71% of organizations now rely on more than three cloud infrastructure providers.
A full 84% of survey respondents also noted that tracking costs and cloud cost allocation is burdensome and time-consuming, and 61% admitted they lacked sufficient visibility into which teams own what cloud resources. Nearly a quarter (24%) are considering making changes to their monitoring and observability practices as infrastructure costs rise.
Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate events with costs as part of an effort to rein in the costs of IT, said Razzaq.
In the immediate aftermath of the COVID-19 pandemic, the number of workloads being deployed on public clouds increased sharply. In theory, many organizations signed enterprise licenses that reduce cloud costs if they consistently consume a certain level of infrastructure resources. In practice, however, individual developer teams are showing a preference for one cloud platform over another based on the attributes of their workloads. As a result, however, it becomes more challenging to not only consistently observe diverse platforms but also to control costs.
It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of pre-defined but often conflicting metrics. Observability platforms unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.
The rate at which DevOps teams will embrace observability will naturally vary. In 2022, the biggest obstacle might not be the technology as much as it is simply understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs. Regardless of approach, however, the ability to manage complex IT environments in the months and years ahead will continue to steadily improve.
CircleCI today published a report that found most successful software engineering teams have average workflow durations of five to 10 minutes, with any failed run being fixed or reverted in under an hour.
The report was based on two years of data gathered from more than a quarter-billion workflows and collected from nearly 50,000 organizations using its continuous integration/continuous delivery (CI/CD) platform. The CircleCI 2022 State of Software Delivery Report also found those teams have success rates that are above 90% for the default branch of their application and deploy at least more than once per day.
Mike Stahnke, vice president of platform for CircleCI, said the report also makes it clear there is no correlation between team size and the level of DevOps success achieved.
Organizations that focus on optimizing pipelines are also better able to integrate testing within their DevOps workflows, he noted.
In general, Stahnke said more DevOps teams are relying on cloud-based CI/CD platforms versus opting to deploy and maintain infrastructure themselves. That shift also lowers the barrier to entry for organizations looking to embrace DevOps best practices to accelerate application development, he added.
Less clear is the degree to which organizations have embraced both CD and CI. While many developers routinely employ CI to accelerate application development, CD has proven to be a more elusive goal. Each platform a DevOps team supports tends to have unique attributes that require them to rely on manual processes to deploy applications. However, as DevOps processes continue to mature, Stahnke said the CI and CD integration will become more seamless. In fact, as the number of applications that organizations build simultaneously increases, the pressure to automate CD will also rise.
However, it remains to be seen to what percentage of organizations will opt for a tightly integrated CI/CD platform versus separate CI platforms for developers and CD platforms for IT operations teams that are more loosely coupled.
In the meantime, organizations of all sizes are clearly more focused than ever on developer productivity. In the wake of the downturn brought on by the COVID-19 pandemic, there was a rush to launch a range of digital business transformation initiatives. The issue that many organizations are now encountering is they need to find ways to enable a finite number of developers to simultaneously build and deploy multiple applications with multiple interdependencies. Many organizations are trying to address that challenge by sharing best practices across DevOps teams that have varying levels of maturity. Few organizations have a set of standardized DevOps practices that are consistently employed across every application development team within an enterprise.
It will be up to each organization to decide whether to compare their level of DevOps expertise to other organizations. Each application development team faces a unique set of challenges. The most important goal is simply to continuously improve at a time when demand for custom applications has never been greater.
ServiceNow added an incident management platform based on the Lightstep observability platform it acquired last year to its software-as-a-service (SaaS) portfolio.
Ben Sigelman, general manager of Lightstep at ServiceNow, said Lightstep Incident Response gives DevOps teams access to observability tools that, via a self-service portal, enable them to determine the root cause of any incident much faster. It combines the ability to orchestrate on-call escalation, alert grouping, incident analysis and remediation with a set of collaboration and incident management tools.
That approach will make the Lightstep observability platform much more accessible via a cloud service, noted Sigelman. The Lightstep observability platform itself is based on a time-series database capable of processing one trillion events each day.
Lightstep Incident Response manages an organization’s on-call rotations by synchronizing schedules via a shared calendar, with specific tags that indicate who needs to be looped in based on the nature of the incident and the service that is impacted. Team members are invited to a dedicated channel based on prebuilt collaboration integrations for quick remediation. Over time they can create automated processes that self-triage and self-remediate problems as they reoccur. The platform also integrates with monitoring, observability and collaboration tools such as LogicMonitor, Postman, Slack, Sumo Logic and Zoom.
Lightstep Incident Response is generally available now in both free and paid versions. Pricing is based on the use of active services being managed rather than by seat license.
Lightstep Incident Response also natively integrates with the Now Platform that ServiceNow created for IT service management (ITSM). That integration will enable organizations to more easily meld ITSM and DevOps workflows, noted Sigelman.
Observability platforms aggregate the collection of logs, metrics and traces in a way that makes it possible for DevOps teams to query that data. The goal is to make it easier for DevOps teams to identify anomalies that might disrupt an application environment. Those same tools, however, also allow DevOps teams to identify the root cause of an IT incident much faster. Today many organizations routinely convene “war rooms” that require IT teams to painstakingly identify the root cause of an issue by a process of elimination; this can take days—sometimes even weeks—to complete.
With more applications becoming instrumented—thanks, in part, to the availability of open source agent software—Sigelman said observability platforms will play a critical role in helping to automate incident management processes. Prior to being acquired by ServiceNow, Lightstep team members played a role in the creation of both the OpenTracing and OpenTelemetry open source projects for collecting traces, metrics and logs. Today, OpenTelemetry is a sandbox-level project being managed under the auspices of the Cloud Native Computing Foundation (CNCF).
With the deployment of more microservices-based applications, the percentage of applications that are instrumented will soon increase substantially. It’s not feasible to manage these highly distributed applications without some level of instrumentation. The issue now, of course, is determining to what degree to also instrument many of the monolithic applications that are already running in those same environments.