DevOps is a transformative approach to software development and IT operations that emphasizes collaboration, automation, and continuous improvement. However, adopting and implementing DevOps can be a complex and challenging journey for many organizations. From resistance to change and cultural issues to technical hurdles and tool integration, there are several challenges that teams face when adopting DevOps practices.

In this post, we will explore some of the major challenges that organizations face when implementing DevOps, along with their key features and practical solutions for overcoming them.

1. Cultural and Organizational Resistance

Major Features:

• Resistance to Change:
  • One of the primary challenges of DevOps adoption is overcoming resistance to change within the organization. Traditional siloed structures, where development and operations teams work independently, are often deeply ingrained, making it difficult for teams to collaborate effectively.
• Lack of Collaboration Between Teams:
  • DevOps relies heavily on strong collaboration between development, operations, and other departments such as quality assurance and security. In many organizations, these teams are siloed and reluctant to change their long-established workflows, leading to delays in adoption.
• Misalignment of Goals and Objectives:
  • Development teams may be focused on feature delivery, while operations teams may be focused on system stability and performance. These misaligned objectives can cause friction and hinder the success of DevOps implementation.
• Solution:
  • Addressing cultural resistance requires a strong leadership commitment to change, along with training programs and workshops to educate teams about the benefits of DevOps. Emphasizing the shared goals of improved software delivery speed and quality can help align different teams and foster collaboration.

2. Lack of Skilled DevOps Professionals

Major Features:

• Skill Gaps in DevOps Tools and Practices:
  • DevOps requires a combination of technical skills, including expertise in continuous integration, continuous deployment (CI/CD), automation, cloud infrastructure, and containerization. Many organizations struggle to find professionals with the necessary skill set to effectively implement DevOps practices.
• Limited Training Opportunities:
  • Despite the growing popularity of DevOps, there is still a shortage of formal training programs and certifications that provide comprehensive DevOps education. This creates a gap in the talent pool and increases the difficulty of hiring skilled DevOps professionals.
• Overwhelming Scope of Responsibilities:
  • DevOps engineers often wear multiple hats, managing everything from automation to monitoring and troubleshooting. The broad scope of responsibilities can make it difficult to keep up with industry changes and adopt new tools and practices quickly.
• Solution:
  • Organizations can address the skills gap by offering internal training programs, encouraging certifications, and collaborating with educational institutions to create DevOps-focused courses. Leveraging DevOps platforms with built-in automation features can also ease the burden on teams by reducing the need for extensive manual intervention.

3. Tool Integration and Complexity

Major Features:

• Managing Multiple Tools:
  • DevOps involves the use of various tools for version control, CI/CD, automation, containerization, and monitoring. However, integrating these tools into a unified workflow can be challenging, especially when tools don’t easily communicate with each other.
• Tool Overload:
  • With so many tools available in the DevOps ecosystem, choosing the right set of tools and ensuring they work well together can be overwhelming. Teams may experience difficulty in managing tool sprawl, resulting in inefficiencies and confusion.
• Continuous Tool Updates:
  • DevOps tools are continuously evolving, and keeping up with regular updates, new features, and best practices can be time-consuming. This constant change makes it challenging to maintain a stable and secure development environment.
• Solution:
  • Adopting a standardized set of DevOps tools that are well-integrated can simplify the implementation process. Many platforms like GitLab, Jenkins, and CircleCI offer integrated solutions that streamline workflows and reduce the need for manual configuration.

4. Security and Compliance Challenges

Major Features:

• Integrating Security into the DevOps Pipeline (DevSecOps):
  • DevOps requires the integration of security throughout the entire software development lifecycle. However, many organizations struggle to incorporate security checks and practices into their CI/CD pipelines without slowing down the development process.
• Ensuring Compliance:
  • Compliance requirements, such as GDPR, HIPAA, and PCI DSS, often mandate strict controls over data handling, security, and privacy. Ensuring that DevOps workflows remain compliant while maintaining speed and flexibility can be a major challenge.
• Managing Secrets and Sensitive Data:
  • Handling sensitive data and secrets (e.g., API keys, passwords, encryption keys) securely is a challenge in DevOps. The use of multiple automation tools and cloud platforms increases the complexity of managing and storing secrets safely.
• Solution:
  • Adopting DevSecOps practices, which integrate security into every stage of the DevOps pipeline, can help. Automating security testing (e.g., static and dynamic application security testing) and using tools for secret management (e.g., HashiCorp Vault) can mitigate security risks while maintaining agility.

5. Scalability and Infrastructure Management

Major Features:

• Scaling Applications and Infrastructure:
  • As organizations grow, the complexity of managing infrastructure at scale increases. DevOps often requires teams to support large-scale applications and distributed systems, which may include managing thousands of virtual machines, containers, or microservices.
• Managing Hybrid and Multi-Cloud Environments:
  • Many organizations use hybrid or multi-cloud environments, which add complexity to infrastructure management. Integrating on-premise and cloud systems, ensuring consistency, and scaling infrastructure dynamically can become overwhelming without the right tools and processes.
• Cost Optimization:
  • Managing infrastructure at scale while controlling costs is a key challenge in DevOps. Without proper cost management practices, organizations may overspend on cloud resources, leading to inefficiencies and budget overruns.
• Solution:
  • Adopting Infrastructure as Code (IaC) tools like Terraform, AWS CloudFormation, or Azure Resource Manager can help automate infrastructure management and ensure that environments are scalable and consistent. Cloud-native tools like Kubernetes can assist in orchestrating and scaling containerized applications.

6. Performance Monitoring and Continuous Improvement

Major Features:

• Real-Time Monitoring of Applications:
  • Monitoring performance in real time is critical for DevOps success, but continuously tracking the health of distributed systems, microservices, and cloud environments can be challenging. Identifying bottlenecks, issues, and failures requires constant vigilance and automated alerting.
• Feedback Loops:
  • DevOps relies on continuous feedback from both automated testing and real-world user interactions. Gathering and analyzing feedback efficiently, then acting on it quickly, is essential for ensuring that systems evolve and improve over time.
• Balancing Speed with Quality:
  • While DevOps encourages faster release cycles, there’s always the challenge of balancing speed with quality. Ensuring that new code is well-tested and does not introduce regressions or performance issues is a key consideration.
• Solution:
  • Leveraging monitoring tools like Prometheus, Grafana, and New Relic provides real-time insights into application performance. Implementing Continuous Improvement (CI) practices, based on performance data and user feedback, ensures that products continue to evolve in response to user needs and business goals.

Overcoming the Challenges of DevOps

While implementing DevOps offers significant benefits in terms of faster software delivery, improved collaboration, and greater efficiency, the journey is fraught with challenges. Overcoming these challenges—whether related to culture, skill gaps, tool integration, security, scalability, or performance monitoring—requires a strategic approach, strong leadership, and continuous investment in training and tools.

By addressing these challenges head-on and adopting best practices, organizations can unlock the full potential of DevOps and achieve greater success in their software development and operations. Fostering collaboration, automating processes, and ensuring continuous improvement are key to building a sustainable and efficient DevOps pipeline.

Cloudreach announced the launch of Cloudreach DevOps as a Service. This new offering combines Cloudreach development and operations, making them available ‘as a Service’ via a simple and flexible subscription model.

DevOps as a Service is the first of its kind in the market, and fundamentally changes how cloud IT services are consumed to make it easy for enterprises to adopt cloud native technologies and practices.

Dave Chapman, Head of Strategy and Professional Services at Cloudreach, said: “Cloudreach DevOps as a Service brings a DevOps and cloud engineering skill set to any enterprise, whether they are new to the cloud or far along their modernization journey.

“Companies that undergo cloud transformation are better able to adapt to disruption, explore and innovate faster. This service helps technology leaders get the right skills in place, at the right time, and scale up and down to suit their changing requirements.”

Cloud acceleration
DevOps is a set of practices that combines software development and IT operations, removing the barriers between these traditionally siloed teams. Under a DevOps model, development and operations teams work together across the entire software application life cycle, from development and test through deployment to operations.

More than a decade after the introduction of cloud computing, many enterprises still find themselves suffering from the symptoms of legacy IT and legacy partners. Cloudreach DevOps as a Service makes cloud outsourcing easy by providing flexible engineering squads as a monthly subscription service.

The new offering is designed to help technology leaders accelerate their cloud initiatives, embrace true DevOps within their teams, and help their organizations become more cloud native.

Cloudreach DevOps as a Service provides a core DevOps team that can be augmented to perform architecture, platform development, data engineering, application UX and product management roles, all as a unified service.

As business priorities or backlogs change, the flexible nature of the service means customers can swap out squad members and scale the team up and down as needed, within a single statement of work. The minimum squad size includes two resources and 80 hours per month, with a minimum contract commitment of three months.

Cloudreach squads have a radical focus on trend improvement and platform evolution. They can help launch new products, accelerate and scale business initiatives, facilitate stronger collaboration with digital teams, or support key applications and infrastructure.

James Dunn, Head of Cloud Platform Development at Cloudreach, said: “Over its 10-year history, Cloudreach has delivered some of the largest and most successful cloud engineering projects in the world. Now we are bringing Cloudreach’s cloud native expertise to market in a flexible subscription model.”

At the same time, database estates are growing. The same research found that 45% of DBAs expect to manage more databases in the coming year, while 43% expect their estate to remain the same. Cloud migration was cited as the biggest challenge by 22% of respondents. With greater workloads and more frequent changes, it is perhaps unsurprising that human error tops the list of issue causes at 22%, ahead of capacity problems and bad deployments.

For DBAs, surviving and thriving in a DevOps environment means focusing on four distinct areas: standardization, automation, monitoring, and data compliance.

Managing Databases in a DevOps World

The database is now a core component of the DevOps pipeline for many organizations. DBAs can no longer operate in isolation. They need to work alongside developers, adopt shared tooling, and contribute to the same CI/CD pipelines that development teams use. This shift requires DBAs to rethink both their processes and their relationship with the wider engineering team.

Standardizing Approaches Across DevOps Processes

Human error is the leading cause of database issues, and it becomes a bigger risk when larger, mixed teams of DBAs and developers are all making changes to the same database. Standardizing processes is the most effective way to reduce this risk.

Practical standardization steps include:

• Adopting a team-wide coding style for database objects, so that SQL written by any team member follows the same conventions. This makes code reviews faster and reduces confusion-driven errors.
• Using industry-standard development tools consistently across the team, rather than letting individuals choose their own editors or migration frameworks.
• Integrating database scripts into version control alongside application code. Merging changes early and often gives the team a single source of truth and makes it easier to identify when and where a problem was introduced.

Without these guardrails, a minor inconsistency in a schema change can escalate quickly into a production incident that is difficult to diagnose and expensive to roll back.

Automating for Speed and Consistency

Developers who have adopted DevOps already understand the value of continuous integration (CI), continuous delivery (CD), and continuous deployment. Automation reduces manual effort, eliminates whole categories of human error, and produces an auditable record of every change — a significant benefit for regulatory compliance.

Extending these same practices to the database delivers equivalent benefits for DBAs. A typical database CI/CD workflow might look like this:

1. A developer commits a schema change to version control.
2. A CI pipeline is automatically triggered, building a test database and applying the change.
3. Automated tests validate the change and flag any errors immediately.
4. The developer fixes errors and the cycle repeats until the change is clean.
5. The validated change is passed to a release management tool for review and approval before deployment to production.

This approach shortens the feedback loop dramatically and reduces the risk of broken database changes reaching production. However, automation is only as effective as the processes and tooling that support it. Organizations need to invest in the right database DevOps toolchain and ensure that DBAs are involved in designing the pipeline, not just subject to it.

Stepping Up Monitoring to Drive Continual Improvement

Continual improvement is a core DevOps principle, and it applies equally to the database. Monitoring plays a central role in enabling it.

At the operational level, database monitoring tools surface performance degradation, slow queries, blocking, and resource contention before they cascade into outages. DBAs in the Redgate research cited performance issues as a major ongoing challenge, which underlines how important proactive monitoring is at higher deployment frequencies.

Beyond reactive alerting, monitoring data provides the trend information teams need to improve proactively. According to the Redgate research, 40% of organizations already share database monitoring data with developers. This visibility helps developers understand the performance impact of their code changes and identify opportunities for optimization earlier in the development cycle — a clear example of DevOps collaboration generating tangible results.

Guarding Personal Data and Ensuring Regulatory Compliance

Data privacy regulations are expanding globally. The EU’s GDPR, the California Consumer Privacy Act (CCPA, which came into force in January 2020), and similar legislation in other jurisdictions place significant obligations on organizations that process personal data. Organizations must treat themselves as data guardians, not data owners.

This creates a specific tension in DevOps workflows: developers need realistic data to build and test against effectively, but production datasets containing personal information cannot simply be copied into development and staging environments. The solution is data masking and anonymization — tooling that replaces sensitive values with realistic synthetic equivalents so that developers can work with data that behaves like production data without exposing real personal information.

Effective data masking tools also generate an audit trail of how data was handled throughout the pipeline, which supports compliance reporting and reduces the risk of breaches during development and testing activities.

Key Takeaways for DBAs in a DevOps Environment

• Deployment frequency is rising. DBAs need processes that can scale with frequent, sometimes daily, database changes without accumulating risk.
• Human error remains the top threat. Standardized tooling, shared coding conventions, and version control reduce the surface area for mistakes.
• Automation is a force multiplier. CI/CD pipelines applied to database changes catch errors early and create compliance-ready audit trails.
• Monitoring supports both reliability and improvement. Sharing monitoring data with developers creates a tighter feedback loop and improves overall system performance.
• Compliance is non-negotiable. Data masking and anonymization tools allow development to proceed at speed without exposing sensitive data.

DevOps has permanently changed the relationship between DBAs and development teams. Organizations that bring their databases fully into the DevOps pipeline — with the right processes, automation, monitoring, and compliance tooling — will be better positioned to manage increasing workloads and maintain the reliability their business depends on.

This article draws on findings originally reported in the Redgate 2019 State of SQL Server Monitoring Report and an article by Matt Hilbert published on devops.com.

DevOps and Digital Transformation: Two Sides of the Same Coin

Scaling DevOps is no small feat — but the stakes are high. Experts consistently argue that a stalled DevOps journey puts the entire digital transformation effort at risk. The two initiatives are intrinsically connected: DevOps shifts organisational culture, breaks down harmful silos, and creates the conditions for continuous change and rapid experimentation. Those are precisely the capabilities organisations need to meet evolving customer demands.

Matthew Skelton, Head of Consulting at Conflux and co-author of Team Topologies, sums it up clearly: “Digital transformation is almost impossible without well-placed collaboration between different teams building and running IT systems. The speed of technology change is so quick that no one team can expect to understand all the details of relevant technologies, so we need to enable teams to focus on a smaller problem domain. Without a foundation of infrastructure automation and well-chosen team collaborations, the rapid pace of digital transformation would be impossible.”

10 DevOps Best Practices That Accelerate Digital Transformation

The following ten practices represent concrete ways in which DevOps principles and methods move organisations closer to their digital transformation goals. Each section includes perspective from a recognised practitioner or industry voice.

1. DevOps Changes the Cultural Mindset

Steve Burton, CI/CD & DevOps Evangelist, Harness: “DevOps should be the catalyst or team that accelerates change in any modern business, regardless of whether you call that change digital transformation, cloud-native, or something else entirely. DevOps is about taking a business idea and helping the business realise that idea as quickly as possible — it’s not really about technology or buzzwords.”

Corporate culture is the primary reason many large organisations cannot transform. Years of established habits around how software is developed, shipped, and operated create enormous inertia. DevOps challenges that inertia directly. It replaces red tape, committee gatekeeping, and bureaucratic approval chains with a bias toward action — enabling teams to deliver value to the business without unnecessary friction.

Key takeaway: Cultural change is the hardest and most important part of both DevOps adoption and digital transformation. Treat it as a first-class concern, not an afterthought.

2. DevOps Unites People, Process, and Technology

Eran Kinsbruner, Technical Evangelist, Perfecto: “DevOps enables organisations to release new value to their customers faster, hence allowing them to mature and transform their digital face. DevOps unites people, process, and technology: when all three are aligned toward the same business goals, innovation is introduced faster.”

A common failure mode in digital transformation is optimising only one of these three dimensions — investing in tooling without fixing process, or redesigning process without bringing people along. DevOps explicitly acknowledges all three as equally important levers. It also reduces internal waste by focusing teams on high-priority digital innovations, freeing capacity that was previously absorbed by lower-value work.

Without DevOps practices, Kinsbruner argues, the speed of releases needed to stay competitive simply cannot be sustained, and the quality of those releases cannot be guaranteed at scale.

3. DevOps Uncovers Patterns That Help Organisations Improve

Helen Beal, DevOpsologist, Ranger4: “DevOps’ role in digital transformation is to help organisations understand the patterns and practices that are likely to improve their performance in the face of digital disruption, thus improving their competitive posture.”

The journey from a traditional, hierarchical command-and-control organisation to a digitally ready one requires substantial behavioural change. Authority must be distributed. Autonomy and alignment must coexist. Everyone must feel empowered to contribute. DevOps provides both the frameworks and the cultural models to pursue this shift in a structured, evidence-based way.

Crucially, Beal points out that optimising the flow from idea to value delivery is not merely a matter of building a CI/CD pipeline — it requires deliberate attention to the human and organisational patterns that either enable or obstruct that flow.

4. DevOps Enables Teams to Self-Steer Toward Better Solutions

Matthew Skelton, Head of Consulting, Conflux: “DevOps can help make IT infrastructure more testable, resilient, observable, dynamic, and on-demand. This enables safer, more rapid changes to the supporting IT infrastructure, which in turn enables safer, more rapid changes to software applications and services.”

Skelton emphasises two additional benefits. First, infrastructure-as-code practices — where all changes to build, deploy, and infrastructure systems are driven from version-controlled code — eliminate the ambiguity of manual configuration and provide full traceability. Second, when this is combined with rich telemetry from modern monitoring and observability platforms, teams gain a powerful, real-time awareness of system behaviour.

That awareness reduces Mean Time To Recovery (MTTR) and enables teams to take genuine ownership of production services. The result is an organisation capable of responding quickly to changing market conditions — one that can “self-steer” toward better solutions continuously.

5. DevOps Makes Automation a Strategic Priority

Jayne Groll, CEO, DevOps Institute: “IT has been so busy automating the world, we almost forgot the benefit of automating our own toil. DevOps advocates the optimisation of automation to bring its principles to life.”

DevOps principles — increasing flow, shortening feedback loops, encouraging continuous learning and experimentation — require automation to operate at scale. CI/CD pipelines, automated testing, infrastructure provisioning, and site reliability engineering (SRE) practices all reduce the manual overhead that slows delivery and introduces error.

Groll adds an important caveat: automation is not a magic solution on its own. It must be designed by skilled people, embedded in sound process, and supported by an appropriate culture. Automation that codifies a broken process simply produces broken results faster. But without meaningful automation, digital transformation efforts face a hard ceiling on how far they can scale.

6. DevOps Shortens Feedback Loops

One of the foundational principles of DevOps — derived from Lean and Agile thinking — is the relentless shortening of feedback loops. When developers receive immediate feedback on the quality and behaviour of their code through automated tests, monitoring alerts, and rapid deployment cycles, they can identify and correct problems in minutes rather than weeks.

Shorter feedback loops are directly valuable to digital transformation because they reduce the cost of experimentation. When it is cheap and fast to test a hypothesis in production, organisations can run more experiments, learn faster, and build products that more closely match what customers actually need.

7. DevOps Breaks Down Organisational Silos

Traditional IT organisations often suffer from deep silos between development, operations, security, QA, and the business. These silos slow delivery, create handoff bottlenecks, and generate blame-shifting when things go wrong. Digital transformation demands cross-functional collaboration — and DevOps is designed precisely to foster it.

Shared ownership of services, shared on-call responsibilities, and shared metrics encourage development and operations teams to treat software delivery as a unified concern rather than a relay race. This organisational shift is a prerequisite for the agility that digital transformation demands.

8. DevOps Supports Continuous Delivery of New Revenue Streams

Digital transformation is ultimately about creating new value — new products, services, and revenue streams enabled by technology. DevOps enables this by making it possible to ship small increments of working software frequently and safely. Organisations that can release daily or multiple times a day can respond to market signals, validate new business models, and iterate on products far faster than those constrained to quarterly or annual release cycles.

This capability is not merely operational — it is a strategic competitive advantage. It allows organisations to treat software delivery as an engine of business innovation rather than a cost centre.

9. DevOps Improves Security and Compliance Posture (DevSecOps)

Digital transformation increases the attack surface of organisations — more cloud services, more APIs, more endpoints, more data flowing across more systems. DevOps, extended into DevSecOps, integrates security checks, vulnerability scanning, and compliance validation directly into the CI/CD pipeline rather than treating security as a gate at the end of the delivery cycle.

Shifting security left — detecting issues earlier in the development process — reduces the cost and risk of remediation. It also means security does not become the bottleneck that stalls digital initiatives. Organisations undergoing transformation cannot afford to treat security as an afterthought.

10. DevOps Builds a Foundation for Continuous Improvement

Digital transformation is not a project with a defined end date — it is an ongoing capability. The organisations that sustain transformation over time are those that build systems for continuous learning and improvement. DevOps provides exactly that foundation through blameless post-mortems, retrospectives, metrics-driven decision-making, and a culture that treats failure as a learning opportunity rather than a reason to punish.

The Three Ways framework articulated in The Phoenix Project — flow, feedback, and continual learning — maps directly onto what mature digital organisations do. DevOps operationalises these principles at the team and organisational level.

Where to Start

If your organisation is struggling to make progress on digital transformation, the most productive question to ask is not “which tool should we buy?” but rather “which DevOps practice are we missing or doing poorly?” The ten practices above provide a useful diagnostic lens. Cultural change and team structure tend to be the highest-leverage starting points, but the right entry point will depend on your organisation’s specific constraints and maturity level.

What is clear from practitioner experience is that DevOps and digital transformation reinforce each other. Progress on one creates conditions for progress on the other. Neglecting DevOps while pursuing digital transformation is like trying to renovate a building without scaffolding — technically possible in theory, but unnecessarily difficult and risky in practice.

Why Culture Is the Hardest Part of DevOps

When organisations embark on a DevOps transformation, the instinct is to focus on tooling: CI/CD pipelines, container orchestration, infrastructure-as-code, and monitoring stacks. These are visible, purchasable, and measurable. Culture is none of those things, which is exactly why it is so often deprioritised—and why so many transformations fall short of their goals.

You cannot buy a DevOps culture. DevOps demands that people, process, and tools work in concert. Invest only in tools and you automate dysfunction rather than eliminate it. Research from organisations such as Google Cloud and Harvard Business Review has consistently reinforced this point: DevOps initiatives that neglect the human dimension rarely deliver the business outcomes they promise.

Large-scale organisational change is inherently uncomfortable. Leaders must stake their professional reputations on a transformation vision. Employees face uncertainty about their roles, their skills, and their futures. Resistance is not irrational—it is a predictable human response to ambiguity. Addressing that ambiguity through sustained, honest communication is therefore not an optional add-on; it is the foundation on which everything else is built.

Communicate Every Step of the Way

Professional identities form over years. A developer who has spent a decade mastering a particular workflow, or an operations engineer whose entire value has been defined by manual release gates, cannot be expected to reorient overnight. Before you roll out a single new tool or process, cultivate genuine empathy for what your employees are experiencing.

Employees going through a DevOps transformation are typically wrestling with questions such as:

• How will my day-to-day responsibilities change when new processes are in place?
• Is my role at risk once more tasks are automated?
• What skills will I need, and how will I be supported in developing them?
• How will my performance be evaluated in this new way of working?

Anticipate these questions rather than waiting for them to surface as resentment. Proactively share both the questions and the answers with the entire team, not just managers. When people see that leadership has already considered their concerns, trust increases and resistance decreases.

Critically, your communication strategy must reach beyond development and operations teams. A DevOps transformation touches application delivery across the whole organisation. Marketing may need to revise campaign timelines to align with faster release cycles. HR must understand new role definitions and hiring profiles. Finance needs visibility into shifting cost models. Hold cross-functional meetings regularly, listen actively for pain points, and address issues in real time. A transformation that only talks to engineering will quietly create friction everywhere else.

Measure What Matters

Benchmarking against industry peers can be useful for setting initial targets, but the metrics that drive your transformation forward are the ones tied to your specific business goals. If your primary objective is faster, safer software delivery, your metrics should illuminate the health of your delivery pipeline—not simply validate that you are keeping up with competitors.

Identifying meaningful metrics starts with understanding how your current processes drive behaviour. Ask probing questions:

• What corners are being cut to hit a deployment deadline?
• Does accelerating one team’s throughput create bottlenecks or quality problems for other teams?
• Are the metrics we track today changing how people behave—for better or worse?
• Do our pipeline metrics reflect real-world delivery quality, or are they masking problems?

Common DevOps metrics such as deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate (popularised by the DORA research programme) are strong starting points precisely because they are outcome-oriented rather than activity-oriented. They measure the health of the system, not just the busyness of individuals.

Metrics should not live only in dashboards. Bring them into the regular cross-functional meetings described above. When employees see a direct line between their daily work and the numbers that matter to the business, two things happen: engagement increases, and the quality of the data improves, because people on the ground will surface discrepancies that no automated report would catch.

Practical Steps for Leading a Culture-First DevOps Transformation

Putting culture at the centre of your DevOps programme is not a soft aspiration—it requires deliberate, repeatable practices. Consider the following approach:

1. Define and communicate a clear transformation vision. Articulate what success looks like in concrete terms—faster releases, fewer production incidents, reduced toil—and explain why it matters to both the business and to individuals.
2. Establish psychological safety. People must feel safe to raise concerns, admit failures, and experiment without fear of blame. Blameless post-mortems are a proven mechanism for building this culture.
3. Invest in learning and upskilling. Budget time and money for training, communities of practice, and experimentation. Automation anxiety fades when people have the skills to work alongside automated systems.
4. Create feedback loops at every level. Retrospectives, one-on-ones, and town halls are not bureaucratic overhead—they are the mechanisms through which a transformation self-corrects.
5. Celebrate incremental wins. Transformation is a marathon. Recognising small milestones keeps momentum alive and demonstrates that progress is real.
6. Align incentives with the transformation goals. If performance reviews still reward individual heroics over team collaboration, your culture programme will fight an uphill battle. Review and adjust how people are measured and rewarded.

Conclusion

A DevOps transformation touches staffing, organisational structure, performance management, and culture simultaneously. That scope makes it one of the most complex change programmes a technology organisation can undertake. The companies that succeed are not necessarily those with the most sophisticated toolchains—they are the ones that bring their entire organisation along for the journey.

By establishing transparent communication channels, choosing metrics that reflect real business outcomes, and investing consistently in the people behind the processes, you build the cultural foundation that makes every technical improvement sustainable. Communicate the vision relentlessly, measure what genuinely matters, and treat culture as a first-class engineering concern—not an afterthought.

Splunk Launches Industrial IoT Specialization to Connect Partners with Industrial Buyers

Splunk Inc. (NASDAQ: SPLK) announced in August 2019 that customers and partners across multiple industries were achieving measurable improvements in customer satisfaction, operational efficiency, and cost reduction through Splunk’s enterprise Internet of Things (IoT) solutions. Central to this announcement was the introduction of an Industrial IoT Specialization within the Splunk Partner+ Program — the first vertical specialization offered under that program.

The specialization is designed to help channel partners with deep industrial domain expertise build and deliver Splunk-based solutions tailored to industrial buyers — a segment with distinct data challenges compared to typical enterprise IT environments.

Why Industrial IoT Requires a Different Approach

Industrial environments generate data from sources that are fundamentally different from traditional IT infrastructure — SCADA systems, industrial control systems (ICS), sensors on physical assets, energy meters, and operational technology (OT) networks. This data is often siloed, difficult to correlate, and locked in proprietary formats that general-purpose analytics tools struggle to process efficiently.

Jim Gillespie, CEO of GrayMatter (one of the launch partners), described the challenge clearly:

“Operational data is complex and often gets stuck in organizational silos, so it’s exciting to see so many technological breakthroughs available to industrial customers that break down the silos, and provide a complete view of their data to make better business decisions. By partnering with Splunk, we can offer data combination solutions to industrial organizations that provide a simple and secure way to combine data from sources previously hard to correlate, whether it is energy usage, customer sentiment, weather or cyber security for OT information.”

— Jim Gillespie, CEO, GrayMatter

The Splunk Enterprise IoT Solution Stack

Splunk’s enterprise IoT offering at the time of this announcement combined three core components:

• Splunk® Enterprise — the core platform for ingesting, indexing, and searching machine data at scale.
• Splunk Machine Learning Toolkit (MLTK) — enabling predictive analytics and anomaly detection on top of operational data streams.
• Splunk Industrial Asset Intelligence (IAI) — a premium application providing visualizations and insights specifically tailored to industrial asset management and monitoring.

Together, these components are intended to help organizations shift from reactive operations — responding to failures after they occur — to predictive operations, where potential issues are identified and addressed before they cause downtime or safety incidents.

Real-World Use Cases: Customers Putting IoT Data to Work

Puget Sound Energy: Bridging OT and IT in a Utility Environment

Puget Sound Energy, a utility company operating in the Pacific Northwest, deployed Splunk to analyze data from its industrial control systems and SCADA integrations. The goal was to break down the traditional wall between Operational Technology (OT) and Information Technology (IT) teams — a common friction point in utilities organizations.

“Puget Sound Energy is excited to work with Splunk to help us bridge the gap between OT and IT, enabling genuine collaboration between both teams. With Splunk’s data analytics platform, we can better deliver services and manage infrastructure, ultimately enabling us to deliver a seamless experience for our customers.”

— Chris Perez, Advisor and IT Facilities Infrastructure Engineer, Puget Sound Energy

This OT/IT convergence use case is increasingly common across utilities, manufacturing, and critical infrastructure sectors, where historically separate teams manage physical assets and digital systems with little shared visibility.

Sapura Brazil: Real-Time Insights Across Remote Oil and Gas Assets

Sapura Brazil, described as one of the world’s largest integrated oil and gas services and solutions providers, uses Splunk’s enterprise IoT solutions to aggregate and analyze data from complex, geographically distributed systems. The primary benefit cited was the ability to receive real-time information from remote field sites at company headquarters, enabling faster decision-making.

“The use of Splunk in our assets enabled the company to receive real-time information from remote sites to the company’s headquarters, allowing us to take immediate actions when required, with unprecedented celerity. As a result, Sapura is better prepared to fulfill the industry’s high standards and to achieve our targets, not only economically speaking, but especially with regards to quality, health, safety and environment.”

— Rogerio Salbego, CEO, Sapura Brazil

In the oil and gas sector, the cost of unplanned downtime and the safety implications of delayed incident response make real-time data access a high-value capability — not merely a convenience.

Initial Industrial IoT Specialization Partners

At launch, the following partners achieved the Industrial IoT specialization within the Splunk Partner+ Program, each bringing domain expertise in industrial process management, asset management, and operational data:

• Computacenter AG & Co oHG
• ESE Engineering und Software-Entwicklung GmbH
• GrayMatter
• Malisko Engineering, Inc.
• Robotron Datenbank-Software GmbH
• Strategic Maintenance Solutions, Inc.

These partners work directly with shared Splunk customers to design and deliver solutions that address industrial-specific data challenges — from energy monitoring to OT cybersecurity to asset performance management.

Key Takeaways for DevOps and Platform Engineering Teams

For DevOps and platform engineers working in or adjacent to industrial environments, this announcement reflects several broader trends worth tracking:

• OT/IT convergence is accelerating. Tools like Splunk are increasingly being positioned as the bridge between traditionally siloed operational and information technology stacks.
• Vertical specialization in partner ecosystems matters. Generic systems integrators often lack the domain knowledge needed to map industrial data sources to analytics platforms effectively. Vendor-certified vertical specializations help customers identify qualified partners faster.
• Predictive maintenance and real-time monitoring are the primary IoT value drivers. The customer examples cited here — utility SCADA analysis and remote oil and gas asset monitoring — both center on reducing reactive responses in favor of proactive, data-driven operations.
• Security for OT environments is an emerging requirement. The reference to OT cybersecurity in GrayMatter’s comments signals that securing operational networks is increasingly part of the IoT data conversation, not a separate workstream.

About Splunk Inc.

Splunk Inc. (NASDAQ: SPLK) provides a platform for searching, monitoring, and analyzing machine-generated data. Its solutions are used across IT operations, security, and IoT use cases by organizations worldwide. At the time of this announcement in 2019, Splunk positioned its enterprise IoT suite — combining Splunk Enterprise, the Machine Learning Toolkit, and the Industrial Asset Intelligence app — as its primary offering for industrial and IoT customers.

Splunk, Splunk>, Listen to Your Data, The Engine for Machine Data, Splunk Cloud, Splunk Light and SPL are trademarks and registered trademarks of Splunk Inc. in the United States and other countries. All other brand names, product names, or trademarks belong to their respective owners. © 2019 Splunk Inc. All rights reserved.

What Is Azure Dedicated Host?

Microsoft launched a public preview of Azure Dedicated Host, a service that gives organizations exclusive access to physical server hardware in Azure data centers. Unlike standard Azure virtual machines, which run on shared multitenant infrastructure alongside other customers, Dedicated Host allocates an entire physical server to a single organization.

This distinction matters for teams operating under strict compliance or regulatory frameworks — such as HIPAA, PCI-DSS, or government mandates — that require workloads to run on hardware not shared with other tenants.

How It Compares to Competing Cloud Offerings

Azure Dedicated Host was not the first dedicated hardware offering in the major cloud market. Amazon Web Services introduced its Dedicated Hosts product several years earlier, and Google Cloud Platform offers a similar capability through its sole-tenant nodes. Azure’s entry into this space aligns Microsoft more closely with the compliance-focused enterprise workloads both AWS and GCP had already been targeting.

It is also worth clarifying the position of Azure Government: despite its name, Azure Government is a shared cloud environment restricted to government customers, not a single-tenant service. A Microsoft spokesperson confirmed this at the time: “Azure Government is a cloud service that is shared but dedicated to government customers. As a shared cloud service, Azure Government does not provide customers control over the actual VM to physical host mapping.”

Supported Workloads

Azure Dedicated Host supports running both Linux and Windows operating system workloads on Azure virtual machines. SQL Server hosted inside Azure VMs is also supported on Dedicated Host, making it viable for organizations with database compliance requirements.

Hardware Options and Control

Organizations using Azure Dedicated Host have meaningful control over the underlying hardware configuration. Key options include:

• Host type selection: The host type determines the VM series available, RAM capacity, and other hardware characteristics. Only one VM series is permitted per host type.
• VM series mapping: At preview launch, dedicated host type 1 supported Dsv3 and Esv3 Series VMs, while dedicated host type 2 supported Fsv2 Series VMs. Multiple VM sizes within the same series can be mixed on a single host.
• Processor brand and core count: Organizations can select the processor brand and configure the number of cores allocated.

Maintenance Window Control

One of the more operationally significant features of Azure Dedicated Host is granular control over the host-level patching and update process. In a standard multitenant Azure environment, Microsoft manages platform maintenance transparently and on its own schedule. Dedicated Host changes this:

“With an Azure Dedicated Host, you can control all host-level platform maintenance initiated by Azure (e.g., host OS updates). An Azure Dedicated Host gives you the option to defer host maintenance operations and apply them within a defined maintenance window, 35 days. During this self-maintenance window, you can apply maintenance to your hosts at your convenience, thus gaining full control over the sequence and velocity of the maintenance process.”

— Microsoft Azure Dedicated Host announcement

For DevOps and platform engineering teams, this is material: a 35-day deferral window gives teams time to test patches in lower environments before applying them to production hosts, reducing the risk of surprise maintenance impacting availability.

Pricing Model

Azure Dedicated Host pricing is structured differently from standard pay-per-VM billing. Organizations pay for the entire physical host, plus additional hourly costs for running VMs and for the Windows operating system license where applicable. This model means that maximizing host density — running as many VMs as the host type supports — is important for cost efficiency.

Exact host pricing was not detailed in the preview announcement materials. Teams evaluating Dedicated Host should consult the current Azure pricing page directly for up-to-date figures, as rates may have changed significantly since the 2019 preview.

Licensing: Azure Hybrid Benefit and the October 2019 Deadline

Microsoft offered a licensing incentive tied to the Dedicated Host preview, with a notable deadline attached.

Bring Your Own License (BYOL)

Organizations with existing Windows Server and SQL Server licenses could bring those licenses to Azure Dedicated Host using the Azure Hybrid Benefit. This benefit allows on-premises licenses to be applied to Azure infrastructure, potentially reducing the effective cost of running workloads on Dedicated Host.

The October 1, 2019 Cutoff

For licenses purchased before October 1, 2019, Software Assurance coverage was not required to use them with Dedicated Host. After that date, Software Assurance became a requirement. This deadline also applied to organizations hosting software with Microsoft’s designated Listed Providers, which at the time included Microsoft, Alibaba, Amazon (including VMware Cloud on AWS), and Google. Organizations hosting with other providers were not affected by these changes.

Note: The October 2019 deadline has now passed. Teams evaluating Azure Dedicated Host today should review current Microsoft licensing documentation for Azure Hybrid Benefit eligibility requirements.

Is Azure Dedicated Host Right for Your Workloads?

Azure Dedicated Host is best suited for organizations that:

• Have regulatory or compliance requirements mandating single-tenant hardware isolation
• Need deterministic control over when host-level maintenance is applied
• Want to apply existing Windows Server or SQL Server licenses to cloud infrastructure via Azure Hybrid Benefit
• Are running workloads in VM series supported by available host types (Dsv3, Esv3, Fsv2 at launch)

Teams without hard compliance requirements for physical isolation will typically find standard Azure VMs more cost-effective, since the shared-hardware model allows for much finer-grained resource allocation and billing.

Azure Dedicated Host has since moved beyond preview into general availability. Refer to the official Azure Dedicated Host product page for current supported VM families, regions, pricing, and SLA details.

The Root Problem: Preconceived Notions on Both Sides

Security teams have long carried the reputation of being “out of process” — adding requirements, complicating workflows, and disrupting delivery velocity. At the same time, developers are frequently characterized as reckless engineers who treat security as someone else’s problem.

“In many organizations, the teams rarely interact, and the group reputation precedes the meeting. Security is ‘Dr. No’ and app dev is ‘rogue, ignoring security,'” says Matt Keil, director of product marketing at Cequence Security. “The reality is that building security into the development process — be it agile, DevOps, DevSecOps, or a mix thereof — remains a significant challenge for many reasons, beginning with the group relationship.”

These entrenched attitudes make integrating security into the software development life cycle (SDLC) an uphill battle. The solution may lie not in adopting a new acronym or tool, but in fundamentally reframing how organizations think about the problem.

Is Automation the Answer?

One commonly proposed fix is automation — embedding security checks directly into the CI/CD pipeline so they run without requiring manual intervention or cross-team handoffs. Matt Rose, global director of application security strategy at Checkmarx, argues this approach works precisely because it removes the friction of labels and separate workflows.

“When you integrate and use security as part of that automation associated with the DevOps pipeline and continuous integration orchestration, it works much better,” Rose says. “Automation at CI is the key aspect — the conductor of the symphony orchestra.”

Rose identifies four disciplines within a mature DevOps practice where security tooling can be embedded:

• Development: Static analysis (SAST), secrets scanning, and secure coding linting tools run in the IDE or pre-commit hooks.
• Continuous Integration (CI): Automated security tests — SAST, software composition analysis (SCA), and dependency checks — execute on every build.
• Continuous Delivery (CD): Dynamic analysis (DAST) and infrastructure-as-code scanning run against staging environments before promotion.
• Production: Runtime application self-protection (RASP), threat detection, and continuous monitoring provide ongoing visibility.

“You look at those building blocks, and there are different security technologies that slot themselves within each of those disciplines,” Rose says. “It’s about understanding where to integrate, but people make it much more difficult by putting different labels on security. When you look to architect a DevSecOps pipeline, you basically insert the right technologies at the right points in the DevOps process.”

The common “shift left” directive — catching vulnerabilities earlier in the cycle — is useful, but Rose argues it is incomplete. A healthy DevOps pipeline is a continuous loop, not a linear relay race, and security needs to be present at every stage, not just the earliest ones.

Where Does “Sec” Actually Fit In?

Since development and operations first converged to share responsibility and accountability, other business units — including security — have attempted to create their own derivative of the model. Kelly Shortridge, VP of product strategy at Capsule8, argues this is precisely where things go wrong.

“I think we need to discuss a DevOps-centric approach to security rather than trying to figure out a security-centric approach to DevOps,” she says. “SecDevOps is a vendor-driven term that gives a false sense of comfort for security teams so that it seems they are actually doing something to fit into the DevOps world.”

Shortridge’s point is that DevOps is fundamentally a mindset — a collaborative approach to optimizing software delivery and operational performance. Security teams that automate a handful of tasks and declare themselves “DevOps-enabled” are missing the deeper shift required.

“Security has to shift to thinking about how it can improve software delivery performance and how it can start unifying that responsibility and accountability,” she explains. “It takes a lot more work than what I’ve seen commonly, which is supporting the old threat models and controls with new technologies and trying to steamroll the DevOps team by trying to shove all the security testing into the software development life cycle.”

The biggest practical step, Shortridge says, is ensuring security priorities are aligned with business priorities — not just compliance checklists or internal audit requirements.

Changing the DevOps Narrative

The framing of “integrating security into DevOps” carries an implicit assumption: that DevOps teams do not think about security on their own. Julien Vehent, security engineering manager at Mozilla, pushes back on that assumption.

The “move fast and break things” culture so often associated with DevOps was, he explains, largely a symptom of early-stage startups operating with minimal risk exposure. Large enterprises adopting DevOps practices have a different risk profile entirely — they want speed, but they cannot afford to break things.

“These companies have adopted DevOps but have also made sure to integrate security in their quality assurance and testing processes to make sure that they can go fast without breaking things,” Vehent says.

This reframes the challenge: it is not that DevOps is inherently insecure, but that the cultural story told about DevOps has given security teams an excuse to position themselves as an external corrective force rather than embedded partners.

A Real-World Culture Change: The Malwarebytes Example

One of the more concrete examples of culture-driven change comes from Malwarebytes. Mark Patton, senior vice president of engineering at Malwarebytes, describes how the company addressed its DevSecOps gap not by purchasing new tooling, but by creating a dedicated team with a specific charter.

“At Malwarebytes, we did not have good SecDevOps until I created a group within engineering that had the specific charter of ensuring the ‘ops’ and ‘sec’ part of SecDevOps was owned and done properly,” Patton says. “We named the team ‘Site Reliability Engineering,’ and they were the bellwether team that changed the culture of engineering from within.”

The SRE team operated under a clear, memorable mantra: 100% uptime, 0% breaches, optimize cost. That three-part principle gave the team a framework for prioritization and a way to communicate their value to the broader engineering organization without resorting to security jargon.

In practice, the team:

• Reshaped how environments were provisioned and deployed.
• Reworked deployments to use more cost-effective AWS services.
• Showed developers how to architect cloud systems to balance security and cost.
• Implemented security monitoring that routed alerts directly to the appropriate owners.

The process was not frictionless — finding qualified talent and winning over skeptical engineers were both significant challenges. But Patton notes that the results eventually converted even the most reluctant team members.

Leave Your Ego at the Door

Ultimately, closing the gap between security and DevOps demands concessions from both sides. Security teams must be willing to relinquish manual gatekeeping in favor of automated controls that do not block delivery. Development teams must accept that security feedback is not an adversarial review but an enabler of sustainable velocity.

“Security teams need to be willing to loosen the security change control reins, allowing automation to play a larger role in their process,” Keil says. “Security teams also need to look outside of their existing toolset to ensure they have the right mix for their current and future application architectures.”

Jonathan Deveaux, head of enterprise data protection at comforte AG, frames the ideal outcome clearly: the shift to closer collaboration “promotes teams to move from viewing security inclusion as a blocker to instead viewing security as an enabler to getting their code into production.”

Key Takeaways for DevOps and Security Teams

• Culture precedes tooling. No security tool will bridge teams that do not communicate or share priorities. Address the relationship first.
• Embed security in the pipeline, not around it. Security gates that exist outside the CI/CD loop become bottlenecks. Automated checks that run inline become part of normal workflow.
• Align security priorities with business priorities. Security programs that cannot articulate their value in terms of delivery speed, uptime, and cost will remain marginalized.
• Avoid acronym proliferation. DevSecOps, SecDevOps, and similar labels can obscure the real goal: a single, integrated engineering culture where security is everyone’s responsibility.
• Change from within. As the Malwarebytes example illustrates, embedding security-minded engineers inside the engineering organization — rather than keeping them in a separate security silo — can be more effective than any top-down mandate.

Overview

Misconfigured Jira instances operated by well-known technology companies, government bodies, and educational institutions were found to be exposing sensitive internal data to unauthenticated users on the public internet. The exposure included employee names, email addresses, job roles, and details about ongoing projects — information that could be exploited for reconnaissance, targeted phishing, or competitive intelligence gathering.

The issue was discovered and disclosed by Avinash Jain, a security engineer, who reported findings to affected organisations including NASA and the United Nations. BleepingComputer independently verified that the misconfigured instances could be located using advanced search operators (commonly known as Google Dorks).

What Is Jira and Why Does It Hold Sensitive Data?

Jira, developed by Atlassian, is one of the most widely adopted project management and issue-tracking platforms in the world. Agile engineering teams use it to track tasks, bugs, sprints, and releases. Because Jira sits at the heart of development workflows, it inevitably contains details about internal projects, team structures, personnel, and organisational priorities — making it a high-value target if access controls are misconfigured.

The Root Cause: A Visibility Misconfiguration

According to Jain, the core problem lies in how Jira Cloud handles the default visibility setting for filters and dashboards. When a user creates a new filter or dashboard, the default sharing option is set to “All”. Many administrators and users reasonably interpret this to mean “all members of the organisation,” but in practice it means all users on the internet — including unauthenticated visitors.

Two configuration paths contribute to this exposure:

• Public filter and dashboard sharing: Jira Cloud allows filters and dashboards to be shared with a “Public” option. Atlassian’s own documentation warns that “if a filter or dashboard is shared with Public, the name of the filter or dashboard will be visible to anonymous users.” Many organisations enabled this without realising the full scope of what becomes accessible.
• Global Permissions — “Anyone” access: In the Global Permissions menu, administrators can grant access to users who are not logged in by selecting “Anyone” from a drop-down list. Atlassian’s documentation explicitly notes this is not recommended for systems accessible from the public internet, such as Jira Cloud. Despite this warning, many organisations left this setting enabled.

Once anonymous access is enabled at either level, Jira’s built-in user picker functionality can be used to retrieve a complete list of usernames and email addresses registered on that instance — without any authentication required.

How Misconfigured Instances Were Discovered

Jain used Google Dorks — carefully crafted search queries that leverage advanced Google search operators — to identify publicly accessible Jira instances exposing user and project data. This technique requires no special tools or credentials; it relies entirely on data that search engines have already indexed from misconfigured public-facing servers.

BleepingComputer confirmed that applying these search operators surfaced government domains, private companies, and educational institutions among the affected instances. The breadth of exposure was significant: Jain reported finding misconfigured Jira accounts across hundreds of companies, including organisations listed in the Alexa and Fortune top rankings.

“Thousands of companies’ filters, dashboards and staff data were publicly exposed. I have discovered several such misconfigured JIRA accounts in hundreds of companies. Some of the companies were from Alexa and Fortune top list including big giants like NASA, Google, Yahoo, etc and government sites.”

— Avinash Jain, Security Engineer

Organisations Affected

Named organisations reported to have been affected at the time of discovery included Google, Yahoo, NASA, Lenovo, 1Password, Zendesk, and a number of government bodies worldwide. Jain responsibly disclosed his findings to affected parties. Notable acknowledgements he received include:

• NASA: A previously discovered misconfigured Jira server exposed the names and email addresses of approximately 1,000 users. Jain reported this responsibly and was recognised by NASA.
• United Nations: The UN acknowledged Jain’s disclosure and recognised his role in improving their security posture.
• CODIX: A financial software solution used by European Union institutions and agencies, which also recognised Jain’s responsible disclosure.

Why This Matters: Reconnaissance and Attack Surface

Leaking employee names, email addresses, and project details may not seem as immediately dangerous as exposing passwords or financial records, but this data is highly valuable for attackers in the early stages of an attack:

• Spear phishing: Knowing which employee works on which project — and their email address — enables highly targeted phishing emails that are far more convincing than generic attempts.
• Social engineering: Role and project information helps attackers impersonate colleagues or vendors credibly.
• Competitive intelligence: Exposed project names, sprint goals, and task descriptions can reveal product roadmaps and strategic initiatives to competitors.
• Credential stuffing preparation: A validated list of real email addresses from an organisation can be fed directly into automated credential stuffing attacks against other services.

How to Audit and Fix Jira Visibility Settings

Jira administrators should review the following settings to close these exposure paths:

1. Review Global Permissions

Navigate to Settings → System → Global Permissions. Check whether “Browse Users” or “Use Jira” permissions are granted to “Anyone (including anonymous users).” Remove anonymous access unless there is a documented and deliberate reason to allow it.

2. Audit Filter and Dashboard Sharing

Review all shared filters and dashboards. Any item shared with “Public” or “All” should be reassessed. Change sharing to specific groups or projects rather than organisation-wide or public defaults.

3. Disable Anonymous Access to Projects

For each project, check Project Settings → Permissions. Ensure that “Browse Projects” is not granted to “Anyone” unless the project is intentionally public-facing.

4. Restrict User Picker Access

The user picker API endpoint can enumerate all users on an instance when anonymous access is enabled. Restricting anonymous access at the Global Permissions level prevents unauthenticated enumeration.

5. Use Atlassian’s Built-in Security Advisor

Jira Cloud includes a Security Advisor tool under site administration that flags common misconfigurations, including overly permissive anonymous access settings. Run this regularly as part of routine security reviews.

Key Takeaways for DevOps and Platform Teams

• Default settings in SaaS tools are not always secure by default — always validate permission configurations after initial setup and after major upgrades.
• “Visible to all” in a cloud tool frequently means the entire internet, not just your organisation. Read documentation carefully.
• Regularly audit third-party project management and collaboration tools as part of your organisation’s attack surface management programme.
• Google Dorks are a free, low-skill method attackers use to find misconfigured systems. If an attacker can find your Jira instance this way, you will want to know before they do.
• Responsible disclosure by external researchers is valuable — organisations should have a clear vulnerability disclosure policy and acknowledge reports promptly.

What Is ClearDATA Locate?

ClearDATA, a healthcare-focused cloud security and compliance vendor, announced ClearDATA Locate, a multi-cloud SaaS product designed to give healthcare organizations a traceable, continuously updated inventory of their Protected Health Information (PHI) as it moves through Kubernetes-based workloads.

The solution is available on the three major public cloud platforms: Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. It is built on ClearDATA’s proprietary Healthcare Aware Distributed Tracing technology, which was first unveiled at HIMSS 2019 earlier that year.

The Core Problem: PHI Visibility in Microservices Architectures

As healthcare organizations have migrated workloads to the public cloud, sensitive patient data — including names, addresses, Social Security numbers, payment details, and health records — is routinely distributed across containerized microservices. This architecture improves scalability and agility, but it also introduces a significant compliance challenge: it becomes difficult to know exactly where PHI resides at any given moment, whether in transit or at rest.

Traditional monitoring and logging approaches are not purpose-built to track healthcare data as it flows between containers and services within a Kubernetes cluster. Without fine-grained tracing, a single security incident can appear to affect every record in a system — even when only a small subset was actually exposed.

“We’ve come a long way since healthcare was at odds with the public cloud. However, the ability to track sensitive data as it moves from point A to Z was missing from the narrative and represented a huge vulnerability for healthcare organizations.”

— Matt Ferrari, Chief Technology Officer, ClearDATA

How ClearDATA Locate Works

ClearDATA Locate uses distributed tracing — a technique borrowed from general observability practices and adapted specifically for healthcare data compliance — combined with machine learning to identify and track PHI as it passes through Kubernetes applications.

Key capabilities described by the company include:

• PHI inventory tracking: Builds and maintains a continuously updated inventory of where patient data lives across multi-cloud Kubernetes environments.
• Data-in-transit and data-at-rest visibility: Observes sensitive data regardless of whether it is moving between services or stored within a container workload.
• Breach scoping: When a security incident occurs, enables teams to identify the precise records that were exposed rather than assuming all records in the system were compromised.
• Compliance support: Assists organizations in meeting requirements under HIPAA and frameworks such as GDPR, including the “Right to be Forgotten,” by providing an accurate map of where specific patient data has traveled.
• Audit readiness: Produces traceable data flow records that can support audits by regulators such as the HHS Office for Civil Rights (OCR).

The Compliance and Financial Case

Healthcare data breaches carry some of the highest per-record costs of any industry, and HHS OCR fines for HIPAA violations can be substantial. One of the most costly aspects of a breach notification response is over-notification: when an organization cannot determine exactly which records were accessed, it must notify every patient whose data could theoretically have been exposed.

“Today, if you routinely process tens of thousands of patient records through your application, you would have to notify all those patients of a suspected breach when, in reality, only 200 records may have been impacted. ClearDATA Locate can dramatically change the outcome for healthcare organizations and patients.”

— Matt Ferrari, CTO, ClearDATA

By narrowing the scope of affected records with precision, ClearDATA Locate aims to reduce both the direct costs of breach notification and the potential scale of regulatory penalties. It can also limit reputational damage to healthcare providers, payers, and life sciences organizations by demonstrating to regulators and patients that the organization has strong data governance controls in place.

Target Audience

ClearDATA Locate is aimed at three primary segments of the US healthcare industry that regularly handle large volumes of PHI within cloud-native applications:

• Healthcare providers (hospitals, health systems, clinics)
• Payers (insurance companies and managed care organizations)
• Life sciences organizations (pharmaceutical companies, clinical research organizations)

Technology Background: Healthcare Aware Distributed Tracing

The underlying Healthcare Aware Distributed Tracing technology was introduced by ClearDATA at the HIMSS 2019 conference. The approach adapts distributed tracing concepts — well established in DevOps and site reliability engineering for performance monitoring — to the specific requirements of healthcare data governance. By tagging and following PHI through each hop in a microservices pipeline, the system can reconstruct the full data journey for compliance and forensic purposes.

Machine learning is applied to help classify and identify sensitive data patterns automatically, reducing the burden on engineering teams who might otherwise need to manually annotate every data field that could constitute PHI.

Relevance for DevOps and Platform Engineering Teams

For DevOps and platform engineers working in regulated healthcare environments, ClearDATA Locate represents an attempt to shift compliance controls left into the infrastructure layer rather than relying solely on application-level controls. Key points of interest include:

• The solution operates at the Kubernetes workload level, meaning it can be integrated alongside existing container orchestration workflows without requiring changes to individual application codebases.
• Multi-cloud support across AWS, GCP, and Azure aligns with how many larger healthcare organizations operate — using more than one cloud provider for different workloads or as a risk mitigation strategy.
• Continuous inventory updates reflect the dynamic, ephemeral nature of containerized workloads, where pods and services spin up and down frequently.

Teams evaluating this type of tooling should also consider how it integrates with existing observability stacks (such as Prometheus, Jaeger, or cloud-native tracing services) and how PHI tagging and classification rules are configured and maintained over time.

Amazon Web Services, Inc. (AWS) announced the opening of the AWS Middle East (Bahrain) Region. Starting today, developers, startups, and enterprises, as well as government, education, and non-profit organizations can run their applications and serve end-users from data centers located in the Middle East, as well as leverage advanced technologies from the world’s leading cloud, to drive innovation. Customers can get started today at: aws.amazon.com/local/middle_east/bahrain

Tens of thousands of customers and partners across the Middle East are already innovating on AWS, including Al Tayer Group, Anghami, Aramex, Bahrain Bourse, Bahrain iGA, Careem, Classera, Dubizzle, Emirates NBD, Fetchr, Flydubai, Hassan Allam, Mawdoo3.com, MBC Group, Opensooq, OSN, Seera Group, Union Insurance, Virgin Middle East, and many more

“The cloud has the chance to unlock digital transformation in the Middle East,” said Andy Jassy, CEO, Amazon Web Services. “Today, we are launching advanced and secure technology infrastructure that matches the scale of our other AWS Regions around the world and are already seeing strong demand in the Middle East for AWS technologies like artificial intelligence and machine learning, data analytics, IoT, and much more. We are excited to see how our cloud technology will provide new ways for governments to better engage with citizens, for enterprises to innovate for their next phase of growth, and for entrepreneurs to build businesses and compete on a global scale.”

The new AWS Middle East (Bahrain) Region offers three Availability Zones at launch. AWS Regions are composed of Availability Zones, which each comprise at least one data center and are located in separate and distinct geographic locations with enough distance to significantly reduce the risk of a single event impacting business continuity, yet near enough to provide low latency for high availability applications. Each Availability Zone has independent power, cooling, and physical security and is connected via redundant, ultra-low-latency networks. AWS customers focused on high availability can design their applications to run in multiple Availability Zones to achieve even greater fault-tolerance. AWS infrastructure Regions meet the highest levels of security, compliance, and data protection.

Customers and APN Partners welcome the new AWS Middle East (Bahrain) Region

Millions of active customers are using AWS each month in over 190 countries around the world, including tens of thousands of customers in the Middle East and North Africa (MENA). Startups like Alef Education, Almentor, Altibbi, Anghami, Bayt.com, BitOasis, Babil Games, Bey2ollak, Boutiqaat, Careem, Classera, Clicksco, Crowd Analyzer, Dubizzle, EKar, Elephantsocial, Fetchr, Fish.me, Haraj, Health at Hand, Jeeny, Little Thinking Minds, Maestro Pizza, Mawdoo3.com, Mrsool, Naseej, Ngwa, Opensooq, Property Finder, Sarwa, Souqalmal, StarzPlay, Tajawal, ToDoorStep, Ureed, Vezeeta, and Yallacompare are building their businesses on top of AWS, enabling them to scale rapidly and expand around the world.

Enterprises across the region are moving to AWS to become more agile and innovate, and include Al Jouf Cement, Al Tayer Group, Arab Banking Corporation (Bank ABC), Aramex, Bahrain Bourse, Bank Al-Etihad, Batelco, Emirates NBD, Flydubai, Gulf News, Hassan Allam, Lulu International Exchange, MBC Group, OSN, Seera Group, Union Insurance, Virgin Middle East, and many more.

Public sector organizations, including Government of Bahrain’s Ministries, such as the Ministry of Education, Ministry of Finance, Ministry of Information Affairs, Ministry of Labor and Social Development, and Bahrain iGA, as well as other public sector organizations such as Bahrain Polytechnic, Communications and Information Technology Regulatory Authority of Kuwait (CITRA), Mumtalakat, Paris Sorbonne AD, Tamkeen, University of Bahrain, and many more are also using AWS to drive cost savings, accelerate innovation, and better serve the citizens of the region.

Government organizations are also working with AWS to lower costs and better serve citizens in the region. The Bahrain Information & eGovernment Authority (iGA) is responsible for ICT procurement for the Bahrain government and is leading the government’s migration project to support the country’s Cloud First policy. iGA’s Chief Executive Mohammed Ali AlQaed said, “Bahrain is committed to becoming a country in the cloud and we will be able to accelerate our journey with the launch of the AWS Region in Bahrain. By December of this year, we will have 30 percent of all 72 government entities migrated to AWS and by June 2020, we expect to have most government data centers shut down, while the rest are minimized allowing us to focus resources on projects that benefit our citizens and dramatically improve the overall availability and durability of government applications and data.” An example of a government entity that turned to the agility and speed of AWS is Bahrain’s National Bureau of Revenue (NBR), who needed to quickly and efficiently launch the country’s Value Added Tax (VAT) system.

Rana Faqihi, Assistant Undersecretary for Development and Revenue Policies at Bahrain Ministry of Finance, said, “The National Bureau of Revenue needed a solution that would enable a seamless VAT rollout, without delays and with the highest levels of security. By launching SAP S/4 Hana on AWS, the NBR was able to go to market in just under two months while lowering costs by 40 percent. Eliminating the need to manage IT infrastructure allowed us to focus on successfully reaching an important milestone in Bahrain’s economic development. The launch of the new AWS Region in Bahrain is allowing public and private sector organizations to realize the full potential of the cloud.”

Investing in the future of the Middle East

The new AWS Middle East (Bahrain) Region adds to the infrastructure investments AWS has been making across the Middle East, to provide customers with advanced and secure cloud technologies. Today, AWS is also launching a new AWS Direct Connect location in Bahrain, which is the first to be operated by AWS, joining the two AWS Direct Connect locations and two Amazon CloudFront Edge locations in the UAE that launched in 2018. AWS Direct Connect makes it easy for customers to establish a dedicated private network connection between AWS and their data center, office, or colocation environment. Amazon CloudFront gives customers an improved experience for their end users, including faster content delivery and added cybersecurity protection.

For students and educators, the AWS Educate and AWS Academy programs are providing free resources to accelerate cloud-related learning and preparing today’s students in the Middle East for the jobs of the future.

Growing Entrepreneurship in the Middle East

To help grow the next generation of businesses in the Middle East, AWS is supporting startups across the region through the AWS Activate Program. Working with accelerators, angel investors, incubators, government organizations, and Venture Capital firms, AWS Activate provides resources to help startups launch their businesses on AWS and go global in minutes. Across the Middle East, AWS has been working with organizations such as 500 startups, Area 2071 in Abu Dhabi, BADIR in Saudi Arabia, BECO Capital, EDB in Bahrain, Flat6Labs, Hive, MEVP, Oasis500, Seed Stars, Startupbootcamp, Techstars, and many more, providing startups with AWS credits, in-person technical support, AWS trainings, and go-to-market help.

I recently had the pleasure of moderating a lively discussion with security leaders at the SINET Innovation Summit 2019 in New York. The conversation explored one central question: Can security and DevOps coexist? 

DevOps is a well-adopted practice that fosters an agile relationship between development and IT operations by advocating better communication and collaboration between these two business units. Every organization represented on the panel (including two of the largest financial services companies) have mature DevOps programs with security baked into their practices.

I’ll provide my own insights on this topic, lay out key takeaways from the discussion and address challenges companies face as they adopt secure DevOps. 

Second Place Is The First Loser: Security Works To Win the Race

We have arrived at an inflection point for the modern software development life cycle. The conjoining of the engineering side of many organizations with IT operations has been a necessity in the age of rapid digital transformation. DevOps, the agile relationship between the two, has led many development and operation groups to excel at swiftly iterating and delivering new software products and updates across devices, applications, networks and more. As an example, Netflix engineers allegedly release code thousands of times every day to stay ahead of fierce competitors like Hulu and Amazon Prime. 

A common trait of the organizations represented on the panel is the understanding of — and execution on — the fact that security needs to be inserted into DevOps to ensure that it does not get left behind. 

No company can escape the impact software innovation is having on their business, so they can’t compete if they aren’t investing in software development. At one of the companies represented on the panel, the CIO recently took on the responsibility of managing the entire development team, which is growing by leaps and bounds.

As development and IT (and security by extension) are increasingly coming together under the CIO, the security leaders on the panel were clear that inserting security into DevOps is a mindset and a shared responsibility. Within their organizations, everyone involved in the process has a role to play when it comes to enhancing security. For example, application architects who are responsible for the very first phase of DevOps — the application’s requirements — have a great vantage point to do certain aspects of security that cannot be done anywhere else.

We also discussed the notion of following a blueprint of “shifting security left” in the modern software development lifecycle instead of doing security at the end. It didn’t work yesterday and it won’t work as we continue to move toward a world where the only way to beat the competition is to deliver new functionality to your customers faster and securely.

Avoid Cloud Vendor Lock-In

Panelists also emphasized that deploying applications in hybrid- and multicloud environments as a way to create seamless, automated and secure environments for larger institutions while avoiding cloud vendor lock-in. If we consider this from a DevOps perspective, during deployments, it is critical for companies to mimic processes across all clouds to ensure that security is influential. 

Application Security Becomes Key, But It Can’t Be A Burden

One reality many participants face when integrating security with DevOps is the cost of managing security. Billions are spent on network and endpoint security today. The problem is that when organizations are developing software and deploying in the cloud, all of those tools become far less valuable. This is when application security becomes key. 

Inserting security into DevOps has to make it easy for developers. As they move faster, they can’t be burdened by waiting for and interpreting scan results to fix vulnerabilities. 

Software code has two states — a source code form and a running-in-production form. If we bridge the knowledge of both of these states, we can address the security of this explosion of code much more easily and accurately in the midst of the agile software development life cycle, all without burning out the development team. 

Convert Security Requirements Into Code

A significant reason that DevOps adoption is growing is that much of what IT has done historically is now automated through code. In the past, when a new application was ready for production, IT needed to manually buy or provision a server, deploy it and install the application. Now they use code to provision a server on Amazon Web Services or Azure and run the application, almost automatically. What used to take days now takes minutes or seconds.

Something similar needs to happen with security within DevOps. Determining the security requirements for a particular app today is very manual: Security will ask developers what kind of data the app handles and then provide the requirements (e.g., requirements for a mobile banking app are very high). Successful organizations use application security tools to scan the application to determine the data it handles and convert requirements into code automatically. 

Don’t Overlook The Software Supply Chain

More and more applications that companies build today use third-party software, including open source libraries and frameworks (in the case of one company we work with, up to 80-90% of an application’s code comes from third parties). The concern is that if developers use more third-party software, it creates more paths for bad actors to hack an application. The discussion among the panelists on this point focused on ensuring that the software supply chain is taken into account as part of inserting security into the DevOps process. 

When reflecting on the SINET conversation as a whole, it was great to see how some of the largest and most influential companies are viewing the intersection of DevOps and security and the steps being taken to bridge the gap between the two. My subsequent articles for this column will dig deeper into the takeaways summarized here.

Elastic Brings Managed Elasticsearch to GCP Tokyo

Elastic N.V. (NYSE: ESTC), the company behind Elasticsearch and the Elastic Stack, announced in August 2019 that Elasticsearch Service on Elastic Cloud became available in a fifth Google Cloud Platform (GCP) region: Asia Pacific (Tokyo). This made Tokyo the first GCP region for Elastic in Asia Pacific, complementing four other GCP regions the company already operated globally at the time of the announcement.

The expansion was driven by growing demand from Japanese enterprises and SMBs modernising their IT infrastructure — moving workloads off on-premises, traditional data centres and onto public cloud platforms.

“Google Cloud Platform (GCP) has a growing presence in Japan and we’re excited to partner with Google. This new GCP Tokyo region for Elasticsearch Service will give Japan customers a SaaS-first solution for their search, logging, APM, business analytics, infrastructure monitoring, security use cases and more.”

— Tom Kawasaki, Elastic Japan Country Manager

What Is Elasticsearch Service on Elastic Cloud?

Elasticsearch Service on Elastic Cloud is the official hosted Elasticsearch and Kibana offering, built and supported by Elastic themselves. As a fully managed service, it abstracts away cluster administration so teams can focus on their data and applications rather than operational overhead.

Key capabilities included at the time of this announcement:

• Elastic APM — Application performance monitoring integrated directly into the stack
• Elastic SIEM — Security information and event management for threat detection and response
• Elastic Maps — Geospatial visualisation within Kibana
• Canvas — Custom, live infographic-style presentations of data
• Machine learning — Anomaly detection and forecasting built into the platform
• Same-day version and security patch availability
• Zero-downtime upgrades
• Pre-configured hardware templates optimised for common use cases
• Direct support from Elastic

All of these features were made available immediately in the new Asia Pacific (Tokyo) region, consistent with Elastic’s other regional deployments.

Why the Tokyo Region Matters for Asia Pacific Customers

Running Elasticsearch clusters in-region reduces network latency for end users and applications hosted in Japan and nearby Asia Pacific markets. It also helps organisations meet data residency and compliance requirements that may mandate data remain within specific geographic boundaries.

Industries with particularly strong demand for low-latency search, real-time analytics, and log management — such as gaming, e-commerce, and financial services — stand to benefit directly from regional availability.

“As a GCP partner as well as an Elastic partner, we’re extremely excited to start using the Elasticsearch Service on the GCP Tokyo region. The gaming industry and other industries in Japan will greatly appreciate this announcement.”

— Yusuke Hasegawa, President and CEO, grasys Inc.

Deepening the Elastic–Google Cloud Partnership

The Tokyo launch was part of a broader, multi-year strategic partnership between Elastic and Google Cloud. At the time of the announcement, several additional integration milestones were either completed or in progress:

Next GCP Region: Sydney, Australia

Elastic announced that the next planned GCP region would be in Sydney, Australia, further expanding Asia Pacific coverage.

Native GCP Console Integration

Elasticsearch Service was being positioned as a Managed Partner Service (MPS) within the main GCP Console — the same interface where native Google services are provisioned. The planned integration would allow lifecycle operations such as creating, scaling, configuring, and reconfiguring Elasticsearch clusters using familiar GCP-style workflows, without leaving the GCP Console.

Integrated Billing Through GCP Marketplace

GCP customers were set to be able to provision Elasticsearch Service through the GCP Marketplace and have that spend count fully towards their existing Google Cloud committed spend. This simplifies procurement significantly for enterprises with pre-negotiated GCP contracts.

“Google Cloud and Elastic are both committed to the open source community and are excited to announce the expanded availability of Elastic Cloud in GCP’s Tokyo region, and unified billing, coming soon. This brings simplicity and speeds up the time to value realization for joint customers.”

— Masato Takahashi, Director, Partnerships, Google Cloud Japan

“New regions like Tokyo and Sydney, seamless access to the Elasticsearch Service through the Google Cloud Platform Console, and billing through Google Cloud, which is targeted for release this August, are all examples of our mutual investments to create a great user experience in the cloud.”

— Craig Griffin, Vice President of Business Development, Elastic

Getting Started with Elasticsearch Service on GCP Tokyo

The following guidance was provided at the time of the announcement:

• Existing Elasticsearch Service users: Log in to Elastic Cloud and select the Asia Pacific (Tokyo) GCP region when creating a new deployment.
• Migrating self-managed workloads: Elastic’s documentation and migration webinars provide guidance on moving from self-hosted Elasticsearch to the managed service.
• New users: A 14-day free trial was available, requiring only an email address to get started.

About Elastic

Elastic is a search company and the creator of the Elastic Stack — comprising Elasticsearch, Kibana, Beats, and Logstash. Elastic builds both self-managed and SaaS offerings designed to make data usable in real time and at scale across search, logging, security, and analytics use cases.

Elastic and associated marks are trademarks or registered trademarks of Elastic N.V. and its subsidiaries. All other company and product names may be trademarks of their respective owners.

Overview

VMware and Google announced a partnership to run VMware workloads natively on Google Cloud Platform (GCP). The agreement builds on both companies’ hybrid cloud ambitions and mirrors similar arrangements VMware already has with Amazon Web Services and Microsoft Azure. For enterprise IT and DevOps teams managing VMware estates, this opens a credible path to GCP without re-platforming workloads.

What the Partnership Delivers

Under the arrangement, organizations can run core VMware stack components on GCP, including:

• VMware vSphere — server virtualization
• VMware NSX — software-defined networking
• VMware vSAN — hyper-converged storage

These components run as part of VMware Cloud Foundation on a platform operated by CloudSimple, a VMware partner that provides dedicated, bare-metal VMware environments inside GCP. CloudSimple handles the provisioning and administration layer, so teams interact with familiar VMware tooling rather than raw GCP primitives.

Broader Google–VMware Integration Points

This workload-portability deal is one layer of a wider integration between the two companies. Other active collaboration areas at the time of the announcement included:

• NSX and SD-WAN on GCP — an earlier partnership to support Google Cloud networking with VMware NSX and SD-WAN capabilities.
• Google Cloud Anthos — a joint effort enabling applications to run across on-premises environments and multiple clouds, with VMware providing the on-prem virtualization layer.
• vRealize Automation plug-in — a Google Cloud plug-in for VMware vRealize Automation, allowing teams to provision and manage GCP resources from within the familiar vRealize interface.
• Kubernetes (2017) — VMware and Google partnered on Kubernetes support in 2017, with Pivotal also involved. Both VMware and Pivotal were under Dell’s ownership at the time.

How This Fits VMware’s Multi-Cloud Strategy

The Google Cloud expansion completes a three-hyperscaler picture for VMware:

For DevOps and infrastructure teams, this multi-cloud consistency is significant. It means a VMware-based operating model — familiar tooling, consistent networking policies via NSX, and unified storage — can in principle extend across all three major public clouds without requiring workload re-architecture.

Implications for Telco and Network Virtualization

While the partnership was framed as an enterprise story, it carries meaningful implications for telecommunications operators. Telcos were actively evaluating hybrid cloud architectures to host network functions virtualization (NFV) workloads at the time. VMware had already established telco network virtualization as a strategic priority, and the combination of VMware’s NFV capabilities with GCP’s global infrastructure and Anthos’ multi-cloud management layer made the joint offering attractive for carriers exploring hybrid cloud-native network deployments.

Key Takeaways for DevOps and Infrastructure Teams

• If your organization runs VMware on-premises and evaluates GCP, the CloudSimple-based VMware Cloud Foundation on GCP reduces migration friction by preserving existing operational tooling.
• Google Cloud Anthos, reinforced by VMware’s on-prem virtualization layer, provides a common control plane for hybrid and multi-cloud application management.
• vRealize Automation’s GCP plug-in means infrastructure-as-code and self-service portal workflows can span on-premises VMware and GCP from a single tool.
• VMware’s consistent presence across AWS, Azure, and GCP gives enterprises genuine flexibility to choose or distribute workloads across hyperscalers without abandoning their VMware investment.

This article summarizes reporting and announcements from July 2019. Product names, partnership structures, and service availability may have changed since then. Verify current offerings with VMware and Google Cloud documentation.

DevOps and MSPs: A Primer

Managed Service Providers (MSPs) are companies that deliver IT services to client organizations on a contract basis. MSPs are typically engaged by organizations that want to outsource some or all of their IT functions—reducing the need to hire, train, and retain in-house IT staff.

DevOps is a software delivery philosophy and cultural practice that emphasizes close collaboration between development and IT operations teams. Its core goals include shorter release cycles, continuous feedback loops, shared responsibility, and iterative improvement across the full software delivery lifecycle.

Both the MSP market and DevOps adoption have been growing steadily within the IT industry. The fundamental question is whether an organization can pursue both at the same time—or whether choosing one means limiting the other.

Where DevOps and MSPs Work at Cross-Purposes

The core tension is straightforward: DevOps requires direct control over IT operations culture, tooling, and process. When you outsource IT operations to an MSP, you typically hand that control to a third party.

MSP clients generally do not dictate which tools, workflows, or cultural practices their provider uses internally. The MSP manages those decisions. This creates a structural barrier to DevOps adoption:

• No in-house Ops team: If your entire IT operations function is outsourced, there is no internal team with whom developers can collaborate in the DevOps sense. The “Ops” side of DevOps effectively sits behind a contractual wall.
• Partial outsourcing: If you retain some IT staff but rely on MSPs for certain services, your DevOps practice is constrained to whatever your in-house staff can support. Anything the MSP handles falls outside the DevOps loop.
• Cultural misalignment: DevOps depends on a shared culture of continuous improvement, blameless post-mortems, and rapid feedback. An MSP operating under a traditional service-level agreement (SLA) model may not naturally align with those values.

In short, the more heavily an organization relies on MSPs for its IT operations, the harder it becomes to implement a genuine DevOps practice—not because of technical limitations, but because of organizational and cultural ones.

DevOps-Friendly MSPs: A Practical Middle Ground

The conflict between MSPs and DevOps is real, but it is not absolute. A growing number of MSPs explicitly design their services and communication models to support DevOps practices. If your organization wants to use managed services while also pursuing DevOps, the key is selecting the right MSP partner.

What distinguishes a DevOps-compatible MSP from a traditional one?

• Transparent operations: Rather than operating as a black box—delivering outputs without visibility into process—a DevOps-friendly MSP shares data, metrics, and operational context with the client.
• Collaborative planning: The MSP actively involves the client organization in IT planning, change management, and incident reviews rather than handling everything internally.
• Toolchain flexibility: The MSP is willing to integrate with the client’s existing CI/CD pipelines, monitoring tools, and communication platforms (such as Slack, PagerDuty, or Jira) rather than enforcing a proprietary stack.
• Continuous feedback loops: The MSP provides regular reporting and is open to iterative process improvement based on client feedback—mirroring the retrospective culture central to DevOps.
• Shared responsibility model: Incidents and outages are treated as shared problems to solve together, not as contractual disputes over SLA compliance.

Working in a DevOps manner across an organizational boundary—between an in-house dev team and an external MSP—does demand more effort from both sides. Communication must be more deliberate. Agreements around tooling, escalation paths, and data sharing need to be explicit rather than assumed. The seamless collaboration that DevOps enables within a single co-located team becomes harder to achieve when some participants work for a different company.

Key Questions to Ask Before Combining MSP and DevOps

Before committing to a hybrid MSP-plus-DevOps model, engineering and IT leadership teams should work through the following questions:

1. Which IT functions are being outsourced? If the outsourced functions are entirely separate from the software delivery pipeline (e.g., facilities networking or helpdesk), DevOps may not be significantly affected. If Ops functions central to deployment and monitoring are outsourced, the impact is much greater.
2. Does the MSP support your toolchain? Ask prospective MSPs whether they can integrate with your CI/CD pipeline, monitoring stack, and incident management tools.
3. How does the MSP handle incidents? Understand whether the MSP conducts post-incident reviews, shares root cause analyses, and welcomes client participation—or whether incidents are resolved internally with minimal client visibility.
4. What does the contract allow? Review SLA terms to understand whether the agreement supports the kind of transparency and collaboration DevOps requires, or whether it creates barriers.
5. Is the MSP willing to adopt your communication culture? A DevOps-oriented organization that communicates in real time via chat and shared dashboards will struggle with an MSP that defaults to weekly email reports and ticketing queues.

The Bottom Line

DevOps and MSPs are not mutually exclusive, but they do require deliberate alignment. Organizations that lean heavily on managed services without thinking carefully about DevOps compatibility risk ending up with fragmented teams, opaque operations, and delivery pipelines that are difficult to iterate on.

The organizations best positioned to benefit from both are those that treat their MSP relationship as a genuine collaboration rather than a transactional service contract—and those that select MSP partners who are willing to operate that way. As both DevOps practices and managed IT services continue to mature, the market for MSPs that explicitly support DevOps workflows is likely to grow alongside demand from engineering-led organizations.

New device releases, shifting market expectations, and a perpetual shortage of skilled engineers make spring one of the most demanding periods for software development teams. Rather than simply pushing harder, it is worth taking a step back to assess your DevOps practice and clear out the friction that slows delivery. Below are four concrete areas where a focused clean-up can yield faster releases and measurably better customer satisfaction.

1. Clarify Roles and Responsibilities

DevOps deliberately blurs the traditional boundaries between development, testing, security, and operations—and that flexibility is a feature, not a bug. However, when responsibilities are permanently ambiguous, engineers experience role confusion, accountability gaps open up, and handoffs break down.

As security and networking move earlier into the software development lifecycle (SDLC), every team needs a clear picture of where they plug in. A practical starting point is to schedule what some practitioners call service health reviews: regular, structured meetings where each team discusses the current state of production services, recent wins, and active pain points—including cultural ones. Monthly cadence tends to work well; it is frequent enough to catch drift before it compounds, but not so frequent that it becomes overhead.

• Document who owns each stage of the SDLC before a new project kicks off.
• Distinguish between who is responsible for a task and who is merely consulted (a simple RACI matrix can help).
• Revisit role definitions whenever the team structure or toolchain changes significantly.

2. Sharpen Your Team’s Skill Sets

The blurring of DevOps roles demands a broader and continually refreshed skill set. Automation expertise, cloud-native tooling, security fundamentals, and observability practices are all increasingly expected of engineers across the pipeline—not just specialists. A periodic skills audit helps identify where your team is well-covered and where gaps could become blockers.

Three levers that consistently move the needle on team capability:

• Secure executive buy-in. Training budgets and protected learning time require leadership commitment. Frame the investment in terms of delivery risk and time-to-market rather than abstract professional development.
• Establish a structured mentoring programme. Pairing engineers of different experience levels—cross-functionally where possible—accelerates knowledge transfer and surfaces operational knowledge that is rarely written down. Mentors should be matched on complementary skills, not just seniority.
• Let teams choose frameworks that suit them. Acceptance Test-Driven Development (ATDD) and Behaviour-Driven Development (BDD) are two approaches that help bridge skill gaps across the SDLC by grounding work in shared, human-readable specifications rather than implementation-specific details.

3. Identify and Remove Delivery Barriers

Before investing in new tools, audit what you already have. Systematically review your pipeline for bottlenecks—places where work queues, hand-offs stall, or feedback loops are too slow. Useful data sources include:

• Performance metrics: deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate.
• Customer feedback: bug reports, support ticket volume, and satisfaction scores tied to specific releases.
• Team self-assessment: ask engineers directly where they lose the most time on non-value-adding work.

Once barriers are visible, establish explicit best practices for how teams share work, communicate application health, and hand off changes for review or testing. Specifically, a well-maintained codebase with continuous testing at every stage can:

• Prevent memory leaks and regressions from reaching production.
• Stop poor coding patterns before they proliferate across the codebase.
• Ensure that every team member has timely, accurate visibility into build and deployment status.

4. Revisit and Modernise Your Automation Strategy

Automation is no longer optional in a high-velocity DevOps environment, but not all automation is created equal. A common mistake is treating automation as a one-time investment: scripts written years ago may be fragile, inconsistently maintained, or fundamentally unsuited to a pipeline that has since evolved.

A useful framework for your audit:

• Keep what works. Stable, deterministic automation that passes consistently should be left largely untouched. Unnecessary refactoring introduces new risk.
• Replace or augment what is flaky. Tests or scripts that produce inconsistent results erode trust and slow pipelines. Evaluate whether AI-assisted or model-based testing tools can improve coverage and reliability in those areas.
• Map automation to your CD goals. Every piece of automation should have a clear owner, a defined trigger, and a measurable contribution to shortening the path to production.

Advances in machine learning are making it possible to identify test gaps, predict failure-prone code paths, and prioritise test execution dynamically. These capabilities are genuinely useful when applied to areas where traditional rule-based automation struggles—but they are a complement to solid foundational automation, not a replacement for it.

Putting It Together

DevOps improvement does not require a wholesale overhaul. A periodic, structured review of roles, skills, process barriers, and automation maturity can compound into significant gains in delivery speed and quality. Start with one area, measure the impact, and use that momentum to tackle the next. Consistent incremental improvement is, after all, a core DevOps principle.

Two Disciplines, One Shared Problem

DevOps and cybersecurity are both high-priority investment areas for modern enterprises, and both have undergone significant transformation in recent years. On the surface they address different concerns — one focuses on shipping software reliably, the other on protecting systems and data. But beneath the surface, both disciplines are wrestling with the same fundamental challenge: how to move from rigid, siloed, reactive models toward adaptive, collaborative, continuously improving practices.

Understanding how DevOps navigated its own organizational transition offers a useful roadmap for security teams trying to do the same.

The DevOps Transition: More Than a Technology Problem

The core ideas behind DevOps did not appear overnight. Organizations had been adopting Agile development methodologies for years before DevOps entered mainstream conversation. Agile gave teams a philosophy — iterative releases, faster feedback loops, greater responsiveness to customer needs — but philosophy alone wasn’t enough.

The hard realization came when teams discovered that choosing to be Agile did not automatically make them Agile. Development and Operations still lived in separate organizational silos. Testing was still a downstream, sequential phase that happened after code was written. The handoffs between teams introduced delays, miscommunications, and quality problems that undermined the very speed Agile promised.

The breakthrough was structural, not technical. When Dev and Ops began sharing ownership of the delivery pipeline — when testing became a continuous, integrated activity rather than a final gate — the benefits of Agile development were finally realized at scale. CI/CD pipelines, shared on-call responsibilities, and cross-functional product teams were symptoms of that organizational shift, not its cause.

The lesson: knowing what needs to change is not sufficient. The organization itself has to be restructured to support the new working model.

Cybersecurity Is in the Same Transition

IT security is at a similar inflection point. For well over a decade, the industry has understood at a conceptual level what needs to change:

• The traditional perimeter model — trust everything inside the network, block everything outside — is no longer adequate.
• Threat detection must be continuous and adaptive, not a single yes/no decision at a firewall or gateway.
• Authentication needs to go beyond passwords, incorporating behavioral signals and risk context.
• Organizations must be able to contain an infection without catastrophic data loss or disruption to legitimate users.

Enormous resources have been invested in addressing these goals. Yet many organizations still find that threats get through, security teams are overwhelmed by alert volume, and enforcement still relies heavily on signature-based blocking. The technology has improved significantly, but outcomes often fall short of expectations.

As with DevOps, the gap between ambition and outcome is frequently organizational rather than purely technical.

The Silo Problem in Security: Identity vs. Threat Prevention

In many enterprises, Identity and Access Management (IAM) and Security/Threat Prevention operate as entirely separate functions — different teams, different toolsets, different reporting lines, and different workflows. This separation mirrors the pre-DevOps split between Development and Operations.

The problem is that attackers do not respect those boundaries. A typical intrusion pattern works like this:

1. An attacker gains an initial foothold — through phishing, credential stuffing, or a vulnerable service.
2. They immediately leverage the compromised account’s identity and access privileges to move laterally.
3. They escalate privileges, locate sensitive assets, and compromise additional accounts and devices.

At each step, the attack exploits the gap between the team that knows about the identity (IAM) and the team monitoring for threat activity (Security Operations). The two teams may detect partial signals independently, but without shared context, neither can respond effectively in real time.

Conditional Access: A DevOps-Style Integration for Security

Conditional Access is an approach that begins to close this gap. Rather than treating authentication as a static, one-time event, Conditional Access evaluates the full context of an access request — user identity, device health, location, behavior patterns, and real-time threat signals — before granting, denying, or challenging a request.

This approach brings IAM and Threat Prevention into a shared, continuous workflow, much as DevOps brought Development and Operations together into a shared delivery pipeline. Key characteristics include:

• Real-time, risk-based decisions: Access decisions incorporate live threat intelligence and behavioral analytics rather than relying solely on static role assignments.
• Graduated enforcement: Instead of a binary block/allow, the system can step up authentication requirements (e.g., require MFA) when it detects anomalous behavior, letting legitimate users continue while stopping suspicious activity.
• Pre-access enforcement: Enforcement happens before a sensitive asset is reached, not after a breach is detected.
• Unified context: Identity, device posture, risk score, and threat signals are evaluated together rather than in isolation by separate teams and tools.

The organizational implication is that IAM and Security Operations teams need shared visibility, shared tooling, and shared policies — just as Dev and Ops needed shared ownership of the delivery pipeline before CI/CD could deliver on its promise.

People and Process Before Technology

The DevOps story is instructive precisely because the technology — version control, build servers, containerization, configuration management — was largely available before DevOps became mainstream. What unlocked the transformation was the willingness to restructure teams, redefine ownership, and accept that two previously separate disciplines needed to operate as one continuous function.

Cybersecurity teams considering a Conditional Access model, a Zero Trust architecture, or any other modern security framework should approach the initiative with the same mindset. The technical implementation matters, but the organizational design — who owns what, how teams share information, how policies are set and enforced jointly — often determines whether the new approach succeeds or simply becomes another layer of complexity.

Key Takeaways

• DevOps succeeded not just because of new tools, but because it restructured the relationship between Development and Operations into a shared, continuous workflow.
• Cybersecurity faces an analogous challenge: IAM and Threat Prevention teams need integrated processes, not just integrated technology.
• Conditional Access represents a practical model for unifying identity, risk, and threat signals into a single, adaptive enforcement layer.
• Organizations should audit their security team structures as carefully as their security toolsets — organizational silos are often a larger barrier than technology gaps.
• Graduated, context-aware enforcement (challenge rather than block) reduces friction for legitimate users while improving security outcomes.

Breaking down walls between teams is never easy. But as the DevOps movement demonstrated, the organizations willing to make those structural changes are the ones that ultimately deliver on the promises their technology investments make.

Why DevOps Adoption Keeps Growing

Organizations of every size continue to pursue DevOps practices, driven by a common set of pressures: shrinking time-to-market windows, rising quality expectations, the need to cut operational costs, and the imperative to stay competitive in increasingly digital markets. The shift toward cloud-native infrastructure, agile frameworks, and digital business models has reinforced the urgency—but technology alone does not deliver the promised acceleration. The missing ingredient is almost always people: specifically, how well teams collaborate across traditional boundaries.

DevOps is not a tool or a product. It is a combination of cultural practices, organizational structures, and automation capabilities that must be assembled differently in every company. That is precisely why it defies a universal recipe.

Leadership Is the Most Critical Success Factor

Depending on company size and complexity, a meaningful DevOps transformation can take months—often years. From practical experience across many organizations, the single most important factor is engaged leadership. Without active sponsorship from senior leaders, silos persist, budgets stall, and cross-team initiatives lose momentum.

Effective leadership support enables organizations to:

• Break down entrenched organizational silos between development, operations, security, and business teams.
• Create flexible, dynamic workflows that span multiple teams simultaneously.
• Align software delivery speed with the ability to respond to changing customer demands.
• Sustain momentum through the inevitable resistance that accompanies cultural change.

Without this top-down commitment, even the most technically sophisticated DevOps toolchain will produce marginal results.

Implementing DevOps Is Unique to Every Company

There is no single DevOps playbook that transfers cleanly from one organization to another. Every company brings its own history, culture, risk tolerance, and way of working. Two organizations can adopt the same CI/CD toolchain and end up with completely different outcomes because the human and organizational contexts differ.

DevOps is best understood as an amalgamation of several distinct dimensions:

• Technology and automation: CI/CD pipelines, infrastructure-as-code, monitoring, and observability tooling.
• Lean process design: Reducing waste, minimizing batch sizes, and streamlining feedback loops.
• Cultural transformation: Building shared ownership, psychological safety, and a blameless post-incident culture.
• Organizational structure: Restructuring teams around products rather than functions, often using models like team topologies.

The weighting of each dimension varies by organization. A startup with 20 engineers needs a very different approach than a regulated financial institution with thousands of developers across multiple geographies. Copying another company’s implementation without adapting it to your own context is one of the most common reasons DevOps transformations stall.

The Challenge of Scaling Beyond the Pilot

The trajectory of DevOps adoption closely mirrors what the industry saw with agile: most organizations begin with a small, often hand-picked pilot team, demonstrate early wins, and then struggle to scale those results enterprise-wide. The pilot succeeds in part because it operates outside normal organizational constraints. Scaling reintroduces all of those constraints simultaneously.

Common barriers that emerge at the scaling stage include:

• Legacy systems and monolithic architectures that resist continuous delivery practices.
• Inconsistent tooling choices across teams that create integration overhead.
• Middle-management layers that have not been aligned to the new way of working.
• Lack of platform engineering capability to provide self-service infrastructure to product teams.
• Insufficient investment in developer enablement and training.

Automation tools bring organizations closer to continuous integration and continuous delivery, but the gap between a functional CI/CD pipeline and a truly continuous delivery culture is significant. Many teams achieve automated builds and tests while still releasing infrequently due to approval bottlenecks or release-night rituals that have not been re-examined.

Uneven Adoption Across Application Types

DevOps adoption is not uniform across application portfolios within the same organization. Mobile and greenfield applications typically see earlier and deeper adoption because they were often built without the legacy constraints that affect older systems. Core enterprise platforms, ERP systems, and mainframe workloads frequently lag behind, creating a two-speed IT environment that itself becomes a source of friction.

Organizations need strategies for both ends of this spectrum: accelerating delivery for modern workloads while carefully managing risk and compliance for legacy systems. Attempting to force a single delivery model across all application types rarely succeeds.

Measuring DevOps Success Meaningfully

A persistent challenge is defining what DevOps success actually looks like for a given organization. Deployment frequency and lead time for changes are useful technical indicators, but business leaders also need metrics that connect delivery performance to outcomes:

• Time to restore service after an incident, which reflects operational resilience.
• Change failure rate, which indicates delivery quality under speed.
• Product revenue or customer satisfaction tied to specific delivery improvements.
• Process efficiency gains measured as reduction in manual handoffs or approval cycle time.
• Innovation rate, such as the number of experiments or new features shipped per quarter.

Without connecting DevOps metrics to business outcomes, transformation programs risk being judged solely on tool adoption rather than value delivered. The metrics framework should be established early and revisited as the organization matures.

Learning from Others Without Copying Them

There is genuine value in studying how other organizations have navigated their DevOps journeys. Case studies, industry conferences, and community sharing surface patterns and anti-patterns that can accelerate your own thinking. However, the key discipline is translation: understanding why a practice worked in another context before deciding whether and how to adapt it to your own.

Two organizations using the same automation platform will have different team structures, different governance requirements, different release cadences, and different definitions of done. The tooling is the easiest part to replicate. The organizational learning embedded in how those tools are used, governed, and continuously improved is the harder part—and it cannot be copied directly.

Key Takeaways for DevOps Leaders

• Secure leadership commitment first. Technical initiatives without executive sponsorship will plateau quickly.
• Treat your DevOps adoption as a product. Define a roadmap, set measurable goals, and iterate based on feedback.
• Design for your context. Study best practices from peers, but adapt rather than copy.
• Plan explicitly for scaling. A pilot that works with one team will require deliberate investment in platform engineering and enablement to scale across the enterprise.
• Connect metrics to business outcomes. Deployment frequency matters, but it must ultimately tie back to customer value and business performance.
• Be patient. Fundamental shifts in how software is created, delivered, and maintained take years, not quarters. Sustained momentum matters more than rapid early wins.