What the Forrester Consulting Analysis Claimed

The Forrester Consulting study, conducted on behalf of GitLab, modeled the financial impact of adopting GitLab’s platform across a composite enterprise organization. Key headline figures from the report included:

• 87% improvement in application development and delivery speed.
• $23 million or more in total projected savings and revenue impact.
• $3.7 million saved by reducing the number of DevOps tools required—by approximately a factor of four.
• 12× increase in the number of revenue-generating application releases per year, translating to $12.3 million in additional projected revenue.
• $16.8 million in savings attributed to a reduction in code defects.
• 407% return on investment (ROI) calculated for the GitLab platform over the study period.

GitLab also published an online DevOps cost estimator based on the Forrester methodology, allowing organizations to model potential savings using their own headcount and tooling data.

The Strategic Argument: Fewer Tools, Tighter Workflows

According to Colin Fletcher, then Manager for Market Research and Customer Insights at GitLab, the platform is designed so that every integrated capability is a natural extension of an existing DevOps workflow rather than a separately configured integration. The argument is straightforward: when source control, CI/CD, security scanning, container registry, and release orchestration all live in a single data model, teams spend less time managing integrations and more time shipping software.

The toolchain reduction figure—roughly four times fewer tools—is where many organizations see immediate, tangible cost relief. License fees, integration maintenance, context-switching overhead, and the cognitive load of operating separate systems all contribute to hidden costs that are rarely tracked in a single budget line.

Context: Why This Argument Gained Traction in 2020

The report was published during a period of significant economic and operational pressure. The COVID-19 pandemic had forced most DevOps teams to shift to fully remote work, which exposed weaknesses in toolchains that depended on tribal knowledge or co-located collaboration. At the same time, organizations accelerating digital transformation initiatives were under pressure to ship more software faster while simultaneously cutting costs—a tension that made platform consolidation discussions more urgent.

Remote work also changed how teams were structured. Rather than organizing around functional specialties, some organizations began restructuring DevOps teams around specific product or application domains, increasing the need for self-contained tooling that required less cross-team coordination to operate.

The Real Barrier: Toolchain Inertia

Despite the financial case, platform migration is rarely straightforward. Most engineering organizations have invested significant time configuring and extending their existing pipelines. Custom integrations, established runbooks, institutional knowledge, and team preferences all create substantial inertia. Switching DevOps platforms requires not just a technical migration but organizational change management—a form of political capital that engineering leaders have to spend carefully.

There is also a genuine tension between standardization and developer autonomy. Most engineers prefer to choose their own tools when given the option. Mandating a single platform can reduce costs on paper while quietly increasing frustration and attrition if the mandated platform does not meet the ergonomic expectations of the team.

A practical middle path that many organizations take is incremental consolidation: rationalizing the highest-cost or most fragile integrations first, rather than attempting a full cutover from one platform to another. Downturns often accelerate this process, particularly when multiple DevOps platforms are already in use within the same organization and pressure mounts to reduce redundant licensing.

How to Read Vendor-Commissioned ROI Studies

Vendor-commissioned Total Economic Impact (TEI) or ROI studies—regardless of which analyst firm produces them—should be read with a clear understanding of their methodology. A few questions worth asking before applying any figure to your own organization:

• Who is the composite organization? Study results are modeled on a constructed composite customer, not a specific company. Actual results will vary significantly based on team size, existing toolchain complexity, and maturity of existing processes.
• What is the baseline? A 12× increase in releases is only meaningful relative to a known starting point. Organizations already practicing continuous delivery may see much smaller delta improvements.
• How are savings categorized? Tool cost reduction is relatively easy to measure. Developer productivity gains and defect-reduction savings are harder to isolate and often involve assumptions about hourly rates and attribution.
• What is the payback period? ROI figures typically cover a multi-year window. Short-term migration costs, including downtime, training, and re-tooled pipelines, can erode early-year returns substantially.

What Engineering Leaders Should Take Away

The core insight of the Forrester analysis—that toolchain fragmentation carries real, measurable costs—holds up regardless of which platform an organization ultimately adopts. License proliferation, integration maintenance, and cognitive overhead are genuine budget items that deserve scrutiny in any DevOps spend review.

Whether GitLab specifically delivers the projected 407% ROI for your organization depends entirely on your current state, team size, migration readiness, and the degree to which your existing workflows can map cleanly to a consolidated platform. The Forrester figures are a starting point for internal modeling, not a guarantee.

For organizations still evaluating whether to consolidate DevOps toolchains, the most useful exercise is to audit current tooling costs—including integration engineering time—before engaging any vendor’s cost estimator. That baseline will make any vendor-supplied projection far more grounded and defensible to finance stakeholders.

DevOps Is More Than a Delivery Pipeline

DevOps is arguably the most influential IT philosophy of the last two decades. It draws on psychology, sociology, systems thinking, and economics to help engineering organizations move faster and more reliably. Companies from AWS to Netflix have credited DevOps practices as central to their ability to scale and innovate.

But DevOps is often reduced to its tooling — CI/CD pipelines, infrastructure-as-code, containerization. The deeper story is how these practices shape team culture: how people collaborate, find meaning in their work, and continuously get better at what they do.

The Three Ways: The Philosophical Core of DevOps

Gene Kim describes the foundational principles of DevOps as The Three Ways: Flow, Feedback, and Continuous Learning and Improvement. These are not just process guidelines — they are a framework for building teams that are engaged, autonomous, and effective.

The First Way: Flow

Flow is about optimizing the movement of work from development through to production. It underpins the practice of continuous delivery: the ability to get changes into users’ hands quickly, reliably, and with minimal friction.

In practice, Flow means:

• Version control — every change is tracked, documented, and reversible. A clear commit history helps future maintainers understand why decisions were made.
• Automated builds and tests — repetitive validation tasks are handed off to machines, reducing human error and freeing engineers for higher-value work.
• Automated deployments — releases become routine events rather than high-risk, high-stress operations.

Beyond efficiency, Flow has a human dimension. When developers can ship meaningful features and bug fixes quickly — without bureaucratic delays or error-prone manual steps — they experience a direct connection between their effort and real-world impact. That sense of purpose is a powerful driver of engagement and job satisfaction.

Flow also demands that teams actively eliminate waste: unnecessary approvals, handoff delays, redundant manual testing, and “toil” — repetitive operational work that scales linearly with system growth. Removing these obstacles is as much about respect for engineers’ time as it is about delivery speed.

The Second Way: Feedback

Continuous delivery without feedback is flying blind. The Second Way builds on Flow by creating fast, reliable feedback loops at every level of the system.

Feedback operates in two directions:

• From production systems — instrumentation, monitoring, alerting, and observability tools that surface the real-world behavior of the software you ship.
• From the development process itself — metrics like deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate (the DORA “four key metrics”) give teams a quantitative picture of their delivery performance.

As systems have grown into web-scale, distributed architectures, the observability challenge has become significant. Netflix’s Atlas monitoring platform — which at one point was tracking over a billion individual time series — illustrates the scale at which modern Ops teams must work. The engineering challenge is not just collecting data, but filtering it: surfacing the signals that actually matter and suppressing noise that would otherwise overwhelm on-call engineers.

A useful analogy: if Flow is the nervous system’s efferent pathways — the signals that drive action and movement — then Feedback is the afferent pathways, carrying sensory information back from the world. Both are necessary for coordinated, effective behavior.

The Third Way: Continuous Learning and Improvement

The Third Way is where Flow and Feedback come together. Teams use the information generated by their systems and processes to experiment, adapt, and improve — continuously and deliberately.

This is also the way that most directly unites Dev and Ops. Examples of how this plays out in practice:

• A new software deployment triggers unexpected CPU spikes. The Ops team raises the alert, the development team investigates, and both collaborate on a fix — learning something about the interaction between the code and the infrastructure.
• An infrastructure change — say, a migration to a new runtime or a network policy update — affects what deployment patterns are viable. Dev teams need to adapt their approach.
• A post-incident review (blameless retrospective) produces documented learnings that prevent the same failure mode from recurring.

Central to the Third Way is a systems perspective: understanding that complex software systems behave in ways that no single team fully controls or predicts. Operating effectively in this environment requires psychological safety, a focus on practical improvement over assigning blame, and the freedom to experiment and learn from failure.

Embedding These Principles in Team Culture

The Three Ways make intuitive sense as principles. Making them real inside an organization is harder — it requires both tooling investment and cultural change.

Moving Away from Command-and-Control Management

One of the defining characteristics of knowledge work — software engineering included — is that the people doing the work often understand the technical details better than their managers do. That’s not a failure of management; it’s the nature of deep specialization. A senior engineer who has spent weeks working inside a distributed caching layer knows things about it that no manager or architect can absorb from a status update.

This reality has a direct implication for how DevOps teams should be structured and led. Hierarchical, directive management — where decisions flow down from those with authority — is poorly suited to environments where expertise is distributed and conditions change rapidly. Instead, effective DevOps leadership means:

• Delegating decision-making to the people closest to the problem.
• Creating clear goals and constraints rather than prescribing solutions.
• Building systems (runbooks, on-call rotations, incident review processes) that capture and distribute learning across the team.
• Fostering psychological safety so that engineers feel comfortable raising concerns, reporting incidents honestly, and proposing changes.

Autonomy as a Driver of Engagement

DevOps, at its best, gives individual contributors the autonomy to act, observe results, and adapt — rather than simply executing instructions. This is not a soft, feel-good benefit. Research in organizational psychology consistently links autonomy, mastery, and purpose to higher performance and lower attrition in knowledge-work environments.

When teams own their deployment pipelines, define their own alerting thresholds, and run their own post-incident reviews, they develop a direct relationship with the outcomes of their work. That ownership is motivating in a way that ticket-based, handoff-driven processes rarely are.

Key Takeaways for DevOps Leaders

• Invest in Flow before anything else. Automation of builds, tests, and deployments is the foundation on which everything else rests. Without it, feedback loops are slow and learning is impaired.
• Treat observability as a first-class requirement. Teams cannot learn from systems they cannot see. Monitoring, logging, and tracing infrastructure should be built alongside the application, not bolted on afterward.
• Make retrospectives and post-incident reviews a genuine practice, not a compliance exercise. Blameless, action-oriented reviews are the mechanism through which Continuous Learning becomes real.
• Restructure for autonomy. Push decision-making authority toward the people with the most context. Managers’ roles shift from directing to enabling and unblocking.
• Measure the right things. The DORA four key metrics — deployment frequency, lead time, change failure rate, and MTTR — are a practical starting point for understanding delivery performance.

Conclusion

The Three Ways are not a checklist. They are a way of thinking about software delivery as a sociotechnical system — one where human motivation, team structure, and tooling all interact. Organizations that implement DevOps purely as a tooling upgrade often get incremental gains. Those that internalize the underlying principles — Flow, Feedback, and Continuous Learning — build teams that are more engaged, more resilient, and more capable of sustained improvement over time.

The question for any engineering leader is not just “what tools should we adopt?” but “what kind of team are we trying to build, and what do our people need to do their best work?”

From Agile to DevOps: A Natural Evolution

Agile development is an umbrella term covering a range of iterative software development practices — including Scrum, Kanban, SAFe (Scaled Agile Framework), Extreme Programming (XP), and Lean Development. Despite their differences, these methodologies share a common foundation: continuous feedback loops, incremental delivery, and close collaboration between cross-functional teams.

DevOps grew directly out of the agile movement. As agile practices increased software velocity and the frequency of releases, operations teams struggled to keep pace with development. DevOps emerged as a cultural and technical response to that friction — bridging the historically siloed worlds of software development and IT operations.

The term DevOps is widely attributed to Patrick Debois and Andrew Clay Shafer, who began promoting the concept around 2009. It combines "development" and "operations" and signals a shift toward shared ownership of the software delivery lifecycle.

What DevOps Actually Means in Practice

DevOps is not a single tool or product — it is a combination of cultural principles, practices, and enabling technologies. The core goals are:

• Continuous collaboration between development, operations, and business stakeholders
• Continuous delivery of high-quality software at speed
• Automation of repetitive tasks across the build, test, and deployment pipeline
• Fast feedback to catch and fix problems earlier in the development cycle

Tools are enablers of these goals, not the goals themselves. Teams that treat DevOps as a tooling exercise without addressing culture and process often find limited returns.

Why Automation Is Central to DevOps

Manual quality assurance and deployment processes simply cannot scale to match the release frequency that modern agile and DevOps teams target. This is the fundamental reason automation has become inseparable from DevOps practice.

Automation in a DevOps context typically spans several disciplines:

• Test automation: Automated unit, integration, and end-to-end tests run on every code commit, catching regressions without developer intervention.
• CI/CD pipelines: Continuous Integration and Continuous Delivery pipelines automatically build, test, and deploy code changes, reducing the time from commit to production.
• Infrastructure as Code (IaC): Tools like Terraform and Ansible allow infrastructure to be provisioned and managed through version-controlled code, eliminating manual configuration drift.
• Monitoring and alerting: Automated observability tools detect anomalies and trigger alerts or self-healing responses without human oversight.

A typical automated CI/CD workflow looks like this: a developer pushes code to a shared repository; a CI server automatically builds the artifact and runs the test suite; results are logged and compared against previous runs; if tests pass, the pipeline deploys the build to a staging or production environment. If tests fail, the pipeline notifies the team and halts deployment. Developers review only the exceptions — not every build step.

The Business Case for DevOps Automation

Automation delivers measurable value beyond faster releases. Key benefits include:

• Consistency: Automated processes execute the same steps every time, eliminating human error in repetitive tasks.
• Scalability: Automated environments can scale to handle larger workloads without proportional increases in headcount.
• Developer productivity: By offloading mundane tasks to automation, engineers can focus on higher-value work such as feature development and architecture.
• Faster mean time to recovery (MTTR): Automated rollback and self-healing mechanisms reduce the impact of production incidents.

Key DevOps Tool Categories Driving Automation

The DevOps toolchain is broad. The following categories represent the most impactful areas for automation initiatives:

Source Control and Collaboration

Platforms such as GitHub, GitLab, and Bitbucket provide the foundation for collaborative development and serve as the trigger point for automated pipelines. Every merge request or pull request can automatically kick off build and test workflows.

CI/CD Platforms

Tools like Jenkins, GitLab CI, GitHub Actions, and CircleCI orchestrate the automated build, test, and deployment lifecycle. CircleCI, for example, is a cloud-native CI/CD platform that focuses on speed and configurability for teams of varying sizes.

Artifact Management

Artifact repositories such as JFrog Artifactory store and manage build outputs, container images, and dependencies. Integrating artifact management into the pipeline ensures that only validated, versioned artifacts are promoted to production environments.

Security Scanning

Shifting security left — integrating vulnerability scanning earlier in the pipeline — is increasingly a standard DevOps practice. Tools such as JFrog Xray scan artifacts for known vulnerabilities before they reach production, automating a step that would otherwise require manual security review.

Infrastructure Automation

Terraform, Pulumi, Ansible, and similar tools enable teams to define, provision, and manage infrastructure through code. This removes manual server configuration, reduces drift, and makes environment creation repeatable and auditable.

Remote Work and the Acceleration of DevOps Adoption

The shift to distributed and remote work environments that accelerated in 2020 placed additional pressure on IT teams to deliver digital services reliably and at scale. When teams are geographically dispersed, automated pipelines become even more important — they replace the informal coordination that happens naturally when developers and operations staff share a physical space.

Cloud-based DevOps platforms are particularly well-suited to distributed teams because they are accessible from anywhere, require no on-premises infrastructure, and scale elastically with demand. The period of widespread remote work served as a forcing function for many organizations to modernize their delivery pipelines and invest in DevOps tooling they had previously deferred.

Getting Started with DevOps Automation

Organizations beginning or maturing their DevOps automation journey should consider the following practical steps:

1. Audit your current pipeline — Identify manual steps that are repetitive, error-prone, or slow. These are the highest-value automation targets.
2. Start with CI — Implementing automated builds and tests on every commit provides an immediate feedback loop and a foundation for further automation.
3. Standardize environments — Use containers or IaC to ensure that development, staging, and production environments are consistent.
4. Integrate security early — Automate dependency and vulnerability scanning within the pipeline rather than as a gate at the end.
5. Measure outcomes — Track metrics such as deployment frequency, change failure rate, and MTTR to quantify the impact of automation investments.

Conclusion

DevOps tools are not simply convenience features — they are the operational infrastructure that enables organizations to deliver software continuously, reliably, and securely. As software systems grow in complexity and release cadences continue to accelerate, the teams that invest in robust automation across their pipelines will maintain a significant competitive advantage. The cultural shift toward shared ownership between development and operations, combined with the right tooling, is what transforms automation from a one-time project into a sustainable, scalable practice.

What Is Shift Left?

“Shift left” is the practice of moving traditionally late-stage software development activities — testing, security analysis, code reviews, performance assessments — earlier into the build cycle. Instead of treating these as gates before release, teams integrate them continuously from the very first sprint.

Activities that can be shifted left include:

• Functional and non-functional testing
• Code reviews
• Static and dynamic security code analysis
• Security validations and compliance checkpoints
• Performance and UX assessments
• Code coverage analysis
• Unit testing tied to specific code changes

The underlying logic is straightforward: defects found early are cheaper and faster to fix than those discovered after code has been integrated, tested by QA, or — worst of all — shipped to production.

Why Shift Left Matters for DevOps

Shift left is not a silver bullet, but it aligns naturally with core DevOps values. It supports the “fail fast, fix fast” ethos that removes code instabilities early and improves overall quality. It is also a natural companion to continuous integration (CI): as each code change is checked in, automated tests and security scans run immediately, surfacing issues before they compound.

Security is a clear illustration. Shifting security left — sometimes called DevSecOps — means embedding security requirements, audits, and quality checkpoints into every iteration of the software lifecycle. Vulnerabilities are identified and remediated before they ever reach a release candidate, dramatically reducing the attack surface and the cost of remediation.

Shift left also makes ongoing maintenance easier. When testing and security validation are part of the build cycle rather than an afterthought, they are naturally carried forward into every subsequent release rather than rediscovered from scratch.

The Adoption Gap: What the Data Shows

Despite the clear benefits, shift left has not been widely adopted. According to the Gatepoint 2020 State of Test Automation Report — a survey of executives from more than 100 digital enterprises in the United States conducted by Gatepoint and Perfecto — the numbers reveal a significant gap between theory and practice:

• 63% of companies surveyed begin testing only after a new build or code has already been developed.
• 81% still rely primarily on dedicated QA teams for testing, with only 19% using development teams.
• Only 40% test upon each code change or at the start of a new sprint.

Anecdotally, the same lag applies to non-testing shift-left activities such as security analysis and performance assessment. The vision of continuous, developer-driven quality has not yet matched the reality for most organisations.

Why Shift Left Goes Wrong

1. Culture and Leadership Misalignment

The most common root cause is cultural. When development teams are incentivised purely by shipping on deadline, testing and security become secondary concerns. This is a false economy: product failures, security breaches, and unhappy customers all cost far more to address post-release than the time saved by skipping early validation. Without visible leadership support that treats shift left as a business-class requirement rather than a developer preference, adoption stalls.

2. Developer Overload and Resentment

Asking already stretched development teams to absorb work previously handled by QA — without reducing their existing workload — breeds resentment. Shift left is framed as offloading effort onto developers, rather than redistributing it intelligently across the lifecycle. When it feels like a burden rather than an enabler, teams quietly resist.

3. Tool Imposition Without Buy-In

Organisations often introduce shift-left tooling top-down, without involving the developers who will use those tools daily. History consistently shows that if developers do not want to use a tool, they will find a workaround. Tools that disrupt existing workflows or do not integrate with preferred environments face silent abandonment.

4. Poorly Scoped Testing Suites

When the scope of what needs to shift left is too large or poorly defined, it cannot realistically be embedded into the build cycle. Bloated test suites slow pipelines, frustrate developers, and erode confidence in the process. Without clear boundaries around what should run on every commit versus what can be deferred, the entire initiative bogs down.

5. Disconnected Product Owners

Shift left requires collaboration between product owners and engineers from the very beginning of a project. When product owners fail to engage with development teams at the requirement and design phase, the information needed to define meaningful early tests and security checks simply is not available, making shift left structurally impossible.

How to Overcome the Challenges: 6 Practical Tips

1. Educate Stakeholders on Business Value

Make the case for shift left in terms that resonate with product managers, engineering leaders, and developers alike. Connect early defect detection to reduced rework, faster release cycles, lower support costs, and reduced security risk. Leadership buy-in is a prerequisite for cultural change.

2. Involve Teams in Tool Selection

Give developers a genuine voice in choosing the tools that will be integrated into their workflow. Tools selected with developer input are far more likely to be used consistently and to integrate smoothly with existing pipelines and IDEs. Favour open architectures and well-supported integrations over monolithic platforms.

3. Define Clear, Manageable Scope

Break down what needs to shift left into discrete, achievable chunks: essential functional tests, unit tests scoped to what actually changed, targeted security scans, and lightweight performance checks. Review test suites regularly to prune obsolete cases, keep execution times reasonable, and ensure coverage stays relevant to the current codebase.

4. Reduce Friction with the Right Tooling

Choose techniques and tools that fit around existing workflows rather than replacing them. Automate as much as possible, but be realistic: not every test or security check can or should be automated. Consider low-code or codeless testing tools where they make the process more accessible to developers who are not testing specialists.

5. Use Smart Analytics to Demonstrate Impact

Shift-left tools generate large volumes of data. Use analytics and reporting to surface the signal from the noise — identifying which issues have the highest business impact and which tests provide the most value. Visible metrics help teams understand the tangible benefits of shift left throughout the SDLC and sustain momentum for the initiative.

6. Know What Cannot Shift Left

Some activities legitimately belong close to production. Final exploratory testing, manual UX review, and activities that occur rarely are reasonable candidates to remain later in the cycle. Acknowledging these boundaries prevents teams from feeling that every task must move left, and allows them to focus shift-left energy where it delivers the greatest return.

Beyond Shift Left: Adding Shift Right

In mature DevOps organisations, shift left is increasingly complemented by shift right — the practice of continuing to test and observe software in production. Canary releases, feature flags, continuous monitoring, and real-user feedback loops allow teams to validate assumptions and catch issues that only emerge at scale or under real-world conditions. Together, shift left and shift right create a continuous feedback loop that spans the entire software lifecycle, supporting the core DevOps principles of continuous inspection, continuous improvement, and rapid delivery of high-quality software.

Key Takeaways

• Shift left moves testing, security, and quality activities earlier in the SDLC to reduce defect cost and improve release confidence.
• Adoption remains low; cultural resistance, tool imposition, and scope creep are the leading barriers.
• Success requires leadership support, developer involvement in tool selection, well-scoped test suites, and clear metrics.
• Not everything can or should shift left — knowing the boundaries is as important as knowing the benefits.
• Combining shift left with shift right creates a comprehensive, continuous quality feedback loop aligned with Agile and DevOps values.

The five projects below are among the most widely adopted in the Kubernetes ecosystem. They address key concerns for developers and operations teams alike.

1. Prometheus

Prometheus is an open source systems monitoring and alerting toolkit originally built at SoundCloud. It was the second project to join the Cloud Native Computing Foundation (CNCF), after Kubernetes itself, which reflects how central observability is to cloud-native operations.

Prometheus is built around a time-series data model. It can monitor individual host systems, but its real strength is in monitoring dynamic, service-oriented architectures — exactly the kind of distributed, microservices-based workloads that Kubernetes environments tend to run. Metrics are scraped from instrumented targets on a pull-based model, and a built-in query language (PromQL) lets operators explore and alert on that data in flexible ways.

Prometheus is frequently deployed alongside complementary projects in the observability space:

• Jaeger — distributed tracing for monitoring and troubleshooting microservices-based systems.
• Grafana — a popular dashboarding layer that visualizes Prometheus metrics.
• Istio — a service mesh that provides traffic management, policy enforcement, and telemetry aggregation across microservices.

The modular nature of the Kubernetes ecosystem makes it practical to combine or substitute these tools to meet specific workload requirements, without changing the core platform.

2. Operator Framework

Kubernetes provides flexible primitives for scheduling and lifecycle management, but these general-purpose abstractions do not cover the operational complexity of stateful applications. Standing up a database cluster, for example, often requires components to start in a specific order, managing configuration details, performing backups, and handling version upgrades — none of which Kubernetes handles natively.

Kubernetes Operators solve this problem by encoding the knowledge of an expert administrator directly into software. An Operator is a custom controller that extends the Kubernetes API to manage the full lifecycle of a specific application. A database Operator, for instance, can:

• Install a database cluster at a declared version and member count.
• Monitor the running cluster and detect failures.
• Perform automated backups and recovery.
• Manage rolling upgrades with application-specific logic.

This maps directly to the Site Reliability Engineering (SRE) principle of automating toil — tasks that are repetitive, manual, and automatable — so they no longer need human intervention each time they occur.

The Operator Framework is the open source toolkit for building and running Operators. OperatorHub.io provides a community catalog of ready-made Operators for many common applications, from databases like PostgreSQL and Cassandra to messaging systems and monitoring stacks.

3. Knative

Knative brings serverless capabilities to Kubernetes. At its simplest, it allows you to run serverless containers on a Kubernetes cluster without managing the underlying networking, autoscaling, or revision tracking yourself. Developers declare what they want to run; Knative handles the infrastructure concerns.

Knative is organized around two main components:

• Knative Serving — manages deployment, routing, and autoscaling of serverless workloads, including scaling to zero when there is no traffic.
• Knative Eventing — provides an event infrastructure for building event-driven applications, covering the event sources, channels, and subscriptions that most serverless architectures depend on.

A key advantage of Knative over managed serverless offerings from cloud providers is portability. Because Knative runs on Kubernetes, workloads are not tied to any single cloud provider’s proprietary serverless platform. Applications can use portable services deployed via Operators, making it easier to avoid vendor lock-in.

Knative also supports more complex serverless architectures than the original functions-as-a-service model. It accommodates microservices and container-based workloads that are triggered by events but are more stateful or longer-running than a simple Lambda-style function.

Why These Projects Matter

Each of these projects reflects the same underlying principle: Kubernetes deliberately keeps its core small and extensible, and the ecosystem fills the gaps through open source collaboration under the CNCF umbrella. This modular design lets teams assemble a platform that fits their specific workloads rather than accepting a one-size-fits-all solution.

For operations teams, Prometheus and the Operator Framework address the two most pressing operational concerns in a Kubernetes environment: knowing what is happening in production, and automating complex Day-2 operations. For developers, Knative lowers the overhead of building event-driven, scalable applications without requiring deep Kubernetes expertise.

Exploring these projects — and the broader CNCF landscape at cncf.io/projects — is a productive next step for any team looking to mature its Kubernetes platform beyond a basic cluster deployment.

This article is based on reporting originally published at enterprisersproject.com.

Kubernetes Is Mature — But Still New to Many Teams

Kubernetes reached version 1.0 in July 2015, making it a well-established project within the Cloud Native Computing Foundation (CNCF) ecosystem. Despite that maturity, it remains relatively new to many engineering teams, and the learning curve it imposes creates real security exposure. Understanding where the risks lie — and recognising that most of them are not novel — is the first step toward a defensible Kubernetes environment.

Kubernetes Has Strong Native Security Capabilities

Before cataloguing the risks, it is worth acknowledging what Kubernetes provides out of the box. According to Kirsten Newcomer, a security strategist at Red Hat, Kubernetes enables automated scaling, high availability, and resiliency for cloud-native applications. Those capabilities come with a correspondingly complex architecture, and complexity is itself a risk factor.

“As noted in last year’s CNCF-sponsored Kubernetes security audit, Kubernetes is a complex system,” Newcomer says. “And that complexity can lead to increased risk if not appropriately managed.”

The CIS Kubernetes Benchmark is a widely adopted starting point for hardening a Kubernetes deployment. It does not introduce new security principles, but it translates established hardening guidance into Kubernetes-specific configuration recommendations — a practical reference for teams new to the platform.

Namespaces and RBAC: Core Isolation Mechanisms

Luis Pabon, an engineer at Portworx, draws a useful analogy: “Kubernetes provides users with a secure, multi-tenant model to access resources like containers. Cloud providers have been doing the same thing for a decade, just for VMs.”

Kubernetes implements this isolation primarily through two mechanisms:

• Namespaces — logical partitions that group and isolate resources such as secrets, services, applications, and persistent volumes.
• Role-Based Access Control (RBAC) — fine-grained control over which users and service accounts can perform which actions against which API objects and resources within a namespace.

Both mechanisms are powerful, but neither is configured securely by default in all scenarios. Getting them right requires deliberate effort.

Six Security Risks That Are Old Problems in a New Context

“Kubernetes changes the approach to application security in some ways, but not in as many ways as most people think,” Pabon says. “Because security comes in layers, you still have to think about many of the same things, whether you are running apps on Kubernetes or in a more traditional manner.”

The following areas represent security concerns that predate Kubernetes but present themselves in new forms when teams adopt it.

1. Neglecting Foundational Security Hygiene

Kubernetes does not change the basics. Physical data centre security, operating system and application patching, and credential rotation for cloud services and databases are all still required. Pabon is direct on this point: “Kubernetes doesn’t change these security fundamentals.”

Teams excited by Kubernetes’ capabilities can inadvertently deprioritise hygiene tasks that feel mundane. That is a mistake. Unpatched nodes and stale credentials remain easy entry points regardless of the orchestration layer above them.

2. Treating Security as an Afterthought

One of the most persistent risks in software delivery is embedding security only at the end of the pipeline — or reacting to it only after an incident. Maksim Yankovskiy, VP of Engineering at Zettaset, traces this pattern to earlier generations of infrastructure design:

“Legacy systems were not engineered with security in mind; it was added later, in stages, in most cases to address bare minimum regulatory and compliance requirements.”

Maksim Yankovskiy, VP of Engineering, Zettaset

The consequences Yankovskiy identifies include overly permissive access policies, application services running under privileged accounts, inadequate separation of duties between data administrators and security administrators, and encryption key mismanagement — such as using a single key across multiple databases and applications.

Practices like DevSecOps and shift-left security exist precisely to counter this tendency — integrating security controls and reviews earlier in the development lifecycle rather than bolting them on at the end. These are not Kubernetes-specific concepts, but Kubernetes environments benefit from them as much as any other infrastructure paradigm.

3. Misconfigured Settings and Overly Broad Privileges

Misconfiguration has been a leading attack vector across virtually every technology generation, and Kubernetes is no exception. Sam Bisbee, Chief Security Officer at Threat Stack, is unambiguous: “Misconfigurations are still a primary concern with k8s, as they are with traditional apps and infrastructure. With k8s in particular, organisations are still learning how to run k8s, which makes it easy to make mistakes that can increase risk.”

Kubernetes-specific misconfigurations often arise at the intersection of three layers:

1. The cloud provider’s underlying infrastructure (IAM roles, VPC networking, managed node groups)
2. The Kubernetes orchestration layer (RBAC policies, network policies, pod security settings)
3. The containerised workloads themselves (image configurations, runtime privileges, secret handling)

Teams that do not understand how these layers interact are prone to configurations that appear correct in isolation but create exposure when combined. A pod granted a broad IAM role, for instance, can undermine namespace-level isolation entirely.

Common privilege mistakes to watch for include:

• Running containers as root when it is not required
• Binding the cluster-admin ClusterRole to service accounts or users more broadly than necessary
• Leaving the default service account token automounted in pods that do not need API access
• Not restricting privilege escalation via allowPrivilegeEscalation: false in security contexts

4. Reusing Credentials and Encryption Keys

Encrypting different databases with the same key is a long-standing bad practice. So is reusing passwords or credentials across cloud providers and services. Neither habit becomes acceptable in a Kubernetes context. Kubernetes Secrets are the native mechanism for injecting sensitive values into workloads, but they come with their own considerations: by default, Secrets are stored unencrypted in etcd. Enabling encryption at rest for etcd is a concrete step teams should take early in cluster configuration.

5. Underestimating the Complexity of Multi-Cloud and Hybrid Environments

Kubernetes is frequently deployed across multiple cloud providers or in hybrid on-premises and cloud configurations. Each environment introduces its own identity, networking, and storage abstractions, all of which need to be secured consistently. Teams that have siloed their security practices by environment will find this consistency difficult to achieve.

Network policies in Kubernetes are namespace-scoped and must be explicitly configured; by default, all pods can communicate with all other pods across the cluster. This is appropriate for early development but inappropriate for production workloads carrying sensitive data.

6. Skipping Ongoing Audit and Monitoring

Kubernetes emits rich audit logs covering API server activity, but those logs are only useful if they are collected, stored, and analysed. Teams that do not have an audit strategy in place are flying blind. The same logging and monitoring discipline that applied to traditional infrastructure applies here — with the added dimension of container-level and pod-level observability.

Practical Starting Points

• Apply the CIS Kubernetes Benchmark to your cluster configuration and review findings against your threat model.
• Audit your RBAC configuration regularly. Identify any cluster-admin bindings that are broader than necessary and reduce them.
• Enable etcd encryption at rest to protect Secrets stored in the cluster datastore.
• Define NetworkPolicy resources to restrict pod-to-pod traffic to only what is required by your application architecture.
• Enforce Pod Security Standards (or their predecessors, PodSecurityPolicy, depending on your Kubernetes version) to prevent containers from running with unnecessary privileges.
• Integrate security scanning into your CI/CD pipeline for container images and Kubernetes manifests before they reach production.
• Review the CNCF Kubernetes security audit findings, which remain a useful reference for understanding known architectural risk areas in the platform.

The Bottom Line

Kubernetes does not introduce entirely new categories of risk. It presents familiar risks — misconfiguration, excessive privilege, poor credential hygiene, security as an afterthought — in a more complex and distributed context that makes those risks harder to spot and easier to underestimate. Teams that bring solid security discipline to their Kubernetes adoption will find that much of what they already know applies directly. Teams that do not will find that Kubernetes amplifies, rather than corrects, their existing weaknesses.

Original reporting by enterprisersproject.com. Quotes attributed to Kirsten Newcomer (Red Hat), Luis Pabon (Portworx), Maksim Yankovskiy (Zettaset), and Sam Bisbee (Threat Stack) are drawn from the original source article.

The Problem: Too Many Consoles, Not Enough Visibility

Modern DevOps toolchains are rarely homogeneous. A single software delivery pipeline can span issue trackers, source control platforms, CI/CD systems, and project management tools — each with its own management console. Engineering leaders who need a cross-platform view of work in progress have historically had two unappealing options: build and maintain bespoke integrations themselves, or context-switch between multiple dashboards and attempt to correlate data by hand.

What Pinpoint Announced

In April 2020, Pinpoint launched an engineering operations dashboard designed to aggregate activity from multiple DevOps platforms into a single, unified view. According to company CEO Jeff Haynie, the dashboard provides real-time visibility into work occurring across commonly used platforms, including:

• Jira — issue and project tracking
• GitHub and GitLab — source control and pull request workflows
• Bitbucket — source control and CI integration
• Azure Team Foundation Server (TFS) — work item tracking and version control

Rather than replacing any of these tools, the Pinpoint dashboard acts as an aggregation layer, letting engineering managers and team leads drill into issues and pull requests without leaving a single console.

Key Capabilities

Unified Issue Workflow View

The dashboard surfaces a consolidated issue workflow timeline, so teams can see how work items move across platforms in real time. This is particularly valuable for organizations running mixed toolchains — for example, using Jira for backlog management while pull requests and code review live in GitHub or GitLab.

Bottleneck Identification

Haynie stated that the primary use case Pinpoint anticipates is identifying bottlenecks in the software development process. By correlating data across tools, the platform can surface patterns that would otherwise be invisible — such as pull requests sitting unreviewed, issues stalled between teams, or delivery timelines slipping due to under-staffed workstreams.

Machine Learning-Based Forecasting

Pinpoint has embedded machine learning models designed to forecast where delivery risks might arise. According to Haynie, these models factor in the number of developers working on a project, the organization’s historical delivery patterns, and projected deadlines. The goal is to shift the conversation from “are we writing more code faster?” to “are we writing the right code at the right time to keep projects on track?”

Why Cross-Platform Visibility Matters for DevOps Teams

The challenge Pinpoint is addressing is well-documented in engineering organizations of any scale. As dependencies between projects multiply, the cost of poor visibility compounds. A simple resourcing gap — say, one project needing two additional developers before a downstream project can begin — can cascade into missed deadlines across an entire portfolio if no one has a clear line of sight across tools.

Haynie described software engineering as a persistent “black box” from a business planning perspective. Platform-native dashboards exist within tools like Jira and GitHub, but each is optimized for that platform’s own data model. A neutral aggregation layer that integrates across any platform addresses a genuine gap, particularly for larger organizations running heterogeneous toolchains.

Platform-Native Dashboards vs. Third-Party Aggregators

Haynie acknowledged that major DevOps platform vendors have been building similar visibility tools, but noted that each offering is optimized for its own ecosystem. An organization using GitHub for source control and Jira for project tracking, for instance, will find that neither tool’s native reporting gives a complete picture on its own. Third-party aggregators like Pinpoint position themselves as platform-agnostic alternatives that preserve tool choice while adding cross-system observability.

Considerations for Engineering Leaders

Increased visibility into engineering work carries both organizational benefits and potential downsides. Used well, dashboards like Pinpoint’s can help managers allocate resources proactively, surface blockers early, and give non-technical stakeholders realistic delivery forecasts. Haynie was candid that some organizations might use the tool primarily to monitor output rather than to foster collaboration — though he expressed the expectation that most teams would use it constructively.

Engineering leaders evaluating tools in this category should consider how metrics will be contextualized and communicated to developers. Raw throughput data without context can be misleading and damaging to team culture. The most effective use of aggregated DevOps telemetry is to identify systemic bottlenecks and resource gaps — not to rank individual contributors.

Summary

Pinpoint’s 2020 dashboard launch targeted a real and recurring pain point: the lack of a unified, platform-agnostic view across the tools that make up a typical DevOps toolchain. By integrating with Jira, GitHub, GitLab, Bitbucket, and Azure TFS, and layering in ML-based delivery forecasting, the product aimed to give engineering managers actionable visibility without requiring custom integration work. As DevOps toolchains grow more complex, cross-platform observability tools of this kind are likely to become a standard part of the engineering operations stack.

Is Edge Computing Just a New Label for Cloud?

Enterprise cloud computing is now well established — but a newer term keeps appearing alongside discussions of 5G and the Internet of Things (IoT): edge computing. Is it genuinely new, or simply a rebrand of cloud concepts? The honest answer is that the boundary is blurry, and debate continues about exactly what qualifies as edge computing.

As Gordon Haff, technology evangelist at Red Hat, puts it: “Edge computing can apply to anything that involves placing service provisioning, data, and intelligence closer to users and devices.” That breadth of definition is part of what makes the term slippery.

The core idea, however, is straightforward: instead of routing every workload to a hyperscale data center hundreds or thousands of miles away, you place computing resources at the “edge” of the network — closer to the user or the device generating data. The goals are lower latency, faster response, and more efficient use of network bandwidth.

Where Edge Computing Performance Matters

The clearest argument for edge computing comes from latency-sensitive, safety-critical applications. Consider autonomous vehicles:

• Cloud-suitable task: Distributing navigation software updates to a fleet of vehicles overnight. There is no urgency; a distant data center handles this fine.
• Edge-required task: Deciding whether to steer left or right to avoid a pedestrian stepping into the road. Waiting for a response from a remote server is not an option — the decision must be made in milliseconds, either onboard or at a nearby network node.
• Edge-assisted task: Networked traffic management systems running on compute nodes embedded in traffic lights and cell towers. If a vehicle is travelling the wrong way at high speed, alerting nearby cars quickly enough to matter requires processing at or near the roadside — not in a data center 2,000 miles away.

Adam Drobot, chairman of OpenTechWorks Inc. and a member of the FCC Technology Advisory Committee, explains the physics: “From the cell tower, the signal can go over fiber, which is lightning fast, but there’s latency still at the speed of light, and if you have to communicate with a data center 2,000 miles away, that’s going to be a large latency.”

His conclusion: “Things that require real-time performance are going to tend to be done at the edge.”

Edge Computing and 5G Are Interdependent

Telecom operators promoting 5G have a strong incentive to build out edge infrastructure. Dalia Adib, who leads the edge computing practice at STL Partners, is direct on this point: “The latency targets they have for 5G you almost can’t get without edge.” The two technologies reinforce each other — 5G provides the high-bandwidth, low-latency radio link, while edge computing ensures that data does not have to travel far once it leaves the radio access network.

Drobot notes that mobile operators already own physical infrastructure at every cell tower site — equipment enclosures that could be converted into small, distributed data centers providing edge services. That existing footprint gives telecoms a meaningful role in any future edge ecosystem.

A Manufacturing Use Case: Predictive Maintenance

Edge computing is not limited to consumer or automotive scenarios. A common industrial example is predictive maintenance on a factory floor:

1. Robots on an assembly line generate continuous sensor data — vibration, temperature, pressure, cycle counts.
2. An edge device with more compute power than any individual robot aggregates that sensor data in real time.
3. Local algorithms running on the edge device detect patterns that signal an impending component failure — for example, a suction gripper about to wear out.
4. Maintenance is scheduled proactively before the robot fails, preventing production line stoppages and product damage.
5. The edge device also forwards aggregated, anonymized data to cloud-based machine learning systems, which refine the predictive algorithms and push updates back to the edge device.

This architecture — edge for real-time detection, cloud for model training — illustrates the complementary relationship between the two approaches.

Edge Does Not Replace the Public Cloud

Early predictions that public cloud would eventually absorb all enterprise computing have not come true. Gordon Haff argues that the same pattern will hold for edge computing:

“Edge computing only replaces public clouds in a world where public clouds were going to otherwise capture all workloads. And that world isn’t this one.”

Gordon Haff, Red Hat

Enterprise computing has always been heterogeneous. On-premises systems, colocation, private clouds, public clouds, and now edge nodes each occupy a place in a spectrum of deployment options. Edge computing adds another point on that spectrum — not a replacement for anything that already exists.

Beyond Latency: Other Reasons to Use Edge

Real-time performance is the most frequently cited reason to adopt an edge architecture, but it is not the only one:

• Bandwidth efficiency: Processing data locally and sending only relevant results to the cloud reduces traffic on network backbones, lowering both cost and congestion.
• Security and privacy: Keeping sensitive data closer to its source — rather than transmitting it to a centralized location — can reduce exposure and simplify compliance.
• Data sovereignty: Some jurisdictions require that certain data remain within specific geographic boundaries. Edge nodes within those boundaries can satisfy these requirements without routing data to a distant cloud region.
• Offline resilience: Edge devices can continue operating if the WAN connection to a central cloud is interrupted, which matters in industrial or remote environments.

The Role of Open Standards and Containers

Container technologies — already central to moving workloads between on-premises systems and the cloud — are expected to play a similar role in distributing workloads to edge locations. Containers provide consistent packaging and deployment regardless of the underlying hardware, which matters when edge nodes may span many different device types and locations.

Adib notes that enterprises in manufacturing, oil and gas, and telecommunications are wary of repeating past mistakes with proprietary technologies: “They’re trying not to replicate the mistakes of the past. Also, they don’t yet know who to work with… and they don’t want to be locked into any application or system that they can’t rip out if they want to.”

Open software and open standards reduce vendor lock-in — a lesson that the cloud era reinforced for many organizations.

Challenges Still Ahead

Edge computing carries real maturity risks. A Gartner report titled How to Overcome Four Major Challenges in Edge Computing warned that through 2022, a significant share of edge computing proofs of concept would fail to scale to production use. (The specific figures cited in that report should be verified against the primary source, as market research projections can be revised or misquoted.)

Common challenges include:

• Managing and monitoring a large number of geographically distributed edge nodes
• Establishing governance frameworks for data generated at the edge
• Integrating edge infrastructure with existing cloud and on-premises systems
• Securing devices that may be physically accessible in public or semi-public locations
• Defining best practices for deployment, updates, and lifecycle management

Edge and Cloud Coexist — and Complement Each Other

The practical conclusion from industry observers is that edge and cloud computing serve different parts of the same overall system. An FCC white paper on 5G, edge computing, and IoT (co-authored by Adam Drobot) captures this directly: many industry experts reject the framing of cloud and edge as competitors, and forward-looking organizations are instead determining how to selectively employ both.

A useful mental model:

• Edge: Latency-sensitive processing, real-time control, local data filtering, and applications where network connectivity cannot be assumed to be fast or reliable.
• Cloud: Big data aggregation, model training, long-running analytics, global collaboration, and workloads that benefit from virtually unlimited and elastically scalable compute.

Adib sums up the architecture reality well: “I think it’s going to be very rare that an application will live only in edge computing. It’s going to need to communicate and interact with other workloads that are in the cloud or in an enterprise data center or on another device.”

Key Takeaways for DevOps and Platform Engineers

• Edge computing places compute, storage, and intelligence closer to the data source to reduce latency and network load — it is not a replacement for the cloud.
• The strongest use cases are latency-critical (autonomous vehicles, industrial automation, augmented reality) and bandwidth-constrained (remote or high-volume sensor environments).
• 5G and edge are mutually dependent; neither fully delivers on its promise without the other.
• Container-based deployment patterns that work for cloud workloads transfer naturally to edge deployments.
• Favour open standards to avoid proprietary lock-in across a distributed edge estate.
• Expect a hybrid architecture: edge for real-time processing, cloud for aggregation, training, and global scale.

Proliferation of hybrid and multi-cloud architectures has resulted in rapid and remarkable technological advances. But it has also introduced monumental, multi-faceted complexities into IT infrastructure management, including:

Managing multiple on-premises, private and public cloud resources
Complicated and lengthy provisioning processes for resource deployment
Continually evolving challenges maintaining visibility into multi-cloud ecosystems
Ongoing concerns around governance, cost control and security
In the face of these challenges, enterprise IT must enable innovation and digital transformation. Whether through self-service and intelligent automation, or through building a base of continuous insights driven by AI, machine learning, and deep learning, adopting these new paradigms has never been more critical. Simultaneously, IT needs to stay operationally vigilant regarding visibility, governance and cost control as organizations accelerate their hybrid cloud growth.

Unfortunately, many IT leaders are struggling to successfully adapt to these challenges. According to ESG’s 2019 Technology Spending Intention Survey, most executives view IT as a drag on — not a driver of — innovation. Specifically, a mere 6 percent consider IT a competitive differentiator, and a full quarter of executives actually see IT as a business inhibitor. In a rapidly changing world of cloud, there has to be a better way.

By adopting these five core principles of IT infrastructure management, IT leaders can become strategic business drivers and better meet end users where they are:

1. Self-service

To prevent bottlenecks, IT must institute a self-service delivery model enabling developers to access resources when they need them. When end users are able to quickly and easily access the resources they need – storage, compute, networking and more – without having to go through IT, organizations can reach a whole new level of agility and productivity.

2. Intelligent automation

Self-service depends on automation – intelligent automation. It must ensure the orchestrated delivery of IT resources — whether that’s infrastructure or advanced services such as IoT, blockchain and developer tools — fit the end user’s role and responsibilities as well as the needs of the business. With intelligent automation, IT teams can build security and cost guardrails into provisioning those resources, covering everything from access privileges to how long provisioned resources remain available in the cloud. The result? Better governance and cost control.

3. Comprehensive visibility

Business and IT leaders don’t need visibility into some of their infrastructure; they need visibility into all of their infrastructure — whether that’s virtual machines on-prem, to private cloud networks, or multi-tier, load balanced applications in AWS, Azure, GCP and others. And they need this visibility consolidated into a single view, the proverbial “single pane of glass.” Unified visibility enables modern IT leaders to always know where and how resources have been deployed, monitoring all usage from a single platform.

4. Modular extensibility

To swiftly adopt new technologies and leverage existing IT investments, modern IT leaders embrace modular, extensible frameworks. You need such frameworks — for example, modular plug-in in the form of scripts, web hooks and email notifications – to support a rapidly evolving array of development tools, paradigms and priorities. For example, the world of hybrid cloud can mean using a mashup of existing tools, whether that’s Terraform for provisioning, Ansible for configuration, Veeam for cloud migration and many more. IT teams need to go beyond the API and leverage extensibility that makes plug-and-play painless. The result? Less vendor-locking and the ability to build your hybrid cloud, your way.

5. Continuous insight

Unified visibility into IT resource deployment and usage depends on the capture of data across workloads, clouds and teams. This allows IT teams to quickly identify areas of risk, sprawl and inefficiency. More impactfully, it also enables IT to pursue data-driven resource planning. With increased accuracy in rate estimation, up-to-date views of inventory and predictive provisioning based on recognized patterns of usage, IT can proactively anticipate the needs of the business and application development teams, becoming the innovation enabler it should be.

Real-world examples: The Home Depot

Situation

The Home Depot had its sights set on continuous integration and continuous delivery (CI/CD), but getting a machine provisioned took anywhere from several days to a week, causing major bottlenecks in business productivity. Also, the company lacked an effective way to track and manage resources, particularly in its hybrid cloud environment.

Solution

The company developed a self-service model, providing developers with front-facing infrastructure services. The IT team now allows thousands of users to provision cloud-based resources without submitting a ticket. What once took one to two weeks now takes 20 minutes.

Furthermore, by implementing a more flexible framework built on modular extensibility for orchestration, Home Depot made integration with existing infrastructure easy. This extensibility supports Home Depot’s evolving IT strategy and facilitates the adoption and integration of Kubernetes, Docker, Terraform and other emerging technologies.

InterContinental Hotels Group (IHG)

Situation

IHG owns over 5,000 hotels and utilizes four different public clouds. They wanted the flexibility of multiple public clouds in order to use the platform that provides the optimal environment for each workload, as well as to protect the organization from price increases and instabilities from any one public cloud. As a result, administrators needed to understand and use four different interfaces to locate, manage and provision compute resources.

Solution

IHG moved all managed resources from VMware vRA to a cloud management platform that provided a single user interface and API, through which they could deploy complex apps to VMware and any of the four public clouds they used. This enabled them to manage these apps and their servers over the course of their lifecycle, allowing for business policy automation as well as adoption of best practices around server deployment and management.

IHG now also uses comprehensive visibility and intelligent automation to control VM sprawl and protect against unexpectedly large bills from vendors. Through the use of expiration dates for servers, configurable expiration behavior, visibility into all VMs across all technologies, quotas, cost tracking and easy de-provisioning of servers and services, IHG ensures that organizations only pay for what they need and use.

The 5 principles and your organization

To tame enterprise IT infrastructure complexity, IT leaders must adopt a flexible and extensible model for IT infrastructure management that relieves pressure on IT while freeing both the enterprise and developer teams to take advantage of emerging technologies. By adopting the five core principles of IT infrastructure management, your organization can improve time-to-value for your hybrid cloud and multi-cloud management strategy.

Why Kubernetes Security Demands Attention

Container and Kubernetes adoption has grown rapidly across enterprises of all sizes. However, that growth has outpaced security maturity in many organizations. Reports from both the CNCF and security vendors have consistently identified misconfiguration as the leading cause of Kubernetes security incidents—not sophisticated zero-day exploits. Addressing the fundamentals is, therefore, the highest-leverage activity for most teams.

1. Integrate Security Into DevOps Workflows (Shift Left)

Kubernetes is a core part of most modern DevOps pipelines. Security should not be an afterthought applied at deployment time—it needs to be embedded throughout the CI/CD lifecycle.

• Static analysis and linting: Use tools such as kube-score, kube-linter, or Checkov to scan Kubernetes manifests for security misconfigurations before they reach a cluster.
• Policy-as-code in pipelines: Enforce admission policies through tools like Open Policy Agent (OPA) / Gatekeeper or Kyverno so that non-compliant workloads are rejected automatically.
• Secrets management: Avoid storing secrets in plain YAML files. Integrate a secrets manager (HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets with encryption at rest) into your pipeline.

Automating these checks eliminates a significant proportion of human error—the primary root cause of Kubernetes security incidents.

2. Pod-Level and Node-Level Security Hardening

Kubernetes exposes configuration knobs at both the pod and the underlying node level. Both layers must be hardened.

Pod-Level Controls

• Pod Security Admission (PSA): As of Kubernetes 1.25, PodSecurityPolicy (PSP) has been removed. The replacement is Pod Security Admission, which enforces built-in security profiles (privileged, baseline, restricted) at the namespace level. Aim for the restricted profile on production workloads.
• Non-root containers: Set runAsNonRoot: true and explicitly define runAsUser in the pod’s securityContext.
• Read-only root filesystems: Use readOnlyRootFilesystem: true to prevent attackers from writing malicious files to the container filesystem.
• Drop unnecessary Linux capabilities: Use capabilities.drop: ["ALL"] and add back only what the workload specifically requires.

Node-Level Controls

• Use minimal, purpose-built node operating systems (e.g., Bottlerocket, Flatcar Linux) that reduce the attack surface.
• Limit SSH access to nodes; prefer using kubectl exec for debugging where possible.
• Apply CIS Kubernetes Benchmark recommendations to node configuration.
• Enable node auto-repair and keep the Kubernetes version current to receive security patches.

3. Securing Container-to-Container Communication

By default, all pods in a Kubernetes cluster can communicate with each other. This flat network model is convenient but dangerous—a compromised pod can reach any other pod without restriction.

Network Policies

Kubernetes NetworkPolicy objects let you define ingress and egress rules at the pod level using label selectors. A default-deny posture—blocking all traffic unless explicitly allowed—is the recommended starting point for production namespaces.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Service Meshes for Mutual TLS (mTLS)

Network policies operate at Layer 3/4 but do not encrypt traffic. A service mesh—such as Istio, Linkerd, or Cilium with WireGuard—adds a sidecar proxy (or an eBPF-based data plane) to each pod, enabling mutual TLS (mTLS) for all service-to-service communication. This ensures that only authenticated services can talk to each other, and that all traffic is encrypted in transit even inside the cluster.

4. Role-Based Access Control (RBAC)

RBAC is the primary authorization mechanism in Kubernetes and should be configured with a least-privilege approach across every component.

• Avoid cluster-admin bindings: Grant only the permissions a service account or user actually needs. Audit existing ClusterRoleBindings regularly.
• Use namespaced roles where possible: Prefer Role and RoleBinding over ClusterRole and ClusterRoleBinding to limit blast radius.
• Separate service accounts per workload: Do not share a single service account across multiple applications. This limits lateral movement if one workload is compromised.
• Disable automounting of service account tokens: Set automountServiceAccountToken: false on pods that do not need to communicate with the Kubernetes API.

An attacker who gains access to a pod with an overly permissive service account token can escalate privileges across the entire cluster, including reaching the API server and etcd. Tight RBAC configuration is a critical control against this attack path.

5. Managed Kubernetes Services

Operating a self-managed Kubernetes cluster requires significant expertise. Teams lacking dedicated platform security resources often find that managed Kubernetes offerings—such as Amazon EKS, Google GKE, or Azure AKS—substantially reduce operational security burden.

Managed services typically provide:

• Automated control plane patching and upgrades.
• Managed etcd with encryption at rest handled by the provider.
• Integration with cloud-native identity systems (IAM) for authentication.
• Built-in audit logging pipelines.

Managed Kubernetes is not a substitute for correctly configuring workload security—pod security, RBAC, and network policies remain the team’s responsibility—but it removes a significant class of control-plane vulnerabilities caused by mismanaged infrastructure.

6. Kubernetes-Native Security Platforms

Beyond built-in Kubernetes controls, a growing ecosystem of security platforms provides runtime threat detection, vulnerability scanning, and compliance reporting specifically tailored to containerized environments. Categories include:

• Container image scanning: Tools such as Trivy, Grype, or Snyk scan container images for known CVEs before or during deployment.
• Runtime security: Falco (CNCF) monitors system calls at runtime and alerts on anomalous behavior such as unexpected shell executions inside containers.
• Cloud Security Posture Management (CSPM): Platforms such as Prisma Cloud, Wiz, or Lacework continuously assess cluster configuration against security benchmarks.

The right tooling mix depends on your threat model, compliance requirements, and operational maturity. Evaluate tools against the CIS Kubernetes Benchmark and NIST SP 800-190 (Application Container Security Guide) for an objective baseline.

Summary: Key Kubernetes Security Controls

Kubernetes security is not a one-time configuration task—it is an ongoing practice that spans development, deployment, and production operations. Starting with the fundamentals above and continuously auditing your cluster configuration against a recognized benchmark will eliminate the majority of risk present in most production Kubernetes environments.

What Is Minikube?

Minikube is an open source tool that runs a single-node Kubernetes cluster inside a virtual machine on your laptop or workstation. It does not require a cloud environment or an on-premises data center. The goal is to bring Kubernetes down to a manageable local footprint without gutting the functionality developers actually need day to day.

Despite the “mini” in the name, Minikube supports a broad set of Kubernetes features, including:

• DNS and NodePorts
• ConfigMaps and Secrets
• The Kubernetes Dashboard
• Container runtimes: Docker, CRI-O, and containerd
• Ingress controllers
• Container Networking Interface (CNI)
• A growing library of add-ons (see Fact 4 below)

What is downsized is scope — specifically, you are limited to a single node. Functionality, however, remains surprisingly complete for local development and testing purposes.

1. Minikube Can Help You Make the Case for Kubernetes

Getting organizational buy-in for Kubernetes can be difficult when stakeholders range from deeply technical engineers to business-focused executives. Minikube provides a low-risk, hands-on way to demonstrate Kubernetes capabilities without provisioning cloud infrastructure or standing up a full cluster.

“Minikube is a great way for some IT decision-makers to get a ‘lab’ experience — especially if it is done in the context of business outcomes that matter to the enterprise.”

E.G. Nadhan, Red Hat Chief Architect and Strategist, North America Commercial

A live demo running on a laptop can be more persuasive than a slide deck. If you are trying to help leaders at varying levels of seniority understand what Kubernetes could do for the business, a Minikube-powered walkthrough is a practical starting point.

2. Minikube Is Free and Relatively Easy to Get Started With

Kubernetes has a well-earned reputation for a steep learning curve, particularly in production. Minikube is explicitly designed to lower that barrier. It is a free download that runs on Linux, macOS, and Windows, and the official Kubernetes documentation provides clear installation instructions along with a beginner-friendly tutorial for deploying a simple application.

For teams working on RHEL, Fedora, or CentOS workstations, distribution-specific setup guides are available from the open source community. The official Kubernetes documentation at kubernetes.io is the most authoritative and up-to-date starting point.

3. Minikube Is Especially Valuable for Developers

While Minikube is useful for anyone exploring Kubernetes, it is a particularly strong fit for developers. It supports the full development lifecycle from initial learning through day-to-day coding work, without requiring access to a shared cluster or cloud environment.

“Developers who wish to quickly start learning Kubernetes, without having to invest in or utilize a multi-node Kubernetes cluster on-premises or in a cloud, can use Minikube as a first step. Minikube powers the capability of a Kubernetes cluster to run in a single box with limited resources.”

Raghu Kishore Vempati, Director of Technology, Research, and Innovation, Altran

One important caveat: Minikube is not intended as a production tool. Attempting to use it for production workloads would be misusing it — it is architected for local experimentation and development, not for managing live, distributed applications at scale.

4. Minikube Works Well for Testing, Including Complex Features

Beyond learning and experimentation, Minikube is genuinely useful for testing cloud-native applications before they enter a formal CI/CD pipeline or a staging cluster. Its add-on ecosystem is what makes this possible — even on a single-node local cluster, you can enable capabilities that reflect production-like conditions.

Notable add-ons available in Minikube include:

• EFK stack (Elasticsearch, Fluentd, Kibana) — for local log analysis
• Helm / Tiller — for package management testing
• Kubernetes Dashboard — for visual cluster management
• Istio — for testing service mesh behavior before scaling up
• NVIDIA GPU driver and device plugin — for GPU-dependent workloads
• Ingress controller — for routing and load balancing experiments

“For developers building cloud-native applications, Minikube can be used to perform initial testing locally, before they put them through a more formal test cycle.”

Raghu Kishore Vempati, Altran

Minikube is also a safe environment for evaluating new Kubernetes versions before rolling upgrades out to production clusters — a lower-risk way to assess compatibility and catch breaking changes early.

5. Minikube Is Open Source and Extensible

Minikube is released under the Apache 2.0 license, which means developers are free to inspect, fork, and extend it. This matters in practice: teams in large organizations sometimes maintain a customized internal distribution of Minikube that includes organization-specific add-ons or pre-configured settings, reducing setup time for individual developers.

“Developers can extend Minikube particularly to create custom add-ons and provide a customized version of Minikube. This approach is particularly useful in large organizations where developers use a Minikube version with customized add-ons.”

Raghu Kishore Vempati, Altran

This extensibility mirrors one of Kubernetes’ own core strengths and is a meaningful reason why the tool has remained relevant even as the Kubernetes ecosystem has grown more crowded with tooling alternatives.

6. Minikube Is Not the Only Option for Running Kubernetes Locally

Minikube is a strong default choice, but it is worth knowing the alternatives — different tools serve different workflows, team structures, and CI/CD requirements.

• kind (Kubernetes IN Docker) — runs Kubernetes cluster nodes as Docker containers, making it a popular choice for CI/CD integration. It is lightweight, fast to spin up, and well-suited to automated testing pipelines.
• Minishift — a close relative of Minikube designed for running OKD (the community distribution underlying Red Hat OpenShift) locally. Useful if your production environment is OpenShift-based.
• k3s / k3d — a lightweight Kubernetes distribution from Rancher, designed for resource-constrained environments and edge use cases. k3d wraps k3s in Docker for easy local use.
• Docker Desktop — includes an optional single-node Kubernetes cluster, offering the simplest setup for developers already using Docker Desktop on macOS or Windows.

The right choice depends on your team’s priorities. Minikube excels at faithfully reproducing Kubernetes behavior locally with broad add-on support. kind excels when CI/CD pipeline integration is the priority. Evaluate based on your actual workflow rather than defaulting to any single tool.

Summary: When to Use Minikube

Minikube remains one of the most practical entry points into Kubernetes. It is free, well-documented, actively maintained, and honest about its scope: a powerful local cluster for development and learning, not a production substitute. For teams that are beginning their Kubernetes journey or need a reliable sandbox for testing, it is a tool worth knowing well.

Original source article: The Enterprisers Project. Quotes attributed to E.G. Nadhan (Red Hat), Tom Manville (Kasten), and Raghu Kishore Vempati (Altran) are sourced from the original article.

Why Mainframe DevOps Matters

Mainframes continue to run the core business processes of banks, insurers, retailers, and governments worldwide. Yet the software delivery practices surrounding them have, in many organisations, changed little in decades. As enterprises adopt Agile and DevOps across distributed and cloud workloads, the mainframe risks becoming an island — a bottleneck that limits the speed and reliability of the entire value stream.

To remain competitive, enterprises must bring the same DevOps disciplines that accelerate cloud-native delivery to bear on their mainframe applications and data. The following ten steps provide a practical, phased roadmap for doing exactly that.

Step 1 — Modernise the Developer Workspace

Most mainframe development still happens inside 3270 green-screen ISPF environments. These tools require highly specialised knowledge and are immediately alienating to developers who have grown up with modern IDEs. The productivity gap between experienced mainframe engineers and newer staff widens every year.

The first step is to give developers a workspace that looks and behaves like the Eclipse-style IDEs they already know. A modern, GUI-based mainframe IDE lowers the barrier to entry, allows developers to move fluidly between mainframe and non-mainframe codebases, and makes it practical to build cross-functional Scrum teams that include mainframe components without requiring every member to master ISPF.

Step 2 — Introduce Unit Testing

Unit testing is a cornerstone of Agile delivery. Frequently testing small, isolated increments of code allows developers to verify that their work aligns with immediate objectives and to catch defects at the lowest possible cost — before they compound.

Many mainframe developers have spent careers in waterfall environments where testing happened late and infrequently. Introducing unit testing therefore requires both tooling and a shift in working habits. Teams must learn to decompose their work into smaller, testable units and to run tests continuously as they code rather than at the end of a development cycle.

Step 3 — Add Functional and Integration Testing

Unit testing confirms that individual code units work correctly in isolation. Functional testing validates that those units satisfy their specified requirements — that the system does what it is supposed to do from a business perspective.

Once functional testing is in place, integration testing extends coverage further: it verifies that two or more programs work together as expected. On the mainframe, where large COBOL or PL/I applications interact with DB2, VSAM, CICS, and IMS, integration testing is particularly important. A defect in a cross-program interface can cascade into failures across core business processes.

Step 4 — Make Application Logic Visible and Understandable

Mainframe applications are often large, complex, and poorly documented. A single COBOL program may have grown over decades through dozens of hands, with little consistent commentary. New contributors — and even experienced ones working in unfamiliar areas — can spend the majority of their time simply trying to understand existing code before they can safely modify it.

Tooling that automatically visualises application logic, program interdependencies, data structures, and runtime call sequences dramatically reduces this orientation time. When developers can see how a system behaves at runtime — including which programs are called, in what order, and what data they read and write — they can work on unfamiliar systems with far greater confidence and speed.

Step 5 — Implement Continuous Quality Controls

Mainframe applications typically support core business processes that have very low tolerance for error. Transitioning from waterfall to Agile delivery cycles makes continuous quality control not just desirable but essential, for three reasons:

• Error tolerance is low. Failures in core business systems — payments, claims processing, inventory — carry immediate and significant business consequences.
• Cost of defects rises with time. In Agile cycles, a defect caught in the current sprint costs far less to fix than one discovered during system integration testing or, worse, in production.
• The developer talent pool is changing. As experienced mainframe engineers retire, less experienced developers are increasingly responsible for maintaining and evolving these systems. Automated quality controls compensate for the loss of institutional knowledge.

Continuous Integration (CI) is the enabling mechanism here. A CI pipeline that triggers quality checks — static analysis, unit tests, security scans — every time code is committed ensures that quality is maintained continuously rather than assessed periodically.

Step 6 — Adopt Agile Planning and Cross-Platform Scrum Teams

The goal is to move away from mainframe-only development silos and toward unified Scrum teams that include developers working on mobile, web, and mainframe components simultaneously. Work should be captured in stories and epics that represent specific units of business value — not technical tasks tied to a waterfall project plan.

This requires formal Agile training for all team members. Technical leads and Product Owners need in-depth coaching on backlog management, sprint planning, and the role of acceptance criteria. All team members should at minimum understand how to read a Scrum or Kanban board and participate in sprint ceremonies. Without this foundation, Agile tooling becomes overhead rather than an accelerator.

Step 7 — Leverage Operational Data Throughout the Lifecycle

Writing correct code is necessary but not sufficient. Mainframe applications must also perform efficiently under production load, because mainframe compute is typically billed by MIPS or MSU consumption. Inefficient code that works correctly can still be extremely expensive to run.

Integrating operational metrics — CPU usage, I/O rates, response times, database call patterns — into the DevOps lifecycle gives both development and operations teams a shared, data-driven view of application behaviour throughout its lifecycle. Early visibility into performance characteristics allows teams to identify and eliminate inefficient code before it reaches production, reducing both risk and cost.

Step 8 — Modernise Software Configuration Management

Traditional mainframe Software Configuration Management (SCM) tools were designed to support waterfall delivery: they provide version control, change tracking, and audit trails, but they are not built for the rapid, iterative workflows of Agile and DevOps.

Modern SCM for the mainframe must do more than automate and audit the SDLC. It must integrate with the broader DevOps toolchain — linking to CI/CD pipelines, issue trackers, testing frameworks, and deployment automation — so that the mainframe participates in the same end-to-end workflow as every other platform. The transition from waterfall SCM to Agile-enabling SCM is a significant change and should be carefully planned to avoid disrupting work in progress.

Step 9 — Automate Deployment with Reliable Rollback

Fast, reliable delivery requires automating the promotion of code and related artefacts across all targeted environments in a synchronised, repeatable way. Manual deployment processes introduce delay, inconsistency, and human error — all of which are incompatible with the release cadences that DevOps demands.

Equally important is automated rollback. When a deployment fails or a defect is discovered in production, teams must be able to revert quickly and automatically to the last known-good state. Automated rollback is not just a safety net; it is a prerequisite for accepting the higher deployment frequency that DevOps targets, because it contains the blast radius of any individual failure.

Step 10 — Integrate the Mainframe into a Unified, Cross-Platform DevOps Model

The ultimate objective is a de-siloed environment in which the mainframe is treated as one platform among many — distinguished by its scalability, reliability, performance, and security, but managed through the same DevOps processes, pipelines, and dashboards as distributed and cloud systems.

This unified model extends to IT Service Management (ITSM) as well. As more business-critical user journeys span multiple platforms — from a mobile front end through a web API layer to a mainframe system of record — ITSM teams need a single pane of glass for incident detection, triage, and resolution regardless of where the root cause lies.

The payoff is significant: when mainframe delivery velocity matches the rest of the organisation, the entire business becomes more adaptive. Conversely, if the mainframe remains a bottleneck, the agility gains achieved on other platforms will always be constrained by the slowest part of the value chain.

Summary

Mainframe modernisation is not a single project with a finish line — it is a continuous journey of incremental improvement. Each step in this framework builds on the last, progressively closing the gap between mainframe delivery practices and the DevOps standards now expected across the rest of the enterprise.

ACT-IAC Releases New DevOps Primer
PR Newswire

FAIRFAX, Va., Feb. 20, 2020

Featuring Six Case Studies and a Maturity Model to Guide Federal Agencies’ DevOps Journey

FAIRFAX, Va., Feb. 20, 2020 /PRNewswire/ — The American Council for Technology and Industry Advisory Council (ACT-IAC), the premier public-private partnership dedicated to advancing government through the application of information technology, today officially announced the release of the “DevOps Primer.” It was produced through a collaborative, volunteer effort by a working group from government and industry, hosted by the ACT-IAC Emerging Technology Community of Interest (COI).

DevOps is an organizational philosophy that requires an essential shift in attitudes and approach. It requires a growth mindset as much as it does new and reengineered practices and tools. ACT-IAC developed this primer to be a guide to support the Federal government in its understanding and application of DevOps to support its mission. It includes recommendations from government and industry leaders to identify and explore the culture, practice, and tools to advance the DevOps journey.

“The ACT-IAC DevOps Primer is an outstanding example of the power of government and industry collaboration. It contains essential material for both federal and industry IT leaders looking for practical ways to innovate and quickly deliver results,” said David Wennergren, CEO of ACT-IAC, “The featured case studies on federal agencies provide real world experience on using DevOps to drive improved mission outcomes.”

“The ACT-IAC DevOps Primer will help guide federal agencies and increase their ability to deliver applications and services at a faster pace than using traditional software development and infrastructure management processes. It’s a must-read, especially for smaller agencies,” stated Jeremy Wood, Director of Policy and Planning, Office of the Chief Information Officer, Millennium Challenge Corporation.

“Through hundreds of conversations about what is working and what is not, the ACT-IAC DevOps Primer shares insights on DevOps and ‘what is next’ for Federal agencies. We hope that the lessons learned and the recommendations will help organizations looking to apply DevOps tools and practices to fulfill their missions,” said Robin Camarote, Senior Consultant, Wheelhouse Group.

DevOps in government is the move towards a collaborative and communicative mindset and culture with streamlined practices by bringing the development and operations groups together to work as one team. It is a continuous journey and cannot be completed in a silo.

To complement the DevOps Primer, ACT-IAC is hosting the DevOps Forum on February 20, 2020 in Washington, DC. Explore all the resources and opportunities at ACTIAC.org.

American Council for Technology and Industry Advisory Council (ACT-IAC)
The American Council for Technology and Industry Advisory Council (ACT-IAC) is a non-profit educational organization created to provide a safe haven for collaboration and the only place where government and industry can work together as true partners towards a shared vision of a more effective, efficient and innovative government.

Cloud Adoption Is Accelerating — But So Are the Risks

The public cloud market has been on a sustained growth trajectory, driven by major platforms from Amazon (AWS), Microsoft (Azure), and Google (GCP). Yet beneath the headline growth figures lies a more complicated story: the organizations migrating to the cloud are frequently introducing the very security vulnerabilities they hoped to avoid.

According to figures cited in the original interview, nearly half of organizations surveyed had experienced a cloud security incident, and a significant share had considered moving data back on premises as a result. With half of companies storing personally identifiable information (PII) in the cloud, and roughly a quarter storing payment data there, the stakes are high.

George Burns III, a Senior Consultant of Cloud Operations at SPR, offers a practitioner’s perspective on what those risks actually look like and how engineering and IT leadership teams should respond.

How Fast Is the Cloud Market Growing?

Burns describes cloud growth as broad and sustained across most market segments, with new workloads increasingly being born in the cloud rather than migrated to it. As that shift matures, overall growth rates are expected to stabilize into a more predictable maintenance curve for established services.

The most significant growth potential, Burns argues, lies in emerging technologies:

• Edge computing: Extending compute and data resources closer to end users and devices for lower latency and better experiences.
• IoT infrastructure: The growing fleet of Internet-connected devices and the cloud platforms that support them represent a major new deployment surface.
• AI and ML workloads: The explosion of artificial intelligence and machine learning has directly influenced hardware design — particularly GPUs — and how cloud data centers are architected.

Who Are the Major Players?

Burns identifies the three dominant public cloud providers as AWS, Microsoft Azure, and Google Cloud Platform (GCP). Beyond the hyperscalers, he notes that industry-specific players carry significant weight in their own domains — for example, Epic Systems in the electronic medical records space.

Oracle’s influence extends into cloud through its widely deployed Oracle and MySQL database products. Hardware manufacturers also play a shaping role: as data centers expand and AI workloads grow, chip design itself is being influenced by cloud infrastructure trends.

Storage is another area of active evolution. As data volumes grow and data ages, tiered storage strategies have emerged — with low-cost, high-latency solutions for cold archival data, and high-speed technologies like NVMe over network fabrics addressing the demand for sub-millisecond latency at the hot end.

The Real Source of Cloud Security Risk

Burns makes a distinction that is worth internalizing: the cloud platform itself is rarely the source of risk. The risk lives in the connective tissue — the integrations, configurations, and human decisions that tie platforms and products together.

This is a pattern that DevOps and platform engineering teams encounter repeatedly. Misconfigurations, overly permissive IAM policies, unreviewed third-party dependencies, and undocumented change processes create far more incidents than vulnerabilities in the underlying cloud infrastructure.

Burns identifies several concrete areas of focus:

• Documentation and change management: Maintaining accurate, up-to-date records of infrastructure state is foundational to security. Configuration drift is a common vector for incidents.
• Certificate authorities and trust chains: The integrity of trusted CAs matters more as cloud-connected systems multiply. Any erosion of that trust chain creates systemic exposure.
• Data flow mapping: You cannot secure what you cannot see. A complete understanding of how data moves through your infrastructure — including across third-party integrations — is a prerequisite for effective security posture.
• Vendor and partner vetting: Working with certified, knowledgeable partners is not optional. An insecure partner with access to your environment is a direct security risk to your platform.

How Many Businesses Have Been Affected?

Burns is candid: “More businesses have been impacted by cloud security issues than we’ll ever be able to accurately count.” He argues that the concept of “cloud security” now encompasses almost any data leak or breach scenario, because the cloud touches nearly every layer of modern business infrastructure.

Not every organization will detect every incident. Some breaches stem from under-resourced security teams that lack the tooling or expertise to identify threats. Others originate in failed business relationships — a compromised vendor, a poorly scoped contractor, a misconfigured SaaS integration.

Burns’s position is direct: every business will eventually experience a cloud security gap. Many already have, whether they know it or not.

Practical Steps to Reduce Cloud Security Exposure

Burns outlines a practical framework for reducing risk, applicable to both cloud providers and their customers:

1. Work with certified practitioners. Cloud platforms evolve rapidly, and the skill sets required to operate them securely are specific and often platform-dependent. Ensure the people managing your infrastructure hold current certifications and have hands-on platform experience.
2. Conduct regular security reviews and audits. One-time assessments are insufficient. Scheduled, recurring audits help surface configuration drift, access control issues, and newly introduced vulnerabilities before they become incidents.
3. Build security into your deployment processes. Integrating security review into CI/CD pipelines and infrastructure-as-code workflows reduces the window between introducing a vulnerability and detecting it.
4. Maintain visibility into your full data footprint. Know where your sensitive data lives, who has access to it, and how it flows between services and partners.

What the Future Looks Like for IT Leaders

Burns frames the challenge for IT leadership as a balancing act: “The stability of the proven versus the promise of the new.” Emerging technologies attract attention and often drive genuine competitive advantage, but they also carry unknown risk profiles and are more likely to have unpatched vulnerabilities or immature security tooling.

His prescription for successful IT leadership: embrace change, but do so within a framework of deliberate security and stability governance. Public cloud will remain the default deployment target for most organizations. The leaders who navigate this well will be those who can evaluate and adopt new capabilities without sacrificing the operational discipline that keeps their platforms secure.

Key Takeaways for DevOps and Platform Teams

• Cloud platforms are generally well-hardened. Your configuration, access controls, and integrations are the attack surface.
• Misconfiguration and human error — not infrastructure vulnerabilities — drive the majority of cloud security incidents.
• Regular audits, certified practitioners, and complete data flow documentation are non-negotiable baseline practices.
• Every organization operating in the cloud should assume they have already experienced a security gap, and invest accordingly in detection and response capabilities.
• IT leaders must balance innovation adoption with operational security discipline — neither pure conservatism nor unchecked experimentation serves the organization well.

Original interview conducted by Digital Journal. Statements attributed to George Burns III, Senior Consultant of Cloud Operations, SPR.

Google Cloud Expands Its Certification Portfolio

Google Cloud announced two new certifications aimed at addressing real-world skills gaps in enterprise cloud adoption: the Google Cloud Certified Fellow programme for senior technical leaders, and the Professional Cloud DevOps Engineer certification for practitioners focused on reliability and delivery velocity. Together, the two credentials cover opposite ends of the cloud career ladder — strategic leadership and hands-on engineering.

Google Cloud Certified Fellow: Recognition for Anthos Experts

The Google Cloud Certified Fellow programme is an invitation-only credential designed for technical leaders who have demonstrated deep expertise in designing enterprise solutions on Anthos, Google’s open hybrid and multi-cloud application platform. It is not a self-service exam that anyone can register for; candidates must be nominated and then pass a series of rigorous assessments.

What the Assessment Involves

• Hands-on labs that test practical Anthos skills in realistic scenarios
• A panel interview with Google Cloud product and engineering leadership
• Evaluation of the candidate’s ability to lead organisations through hybrid and multi-cloud adoption

At the time of the announcement, twenty IT leaders had already earned the Certified Fellow designation and were actively applying those skills within their organisations.

What Certified Fellows Gain

• Industry recognition as a proven Anthos and hybrid-cloud expert
• Access to a peer network of other Certified Fellows
• Direct engagement with Google Cloud product and engineering teams
• A platform to contribute knowledge back to the broader cloud community

“The Certified Fellow exam pushed my understanding of Anthos’ capabilities, and the certification provides me with the platform to help educate the community about the latest technology and inspire people to become better engineers.”

— Chris Love, Principal Architect at LionKube and Google Cloud Certified Fellow

“I am proud of the recognition for my skill level from Google Cloud and my clients value the mastery it demonstrates. Having representation in the Certified Fellow Program reinforces Accenture’s commitment to Cloud innovation and to our continued Google Cloud partnership.”

— Zach Snee, Cloud Solutions Architect at Accenture and Google Cloud Certified Fellow

Professional Cloud DevOps Engineer: A Certification for Practitioners

Unlike the Certified Fellow programme, the Professional Cloud DevOps Engineer certification is an open, exam-based credential available to any DevOps professional who wants to validate their skills on Google Cloud. It targets engineers responsible for balancing service reliability with development speed — two tensions at the core of modern site reliability engineering (SRE) and DevOps practice.

Why This Certification Matters

The cloud skills shortage makes it difficult for hiring managers to quickly identify qualified candidates. A vendor-neutral job title like “DevOps Engineer” can encompass vastly different experience levels and tooling backgrounds. A Google Cloud-specific certification gives employers a concrete, verifiable signal that a candidate understands Google Cloud’s operations tooling, CI/CD patterns, and reliability practices.

For engineers, the certification provides a structured learning path and a portable credential that demonstrates expertise in:

• Efficient development operations on Google Cloud
• Service reliability engineering principles
• Delivery speed and deployment pipeline best practices
• Monitoring, logging, and incident response on Google Cloud infrastructure

How the Two Certifications Compare

What This Means for DevOps Teams

For organisations running workloads on Google Cloud — or evaluating a move to Anthos for hybrid or multi-cloud deployments — these certifications provide a practical hiring and talent-development framework. Engineering managers can use the Professional Cloud DevOps Engineer credential as a benchmark when evaluating candidates or building internal training programmes. For individual contributors, it represents a clear and achievable professional development goal with direct market value.

For staff aspiring to architecture or principal engineering roles, understanding the Certified Fellow programme sets a longer-term goal that also provides a deep incentive to master Anthos and enterprise hybrid-cloud design — skills that remain in high demand regardless of which cloud certifications a team pursues.

Further Reading

• Google Cloud Professional Cloud DevOps Engineer certification page
• Google Anthos platform overview

Global DevOps Market at a Glance

According to a 2019 report by Reports and Data, the global DevOps market was projected to reach USD 14.58 billion by 2026. The growth is attributed to organizations accelerating software delivery cycles while simultaneously reducing costs through automation, continuous integration, and continuous delivery (CI/CD) pipelines.

At its core, a DevOps system coordinates all tools and process components required to sustain a rapid software development lifecycle. This includes managing source code changes, code merging, host initialization, build execution, automated release packaging, multi-stage automated testing, and results reporting. By automating these steps, organizations reduce both capital expenditure (CapEx) and operational expenditure (OpEx) through more efficient resource monitoring and utilization.

What Is Driving DevOps Adoption?

DevOps adoption is driven by the need to close the gap between software development speed and business responsiveness. Key drivers include:

• Continuous collaboration: DevOps breaks down silos between development, operations, QA, and business teams, enabling faster integration of customer feedback into product releases.
• Waste reduction: The DevOps feedback loop helps organizations identify duplication of effort, process bottlenecks, and inefficiencies across the delivery pipeline.
• Continuous deployment: Fully automated delivery pipelines—without manual gates—reduce time to market and ensure consistent, repeatable releases.
• Balanced delivery: DevOps helps teams maintain equilibrium between speed, quality, cost, and risk rather than trading one off against another.

Continuous deployment, in particular, plays a critical role: automation validates each step of the software process, simplifies cross-team communication, and ensures releases happen on schedule without introducing manual risk.

Market Segmentation

The global DevOps market can be analyzed across several dimensions. The Reports and Data study segments the market by offering type, organization size, deployment model, industry vertical, and region.

By Offering

• Delivery & Operations Management
• Monitoring & Performance Management
• Testing & Development
• Lifecycle Management
• Analytics

By Organization Size

• Small & Medium-Sized Enterprises (SMEs)
• Large Enterprises

By Deployment Model

• On-Premises
• Cloud-Based

Cloud-based deployment has grown significantly as organizations prioritize scalability and reduced infrastructure overhead. On-premises deployments remain relevant in regulated industries where data residency and compliance requirements are stricter.

By Industry Vertical

• Information Technology (IT)
• Telecom
• Banking, Financial Services & Insurance (BFSI)
• Retail
• Other verticals

BFSI and IT sectors have historically led DevOps adoption due to their high release frequency requirements and competitive pressure to deliver digital services rapidly.

By Region

• North America – United States
• Europe – United Kingdom, France
• Asia Pacific – China, India, Japan
• Latin America – Brazil
• Middle East & Africa (MEA)

North America has traditionally dominated DevOps market share due to early enterprise adoption and a mature ecosystem of tooling vendors. Asia Pacific, led by India’s large IT services sector, is expected to represent one of the fastest-growing regions in the forecast period.

Understanding Customer and Market Dynamics

Market research on DevOps goes beyond technology analysis. Understanding buyer behavior is critical for vendors positioning products and services in this space. Key analytical dimensions include:

• Behavioral segmentation: How organizations currently use DevOps tools, their spending patterns, and consumption volumes help vendors tailor offerings to different maturity levels.
• Psychographic factors: Organizational culture, appetite for innovation, and risk tolerance influence DevOps tool selection and adoption pace.
• Technical proficiency: The degree of in-house DevOps expertise affects whether buyers prefer managed services, open-source toolchains, or integrated commercial platforms.
• Geographic variation: Regulatory environments, cloud infrastructure availability, and regional IT maturity create different buying patterns across markets.

Key Questions the Market Research Addresses

A comprehensive DevOps market report is designed to help technology vendors, investors, and enterprise buyers answer strategic questions such as:

• What is the projected total addressable market (TAM) for DevOps tools and services through 2026?
• How does market size and growth rate vary by country and region?
• Who are the dominant vendors, and what share of the market do they hold?
• How intense is competitive pressure among established players and new entrants?
• What product and service categories are gaining or losing market traction?
• Are market leaders’ competitive strengths and weaknesses meaningfully different from those of start-ups?
• What risks do established vendors pose to emerging players?

Practical Takeaways for DevOps Practitioners

For engineering teams and DevOps leads, the market trajectory outlined in this research has several practical implications:

• Tooling investment is growing: More vendors entering the market means more choice, but also more complexity in evaluating and standardizing on a toolchain.
• Cloud-native is the default: The shift toward cloud-based deployment models favors containerization, Kubernetes-based orchestration, and SaaS-delivered CI/CD platforms.
• Automation depth matters: Organizations moving beyond basic CI/CD toward full continuous deployment (zero manual gates) will see the greatest efficiency gains and align with where the market is heading.
• Cross-industry adoption is accelerating: DevOps is no longer confined to pure-play technology companies. BFSI, retail, and telecom are significant and growing buyer segments.

Source: Reports and Data, as cited by connectinginvestor.com (2019). This article is a rewrite and expansion of market summary content originally published in October 2019.

Why Microservices Matter—and Why They’re Hard

Containers have captured the imagination of both infrastructure teams and application developers. Infrastructure engineers see containers as a more efficient way to allocate virtual compute resources. Developers see them as the path to building disaggregated, distributed, next-generation applications. Decomposing traditional monolithic applications into discrete, independently deployable components promotes code reuse, enables more granular scalability, and supports rapid development cycles by breaking work into smaller, lower-dependency chunks.

Adrian Cockcroft, former head of web engineering at Netflix, defines a microservices architecture as “a service-oriented architecture composed of loosely coupled elements that have bounded contexts.” That definition is elegant, but implementing it across an enterprise application portfolio is far from trivial. It involves a cascade of architectural, organizational, and cultural decisions that many organizations underestimate.

Despite the hype, microservices adoption in enterprises still comes with a steep learning curve, new deployment platforms, unfamiliar developer toolchains, and significant organizational restructuring. IDC has forecast that by 2022, 90 percent of all new applications would feature microservices architectures, with 35 percent of production apps being cloud-native designs. Whether or not that specific figure proves accurate, the directional trend is clear: modular, service-based application architectures are becoming the default for organizations that need development agility and shorter release cycles.

The critical insight that separates successful adopters from struggling ones: microservices is a redesign and construction project, not a remodeling job. You cannot layer microservices on top of a monolith and call the work done. The underlying service boundaries, data ownership, deployment pipelines, and team structures all have to change.

From Monoliths to Microservices: Key Steps

IT consultancy TekSystems has published guidance on making a successful transition from monolithic to microservice-based applications. Combined with Gartner’s advice on designing microservices for agile architecture, the following steps represent a practical framework for practitioners—not just executives—tasked with turning a microservices strategy into working production systems.

1. Start with the Full Cloud and Service Ecosystem

TekSystems frames this as “modernization should be holistic.” Because microservices depend on a wide range of infrastructure and platform components—container orchestration clusters, an API gateway, a service registry, a service bus, and often public cloud services like serverless functions and identity and access management (IAM) directories—you cannot adopt microservices in isolation. Piecemeal adoption leads to integration gaps and architectural debt. Begin by mapping the full platform ecosystem your services will depend on.

2. Identify Core Application Services and Dependencies

The goal of microservices is to decouple reusable service logic from application-specific code. Achieving this requires a thorough analysis of your existing application fleet: what components exist, what they do, and how they depend on one another. Skipping this step produces microservices that are logically monolithic despite being physically separated—sometimes called a “distributed monolith,” which captures the operational complexity of microservices without delivering their benefits.

3. Design Loosely Coupled Services

Reuse is one of the primary value propositions of microservices: a well-designed authentication service, for example, should be usable by any application in your portfolio without modification. That is impossible if services are tightly coupled to each other or to specific applications. The target is a library of generic, composable components that provide functions useful across a wide variety of applications.

Gartner extends this principle to data: each service should own its data in an independent repository that is accessible to other services through a well-defined API, rather than sharing a common database. This is a significant departure from how most enterprise applications are currently structured and is one of the hardest design constraints to enforce in practice.

4. Start Small and Iterate

TekSystems advocates for “quick wins”—minimum viable implementations that demonstrate value, build organizational confidence, and create a foundation for iterative improvement. Big Bang transitions, where an organization attempts to re-architect an entire application portfolio simultaneously, multiply project dependencies, stretch timelines, and are almost guaranteed to fail. Identify a bounded, lower-risk service as a first candidate, deliver it successfully, learn from the experience, and scale from there.

5. Adopt a Service-Oriented Mindset Across People, Process, and Technology

Microservices architecture is inseparable from organizational design. Project teams should be small and autonomous—Amazon’s “two-pizza team” model is frequently cited here, where teams are small enough to be fed by two pizzas. Smaller teams improve communication, reduce coordination overhead, and enable faster decision-making. Deloitte has published analysis on the benefits of shifting IT’s orientation from projects to products, which aligns with how successful microservices teams are typically structured.

TekSystems is direct on the leadership requirement: “You need to have strong leadership. The decision tree can’t be big and bloated, and the silos can’t be fighting with each other.” On the tooling side, the development platform must support rapid changes, multiple concurrent versions, and automated testing, integration, and deployment (CI/CD pipelines are non-negotiable in a mature microservices environment).

6. Stay Focused on Business Value, Not Technology for Its Own Sake

Microservices are a means to an end: faster development and evolution of applications, business processes, and customer-facing services. It is easy for engineering teams to become absorbed in platform decisions and architectural debates while losing sight of why the work is being done. A useful prompt from TekSystems: “Companies should not only think about improving what they have today, but more importantly, think about what doesn’t exist today.”

Measuring Success: Business Metrics Over Technical Metrics

The success of a microservices program should ultimately be measured in business outcomes, not just technical indicators like deployment frequency or container counts. Metrics worth tracking include:

• Revenue growth attributable to faster feature delivery
• Customer satisfaction scores and retention rates
• Reduction in operational costs
• Reduced cycle times for new application delivery, bug fixes, updates, and incident resolution
• Improved security posture with measurable reduction in cyber vulnerabilities

Learning from Early Adopters: The Netflix Case

The most vocal and extensively documented early adopters of microservices are large technology and online services companies. The FAANG cohort—Facebook, Amazon, Apple, Netflix, and Google—all have microservices embedded in their core infrastructure. Netflix has been the most public about its journey and the lessons learned.

Netflix moved from a monolithic architecture to a microservices-based system roughly a decade before this article was originally published. The motivation was direct: the monolithic codebase was buckling under explosive subscriber growth, and accumulated dependencies meant a single coding error could take the entire platform offline for hours. The decision to decompose was driven by operational necessity, not architectural fashion.

As an early adopter, Netflix encountered immature tooling and had to develop significant portions of its microservices infrastructure internally. That work produced reusable software components covering:

• Service discovery – enabling services to locate and communicate with one another dynamically
• Inter-process and inter-service communication – managing reliable message passing between services
• Service routing – directing traffic to the appropriate service instance
• Monitoring and security – providing visibility and access control across a distributed service mesh
• Workload scheduling – allocating compute resources efficiently across services
• Distributed configuration management – managing configuration state across many independent service instances

Netflix also experienced well-publicized outages caused by insufficient redundancy in its AWS cloud infrastructure—demonstrating that even organizations with significant engineering resources encounter serious failures in distributed systems. The result of sustained investment, however, is a platform that supports more than 150 million subscribers streaming vast volumes of content globally.

Where Enterprise Adoption Stands

As of the original publication of this analysis in late 2019, enterprise microservices adoption was still in early stages, with the share of enterprises running microservices in production likely still in single-digit percentages. The IDC forecast of 90 percent adoption by 2022 was viewed skeptically by some analysts, as it would have required adoption to roughly double each year from that baseline.

The core technology has matured substantially since Netflix made its initial transition. Many components that Netflix had to build from scratch—service meshes, API gateways, distributed tracing, container orchestration—are now available as managed cloud services or mature open-source projects. That lowers the implementation barrier significantly. The harder challenges—service boundary design, data ownership, team structure, and organizational culture—remain as demanding as ever and cannot be purchased as a managed service.

The practical takeaway: before embarking on a microservices program, invest time in studying the documented experiences of organizations that have already made the transition. The patterns of success and failure are well established. The organizations most likely to succeed are those that treat microservices adoption as a long-term redesign program, staff it with appropriate leadership and engineering authority, and measure outcomes in business value rather than architectural purity.

Key Takeaways

• Microservices adoption is a ground-up architectural redesign, not an incremental upgrade to an existing monolith.
• Success depends equally on organizational changes—small autonomous teams, product-oriented ownership—as on technology choices.
• Start with a holistic view of your cloud and platform ecosystem before designing individual services.
• Loose coupling must extend to data: each service should own its data store independently.
• Begin with small, bounded projects to prove value and build organizational capability before scaling adoption.
• Measure the program’s success in business outcomes: revenue, customer satisfaction, cost, and cycle time reduction.
• Study early adopters like Netflix—their published post-mortems and architectural decisions contain hard-won, directly applicable lessons.

This article breaks down the most significant recent additions to the AWS machine learning platform, organized by audience: infrastructure-focused developers and DevOps engineers who build and deploy custom models, and data scientists or non-specialists who need managed services to analyze large datasets without hand-rolling ML pipelines.

Who AWS Is Building For

AWS machine learning investments fall into two broad categories:

• Developer and DevOps tooling — Deep Learning AMIs and Deep Learning Containers target engineers building sophisticated, custom models and the teams responsible for deploying them on cloud infrastructure.
• Managed AI services — Services like Amazon Forecast and Amazon Personalize are designed for data scientists and non-specialists who want to apply advanced ML techniques to large datasets without managing the underlying infrastructure or writing training code from scratch.

AWS Deep Learning Containers

Setting up a reproducible environment for deep learning development has historically been a time-consuming task. Data scientists had to manually resolve dependencies across multiple source repositories, manage framework versions, and tune configuration for their target hardware — a largely DIY process prone to environment drift and hard-to-debug failures.

NVIDIA addressed this problem early with NVIDIA GPU Cloud (NGC), a registry of pre-built containers that bundle all the libraries and drivers needed to run deep learning workloads on NVIDIA hardware. AWS adopted a similar approach and introduced AWS Deep Learning Containers: a set of Docker images pre-configured with the most popular deep learning frameworks.

Supported Environments

AWS Deep Learning Containers can run across a range of AWS compute services and orchestration platforms:

• Amazon Elastic Kubernetes Service (EKS)
• Amazon Elastic Container Service (ECS)
• Amazon SageMaker
• Individual EC2 instances
• Self-managed Kubernetes clusters backed by EC2 instances

Frameworks and Runtime Support

At the time of this writing, the containers shipped with support for TensorFlow 1.14.0, MXNet 1.4.1, and the NVIDIA CUDA toolkit 10.0. Both frameworks expose Python APIs, which is the dominant scripting language in the data science community.

Key capabilities include:

• Model training and inference with both TensorFlow and MXNet.
• Distributed training with TensorFlow, supported via Horovod — an open-source distributed training framework originally developed by Uber.
• CPU and GPU instance compatibility on Ubuntu 16.04.
• SageMaker integration — useful for teams that want to run custom algorithms and containers without managing the training infrastructure directly.

Availability and Deployment

Deep Learning Containers are available at no additional charge from the AWS Marketplace or Amazon Elastic Container Registry (ECR). You pay only for the underlying compute resources you consume.

For Kubernetes-based deployments, the workflow is straightforward: create a pod specification file that references one of the Deep Learning Container images, then schedule it onto your cluster using kubectl. The same container images can be used consistently across local development, EKS, and SageMaker, reducing environment parity issues between development and production.

Deep Learning AMIs: Updates for Smaller-Scale Projects

For teams working on smaller projects — those involving a handful of VMs rather than a full container orchestration cluster — AWS maintains Deep Learning Amazon Machine Images (AMIs). These provide a similar pre-configured environment directly on EC2 instances, without the need to manage container infrastructure.

In 2019, AWS expanded framework support for Deep Learning AMIs with the following additions:

• PyTorch 1.1, Chainer 5.4, and CUDA 10 support for MXNet
• Amazon Linux 2 support, along with TensorFlow 1.13.1, MXNet 1.4.0, and Chainer 5.3.0

AWS also extended the Elastic Inference service to support TensorFlow 1.12, adding a new EIPredictor Python API. Elastic Inference allows you to attach a fractional GPU accelerator to any SageMaker or EC2 instance — rather than provisioning a full GPU instance — which can significantly reduce the cost of deep learning inference workloads while still improving throughput over CPU-only instances.

AWS AI Managed Services: Now Generally Available

Several AI services previewed at re:Invent 2018 reached general availability in the months that followed. These managed services abstract away model training, infrastructure provisioning, and hyperparameter tuning — users supply data, and AWS handles the ML pipeline.

Amazon Forecast

Amazon Forecast is a fully managed time series forecasting service built on technology Amazon developed for its own internal demand-planning use cases. Users supply historical time series data and any relevant metadata, and Forecast automatically selects and trains a predictive model. The service is designed to handle the kind of complex, multi-variable forecasting problems — such as product demand, resource utilization, or financial metrics — that are difficult to address with simple statistical methods.

Amazon Personalize

Amazon Personalize is a managed recommendation and personalization engine that draws on the same underlying models used in Amazon’s retail platform. Teams provide an interaction dataset — such as page views, purchases, or content engagement events — along with an item catalog. Personalize handles model training, tuning, and hosting, and returns ranked recommendations via an API. This makes it practical to add real-time personalization to applications without dedicated ML engineering resources.

Amazon ML Insights for QuickSight

ML Insights is an add-on module for Amazon QuickSight, AWS’s interactive business intelligence service. It introduces machine learning and natural language processing features directly into the BI workflow, including:

• Anomaly detection — automatically surfaces unexpected changes in metrics across large datasets.
• Forecasting — projects future values of time series data within QuickSight dashboards.
• Auto-narratives — generates plain-language textual descriptions of chart data, making it easier to communicate findings to non-technical stakeholders.

ML Insights is aimed at analysts who need more than standard statistical aggregation but do not want to build and maintain separate ML pipelines outside of their BI tooling.

Key Takeaways for DevOps and ML Teams

• If your team builds custom deep learning models, Deep Learning Containers remove the environment setup burden and work across EKS, ECS, SageMaker, and raw EC2.
• For smaller VM-based workloads, Deep Learning AMIs offer a faster path to a pre-configured training environment without container orchestration overhead.
• Elastic Inference is worth evaluating if inference cost on GPU instances is a concern — attaching fractional accelerators can reduce spend compared to full GPU instances.
• Managed services like Forecast and Personalize are production-ready options for common ML use cases where building and maintaining custom models is not justified by the available ML engineering capacity.

Source: Originally based on reporting from searchaws.techtarget.com (2019).

Despite the enterprise benefits assured by adopting a DevOps culture, the majority of IT leaders believe communication between IT security and software development must improve greatly to achieve success, a Trend Micro survey reveals.

DevOps implementation

Led by independent research specialist Vanson Bourne, the company surveyed the attitudes toward DevOps held by 1,310 IT decision makers from within both enterprise and SMB organizations across the globe.

Those surveyed are at various stages of the DevOps implementation as they integrate their teams, application development, information technology operations and security, to shorten and secure the development lifecycle.

While three-quarters (74%) claimed such initiatives had become more important over the past year, an even higher percentage argued that communication within the IT department needed to improve.

Some 89% said software development and IT security teams needed to be in closer contact, while 77% said the same for developers, security and operations. A third (34%) claimed that these siloes are making it harder to create a DevOps culture in the organization.

“History of software development shows that the biggest and best process improvements never happen quickly due to the most valuable variable, people, who have existing behavioral patterns and cultural components,” said Steve Quane, executive vice president of network defense and hybrid cloud security for Trend Micro.

“Organizations implementing a DevOps structure are going in a strong direction, but security cannot be forgotten during this transition.”

Respondents indicated the best ways to drive this cultural change include: fostering greater integration between teams (61%); setting common goals (58%); and sharing learning experiences across teams (50%). Yet over 78% of IT decision makers said improvement is needed in these areas.

Only a third (33%) of respondents said DevOps is a shared responsibility between software development and IT operations, which is another indication of the current communication breakdown between teams. It appears that each department feels responsibility or ownership to lead these projects.

Part of the challenge is believed to be — despite enthusiasm for DevOps, which has seen 81% of organizations already implement or currently work on projects — nearly half of respondents (46%) have only partially developed their DevOps strategy. IT leaders polled confirmed that enhancing IT security is more of a priority (46%) in DevOps than any other factor.

Quane continued by saying, “Regardless of where an organization is in their journey, there are new tools that bake security into the development process while automating rapid deployment of security at the same time as reducing risk and ensuring compliance.”