PLEASANTON, Calif., June 7, 2021 /PRNewswire/ — SpringML, Inc. (“SpringML”), a leader in machine learning and advanced data analytics services, is proud to announce that it has achieved the Security Specialization in Google Cloud Partner Advantage. By earning the Partner Specialization, SpringML has proven their expertise and success in building customer solutions in the Security field using Google Cloud technology.

Partners with this specialization have demonstrated significant success securing customer infrastructure and workflows to Google Cloud. Areas of expertise for SpringML include data encryption management, identifying and masking confidential data, role based access control and network security access to data for internal and external users – all critical components to help lay a secure foundation for data driven transformation.

“We’re pleased that SpringML has achieved the Security Specialization in the Google Cloud Partner Advantage Program,” said Nina Harding, Chief of Global Partner Programs & Strategy at Google Cloud. “Acquiring this specialization is evidence of SpringML’s expertise in building security infrastructure solutions and their continued commitment to helping our customers throughout their digital transformations.”

“SpringML is an agent of change to help enterprises rapidly deploy data-driven digital transformation projects,” said Girish Reddy, CTO of SpringML. “Using Google Cloud tools, we can ensure that security and privacy compliance are maintained at the highest levels throughout a project implementation.”

As enterprises look for new ways to engage with customers, providing creative digital experiences is key. SpringML’s portfolio showcases its ability to deliver data-driven digital transformation projects having built applications for enterprises with an agile, iterative, and incremental delivery model.

Spring ML, Inc.

SpringML delivers data-driven digital transformation outcomes with an experimentation and design thinking mindset. We provide consulting and implementation services and industry-specific analytics solutions that deliver high-impact business value from data. SpringML is a premier Google Cloud partner with capabilities to plan, assess, deploy, and manage data-driven engagements. We have been awarded Google Cloud specializations based on our expertise and customer portfolio for Security, Data Management, Application Development, Data Analytics, Machine Learning, and Marketing Analytics.

Overview: Google Cloud Next ’20 Goes Fully Digital

Google Cloud announced the transformation of its flagship annual conference into Google Cloud Next ’20: OnAir — a free, nine-week, fully digital event series. The event runs from July 14 through September 8, 2020, delivering new content each week rather than compressing everything into a single multi-day conference.

The shift to an on-demand, weekly format is a direct response to the constraints of 2020, but it also presents a practical advantage for DevOps and platform engineering teams: sessions can be consumed at your own pace, on your own schedule, without the need to block out an entire week or budget for travel.

What the Event Includes

Google Cloud Next ’20: OnAir is organized around a nine-week editorial calendar, with each week focusing on a distinct topic area relevant to cloud and DevOps practitioners. Across the full series, attendees have access to:

• 200+ sessions spanning keynotes, breakout sessions, and expert deep-dives
• Weekly keynotes from Google Cloud leadership and industry figures
• Advanced technical sessions covering infrastructure, security, data analytics, application modernization, AI/ML, collaboration, and productivity
• Live Q&A sessions and the ability to book one-on-one time with Google engineers and developer advocates
• A Digital Showcase featuring live product demos and interactive technology experiences

Hands-On Learning and Certification Preparation

For DevOps engineers looking to level up their Google Cloud skills or pursue certification, the event includes several structured learning programs:

• Study Jams — guided group learning sessions to help you prepare for Google Cloud certifications
• Cloud Hero — a gamified, competitive hands-on labs experience
• Free one-month access to Qwiklabs and Pluralsight — curated learning paths aligned to certification tracks, available to all registered attendees
• Live technical sessions with the Google Cloud Developer Relations team

The combination of self-paced labs, live expert access, and free platform access makes this a practical opportunity to build verifiable skills alongside the conference content.

Registration and Access

The event is free to attend. Engineers who were already registered for the in-person Next ’20 were automatically enrolled in OnAir and did not need to re-register. New attendees could register directly on the Next OnAir website.

Registering provides access to:

• A customizable personal schedule builder to plan your nine-week viewing agenda
• Networking and engagement features to connect with Googlers, Google Cloud partners, and peers in the broader cloud community
• Session recommendations based on your role and interests

Weekly Topic Format

Rather than a single broad agenda, OnAir structures content into weekly themes. According to the original announcement, the nine-week schedule covers distinct topic areas relevant to cloud adoption and engineering — including infrastructure, security, data, and application modernization — though the full published schedule was provided via a separate linked asset not reproduced here.

This format allows teams to coordinate viewing around the weeks most relevant to their current projects, making it easier to extract actionable takeaways without consuming the entire catalog.

Why This Matters for DevOps Teams

The OnAir format reflects a broader industry trend toward asynchronous, modular technical education. For DevOps engineers specifically, the relevant sessions on infrastructure modernization, CI/CD, security posture, and platform engineering are typically buried inside large conference schedules. The weekly topic structure makes it easier to identify and prioritize the content that maps to active engineering work.

The free access to Qwiklabs and Pluralsight is a concrete, time-limited benefit worth taking seriously if your team has certification goals for Google Cloud Associate, Professional, or specialty tracks in 2020.

Note: This article is based on the original Google Cloud announcement from May 2020. Event dates, registration links, and session availability were specific to that event cycle and are no longer active.

Datadog (NASDAQ: DDOG), a cloud-based monitoring and analytics platform aimed at DevOps and infrastructure teams, made a high-profile market debut in late September 2019. Shares surged nearly 39% on the first day of trading, and the company closed its opening session with a valuation of approximately $10.9 billion. The IPO positioned Datadog as one of the more successful software market entries of that year, drawing comparisons to other high-growth SaaS companies that had gone public in the same period.

A Strong First Day: From $27 to $40.50

Datadog priced its IPO at $27 per share. When trading opened, investor demand pushed the price to a peak of approximately $40.50 before the stock settled at $37.55 by the end of the first session. That closing price implied a market capitalisation of around $10.9 billion — a significant milestone for a company that had not yet reached profitability.

The strong debut reflected confidence in Datadog’s core business model: a subscription-based platform that helps engineering and operations teams monitor infrastructure, applications, and log data across cloud environments. As organisations increasingly adopt multi-cloud architectures, the demand for unified observability tooling has grown substantially, giving Datadog a well-timed platform on which to go public.

Revenue Growth and the Path to Profitability

According to the company’s S-1 filing with the SEC, Datadog reported revenue of $153.4 million in the first half of 2019, representing a 79% year-over-year increase for that period. The company also reported year-over-year revenue growth of approximately 97% between full-year 2017 and full-year 2018 figures.

Despite this trajectory, Datadog was not yet profitable at the time of its IPO. The company posted net losses of roughly $13.4 million in the first half of 2019. This is a common profile for high-growth SaaS businesses: heavy investment in sales, marketing, and engineering ahead of the revenue scaling needed to achieve positive operating margins. Investors who backed Datadog were effectively betting that the company’s growth rate and customer retention metrics justified a premium valuation even in the absence of near-term profitability.

Customer Retention: The Key Metric Winning Over Investors

In the SaaS industry, revenue growth alone is rarely sufficient to sustain investor confidence — customer retention and expansion metrics matter as much as top-line numbers. Datadog’s dollar-based net retention rate of 146% as of June 2019 was a headline figure from the IPO roadshow. A net retention rate above 100% means that existing customers are, on average, spending more over time than when they first subscribed, even after accounting for any churn. A rate of 146% indicates meaningful expansion revenue from the existing customer base — a strong signal that users are adopting additional Datadog products and increasing usage as their infrastructure grows.

This metric directly addressed one of the central concerns investors have with high-growth software companies: that a large or fast-growing user base can mask underlying churn or stagnant per-customer spending. Datadog’s retention figures suggested the opposite dynamic was at play.

The Cisco Acquisition Attempt: A Valuation Floor

One factor that likely boosted investor confidence ahead of the IPO was widespread reporting that Cisco had explored acquiring Datadog in the weeks leading up to the offering, with figures in excess of $7 billion cited in contemporaneous news coverage. Datadog’s leadership chose to pursue the public market instead. For investors, this reported acquisition interest served an important psychological function: it established a credible floor valuation from a strategic acquirer with deep knowledge of the infrastructure software market. If Cisco — a major networking and software company with its own monitoring portfolio — valued Datadog at over $7 billion as a private acquisition target, public investors could reasonably conclude that the business had tangible strategic worth independent of speculative growth narratives.

By opting for an IPO and successfully pricing above that implied floor, Datadog’s executive team signalled confidence in the company’s standalone prospects and gave early investors a reference point against which to anchor their own valuation thinking.

Why Multi-Cloud Monitoring Is a Durable Market

Datadog’s core product addresses a structural challenge in modern infrastructure: as organisations distribute workloads across multiple cloud providers — AWS, Azure, Google Cloud, and others — they need a single pane of glass to monitor performance, detect anomalies, and correlate logs and metrics across all environments. Purpose-built multi-cloud and hybrid monitoring is not a transient trend; it is a natural consequence of how enterprise IT architecture has evolved over the past decade.

Competing in this space means going up against established players including Splunk, New Relic, Dynatrace, and cloud-native monitoring tools offered by AWS and Azure themselves. Datadog differentiated itself by offering tight integrations across a wide range of technologies and by providing infrastructure, application performance monitoring (APM), and log management within a single unified platform — reducing the need for teams to stitch together disparate tools.

What the IPO Meant for the DevOps Tooling Market

Datadog’s successful IPO was notable not just as a financial event but as a signal about the broader observability and DevOps tooling market. A $10.9 billion public debut for a monitoring and analytics platform validated the idea that infrastructure visibility tooling could command enterprise-grade valuations — a category that had historically been undervalued relative to application-layer software.

For engineering and platform teams evaluating observability vendors, the IPO brought both benefits and considerations: Datadog was now a well-capitalised public company with resources to invest in product development and integrations, but also one with quarterly earnings pressure that could influence product roadmap priorities over time.

As of its 2019 IPO, Datadog had not yet reached operating profitability. Its long-term viability would depend on continuing to grow revenue faster than costs while maintaining the high customer retention rates that made the IPO compelling in the first place.

Overview

Northern Virginia Community College (NOVA) is collaborating with the U.S. Marine Corps and Amazon Web Services (AWS) to build a structured set of courses focused on data intelligence. The curriculum spans cloud computing, data analytics, machine learning (ML), and artificial intelligence (AI)—a combination that reflects growing demand for these skills across both the military and civilian technology sectors.

Program Structure and Degree Pathway

To complete the program, participating Marines are required to earn 31 credits at NOVA, supplemented by a Marine Corps-specific course that covers military-relevant components. Upon finishing those requirements, participants become eligible to pursue an Associate of Applied Science (AAS) degree in Information Systems Technology at NOVA.

This structure is designed to bridge military service training with industry-recognized academic credentials, giving active-duty and transitioning Marines a concrete educational foundation in information technology.

Role of AWS Educate and Amazon SageMaker

The coursework was developed in partnership with the AWS Educate program, Amazon’s initiative for providing cloud-related curriculum resources and access to AWS services for educational institutions. ML and AI courses will leverage AWS Educate’s Machine Learning Pathway, which includes hands-on access to Amazon SageMaker—a fully managed platform for building, training, and deploying machine learning models.

In addition to the technical coursework, NOVA’s program is designed to prepare Marines to sit for the AWS Certified Cloud Practitioner exam, an entry-level certification that validates foundational knowledge of AWS cloud concepts, services, security, and pricing.

What Program Leaders Are Saying

“We have worked side-by-side with the [Marine Corps] while utilizing the AWS console and having access to AWS Educate resources, to design AI and ML coursework to meet the needs of both the USMC and our industry community. Even more exciting is that we see this as a first step to what could be many additional cutting-edge programs of study to support our U.S. Armed Forces.”

— Chad Knights, NOVA Provost for Information and Engineering Technology

Knights’ remarks signal that both NOVA and the Marine Corps view this collaboration as a long-term strategic initiative rather than a one-off program, with potential expansion into additional IT and cybersecurity occupational fields.

Launch Timeline and Expansion Plans

The new course offerings were expected to launch in fall 2019. The Marine Corps was also reported to be exploring opportunities to expand its NOVA partnership into other IT and cyber-focused occupational specialties, suggesting the program could evolve into a broader workforce development pipeline for military personnel.

Broader NOVA–AWS Collaboration

This data intelligence initiative is part of a growing relationship between NOVA and AWS. In June 2019, NOVA and AWS announced a separate program enabling students to earn an associate degree in cloud computing at NOVA and then transfer to George Mason University to complete a full bachelor’s degree. Taken together, these programs position NOVA as a regional hub for cloud and data skills development, serving both civilian students and U.S. military personnel.

Why This Matters for the DevOps and Cloud Community

Military training programs that adopt commercial cloud platforms like AWS represent a meaningful signal about where enterprise and government IT is heading. Key takeaways for the broader DevOps and cloud engineering community include:

• AWS certifications are gaining traction in non-traditional sectors, including defense and higher education, reinforcing their value as a baseline credential.
• Amazon SageMaker is being positioned as an accessible ML tool for learners without deep data science backgrounds, suggesting it is suited for introductory ML instruction.
• The AWS Educate program continues to expand its reach, partnering with community colleges to lower the barrier to entry for cloud skills training.
• Structured credit-to-degree pathways that combine vendor certifications with academic credentials are becoming an increasingly common workforce development model.

Why Software Is the Modern Engine of Disruption

The phrase “software is eating the world” has become a cliché, but the evidence is hard to argue with. Amazon reshaped retail. Netflix dismantled the cable and DVD rental model. Spotify and Apple Music redrew the music industry. Tesla redefined what a car can be after it leaves the factory. In every case, software was not merely a feature — it was the core product and the primary delivery mechanism.

What makes software uniquely disruptive is that it is largely free from the constraints of physics. Manufacturers of physical goods push against the limits of materials, tooling, and logistics. A software developer with the right knowledge can build an application that reaches millions of users overnight and can be updated just as quickly. Cloud computing and container technologies have amplified this further, giving even small teams access to elastic compute capacity and sophisticated data pipelines that would have required enterprise-scale infrastructure a decade ago.

Scale and Sustain: The Two Requirements Beyond the Initial Idea

Dreaming up a groundbreaking application is only the first step. To truly disrupt a market, an organisation must do two additional things:

• Scale — Reliably deliver the solution to a large portion of the target market without degradation in quality or performance.
• Sustain — Continue innovating after the initial launch. A static product quickly becomes a legacy product as competitors iterate.

The Ford Motor Company illustrates both sides of this equation. In the early twentieth century, Henry Ford disrupted the automobile industry by introducing the modern assembly line, dramatically cutting the time and cost to produce a vehicle. Ford dominated for decades. Eventually, however, competitors matched and then exceeded those manufacturing improvements, and Ford’s advantage eroded. The lesson: a single innovation — no matter how transformative — must be followed by continuous improvement to maintain market leadership.

Learning by Doing: The Tesla and Uber Examples

Traditional automotive companies have layered software into their vehicles over the years — fuel management systems, anti-lock brakes, collision avoidance sensors — but these are essentially point-in-time innovations baked into the car at the factory. Updating them requires a physical service visit.

Tesla took a fundamentally different approach by treating the car as a connected software platform. Updates — including new features and safety fixes — are delivered over the air, the same way a mobile operating system update reaches your phone. When Tesla identified that road debris could puncture battery casings on certain models and cause fires, engineers were able to push a software update that automatically raised the chassis ride height at highway speeds, eliminating the risk without a physical recall. This rapid, feedback-driven response would have been impossible without a mature continuous delivery pipeline connecting the engineering team directly to the vehicle fleet.

The contrast with organisations that lacked these capabilities is instructive. The troubled launch of the U.S. Affordable Care Act website is a well-documented example of what happens when software delivery practices are not in place: discovery of problems, triage, and remediation all had to happen sequentially under public scrutiny, delaying the rollout by months. Samsung’s widely publicised battery fire crisis in 2016 is another case where an over-the-air software delivery mechanism — had one existed for the affected hardware — might have allowed a faster, less costly response.

Uber used software in a different but equally instructive way. Rather than disrupting a product, Uber disrupted a service model by using mobile connectivity as the connective tissue between drivers and riders. The platform matched supply and demand in real time at a scale that phone dispatchers simply cannot replicate. Without reliable, continuously updated mobile software and network infrastructure, that matching function could never have reached global scale.

The Pipeline of Innovation: CI, CD, and DevOps

Sustaining innovation at the pace these companies demand requires more than talented engineers — it requires a disciplined engineering system. Three interconnected practices form the backbone of that system:

Continuous Integration (CI)

Developers merge their changes into a shared repository frequently — often multiple times per day. Each merge triggers an automated build and test suite, surfacing integration errors as early as possible. The goal is to keep the codebase in a known, verifiable state at all times and to shrink the feedback loop between writing code and discovering a defect.

Continuous Delivery (CD)

CD extends CI by ensuring that every validated build is also in a release-ready state. Deployment pipelines automate the journey from a passing test suite through staging environments and into production. Teams can release to users on demand — in hours or days rather than months — because the hard work of packaging, testing, and environment configuration is automated and repeatable.

DevOps Culture

CI and CD are practices; DevOps is the cultural and organisational shift that makes them sustainable. DevOps breaks down the traditional wall between development teams (who write code) and operations teams (who run it in production). Shared ownership, blameless post-mortems, cross-functional collaboration, and a commitment to measured experimentation are the hallmarks of a mature DevOps culture. Together, they create the organisational conditions in which CI/CD pipelines can be trusted and continuously improved.

From Agile Development to an Agile Business

These practices do more than keep software tested and operational. They reshape how the entire organisation operates. By extending agile principles across the full software lifecycle — from idea through deployment and into ongoing monitoring — companies build the muscle memory to respond to market signals in near real time.

The feedback loop is the critical ingredient. Disruptors do not simply ship fast; they learn fast. They instrument their software, gather usage data and customer signals, and feed those insights back into the next iteration. This loop — build, measure, learn, ship — is what separates companies that sustain disruption from those that achieve a single breakthrough and then stagnate.

Competitors still operating on quarterly release cycles are perpetually reacting to market changes that disruptors have already identified, addressed, and shipped fixes for. By the time a traditional organisation has gone through its change-approval board, its window of opportunity may have closed.

Key Takeaways for DevOps Practitioners

• Speed of delivery is a competitive moat. The ability to ship reliably and frequently is itself a strategic asset, not just an engineering efficiency.
• Feedback loops drive sustained innovation. Investing in observability, telemetry, and customer feedback channels is as important as investing in the delivery pipeline itself.
• Culture is not optional. CI and CD tooling without the organisational alignment to support experimentation and shared ownership will stall. DevOps is a people and process problem as much as a tooling problem.
• One-time disruption is not enough. Ford’s assembly line story is a warning: early movers who stop innovating will be overtaken. Continuous delivery is the mechanism that keeps innovation compounding.
• Over-the-air and cloud delivery models change the rules. When software can be updated post-shipment — whether on a phone, a car, or a SaaS platform — the economics of releasing change entirely. The cost of a small, frequent release drops dramatically compared to large, infrequent ones.

Organisations that master continuous integration, continuous delivery, and DevOps culture are not just shipping software more efficiently — they are building the organisational capability to outlearn and outpace their competitors. That is the recipe for disruption.

This article draws on material originally published at itproportal.com (2018).

The Missing Piece in Digital Business Transformation

Enterprises across every industry are pursuing digital business transformation—replacing legacy processes with cloud-native applications, data-driven decision-making, and agile delivery pipelines. From a technology standpoint, most of the required components are available: scalable compute, managed databases, container orchestration, CI/CD tooling, and mature AI/ML services. Yet transformation projects routinely stall. One underappreciated reason is public cloud networking complexity.

Networking is rarely the headline topic at a digital transformation kick-off meeting. But as application architectures shift decisively toward the public cloud, the network becomes a critical dependency—and, if poorly managed, a significant drag on velocity.

The Public Cloud Is the New Center of Gravity

On-premises data centers, intelligent edge devices, and branch offices still play important roles. But the center of gravity for new enterprise application development has shifted to the public cloud. AWS, Microsoft Azure, and Google Cloud Platform (GCP) are no longer supplementary infrastructure—they are primary infrastructure for the majority of net-new workloads.

This shift changes where networking complexity accumulates. In a traditional enterprise, networking effort was concentrated in a relatively small number of data centers and branch offices. In a cloud-first enterprise, that effort is distributed across a rapidly growing number of Virtual Private Clouds (VPCs) and Virtual Private Networks (VPNs)—environments that already outnumber physical data centers in many organizations.

VPC Sprawl: A Growing Operational Challenge

VPCs are the fundamental network isolation boundary in public cloud environments. Each major cloud provider—AWS, Azure (where the equivalent construct is a Virtual Network, or VNet), and GCP—uses VPC-like segmentation to isolate workloads, enforce security policies, and control traffic flows.

As organizations scale their cloud footprints, VPC counts grow rapidly. Individual teams provision VPCs for development, staging, and production environments. Business units spin up separate VPCs to maintain isolation. Acquisitions bring entirely new cloud accounts with their own VPC structures. The result is VPC sprawl—dozens or hundreds of isolated network segments that all need to communicate securely and reliably.

Managing peering connections, routing tables, security groups, and VPN tunnels across this many VPCs is genuinely difficult. The combinatorial complexity of VPC-to-VPC connectivity grows nonlinearly: connecting n VPCs in a full mesh requires n(n-1)/2 peering relationships. At scale, this becomes unmanageable with manual configuration.

Shifting Traffic Patterns Amplify the Problem

Traditional enterprise network design assumed that most traffic flowed from centralized data centers or the internet down to end users. Security perimeters, routing policies, and bandwidth provisioning were all optimized for this asymmetric model.

Modern cloud architectures invert much of this pattern. IoT and edge devices generate telemetry that flows up to cloud-based analytics and ML pipelines. Microservices communicate laterally between VPCs and cloud regions. Data replication and backup workloads push large volumes from on-premises systems into cloud object storage. The public cloud is increasingly the destination, not just the origin, of enterprise network traffic.

Network teams that designed infrastructure for the old model find themselves retrofitting security controls, routing logic, and capacity planning for bidirectional, distributed traffic flows they were never originally designed to handle.

Multi-Cloud Architectures Add Another Layer of Complexity

A growing number of enterprises operate across multiple public cloud providers simultaneously. This is often not the result of a deliberate architectural decision made from the top down. More commonly, it emerges organically: one team chooses AWS for its mature managed services; another standardizes on Azure because of existing Microsoft enterprise agreements; a data science group selects GCP for its BigQuery and Vertex AI capabilities.

The outcome is a multi-cloud environment where applications and workloads need to communicate across provider boundaries. Each cloud provider has its own networking primitives, peering mechanisms, VPN gateway implementations, and security group models. Connecting them securely and reliably—without creating bottlenecks or security gaps—requires either deep expertise in all three platforms simultaneously or an abstraction layer that hides provider-specific complexity.

What a Modern Virtual Cloud Network Architecture Looks Like

Addressing multi-cloud and multi-VPC networking complexity requires moving beyond traditional approaches—manual tunnel configuration, static routing, and provider-native peering—toward a virtual cloud network architecture designed from the ground up for distributed cloud environments.

Key characteristics of this architecture include:

• Provider-agnostic connectivity: VPCs across AWS, Azure, and GCP are treated as peer network segments, connected through a consistent control plane regardless of the underlying provider.
• Automated tunnel management: Secure encrypted tunnels between VPCs are created, monitored, and updated programmatically—removing the need for manual IPSec or VPN configuration.
• Policy-driven security: Network segmentation and access control are defined as code and applied consistently across all connected environments, rather than being configured individually per-VPC.
• Operational simplicity: Engineers without deep networking expertise can connect cloud resources and validate connectivity without waiting for specialist network teams.
• Visibility and troubleshooting: A unified view of traffic flows, routing decisions, and connectivity health across all VPCs replaces the per-provider console fragmentation that makes troubleshooting difficult today.

Operational Impact: Speed and Agility

The operational gap between traditional and modern cloud networking approaches is significant. Provisioning a secure tunnel between two network segments using traditional methods—firewall rule creation, VPN gateway configuration, routing table updates, and validation—can take many hours and typically requires specialist involvement. Automated cloud networking platforms aim to reduce this to minutes, enabling any sufficiently skilled engineer to establish secure connectivity without a networking specialist in the loop.

This speed difference matters for digital transformation because application teams are often blocked on network provisioning. When connecting a new microservice to a data pipeline, or extending a staging environment into a second cloud region, delays in network setup translate directly into delays in feature delivery and experimentation cycles.

Networking as a Strategic Dependency

In a cloud-native world, applications are inseparable from the networks they run on. A microservices architecture that can’t route reliably between services doesn’t deliver its intended value. A data analytics pipeline that can’t ingest edge telemetry at scale doesn’t produce useful insights. A multi-cloud deployment that can’t enforce consistent security policies across providers creates compliance and risk exposure.

Digital transformation outcomes—accelerating innovation, reducing time to market, enabling new customer experiences—depend directly on the network’s ability to connect distributed applications, data, and users without friction. Traditional measures like TCO and ROI are increasingly secondary to speed of iteration as a competitive metric. The network either enables or constrains that speed.

Recommendations for DevOps and Cloud Teams

If public cloud networking complexity is creating friction in your transformation efforts, consider the following steps:

1. Audit your VPC inventory. Map all existing VPCs across providers, accounts, and regions. Understand which ones need to communicate with each other and what connectivity currently exists.
2. Identify manual touchpoints. Find the network provisioning steps that require specialist intervention or multi-day lead times. These are candidates for automation.
3. Evaluate cloud-native and third-party networking options. AWS Transit Gateway, Azure Virtual WAN, and GCP Network Connectivity Center each address multi-VPC connectivity within a single provider. Third-party virtual cloud networking platforms extend this across providers.
4. Treat network configuration as code. Store routing policies, security group rules, and peering configurations in version control. Apply them through CI/CD pipelines with the same rigor applied to application code.
5. Define a multi-cloud network security baseline. Establish consistent policies for encryption in transit, network segmentation, and access control that apply regardless of which cloud provider hosts a given workload.

Conclusion

Public cloud networking is not a background concern to be addressed after application architecture decisions are made. For enterprises pursuing genuine digital business transformation, it is a foundational dependency. VPC sprawl, multi-cloud complexity, and bidirectional traffic patterns have made cloud networking meaningfully harder than traditional enterprise networking—and the gap between organizations that have solved this problem and those still managing it manually will widen as cloud adoption deepens.

Investing in a coherent virtual cloud network architecture—one that abstracts provider complexity, automates connectivity provisioning, and enforces consistent security policy—is not a nice-to-have. It is a prerequisite for the speed and agility that digital transformation demands.

So, what’s a guy best known as an advocate for DevOps doing in a data and analytics track session at Interop ITX? Did Andi Mann, chief technology advocate for DevOps company Splunk take a wrong turn? Afterall, analytics has grown to be associated with data scientists and their models, AI, visualization, and algorithms, not rolling out application code updates to fields of servers.

Actually, the high-energy Mann was there to show how data is at the heart of DevOps and, as his 50-minute presentation went along, subtly show how the DevOps concept can play out in any number of business processes.

“You use data from machines to learn what is abnormal. Once you have analytics to identify what is normal, you can act on what is abnormal,” said Mann during an opening overview on analytics. He used the example of a homeowner checking on the status of their home loan, and being dissatisfied with the lender’s service. That customer is ripe to jump to another bank. Yet, if the current lender’s system could tell from the data that the customer was unhappy — that their situation was the abnormal — through visualization tools, the bank could take proactive steps to save the relationship.

That’s a fairly typical scenario for data and analytics professionals to consider. Now step back into the DevOps arena.

Mann outlined eight steps in the typical DevOps process, the software development lifecycle (SDLC) that runs from “idea” through “build” up to “deploy” and “monitor”.  At each of those stages, he listed three or four commonly used tools.

“Each tool is giving off data, like which developers are doing how much work on which system,” he said. The tools also provide data on things like the quality of the application and where issues and delays may crop up. “That data adds value across the software development lifecycle,” he noted.

As those tools feed data into the analytics system, a dashboard provides a view into the data, an at-a-glance look into the DevOps team’s progress, not just with dozens of numbers but with the green-yellow-red color coding that is easy for all of us to understand. Simply, red is bad, green is good, yellow says you need to keep an eye on things.

It’s ingrained in our brains to recognize red — as in the 24,000-millisecond response time below — as trouble, while the 1,600-millisecond result sits happily in the green.

Mann applied the same concepts to business sectors outside of DevOps. For example, a healthcare provider can map the progress of patients from an emergency room, through the in-hospital stay, to discharge. Where are the delays in the various steps? Where are the quality of care issues? Where are the costs?

Then he showed how data collected at multiple points provides a retailer or other business with a view into the customer experience as they move throughout a store or within a website, with “clickflow” data.

In the end, feeding those bits of data taken by diverse tools at each stage of a business process — whether building an application or improving customer experiences — can provide managers and staff with actionable data, enabling them to improve quality, build products faster, or sell more of those products.

Data makes DevOps work, and DevOps offers a lesson in how the rest of the business can make the best use of data.

So, what’s a guy best known as an advocate for DevOps doing in a data and analytics track session at Interop ITX? Did Andi Mann, chief technology advocate for DevOps company Splunk take a wrong turn? Afterall, analytics has grown to be associated with data scientists and their models, AI, visualization, and algorithms, not rolling out application code updates to fields of servers.

Actually, the high-energy Mann was there to show how data is at the heart of DevOps and, as his 50-minute presentation went along, subtly show how the DevOps concept can play out in any number of business processes.

“You use data from machines to learn what is abnormal. Once you have analytics to identify what is normal, you can act on what is abnormal,” said Mann during an opening overview on analytics. He used the example of a homeowner checking on the status of their home loan, and being dissatisfied with the lender’s service. That customer is ripe to jump to another bank. Yet, if the current lender’s system could tell from the data that the customer was unhappy — that their situation was the abnormal — through visualization tools, the bank could take proactive steps to save the relationship.

That’s a fairly typical scenario for data and analytics professionals to consider. Now step back into the DevOps arena.

Mann outlined eight steps in the typical DevOps process, the software development lifecycle (SDLC) that runs from “idea” through “build” up to “deploy” and “monitor”.  At each of those stages, he listed three or four commonly used tools.

“Each tool is giving off data, like which developers are doing how much work on which system,” he said. The tools also provide data on things like the quality of the application and where issues and delays may crop up. “That data adds value across the software development lifecycle,” he noted.

As those tools feed data into the analytics system, a dashboard provides a view into the data, an at-a-glance look into the DevOps team’s progress, not just with dozens of numbers but with the green-yellow-red color coding that is easy for all of us to understand. Simply, red is bad, green is good, yellow says you need to keep an eye on things.

It’s ingrained in our brains to recognize red — as in the 24,000-millisecond response time below — as trouble, while the 1,600-millisecond result sits happily in the green.

Retire “No-Ops” — Welcome to New-Ops

For years, the technology industry flirted with the term “no-ops” — the idea that automation would eventually eliminate the need for operations teams altogether. Jayne Groll, CEO of the DevOps Institute, argues this framing is not only inaccurate but actively harmful to the people doing the work. “If I’m an operations person… I hear no job, no future, no respect,” she says.

The reality on the ground is almost the opposite. Rather than shrinking the operational footprint, DevOps adoption is generating a wave of new, specialized roles that didn’t exist a decade ago. Groll’s preferred replacement term captures this well: new-ops.

New Engineering Roles Born from DevOps

DevOps has moved well beyond a buzzword and into a structural shift in how engineering organizations are composed. As teams adopt continuous integration, continuous delivery, and infrastructure-as-code practices, demand has grown for roles that bridge the traditional development and operations divide. Among the roles Groll highlights:

• Automation Architect — designs and owns the automation strategy across the software delivery pipeline
• Release Engineer — manages the process of packaging, versioning, and shipping software reliably
• Continuous Delivery Architect — builds and governs the pipelines that allow code to flow from commit to production
• DevOps Coach / Agile Coach / Automation Coach — cultural and process roles focused on helping teams adopt new ways of working

These roles reflect a broader truth: automating delivery doesn’t remove the need for human expertise — it changes what that expertise looks like.

The Rise of the Site Reliability Engineer (SRE)

Of all the roles emerging from the DevOps movement, Groll singles out the Site Reliability Engineer (SRE) as one of the most significant. Originally developed at Google to apply software engineering principles to operations problems, the SRE role is now spreading rapidly across the industry.

“DevOps kind of stops at deployment,” says Groll. “I think SRE is going to help address that bridge between deployment and production.” Where continuous delivery focuses on getting code out the door reliably, SRE focuses on what happens after — keeping systems available, performant, and resilient in production.

Groll describes SRE as “continuous operations compared to continuous delivery or continuous deployment” — meaning it brings the same engineering rigor and automation mindset into the operational domain that DevOps brought to the release pipeline.

The demand signal is real. Groll attended an SRE conference where 650 attendees identified professionally as site reliability engineers — and nearly every sponsor booth was staffed by a talent acquisition team actively recruiting. “They were all hunting for SRE talent,” she says.

The Cultural Challenge: IT Managers in the Middle

Adopting new toolchains is the easy part of DevOps transformation. The harder problem is cultural change — and that challenge falls disproportionately on IT managers. “We know how to buy tools; we don’t really know how to transform culture,” says Groll.

IT managers are being asked to do things their training didn’t prepare them for: build and lead cross-functional teams, share accountability across organizational boundaries, and manage human dynamics that can’t be automated away. Groll is empathetic to their position but clear that the skill gap needs to be addressed directly.

She pushes back on the popular concept of the “frozen middle” — the idea that middle management is an immovable obstacle to transformation. Instead, she frames IT managers as an untapped resource. “It’s grooming and teaching them how to be transformational leaders,” she says, “and helping them understand how to manage a cross-functional squad.”

This re-skilling is not just good for the organization — it’s good for the individual. IT managers who develop these leadership capabilities become more relevant, not less, in a DevOps-oriented world.

What New-Ops Actually Encompasses

The “new-ops” framing isn’t just semantic — it points to a genuine expansion of what the operations discipline now touches. Groll identifies several domains that fall under this broader umbrella:

• Site Reliability Engineering (SRE) — operationalizing reliability as an engineering problem
• Cloud Operations — managing infrastructure at scale across cloud platforms
• Data Analytics and AI — applying data-driven insights to operational decisions
• Security (DevSecOps) — integrating security practices into the delivery pipeline
• Skills Development — continuous learning as a core operational competency

Each of these areas represents growth, not contraction — opportunities for operations professionals to deepen their value rather than defend their existence.

Key Takeaways for DevOps Practitioners

• The SRE role is one of the fastest-growing in DevOps-adjacent engineering — if you’re in operations, understanding SRE concepts is increasingly valuable regardless of your title.
• Cultural transformation is the hardest part of DevOps adoption, and it requires deliberate investment in leadership development — not just tooling.
• IT managers are not obstacles to transformation; with the right coaching and skill development, they can become its champions.
• “No-ops” is a misleading and demoralizing term. The operational skill set is expanding, not disappearing.
• DevOps doesn’t end at deployment — production reliability, observability, and incident response are engineering problems that require engineered solutions.

Original source: InformationWeek — DevOps Futures: SREs, Re-Skilling, and New-Ops. Quotes attributed to Jayne Groll, CEO of the DevOps Institute.

What Is Hybrid Cloud, and Why Does the Definition Matter?

Cloud computing has become a standard component of enterprise IT strategy, yet one term continues to generate both excitement and confusion in equal measure: hybrid cloud. It is not a new concept — the term has existed almost as long as cloud computing itself — but it is frequently oversimplified or misused in vendor marketing to mean little more than “some things on-premise, some things in the cloud.”

A more precise and widely accepted definition describes hybrid cloud as a combination of private and public cloud deployment models that remain architecturally distinct, yet are bound together by standardised technology, orchestration, and networking to function as a single, flexible computing platform within the same organisation. The primary goal is to satisfy a diverse range of workload requirements and complex deployment scenarios that neither a purely public nor a purely private model can address on its own.

The Two Waves of Cloud Computing

To understand where hybrid cloud fits, it helps to think about cloud adoption in phases. The first wave was driven by hyperscale public cloud platforms such as AWS and Microsoft Azure, which democratised access to advanced computing capabilities — machine learning, big data analytics, global content delivery — without the need for large upfront capital investment. Any organisation could sign up and provision sophisticated infrastructure within minutes. This accessibility disrupted established hardware and software vendors and permanently changed how technology is consumed.

However, the first wave did not — and could not — immediately replace everything. Many enterprises maintain substantial on-premise estates containing ageing hardware, pools of sensitive or regulated data, and tightly coupled legacy applications that cannot easily be migrated to a public cloud. As public cloud matured and its benefits became clearer, the gap between modern cloud-native architectures and traditional enterprise IT widened rather than closed. Hybrid cloud is the bridge that many organisations are building to cross that gap at a pace that is practical and achievable.

Is There Real Enterprise Appetite for Hybrid Cloud?

The demand is genuine and comes from multiple directions within organisations:

• IT professionals expect on-demand, consistent, and resilient platform characteristics across the entire estate they manage — not just in the public cloud portion.
• End users and consumers expect fast, reliable, and accessible services regardless of where the underlying infrastructure resides.
• Business leaders want greater productivity, stronger security posture, and measurable return on investment from cloud adoption without abandoning sunk costs in existing infrastructure.

Just as virtualisation transformed the traditional data centre in the previous decade, cloud-based technology is now driving a comparable shift in how enterprise organisations design, deploy, and manage IT services. Balancing all of these stakeholder expectations in a rapidly changing business environment is inherently difficult, and hybrid cloud offers a model that can satisfy a broader range of requirements simultaneously.

Is Hybrid Cloud Still Just a Buzzword?

In the early years of cloud computing, hybrid cloud was arguably more concept than reality. That gap has narrowed considerably as the enabling technology has matured. Several concrete developments illustrate this shift:

Microsoft Azure Stack

Microsoft’s release of Azure Stack represented a significant milestone in hybrid architecture. Azure Stack is an extension of the Azure public cloud platform deployed as an on-premise infrastructure package. It allows organisations to run a consistent set of Azure services — the same APIs, the same management interfaces — within their own data centres. This removes much of the integration complexity that previously made hybrid deployments difficult and provides genuine workload portability between private and public environments.

VMware and AWS Integration

VMware, long dominant in enterprise virtualisation, renewed its hybrid cloud commitment by announcing support for running its hypervisor (ESXi) and management tooling (vCenter) directly on AWS infrastructure. This allows organisations already running VMware on-premise to extend workloads into AWS without re-platforming applications or retraining operations teams. This announcement followed VMware’s earlier attempt with vCloud Air, launched in 2013, which sought to connect private VMware environments to a VMware-operated public cloud. While vCloud Air was eventually discontinued, it established key architectural concepts that informed the more successful AWS partnership that followed.

OpenStack as an Open Alternative

For organisations concerned about vendor lock-in, the open-source OpenStack project offers a compelling alternative private cloud foundation. OpenStack provides a scalable, API-driven infrastructure platform that can integrate with public cloud environments, enabling hybrid architectures without tying an organisation to a single vendor’s ecosystem. Notable contributors to the project have included Red Hat, IBM, Intel, AT&T, and Rackspace, giving the project substantial enterprise credibility.

Multi-Cloud and Hybrid Management Tooling

The management tooling ecosystem has evolved to reflect hybrid and multi-cloud realities. Modern platforms increasingly offer the ability to automate and orchestrate workloads consistently across both private and public cloud environments from a single control plane. This consistent operational model — provisioning, monitoring, patching, cost management — is a practical necessity as the number of cloud platforms an organisation uses continues to grow.

Practical Benefits of a Hybrid Cloud Strategy

When designed and implemented thoughtfully, hybrid cloud delivers several concrete advantages:

Workload Optimisation

Hybrid cloud enables organisations to place each workload in the environment best suited to its requirements. A customer-facing application that benefits from global reach and elastic scaling is well suited to a public cloud. A back-office system handling regulated financial data that must remain within a specific jurisdiction may be better hosted on private infrastructure. The ability to make this decision deliberately — rather than defaulting to one model for everything — is a significant operational advantage.

Cost Efficiency and Capacity Management

Maintaining large on-premise capacity buffers to handle peak demand is expensive and wasteful. Hybrid cloud allows organisations to run predictable, steady-state workloads on private infrastructure (where unit costs are typically lower at scale) while bursting into public cloud for variable or spiky demand. This reduces stranded capacity on-premise and eliminates the need to over-provision for worst-case scenarios.

Security and Regulatory Compliance

Public cloud platforms from major providers offer sophisticated security capabilities at the infrastructure level. However, the security posture of any deployment also depends on application architecture, data classification, and applicable regulatory requirements. Hybrid cloud gives organisations greater control over where sensitive data resides, how it is accessed, and what security controls are applied — without sacrificing the agility of cloud for workloads that do not carry the same constraints.

The Real Challenges of Hybrid Cloud Adoption

Hybrid cloud is not without its difficulties, and organisations should go in with a clear understanding of the challenges involved:

• Complexity: Managing multiple environments — each with its own APIs, networking models, and tooling — increases operational complexity. Without careful architectural planning, the result can be a fragmented and difficult-to-manage estate.
• Networking and connectivity: Reliable, low-latency connectivity between private and public environments is essential and is often underestimated in planning phases. Connectivity failures can have significant availability implications for workloads that span both domains.
• Skills: Operating a hybrid environment requires engineers with expertise in both traditional infrastructure and cloud-native platforms — a combination that is in high demand and short supply.
• Governance and visibility: Maintaining consistent security policies, cost visibility, and compliance posture across heterogeneous environments requires deliberate investment in management and observability tooling.

Developing a coherent strategy that maps business requirements to technical architecture before committing to a hybrid model is essential. Hybrid cloud that grows organically without a plan tends to produce exactly the kind of fragmented, hard-to-manage estate it was meant to replace.

Is Hybrid Cloud the Future of Enterprise IT?

For most large enterprises, some form of hybrid architecture is not a future aspiration — it is the current reality. Very few organisations of significant scale have fully migrated every workload to public cloud, and many have made long-term investments in private infrastructure that will continue to generate value for years. The question is less “should we do hybrid cloud?” and more “how do we do hybrid cloud well?”

The technology to support hybrid architectures has matured substantially. The platforms, management tooling, and connectivity options available today make hybrid cloud a practical and achievable strategy rather than a theoretical concept. Organisations that invest in the right foundations — consistent management, sound network architecture, clear workload placement criteria, and strong governance — are well positioned to extract genuine value from a hybrid approach as the broader technology landscape continues to evolve.

Digital transformation will continue to drive the adoption of cloud technology in the enterprise. Hybrid cloud, properly implemented, provides the flexibility to navigate that transformation at a realistic pace without abandoning the investments and constraints of the existing estate.

Data Analytics and E-Commerce: The 2017 Outlook

By early 2017, it was increasingly clear that data analysis was becoming a core driver of e-commerce revenue. The growing importance of data-driven decision-making was pushing e-commerce firms to hire more data scientists, with the goal of understanding how customer engagement patterns translated into sales outcomes.

Performance analytics firm SOASTA published predictions arguing that data analytics would become central not just to marketing teams, but to every part of the organization — from digital transformation initiatives to day-to-day digital performance management. Their five predictions offer a useful snapshot of where the industry was heading.

The Five Predictions

1. Engineering and DevOps Teams Would Manage Performance Like a Product

SOASTA predicted that DevOps and engineering teams would move away from reactive firefighting — fixing the most recent outage or manually tuning the slowest pages — toward a more proactive, data-driven approach. By combining monitoring solutions with advanced analytics, teams would be able to identify the areas of highest business impact before problems escalated. In practice, this meant treating application performance as a product with measurable KPIs rather than as an infrastructure concern handled only when things broke.

2. Data Scientists Would Become the Social Glue Between Business and Technology

The prediction here was that data scientists would evolve into cross-functional collaborators rather than siloed specialists. As data teams continued to surface strong correlations between business metrics (revenue, conversion rates, customer retention) and technical metrics (page load times, error rates, API latency), they would create a shared language that compelled business stakeholders and engineering teams to work more closely together. This foreshadowed the broader trend toward embedded analytics and shared dashboards across disciplines.

3. Machine Learning Would Move from Theory into Business Reality

In 2017, machine learning was still widely viewed as an emerging or experimental technology in most enterprise contexts. SOASTA predicted that ML would begin delivering practical business value, particularly in the area of anomaly detection and alerting. Specifically, ML-powered alerts would carry contextual information derived from Big Data insights, enabling engineering teams to diagnose and remediate issues faster rather than spending time manually correlating data from multiple sources.

4. Stream Processing and In-Stream Data Integration Would Emerge as Key Technologies

The fourth prediction focused on the infrastructure layer. New technologies enabling stream processing — the ability to analyze data in motion rather than in batch — were expected to gain significant traction. In-stream data integration, which allows data from multiple sources to be joined and enriched as it flows through a pipeline, was seen as a necessary evolution to support real-time analytics at scale. Technologies in this space (such as Apache Kafka and Apache Flink) were already maturing at this point, and this prediction broadly aligned with the direction the market was moving.

Looking Back: How Accurate Were These Predictions?

Viewed from the present, several of these predictions held up well. DevOps observability and performance engineering have become established disciplines. Data scientists and analytics engineers now routinely sit at the intersection of business and technology teams. Machine learning is embedded in production alerting systems at organizations of all sizes. And stream processing frameworks are now foundational components of modern data architectures.

What the predictions could not fully anticipate was the speed and scale of the MLOps movement, the rise of the modern data stack, or the degree to which cloud-native tooling would democratize access to these capabilities for smaller engineering teams.

Key Takeaways for DevOps Teams

• Treating application performance as a measurable product — with defined metrics and ownership — remains a best practice for engineering teams.
• Cross-functional data collaboration between engineering, product, and business stakeholders is now an expectation, not an exception.
• ML-assisted alerting and anomaly detection have matured significantly and are available through most major observability platforms.
• Real-time stream processing is no longer a niche capability; it is a standard component of production data infrastructure.

Original predictions attributed to SOASTA via insidebigdata.com, February 2017.