devopsy.kinsta.cloud

Tag: DevOps tooling

DevOps: The Never-Ending Story

Every few years, sometimes every few months, someone declares DevOps dead.

If that sounds familiar, it should. We’ve been hearing some version of this refrain for more than a decade. DevOps has failed. DevOps is broken. DevOps has been replaced by insert latest shiny thing here. And yet, every time the obituary is written, DevOps stubbornly refuses to cooperate.

Which is why I want to talk about DevOps for what it really is: Not a failed movement, not a completed project, but a never-ending story.

This latest round of conversation was sparked by a smart, provocative blog post by Charity Majors, titled “You Had One Job: Why Twenty Years of DevOps Has Failed to Do It.” Charity’s piece struck a nerve, and rightly so. She articulated a frustration many practitioners feel: after two decades, why are so many organizations still struggling with reliability, ownership, and operational excellence?

I responded with a piece of my own on devopsy.kinsta.cloud, “DevOps Didn’t Fail — We Just Finally Gave It the Tools It Deserved.” That article wasn’t meant as a rebuttal so much as a riff—an acknowledgment that Charity’s critique landed because it came from lived experience, not marketing copy.

What followed was the best part. A thoughtful LinkedIn discussion unfolded. Charity herself joined in. Others shared their own experiences. And instead of the usual food fight, something more useful happened: reflection.

And that reflection led me here.

Let’s start with an uncomfortable truth: DevOps has never been perfect. Anyone who tells you otherwise is almost certainly selling something. DevOps didn’t magically fix broken incentives, eliminate silos overnight, or turn every organization into a high-performing engineering culture.

But it did work.

Not always cleanly. Not always consistently. But it worked well enough that entire careers—mine included—were built on it. Teams shipped faster. Failures became more visible. Conversations changed. Responsibility shifted closer to the people doing the work.

And all of that happened long before we had today’s tooling, platforms, and automation layers.

We did DevOps with what we had.

Which is why I bristle a little when I hear that DevOps “failed.” Failed compared to what, exactly? A theoretical ideal? A vendor slide deck? A world where incentives, culture, and humans behave rationally all the time?

DevOps didn’t fail. It endured.

Part of the reason DevOps has survived — while so many other movements have flamed out—is that it never locked itself into a rigid definition. Early on, people were deeply uncomfortable with that. There was no single manifesto that everyone agreed on. No authoritative checklist. No certification that proved you were “doing DevOps right.”

At the time, that felt like a weakness.

In hindsight, it may have been DevOps’s greatest strength.

Because while the industry argued about definitions, DevOps kept evolving. It attached itself to cloud native technologies. It embedded into SRE practices. It became foundational to platform engineering. It absorbed security. It grew up alongside Git. And now, inevitably, it’s entangled with AI.

DevOps doesn’t compete with new ideas. It absorbs them.

That adaptability is not accidental. It’s the direct result of DevOps being less about tools and more about people. About how humans collaborate, share responsibility, handle failure, and learn from it.

As humans change, DevOps changes.

That’s why a line often attributed, in spirit if not verbatim, to Andrew Clay Shafer has been resonating with me lately: we may finally be getting the DevOps we deserve.

Not the DevOps we were promised.
Not the DevOps vendors marketed.
The DevOps we deserve.

For the first time, the tooling is starting to catch up to the intent. Observability platforms that reflect how systems actually behave. Automation that reduces toil instead of adding ceremony. Security tools that integrate rather than obstruct. Platforms that support teams instead of dictating process.

But let’s be clear: Better tools won’t save DevOps if we forget what it was always about.

DevOps was never a destination. It was never a product. It was never meant to be “done.”

It was—and remains—a response to how humans build and operate systems in an increasingly complex world.

That’s why every time someone declares DevOps dead, it sounds less like analysis and more like frustration. Or worse, a sales pitch. Email didn’t die. The web didn’t die. Agile didn’t die. They changed. They adapted. They outlived their original definitions.

DevOps is doing the same.

Yes, there are blemishes. Yes, progress has been uneven. Yes, twenty years in, we should be further along in some areas.

All true.

But in an industry obsessed with reinvention, DevOps has shown something far more valuable: resilience.

It has stood the test of time not because it was perfect, but because it was human. Because it allowed teams to interpret it, adapt it, and make it their own. Because it accepted that the DevOps you get is, in many ways, the DevOps you deserve.

Which brings us back to the beginning.

DevOps isn’t dead.
It isn’t finished.
And it certainly isn’t done evolving.

It’s the never-ending story.

January 22, 2026
The Cloud Reset: DevOps Brings Workloads Back to Private Clouds

Many DevOps teams are hitting the reset button and rebalancing their use of public versus private clouds after a decade of “public cloud-first” strategies.

Recent research reveals that 69% of enterprises are considering moving workloads from public cloud back to private environments. DevOps teams’ desire for greater control, security and cost predictability is largely driving this shift. Indeed, 92% of IT leaders say they trust private cloud more for security and compliance needs than public cloud

The shift to private cloud is very DevOps-driven. This is because all stakeholders can benefit. DevOps teams benefit from the private cloud’s stability and how existing or future investments in on-premises infrastructure are complemented and maintained. With the benefits cloud computing offers (automation, scalability and self-service), DevOps teams are better able to manage security and meet compliance needs, especially when data sovereignty is concerned. Additional benefits for the business DevOps stakeholders include how private cloud can help reduce rapidly rising public cloud costs.

Learning from a Decade of Public Cloud

The lessons learned in the public cloud space over the past few years are key. Public cloud platforms are agile and scalable, but they often present unpredictable costs and data governance issues. Most companies admit that at least some of their public cloud budget is wasted, and almost half believe that at least a quarter of their cloud spending is lost to inefficiencies.

Cost unpredictability has surfaced as a major concern. Most companies acknowledge that at least some of their public cloud budget is wasted, and nearly half believe that at least a quarter of their cloud spending is lost to inefficiencies. What began as a promise of “pay only for what you use” often led to surprise bills from unforeseen usage spikes, data transfer costs and complex pricing models that made budgeting nearly impossible.

Equally significant are concerns over security and data control. While public cloud providers offer robust security features, many organizations struggle to navigate the shared responsibility model and the complexities of managing security across multiple cloud environments. More leaders believe that private or hybrid cloud environments better meet stringent security requirements and provide them with direct oversight of critical data. For industries with strict compliance mandates, having complete control over data location and access has become non-negotiable.

The Evolution, Not Abandonment, of Cloud Strategy

This shift doesn’t signify a failure of cloud computing or a return to traditional on-premises infrastructure. Instead, it illustrates a maturation of cloud strategy. Organizations seek the same cloud benefits, such as automation, self-service provisioning and scalability, but within a more predictable and accountable operational model.

Private clouds have advanced considerably since the early days of virtualization. Modern private cloud platforms now provide the same cloud-native capabilities that made public clouds appealing: containerization, microservices architecture, DevOps tooling and infrastructure as code. The distinction lies in where these capabilities are deployed and who oversees them.

Strategic Workload Placement

The trend toward repatriation is fundamentally about strategic workload placement. Organizations are realizing that not all workloads are equal, and the “lift and shift everything to public cloud” strategy often fails to yield the expected benefits.

Workloads with predictable resource requirements, sensitive data, or stable performance needs are increasingly being transitioned back to private cloud environments, where they can be managed and controlled more effectively. Meanwhile, workloads that benefit from elastic scaling, global distribution, or specialized cloud services continue to reside in public clouds.

This hybrid approach enables organizations to optimize for different priorities, keeping mission-critical applications in private clouds for security and control, while utilizing public clouds for innovation and experimentation. It’s about selecting the right tool for each task rather than forcing all workloads into a single model.

Cost Governance and Predictability

In private cloud environments, IT departments can allocate resources per workload and precisely determine the cost of delivering those resources. This predictability encompasses not only infrastructure costs but also operational expenses, compliance costs and the total cost of ownership.

When a department’s application suddenly requires additional compute power in a private cloud, it prompts a conversation about capacity planning and budget allocation, but not an unexpected bill at the end of the month. This level of control enables organizations to more effectively align IT spending with business objectives and mitigate the “shadow IT” issue that often plagues public cloud deployments.

The Path Forward

In this era of cloud reset, DevOps teams are not abandoning the benefits of the cloud, but rather refining their approach. Our analysis at ReveCom shows the next phase in cloud computing for DevOps teams involves selecting the right environment for each workload while ensuring performance, interoperability and accountability are in alignment with DevOps.

For many organizations, this means developing sophisticated hybrid cloud strategies that leverage the best of both worlds. Private clouds offer the control, security and predictability required for core business applications, while public clouds provide the flexibility and innovation platform for new initiatives.

As DevOps teams continue to move to private and hybrid clouds, it’s a strategic shift in how they think about their infrastructure. It’s acknowledging that the cloud isn’t just a destination, but an operational approach that can be applied where it makes the most sense for business. As DevOps teams continue to refine their cloud strategies, the focus is shifting from “cloud-first” to “cloud-smart,” with private clouds increasingly playing a crucial role in delivering the promise of cloud computing while maintaining the governance and control that enterprises need.

October 21, 2025
AI‑First DevOps is Becoming the Default
If there’s one transformational trend reshaping DevOps today, it’s this: AI‑First DevOps has moved well past the tipping point. What was once hype is now becoming the operational baseline. DevOps teams are no longer experimenting with piecemeal AI features — they are deploying tools enhanced with AI as a standard part of daily work.

AI’s Quiet Revolution in DevOps Tooling

In observability, deployment pipelines, testing, security scanning — AI has already embedded itself. Platforms like Dynatrace leverage proprietary AI (“Davis”) for anomaly detection, root‑cause analysis, predictive analytics and even auto‑remediation across cloud‑native environments. It discovers microservices, traces app performance and helps teams fix issues before customers notice.

Meanwhile, industry commentary and toolchain reports consistently cite AI‑powered anomaly detection, intelligent alerting, predictive scaling and code analysis as core productivity boosters in modern DevOps toolchains (DEV Community, about.gitlab.com, Spacelift, Monterail, SmartDev). These features reduce noise, speed mean time to detect and respond (MTTD/MTTR), and shift teams from reactive firefighting to proactive optimization.

I’ve been writing for years about how DevOps would evolve into something far more intelligent than just CI/CD pipelines. And today, predictive analytics and AI‑based incident resolution are not future promises — they’re operational realities across high‑velocity ops teams.

DevOps Meets MLOps: The Merge is in Full Swing

As DevOps becomes AI‑first, the next logical evolution is the convergence with MLOps. Recent market developments show JFrog, long known for package management and DevSecOps tools, has launched JFrog ML — a unified platform that brings DevOps, DevSecOps and MLOps together under one umbrella (SmartDev, TechRadar, JFrog). JFrog ML enables teams to treat ML models as first‑class artifacts — versioned, secured, bundled and released the same way software binaries are — streamlining collaboration between data science, development and operations teams (TechRadar).

That same integration philosophy is echoed across the industry; as one TechRadar piece recently noted, siloed DevOps and MLOps workflows are one of the main reasons 85% of ML models fail to make it into production. The answer: Treat ML models like code artifacts in a unified software supply chain (TechRadar).

The data bears this out. A mixed‑method study of ML DevOps adoption — surveying over 150 professionals — finds that organizations embracing this convergence achieve higher deployment frequency, lower error rates, improved scalability, stronger compliance and reduced costs (arXiv).

Automated Testing: AI’s Biggest Early Impact

If there’s one area where AI has made an immediate and undeniable impact in DevOps, it’s automated testing. Tools like CloudBees Smart Tests — born from CloudBees’ acquisition of Launchable — use AI to prioritize and optimize test suites, dramatically reducing test times and catching regression patterns before code hits production. Backed with awards like Newsweek’s AI Impact Award for “Best Outcomes in Engineering,” Smart Tests illustrate how model‑driven testing is no longer niche — it’s becoming a default capability (Wikipedia).

This is where speed meets quality. As I wrote previously in “From software factories to intelligence engines,” traditional “software factories”—pipelines that just push binaries — are giving way to intelligence engines. AI is now optimizing when and what to test, even dynamically adjusting based on code and historical risk.

Yes, We’re Early — but Acceleration Is Coming

Let me be clear: We’re still early in this AI‑DevOps evolution. Many organizations have only scratched the surface with AI‑enhanced observability or test planning. Full-blown AI‑driven code generation, pipeline orchestration, LLM‑driven configuration (see research like LADs, which uses LLM chains to optimize cloud infrastructure), or autonomous rollout systems are still emerging in labs and pilot programs (arXiv).

But here’s the thing: innovation and adoption are accelerating. We’re transitioning from manual pipelines to pipelines enhanced with AI; soon, those pipelines themselves will be shaped and orchestrated by AI and ML. Building software will become more automated, almost commoditized. The competitive edge will come from an organization’s intelligence engine — how well it leverages AI/ML to continuously adapt, deliver and iterate.

What an AI‑First DevOps Future Looks Like
- Software and models treated as unified artifacts. Everything — code, containers, ML models, configuration — is versioned, scanned, signed, and promoted together.
- AI‑driven test orchestration. Smart Test selection, predictive test failure detection and even auto‑remediation suggestions.
- Intelligent pipelines. Systems that tune themselves based on performance feedback, deployment success rates, canary results and drift metrics.
- Observability that understands AI. Platforms like Dynatrace track GPU latency, inference drift, feature distribution shifts, connected to infrastructure events.
- Governance baked into AI/ML delivery. Policies-as-code extended to include ML artifacts, with audit trails and traceability across data, features, models and code.
In Closing

We are crossing a threshold. AI‑First DevOps is not a buzzword — it’s becoming the default. DevOps teams today use anomaly detection, predictive analytics, AI‑powered test optimization and increasingly integrated ML pipelines. JFrog ML’s emergence is a clear signal that the industry expects a unified DevOps‑plus‑MLOps future.

Yet even as we accelerate, we must remember that this is still an early era. The true revolution lies ahead: Where DevOps becomes intelligence engineering. Where building and deploying software is table stakes, and the real value lies in how fast and smart your organization learns and adapts.

As I’ve written before: The shift from software factories to intelligence engines isn’t just evolutionary — it’s transformative. Organizations that embrace AI‑First DevOps — and build out intelligence engines that deliver adaptability, reliability, governance and speed — will define the next decade.

That’s where we’re headed. And in that world, AI‑First isn’t optional — it’s the new norm.
July 28, 2025
How Does IT Management Govern EverythingOps?

The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.

I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.

According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.

Everything’s Going Ops

At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.

You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.

At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.

Solution: Shifting Governance Left

There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”

Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.

CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”

Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.

Final Thoughts: Shift Left, Automate and Reuse

For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.

A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.

“Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.

February 1, 2022
Antipatterns That Hurt DevOps Implementations
Avoiding these DevOps antipatterns can help organizations reap the benefits of implementations faster

It’s a given that all organizations at some point will suffer from poor development practices when trying to find the perfect balance between software development and IT operations. The good news, however, is that implementing DevOps can help you improve these processes and get them synchronized and working together in harmony.

However, understanding and mapping out the core issues and the common DevOps “antipatterns” that are holding you back from successful DevOps implementation is essential. This article will focus on the most common DevOps antipatterns that organizations tend to fall into and how to avoid or overcome them.

What Are DevOps Antipatterns?

At first glance, DevOps may sound like a pretty straightforward concept. At its core, DevOps is about bringing together separate but functional areas and bridges the gap between software development (Dev) and IT operations (Ops) with the ultimate goal of delivering software faster and with better stability.

That said, DevOps antipatterns can best be defined as ideas that are counterproductive to the DevOps culture. They include:
- Blame culture: In this kind of culture, blaming and punishing people is the norm when mistakes are done. It can happen at an individual or organizational level.
- Root cause analysis (RCA): RCA is a process that involves identifying the “root” cause of a problem or an event, as well as the appropriate actions to take to avoid a recurrence. It’s an iterative and continuous process that must be performed until data is exhausted or all organizational factors have been identified.
- Human error: Human error is often cited as a root cause in RCA. This is also common in “blame culture” and someone has to be held accountable for mishaps and mistakes.
- Silos: An organizational or departmental silo defines the mentality of teams that don’t share their knowledge with other teams within the same company.
4 DevOps Antipatterns and How to Break Them

Wrong Perception of Your DevOps Team

The perception you have of your DevOps team matters. It’s essential to consider the team as part of the entire process. Neglecting to provide them with structure, resources, and a positive working environment can increase your chances of DevOps failing. Furthermore, making DevOps teams more productive requires proper implementation of processes and tools.

How to Break It

A successful DevOps implementation requires more than just bringing people together. Structuring the team correctly and adding processes is vital if they are to succeed. Providing the necessary resources, technology and information security they need will get the best results.

Practices such as continuous integration (CI) and continuous delivery (CD) are both concerted processes that can be used to bring development teams together in alignment so software products are delivered quickly, operations are more simple to manage and no downtime is present during deployments that are detectable to the end user.

Poor Choice of Technology

Technology plays a significant role in IT; however, the rapid development of new technologies has made it challenging to separate essential and overhyped tech trends. For instance, DevOps itself is a powerful digital transformation tool as it plays a critical role in new software development and problem-solving. Nevertheless, many of the latest IT trends should not be worth your attention unless you and your team are willing to implement it correctly.

How to Break It

This antipattern can be broken by top-level and project managers who make the decisions regarding technology choices. Asking questions such as, “What does the organization need?” or, “How well will this technology work for us?” will help when choosing what tech is right for your organization. With thousands of tools and technologies available, you need such a mindset to make the right decisions.

Unclear Responsibilities in Teams

You may have come across this problem in many other non-IT projects. However, in both IT and DevOps teams, the consequences can be severe if solutions aren’t implemented quickly. If team members aren’t clear on their roles and responsibilities, this can lead to poor decision-making and unnecessary interference in other people’s positions.

How to Break It

First of all, you need to clearly define roles and responsibilities for everyone in the team. A clear definition of roles boosts productivity. For example, having a data scientist in your DevOps team can play a huge role in business success due to their very specific data analytics skills, techniques and tools. In fact, 89% of business managers agree that hiring a data professional will help to improve success at their respective organizations. There just needs to be active and consistent communication between team members for everyone to conduct their own roles and responsibilities efficiently.

Every team member should follow the strategies and plans in place so timelines can be monitored and effective top management decisions can be made. When implementing complex DevOps architectures that require teams and software to work together, poor decision-making will be an issue if roles are left unassigned.

Wrong or No Code Deployment

To put it bluntly, there’s no DevOps without code deployment. With this being the ultimate result, DevOps makes no sense if it fails. This is quite a challenge for several organizations, as having Dev and Ops teams working in harmony can seem impossible.

How to Break It

As mentioned above, code deployment is often a challenging task for DevOps teams. However, organizations can break the resultant antipattern by integrating the units correctly to enable a collaborative environment, a great strategy for successful DevOps implementation.

Such an environment will also make code deployment easier by reducing the need for a series of meetings and reviews, which ultimately delay teams from getting code to deployment.

NoSQL’s Key Role in Database DevOps

DevOps processes need to work in a synchronized manner to be successful. Issues with the database can cause it to slow down and affect the delivery of database changes. However, NoSQL’s unique approach is designed to simplify the process of DevOps implementation in the following ways:

Faster scalability

Many small companies fail to maintain peak performance with greater workloads. A more significant workload calls for better tools that can help maintain peak performance, subsequently making it easier for organizations to scale out.

More efficient technical support

Having technical support that doesn’t hold you back is key to DevOps success. The right NoSQL solution enables you to solve problems before they become full-fledged, expensive and time-consuming.

Faster adaptability

The changes that new codes bring for databases can be challenging. NoSQL makes it easier to deliver solutions to client requests, as it organizes them using dynamic indexing. Therefore, it verifies all queries before answering them with the appropriate index.

Platform testing

Testing is one of the critical steps you need to go through before actual implementation. Databases should be flexible enough to allow you to test queries without interfering with the real data. Testing helps to determine how new changes will impact the development process.

Conclusion

As you can see, there are many ways to implement DevOps systems in your business to deliver products faster, offer more technical support and automate essential tasks.

All of the requirements we have covered are necessary if a business is to scale and grow. Businesses need to ensure the correct strategies are in place, roles in the company have been clearly defined and common antipatterns have been identified and eliminated.
December 1, 2020
CircleCI Extends CI/CD Reach to Windows Platforms

CircleCI today announced it will make available its continuous integration and continuous deployment (CI/CD) platform available on a variety of Windows platforms.

Matt Wyman, vice president of product for CircleCI, said the decision to support Windows stems from recent Microsoft DevOps initiatives, most notably its move to acquire GitHub. As Microsoft invests more time and energy promoting best DevOps practices, demand for CI/CD platforms running on-premises or in the Microsoft Azure public cloud will escalate sharply, said Wyman.

The Windows environment on CircleCI also includes support for Docker Engine – Enterprise for Windows workflows and all Windows jobs run isolated on a virtual machine. Each new job uses an environment that gets created just in time and gets destroyed once the job finishes running. That approach is intended to ensure both build reproducibility and the security of the code, data and secrets stored in a CI environment. All CircleCI features such as caches, Workspaces, approval jobs and Contexts are now being made available for Windows jobs.

Wyman said CircleCI now expects organizations to extend the same software development lifecycle processes for building and deploying both Windows and Linux-based applications. The ability to leverage the same pipelines within the context of a common CI/CD platform spanning both environments will help narrow the time and effort required today to build Windows applications, he added.

Currently, it’s unclear whether a common set of processes for building and deploying applications in Windows and Linux environments might foster greater collaboration within IT organizations. Linux and Windows teams don’t tend to interact much. However, as more organizations look to apply repeatable processes that enable them to build more reliable software faster, the need to standardize DevOps processes has become apparent. Of course, Circle CI isn’t the only provider of a CI/CD platform looking to take advantage of that emerging hybrid cloud computing opportunity.

It’s also worth noting that providers of platforms such as Microsoft and Red Hat are also promoting their own approaches to software development lifecycle management. Organizations need to decide how much they want to rely on the tools and processes made available by platform vendors instead of a CI/CD platform that integrates DevOps processes across multiple platforms. To fight that battle, CircleCI last month revealed it has raised another $53 million in funding. At that time, the company noted that the total monthly job count on its platform stood at 30 million, up from 7 million in January 2018.

Regardless of the path chosen forward, organizations increasingly need to build and deploy software on multiple platforms. The challenges associated with managing those processes are nothing less than considerable. The issue IT leaders will need to determine first is how much they want to drive unification of software development from the top down versus simply providing a common set of tools and platforms that their teams will (hopefully) gravitate toward.

— Mike Vizard

August 7, 2019