devopsy.kinsta.cloud

Tag: devops adoption

Survey: DevOps Haves Benefiting Over Have-Nots

A global survey of 400 global IT executives and practitioners conducted by Longitude, an arm of Financial Times Group, on behalf of New Relic suggests organizations that have embraced best DevOps practices are starting to enjoy material financial benefits over rivals that have not yet made similar investments in modernizing application development processes.

The survey finds 25% of respondents are leaders when it comes to application development, with 90% of those respondents identifying the development and deployment of more perfect software as a strategic priority. Over a third of those respondents report their organizations have seen a 10% more increased revenue over the last three years.

Those same survey respondents have also adopted continuous integration/continuous delivery (CI/CD) platforms (98%) and have made observability a key tenet of their software development efforts (94%).

The survey also finds 77% of developer time on average among leaders is spent on innovation rather than on fixing issues. Leaders also find out about system and software interruptions via observability platforms (78%) versus needing to be informed by end users. A full 99% of leaders say they are able to quickly understand the results of changes to software, which also accounts for why leaders have fewer than five major software or systems outages per month (83%).

Leaders are also more likely to have adopted chaos testing (77%) and automated remediation (89%). Three-quarters of leaders (75%) have an average resolution time of less than 30 minutes.

On average, the survey finds leaders run 66% of their software and systems in the cloud, with a total of 96% having adopted a cloud-native approach to application development.

The top barriers to greater cloud adoption for the leaders were reported as being security concerns and regulations.

Buddy Brewer, global vice president and general manager for digital experience monitoring at New Relic, said more organizations today are focusing on applications that are most critical to the business, which includes digital business initiatives that enable organizations to engage customers during the current COVID-19 pandemic.

IT organizations are also breaking up into smaller teams to enable them to collaborate more effectively when building and deploying these applications, he added. As organization dynamics change, Brewer said those small teams need access to a broad range of cloud-based tools to manage highly distributed applications.

There’s obviously time for IT laggards to close the current DevOps gap between themselves and DevOps leaders. However, as leaders move further down the DevOps maturity curve, the gap between leaders and laggards appears to be widening. Many organizations in the wake of the pandemic have doubled-down a DevOps process that makes it easier for small teams to collaborate as needed.

Of course, during the downturn brought on by the pandemic, not every organization may be able to make strategic investments in IT tools and processes. The catch-22 is that it’s even less clear is just how those organizations will recover after the economy rebounds if they are still dependent on archaic tools and processes.

July 29, 2020
Financial Services: Future Proofing Your Digital Transformation Strategy
The Financial Services: Future Proofing Your Digital Transformation Strategy virtual event will explore the state of development and DevOps in the finance industry, and how organizations can digitally transform their strategy in order to release new, compliant applications and safely adapt to change at any speed demanded by the business. The virtual event will take place on July 9 at 2:30 p.m. CEST (8:30 a.m. ET).

CloudBees is bringing together a stellar line-up of thought leaders to discuss the impact of digital transformation in financial services, including:
- Sacha Labourey, CEO of CloudBees
- Jost Hoppermann, VP and principal analyst at Forrester
- Chafin Bryant, software engineering manager at Capital One
- Keith Blizard, SVP of public cloud services at Fidelity Investments
The experts will discuss the challenges the financial services industry faces in adopting DevOps.

At the Financial Services: Future Proofing Your Digital Transformation Strategy virtual event you will learn:
- How to assure separation of duties and access controls without stifling innovation.
- About Capital One’s DevOps success story and how they’ve tackled some of the unique challenges of CI/CD in the finance industry.
- How to incorporate legacy and hybrid technology into your release trains and processes.
- How to scale across geographies, teams, applications, regulations and environments – and still get the velocity and reliability expected by the business.
- About Fidelity’s cloud transformation journey and CI/CD best practices.
- How to build bridges across devs and ops; employees and contractors.
Join the CloudBees community and learn how to future-proof your digital transformation strategy. To check out the agenda and to register, visit the Financial Services: Future Proofing Your Digital Transformation Strategy website.
July 3, 2020
Survey: Internal IT Teams Embrace ‘DevOps Inspired’ Processes

The “2020 State of Application Services” survey published today by F5 Networks suggests more IT organizations than ever are adopting some elements of DevOps principles to manage an increasingly diverse application portfolio.

Based on a global survey of 2,600 IT professionals, the report finds 63% of organizations still place primary responsibility for application services within IT operations. However, more than half the organizations surveyed said they are moving toward “DevOps-inspired” teams. In addition, 73% of respondents said their organizations are automating network operations to boost efficiency.

Lori MacVittie, principal technical evangelist for F5 Networks, said the report makes it clear many IT organizations are trying to adopt best DevOps practices gradually. They may in some cases set up dedicated DevOps teams, but the preference long-term is trending toward a more evolutionary transition, she said.

At the same time, application environments are becoming more complex at a faster rate. The survey finds three-tier web and mobile application architectures come are most common (40%), followed by client-server applications (34%), microservices/cloud-native applications (15%) and mainframe monolithic applications (11%). The survey also finds 87% of organizations are using multiple clouds, but only 27% of respondents will have more than half of their applications in the cloud by the end of 2020. It’s also worth noting less than half the applications being managed (45%) are external-facing.

In terms of application services deployed today, the most common are SSL VPN and security services such as firewall, IPS/IDS, antivirus and spam mitigation, followed by load balancing, global server load balancing and DNS and web application firewall (WAF) and distributed denial of service (DDoS) protection. In the next 12 months, however, software-defined wide area networks (SD-WANs) take the top slot at 41%, followed by DNSSEC (37%) and service mesh (37%). Botnet protection, anti-fraud and common performance optimization services fill out the top six, with 36% of organizations planning to deploy each.

MacVittie said the survey results make it clear IT organizations will find themselves having to cope with more complex IT environments for years to come, with the most intense pressure being on cybersecurity. The survey finds 71% of organizations admit to having a skills gap in security.

Overall, 62% of respondents said they are confident in their ability to protect applications in an on-premises data center. However, only 45% of respondents said the same for applications residing in public clouds.

The study also suggests there is a strong link between organizations that have embraced digital business transformation and the need to build and deploy applications faster. A total of 80% of respondents said their organizations are executing on some form of digital transformation.

However, as organizations make that transition, it is apparent IT teams are challenged by the need to be more responsive to the business, said MacVittie. The day is coming to an end when IT could operate as a utility that was managed by open and closing tickets as regimented tasks were completed. IT teams need to embrace DevOps to respond faster to rapidly changing business conditions, she said.

It’s unclear how long it may take for best DevOps practices to be absorbed across mainstream IT teams. However, the one thing that is clear is that many of the DevOps concepts associated with ruthlessly automating IT in the name of agility are finally starting to hit home.

— Mike Vizard

February 11, 2020
Report Finds Faster DevOps Adoption in Retail

Conventional wisdom holds that when it comes to any IT advancement, technology companies lead the way followed by the financial service sector. However, Puppet has made available an industry scorecard based on the company’s 8th annual “State of DevOps” survey that suggests that when it comes to DevOps adoption, it’s the retail sector that is now the most advanced.

The survey finds 28% of respondents working in the retail sector said they are deploying on-demand, while 57% said they can deploy on-demand. That compares to 26% doing so in the technology sector and 49% that are capable. In contrast, only 17% of the respondents working in the financial services/insurance sector said they are deploying on-demand, versus 42% who said they are capable.

The retail sector is also able to resolve critical vulnerabilities the fastest, with 53% reporting they can remediate a vulnerability in less than one day. However, the retail sector also ranks dead last in terms of reported “significant” or “full” security integration (32%).

Alanna Brown, director of product marketing at Puppet, said the retail sector is embracing DevOps more aggressively largely because of the increased focus on digital transformation. Companies are differentiating themselves more by the quality of the application experience, she said.

It’s also fair to note that application environments in the financial/life insurance sector tend to be more complex, she noted.

Of course, DevOps expertise of any one organization in an industry sector is likely to vary widely. However, the Puppet survey makes it clear that the adoption of DevOps is becoming broader.

In fact, in terms of year-over-year growth, the survey finds the media/telecommunications sector has made the second most progress after retail. The percentage of highly evolved telecom organizations increased by nine points from 8% to 17%. The number of organizations that scored in the low category dropped to 5% from 13%. A large proportion of telecom organizations are embedding a designated security expert in teams while maintaining a centralized security function (41%). However, in terms of DevOps adoption, only 16% said they do deploy on-demand, while 31% said they can. At that rate, that’s even slower than government agencies. A fifth of government agencies (20%) said they deploy on-demand, while 41% said they can. However, only 3% said they are able to remediate vulnerabilities in less than one hour and 24% are able to remediate in less than one day.

Brown noted that while there is still a lot of room for improvement across all vertical industry sectors, when it comes to DevSecOps there is a definite shift to the left occurring. Many development teams are now designating a cybersecurity expert that advises the rest of the team on security issues versus waiting to engage with a cybersecurity expert from within the central IT organization who has little to no programming expertise.

It may still be a while before DevOps is adopted pervasively across all vertical industry sectors. In the meantime, however, it’s clear that DevOps progress is finally starting to accelerate.

— Mike Vizard

February 4, 2020
Compuware Extends Alliance With CloudBees

Compuware has become a premier member of the CloudBees Technical Alliance Partner Program (TAPP), as part of an effort to accelerate the adoption of best DevOps practices in mainframe environments.

Sam Knutson, vice president of product management for Compuware, said his company has already developed six plugins for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform. By joining TAPP, Compuware is signaling it will develop more modules in collaboration with CloudBees that can be employed on either the open source edition of Jenkins or the enterprise edition supported by CloudBees, he said.

Compuware doesn’t plan to build a CI/CD platform itself. Rather, Knutson said Compuware is pursuing an “open borders” approach to CI/CD platforms that complement its Topaz tools for building mainframe applications. As such, IT organizations should expect to see Compuware allying with multiple providers of CI/CD platforms. However, in terms of overall adoption in mainframe environments, Compuware is seeing more instances of Jenkins than any other CI/CD platform, Knutson noted.

Compuware also updated Topaz to provide a new editing experience that guides novice developers using COBOL, PL/I and JCL programming languages. It also now includes native integration with Eclipse integrated development environments (IDEs) and real-time COBOL and PL/I syntax-checking.

Knutson said the adoption of best DevOps practices and CI/CD platforms are on the rise in mainframe environments, thanks mainly to the rise of digital business initiatives that require organizations to update applications more frequently. IT teams can choose to build those applications on distributed systems that then need to be integrated with existing applications running on a mainframe, or they can modernize the applications they have running on the mainframe, he said.

The latter approach not only reduces the amount of technical debt any IT organization will need to manage, but it also results in a more secure application environment running on a mainframe, he noted. In fact, Knutson described building applications that duplicate functionality at the edge of a mainframe as “an unnatural act.”

Knutson said IT organizations that employ mainframes are at varying levels of maturity when it comes to DevOps adoption. However, he predicts in 2020 there will be many more organizations highlighting their success building and deploying applications on mainframes using DevOps practices.

Naturally, Compuware is not the only provider of mainframe tools trying to foster the adoption of best DevOps practices in mainframe environments. However, mainframe environments have employed waterfall processes for decades to build highly reliable applications. Many of the organizations that rely on those legacy processes are hesitant to abandon them if it means the application being deployed might be less stable or secure. At the same time, IT organizations that have mainframes are definitely under pressure to roll out application updates faster. As such, many of them have begun to incorporate agile programming techniques and best DevOps practices to achieve that goal. In fact, a recent survey published by Compuware finds organizations have increased deployment frequency an average of 41% for new mainframe features.

Like it or not, change is coming to mainframe application development and deployment.

— Mike Vizard

January 13, 2020
ServiceNow Makes the DevOps Connection

ServiceNow today announced it is extending the reach of its IT operations management platform to integrate with a variety of DevOps platforms.

Richard Hawes, director of product marketing for ServiceNow, said ServiceNow DevOps will provide IT operations teams relying on an ITIL-based framework accessed as a software-as-a-service (SaaS) application visibility into DevOps processes and events occurring in on-premises environments or public clouds.

At present, ServiceNow DevOps is available for financial services organizations based in the Northeast region of the United States and the UK. The service gradually will be rolled out to additional ServiceNow customers over the course of 2020. ServiceNow DevOps initially integrates with Jira Software, GitHub, BitBucket and Jenkins, with more integrations expected to be rolled out periodically.

Hawes said ServiceNow recognizes that IT organizations are building and deploying applications at rates that are faster than existing ITIL-based approaches can track. However, ITIL-based frameworks provide the highly structured set of processes around which the bulk of IT environments are managed. ServiceNow DevOps enables IT teams to automate change management tasks such as planning, development, testing, deployment and operations via a single dashboard surfacing a common set of metrics, he said. He added in many cases, those preset rules and policies will eliminate manual processes that often conspire to slow the rate at which applications can be deployed and updated within any IT environment, said Hawes.

No developers need to be involved in those processes because IT operations teams can set rules and policies, and developers will see their code running in production environments in a matter of minutes regardless of what tools they employ, said Hawes. That approach also will make it easier to scale DevOps across an enterprise IT organization at a time when adoption of DevOps is still uneven at best, he noted.

At the same time, that level of integration should also make it easier for IT teams to audit DevOps processes using a common framework to capture events such as when code is checked into a DevOps platform, he said. That capability is a critical requirement for any company trying to apply best DevOps processes with the context of a highly regulated industry such as financial services.

Hawes said the majority of organizations that have adopted ServiceNow to manage IT have also adopted a DevOps platform. Overall, Forrester Research reports 56% of global infrastructure decision-makers now report that their organizations are implementing, have implemented or are actively expanding their DevOps initiatives. ServiceNow doesn’t expect DevOps processes to supplant ITIL-based frameworks as much as it anticipates both approaches co-existing as they continue to evolve, he said.

With the release of the latest version of the ITIL framework, it’s apparent that the proponents of ITIL have come to recognize that IT needs to become more agile to meet the needs of digital business. The challenge they face is finding ways to enable IT teams to become more agile without sacrificing the gains in stability achieved over the course of the last two decades. With the launch of ServiceNow DevOps, the effort to find a middle ground between those two extremes can now begin in earnest.

— Mike Vizard

November 18, 2019
Five Don’ts When Scaling DevOps

The DevOps market is expected to reach $50 billion by 2022. However, despite the growing market, many organizations are struggling to make the transition from the successful implementation of a DevOps project to scaling across an organization. Gartner anticipates that 75% of DevOps initiatives will fail to fully meet expectations through 2022. If organizations are to buck this trend, then they need to consider some of the common hurdles they will encounter as they embark on the path to scaling DevOps.

Making the transition from isolated project to the broad adoption of DevOps presents significant challenges that span culture, systems and technology. Before diving into scaling, organizations should consider the following pitfalls that have derailed others in their quest to embrace DevOps.

Don’t Start Without Resolving the Conflict Between IT and the Business

The key to setting yourself up for success is to establish goals before trying to scale. A critical hurdle to overcome is to reach consensus on the pace of software updates. IT teams traditionally want to continually release software as quickly as possible while the business prefers incremental change, with the goal of minimizing customer friction that frequently results from the constant software updates. Before trying to scale, organizations need to agree on a way forward that everyone accepts and works toward. Otherwise, the silos between teams will not be broken down. This requires leadership, especially the CIO, to take an active role. Without addressing this hurdle, it will be almost impossible to scale.

Don’t Expect Immediate Cost Savings with DevOps

Many are surprised as they try to scale DevOps that it doesn’t result in cost savings. It’s important to remember the DevOps mission is to deliver more reliable software at speed by increasing automation. By doing this at scale, the benefits to the broader business are significant as organizations are able to better serve their customers and compete more effectively in the market.

Don’t Forget About Environment Management

Environment management is another hurdle that occurs when scaling, and it’s tough to solve if you have a lot of complexity. Don’t think it’s just technology, especially if you have multiple customized legacy systems. These present a significant challenge when trying to scale DevOps, so don’t underestimate the time it will take and don’t give up at the first challenge you encounter. However, once you have solved this challenge you will be able to manage these systems more efficiently and with less risk.

Don’t Get Distracted by Tools

From a technology perspective, the plethora of tools available can be overwhelming. As you scale, don’t be distracted by playing with tools. Go back to your goals and focus your efforts on the solutions that help you achieve these rather than being distracted by what is new and cool. Don’t be fooled into thinking that by investing in the latest Jenkins tool it will help accelerate the adoption of DevOps. Having the latest and greatest automation toolset doesn’t ensure that you will be able to scale DevOps.

Don’t Underestimate the Cultural Change Required

Scaling DevOps requires a significant cultural shift for every organization irrespective of industry. It’s relatively easy to carve out a project and make progress on DevOps, particularly as most companies start with an area where the teams will be more willing to collaborate. Scaling requires significant cultural change that will take time, and you will encounter many setbacks as you undertake this transformation.

Blurring the boundaries between teams is the foundation for scaling DevOps. This transformation requires changing the dynamics of how operations and development teams interact and breaking down silos. Scaling is dependent on cultural change, and that’s when organizations tend to stumble as they encounter resistance and many efforts stall.

Scaling DevOps is not a simple endeavor that can be achieved overnight and you will encounter a myriad of challenges along the way. By taking into account these five common pitfalls, scaling is much more likely to become a reality rather than an elusive goal that remains out of sight.

— Antony Edwards

October 24, 2019
DOES19 London: Sharing DevOps Lessons Learned

There’s a long-held belief in the DevOps space, “If you’re not moving forward, you’re dying.” But if you’re a DevOps veteran, you know that one of the best ways to orient yourself to keep moving, regardless of where you’re at in your DevOps journey, is to listen to stories of others—both their successes and failures.

Through story, we are given the opportunity to better understand the landscape of each phase of our growth and evolution, as well as to develop a deeper knowing of the challenges impacting our large-scale DevOps transformations.

This is why it’s always a unique opportunity to listen as thought leaders share their first-hand experiences each year at the DevOps Enterprise Summit.

Recently, in London, I continued our series speaking with some of the keynote speakers in our Digital Anarchist newsroom. There I was joined by two such thought leaders in the space: Ross Clanton, formerly executive director at Verizon, and Andy Burgin, platform engineer at Sky Betting and Gaming.

Ross Clanton has been one of the keynote speakers at DOES right from the beginning. This year, he gave a “DevOps confessional” style presentation of real stories of real failures and the leadership lessons, which he highlighted during our chat.

This isn’t Andy’s first time at DOES, either. This year, he shared several of the lessons learned from Sky Betting and Game’s time in its agile transformation since 2011, including sharing a practical approach to how company has structured teams, managed work and even the way it owns products and services.

Below the interview you can find the presentations from Ross and Andy at this year’s DOES London event.

In addition to this conversation, don’t miss the other 30 or so interviews we have from the conference on the Digital Anarchist site.

And, don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening Oct. 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

— Alan Shimel

October 1, 2019
CloudBees Looks to Drive Software Delivery Management

At its DevOps World | Jenkins World 2019 conference, CloudBees today unfurled an early preview of the CloudBees Software Delivery Management (SDM) service, which applies analytics to metrics gathered by the company’s continuous integration/continuous deployment (CI/CD) platforms to enable organizations to optimize DevOps processes based on their business goals.

CloudBees CEO Sacha Labourey said CloudBees is trying to take DevOps to another level by providing a unified view of all development activity and the impact any delay those projects might encounter will have on the organization.

The CloudBees SDM service provides access to a Contributions dashboard to provide insights into work prioritization and dependencies that are hindering other projects, as well as an Efficiency dashboard to provide retrospective insights that can be used to improve development going forward.

In addition, the CloudBees SDM service surfaces suggestions and alerts based on a policy and rules-based engine that identifies issues that warrant deeper investigation, such as code that doesn’t comply with a regulatory compliance mandate.

There’s also an integrated feature flag management that enables DevOps teams to manage delivery and rollout of application features based on business and operational metrics.

Finally, the CloudBees SDM service provides access to a Product Hub module, which provides visibility into all the data, resources, development and delivery activity around a specific product, and a Value Stream Management module, through which additional business insights relating to feature contributions and the overall status of a specific project are surfaced.

Labourey said the CloudBees SDM service initially will be available as a cloud service, but the company expects to make an on-premises edition available as well.

The goal is to provide IT leaders with a framework for managing multiple development teams that roughly equates to the capabilities a customer relationship management (CRM) application provides managers of sales teams, which should make it easier for organizations to identify best DevOps practices that should be shared across the organization, said Labourey. DevOps practices have been adopted unevenly across many organizations. The CloudBees SDM platform goes further than legacy approaches to software development lifecycle (SDLC) platforms in that it also makes it easier to identify what impact DevOps processes also are having on the business, he said.

Longer-term, Labourey also noted the CloudBees SDM platform will act as the mechanism through which machine and deep learning algorithms will be applied, once a critical mass of data is acquired.

CloudBees envisions its SDM service being used as a tool to coach developers on how to build better code faster. However, there always will be organizations that will make use of any SDLC platform as a vehicle primarily employed to drive higher levels of developer productivity, noted Labourey.

Whatever the motivation for adoption, advances in analytics are transforming the way every process is managed. Software development is no exception; it’s one of the first job functions where advanced analytics most likely will be applied aggressively.

— Mike Vizard

August 14, 2019
Why Did DevOps Become So Popular? 3 Theories
DevOps has now been a thing for a solid decade. As we look back at the history of DevOps, it’s worth asking: Where did DevOps come from, and why did it take off when it did?

In honor of the 10-year anniversary of DevOps, I’d like to explore these questions.

A Brief History of DevOps

The very basic history of DevOps goes like this: First, there was agile, an idea exemplified in the Agile Manifesto that gained prominence among software developers in the early 2000s.

Then, in 2008, Patrick Debois, a developer from Belgium, conceived of DevOps as a way to improve upon the agile concept by encouraging developers to work more closely with ITOps teams. His ideas began spreading in 2009. By the early 2010s, they had gained a sizable following and the rest is history.

That, again, is a really basic history of DevOps. For more detail, I recommend this DevOps history post by Steve Mezak.

Why DevOps? Why Now?

The narrative of how DevOps originated is one thing. Explaining why DevOps became so popular in a relatively short span of time is another.

As I see it, there are three possible theories to explain the rise of DevOps over the past decade. The first is to argue that Debois simply happened to have some very good ideas, and he promoted them well. You could think of this as the great man theory of DevOps’ origins. This seems to me, however, to be an unlikely explanation. It’s very rare for highly influential ideas to be born from just a single mind, or to spread through the singular efforts of one person.

The second possible explanation for why DevOps became popular is it is simply an evolved form of agile. This is like arguing that World War II was simply a continuation of sorts of World War I, and therefore the origins of World War II are ultimately the same as those of World War I. From this viewpoint, the history of DevOps is really the history of agile, and so DevOps itself doesn’t have a unique history at all. I’d find this argument compelling if I believed DevOps is really just agile by another name, but I don’t. DevOps is broader, and has a much stronger implementational and practical element.

The third theory—and the one I find most persuasive—is DevOps was born out of a particular moment in the history of computing and IT. That moment, which started in the mid-2000s, was marked by several key features that helped give rise to DevOps, including:
- The widespread adoption, starting circa 2007, of cloud computing.
- The success of the open source software movement around 2010 in making open source the go-to licensing strategy for many popular software projects and in making collaboration around code easier.
- The rise beginning around 2010 of microservices and containers, which made applications much more complex to design, deploy and manage.
- The explosive popularity of mobile computing starting with the launch of the iPhone in 2007. The mobile revolution meant organizations increasingly had to deliver software for multiple target environments (PCs, Android phones and iOS, for example) at the same time, necessitating branched delivery pipelines.
- The demand for ever-increasing speed in software delivery as a way to gain an edge in software markets which, by the late 2000s, had grown more competitive than ever.
When you put these changes together, you end up with a need to manage much more complex, fast-moving software delivery pipelines. Powered by cloud infrastructure and microservices architectures, the software market starting around 2010 required more responsive, better coordinated management by IT teams. DevOps provided an answer by increasing efficiency, decreasing response times and making software delivery faster.

I don’t think DevOps would have taken off if the idea had emerged in the 1990s, when there was much less demand for fast software delivery, most applications ran locally and codebases were relatively simple.

Nor am I sure DevOps would prove as popular if it were first introduced today. At present, we have a litany of management tools (such as Ansible and Kubernetes, to name a couple of examples) that didn’t exist 10 years ago. Those tools make it easier to handle all of the complexity of modern software environments even if you don’t have a management strategy rooted in DevOps culture.

To put it simply, DevOps resulted from the combination of several specific developments in the world of IT between the mid- and late-2000s. Debois may certainly deserve credit for helping to spread the idea, but it would not have spread so quickly if it had not emerged at that particular time.

— Chris Tozzi
July 22, 2019