HONG KONG, June 2, 2021 /PRNewswire/ — With growing customer demand and increasing cloud computing spending all over the globe, Tencent Cloud, the cloud business of Tencent, today announced the launch of four new internet data centers (IDC) in Bangkok, Frankfurt, Hong Kong and Tokyo. The addition of the new IDCs places Tencent Cloud’s operation in 27 regions and 66 availability zones worldwide, ushering in the opening of the second availability zones (AZ2) in Bangkok, Frankfurt and Tokyo and the third (AZ3) in Hong Kong in order to addressing the ever-growing business needs around the world.

According to data from Frost & Sullivan[1], 52% of organizations globally are using cloud services as of 2020, with another 34% expected to add cloud infrastructure within the next two years. The latest information from Gartner[2] also indicates that worldwide end-user spending on public cloud services is forecasted to grow 23.1% in 2021 to total US$332.3 billion, up from US$270 billion in 2020, signifying more growth in the already burgeoning cloud industry in which Tencent Cloud intends to further flourish.

Poshu Yeung, Senior Vice President, Tencent Cloud International, said, “The cloud industry is quickly evolving and growing, making Tencent Cloud look forward to further demonstrating its commitment to provide customers with more diverse cloud products as well as stronger redundancy and backup options. The launch of the new IDCs in Bangkok, Frankfurt, Hong Kong and Tokyo at the same time is a significant development in our strategy to rapidly and efficiently expand our international portfolio. We are also planning to have over 30% growth in terms of our IDCs all over the world by end of this year.”

Keeping up with Tencent Cloud’s momentum of providing groundbreaking and state-of-the-art technologies, the new IDCs are all tier-3 design facilities and are located in prime network hub locations, providing highly-reliable and high-quality BGP integrated with major local and international network operators.

The launch of the new IDCs is the latest step forward in Tencent’s robust growth strategies in terms of global infrastructure. In late 2020, Tencent Cloud has opened its second availability zone in Korea, followed by the first IDC in Indonesia as well as the third availability zone in Singapore in April 2021. The company is set to launch its second Indonesian IDC and its first in Bahrain by the end of the year.

Tencent Cloud is a secure, reliable and high-performance public cloud service provider that integrates Tencent’s infrastructure-building capabilities with the advantages of its massive user platform and ecosystem, consistently enhancing its rich array of global services to both the public and private sectors.

Tencent Cloud

Tencent Cloud is Tencent’s cloud services brand, providing industry-leading cloud products and services to organizations and enterprises across the world. Leveraging its robust data center infrastructures around the world, Tencent integrates cloud computing, big data analytics, AI, Internet of Things, security and other advanced technologies with smart enterprise scenarios. At the same time, we provide a holistic smart enterprise solution for sectors including finance, education, healthcare, retail, industry, transport, energy and radio & television.

Advantages of Microsoft Azure

High Availability and SLA Guarantees

Azure publishes a financially backed SLA of 99.95% uptime for most of its core services, which translates to roughly 4.5 hours of permitted downtime per year. This is underpinned by a global network of data centers that can redistribute workloads if a single region experiences an outage. Availability Zones within a region provide additional redundancy by isolating workloads across physically separate facilities.

Cost Model: Pay-As-You-Go

Azure’s consumption-based pricing eliminates the need for large upfront capital expenditure on physical hardware. Teams pay only for the compute, storage, and networking resources they actually consume. Reserved Instances and Savings Plans are available for predictable workloads, offering significant discounts compared to on-demand rates. This model also reduces ongoing maintenance overhead—patching and hardware lifecycle management for managed services shifts to Microsoft.

Security and Compliance

Azure operates a layered security model covering identity, network, host, application, and data layers. Key security capabilities include:

• Azure Active Directory (Entra ID): Centralised identity management with multi-factor authentication and conditional access policies.
• Microsoft Defender for Cloud: Continuous security posture assessment and threat detection across cloud and hybrid workloads.
• Compliance certifications: Azure holds a large portfolio of regulatory certifications including ISO 27001, SOC 2, PCI DSS, HIPAA, and FedRAMP, making it viable for regulated industries.
• Encryption at rest and in transit: Data is encrypted by default across Azure storage and communication channels.

Elastic Scalability

Azure provides both vertical scaling (resizing a VM or database tier) and horizontal scaling (adding more instances). Auto-scaling rules in Azure Monitor, Azure Kubernetes Service (AKS), and Azure App Service allow workloads to respond automatically to demand spikes. This is particularly valuable for applications with variable traffic patterns, such as e-commerce platforms or seasonal reporting services—teams are not forced to provision for peak capacity year-round.

Global Data Center Footprint

Azure operates across a large number of geographic regions worldwide. This footprint allows teams to deploy workloads close to end users, satisfying data residency requirements while minimising network latency. Azure Traffic Manager and Azure Front Door provide global load balancing and failover routing across regions.

Broad Language, Framework, and Toolchain Support

Azure is designed to be platform-agnostic in practice. It supports a wide range of languages and runtimes including .NET, Java, Python, Node.js, Go, PHP, and Ruby. Container support is first-class through AKS, Azure Container Apps, and Azure Container Registry. Developers already using Visual Studio or Visual Studio Code benefit from deep Azure integration, but teams using other editors and CI/CD toolchains (GitHub Actions, Azure DevOps, Jenkins, GitLab CI) are equally supported.

Extensive Integration Ecosystem

Azure integrates natively with the broader Microsoft product ecosystem—Microsoft 365, Dynamics 365, Power Platform—which is a practical advantage for organisations already standardised on Microsoft tooling. Beyond Microsoft products, Azure Logic Apps and Azure API Management provide connectivity to hundreds of third-party services and APIs, reducing the integration effort for common SaaS tools.

Automation and Infrastructure as Code

Azure is well-suited to infrastructure-as-code and automation workflows. Key options include:

• Azure Resource Manager (ARM) templates and Bicep: Native declarative IaC formats.
• Terraform: Mature third-party provider maintained by HashiCorp with broad Azure resource coverage.
• Azure CLI and PowerShell Az module: Scriptable command-line interfaces suitable for pipeline automation.
• Azure Automation and Azure Functions: Managed services for scheduled and event-driven task execution.

Hybrid Cloud Capabilities

Azure Arc extends Azure management—policy enforcement, monitoring, and security—to on-premises servers, Kubernetes clusters, and other cloud environments. Azure Stack allows organisations to run Azure services in their own data centres. This makes Azure a practical choice for organisations that must maintain on-premises infrastructure due to regulatory, latency, or connectivity constraints, while still benefiting from a unified control plane.

AI and Machine Learning Services

Azure provides a comprehensive set of AI and ML services through Azure AI Services (formerly Cognitive Services), Azure Machine Learning, and Azure OpenAI Service. These allow teams to add capabilities such as natural language processing, computer vision, speech recognition, and generative AI to applications without managing the underlying model infrastructure. Azure Machine Learning provides MLOps tooling for model training, versioning, deployment, and monitoring at scale.

Disadvantages of Microsoft Azure

Operational Complexity Requires Dedicated Expertise

Azure is an IaaS and PaaS platform, not a fully managed SaaS product. This means that for many services—particularly IaaS virtual machines and self-managed Kubernetes clusters—your team retains responsibility for OS patching, security configuration, monitoring, and incident response. Azure’s service catalogue is extensive, and configuring services correctly requires engineers with platform-specific knowledge. Under-provisioning or over-provisioning resources due to misconfiguration is a common and costly mistake, particularly in organisations new to the platform.

Steep Learning Curve

The breadth of Azure services—compute, networking, storage, databases, security, AI, DevOps tooling, and more—means that onboarding engineers unfamiliar with the platform takes meaningful time and training investment. Azure’s naming conventions and service boundaries have also evolved over time, which can create confusion when following older documentation or tutorials. Organisations moving from on-premises Windows Server environments may find the transition more intuitive, but those coming from AWS or GCP will encounter different abstractions and terminology.

Latency Sensitivity to Region Proximity

Azure’s global network is extensive, but latency is still a physical constraint. If your users or workloads are located in a geography not well-served by an existing Azure region, you will experience higher round-trip times. This is a shared limitation of all major cloud providers rather than an Azure-specific flaw, but it is worth factoring into architecture decisions—particularly for latency-sensitive applications such as real-time gaming, high-frequency trading, or low-latency industrial control systems.

Cost Management Complexity

Although Azure’s pay-as-you-go model is cost-efficient in principle, cloud bills can grow unexpectedly if resource usage is not actively monitored. Egress costs, idle resources, and orphaned services are common sources of unplanned expenditure. Teams should implement Azure Cost Management and Budgets alerts from day one, and establish tagging policies to attribute costs to teams and projects. Without this discipline, cloud spend can quickly exceed on-premises equivalents.

Summary: Is Azure the Right Platform for Your Team?

Azure is a mature, feature-rich cloud platform with strong enterprise credentials, a broad compliance portfolio, and deep integration with Microsoft’s software ecosystem. For DevOps teams building on Windows-centric stacks, or for organisations already invested in Microsoft tooling, Azure offers genuine productivity advantages. Its hybrid capabilities via Azure Arc and Azure Stack also make it a realistic option for organisations that cannot fully migrate to public cloud.

The primary trade-offs are operational: Azure demands platform expertise, active cost governance, and ongoing management attention. Teams expecting a low-overhead, fully managed experience for complex workloads may find the operational burden heavier than anticipated. Evaluating a representative workload in Azure before committing to a full migration is the most reliable way to validate fit for your specific requirements.

Original source reference: techiexpert.com (via bestdevops.com, April 2020). This article has been substantially rewritten and updated with current technical detail.

Hyperscale Spending Hit a Record High Before the Pandemic Struck

Even as the COVID-19 pandemic began disrupting enterprise IT budgets in early 2020—delaying hardware purchases, canceling events, and freezing discretionary spend—the world’s largest cloud and internet companies showed no signs of pulling back on data center investment. According to Synergy Research Group, hyperscale capital expenditure (capex) on data centers reached an all-time high of over US$120 billion in 2019, with a record-breaking fourth quarter alone exceeding US$32 billion.

The top five hyperscale spenders in 2019 were Amazon, Google, Microsoft, Facebook, and Apple, whose data center budgets dwarfed all other operators. Other significant spenders included Alibaba, Tencent, IBM, JD.com, Baidu, and Oracle.

Data Center Spend Rose 11% Even as Overall Capex Stayed Flat

A notable nuance in the Synergy data: while total hyperscale operator capex grew only 1% year-over-year in 2019, spending specifically directed at data centers jumped 11% compared to 2018. This distinction matters—it signals that these companies were actively prioritizing physical infrastructure investment even when tightening spending in other areas.

As of the end of 2019, Synergy counted 512 hyperscale data centers in production worldwide, with further growth anticipated through 2020 despite the pandemic.

Why Cloud Giants Are Better Insulated Than Other Industries

John Dinsdale, Chief Analyst at Synergy Research Group, explained the reasoning directly:

“While there are many unknowns, what is clear is that the hyperscale operators generate well over 80 percent of their revenues from cloud, digital services and online activities. The radical shifts we are seeing in social and business behavior will actually provide some substantive tailwinds for many of these businesses. These hyperscale firms are much better insulated against the current crisis than most others and we expect to see ongoing robust levels of capex.”

John Dinsdale, Chief Analyst, Synergy Research Group

The logic is straightforward from a DevOps and infrastructure perspective: the mass migration to remote work, video conferencing, online collaboration, e-commerce, and digital entertainment all run on cloud infrastructure. Demand spikes across these categories directly benefit providers like AWS, Google Cloud, and Microsoft Azure—and justify continued investment in capacity.

What Hyperscale Data Centers Actually Look Like

For context, the majority of hyperscale capex goes toward building, expanding, and equipping hyperscale data centers—massive facilities housing tens of thousands of physical servers alongside millions of virtual machines. These aren’t typical enterprise data centers. They are purpose-built campuses designed for extreme density, power efficiency, and redundancy, often spanning hundreds of thousands of square feet.

Synergy’s analysis tracked the capex and physical footprint of 20 of the world’s largest hyperscale operators across SaaS, e-commerce, social networking, IaaS, and PaaS categories. In aggregate, those 20 companies generated nearly US$1.4 trillion in revenue in 2019, up 13% from 2018.

The Broader Industry Picture: COVID-19’s Uneven Impact on IT

Not every segment of the technology industry was as well-positioned. Dell Technologies CEO Michael Dell, speaking to CRN at the time, acknowledged the unprecedented nature of the disruption:

“Having done this for 35 years or so, I’ve seen a lot of things. There’s been nothing really like this. So the whole work-from-home movement is something our customers need a lot of help with. Customers and partners need us more than ever.”

Michael Dell, CEO, Dell Technologies

Traditional IT hardware vendors, on-premises data center equipment suppliers, and event-dependent businesses faced steep headwinds. The contrast with hyperscale operators was stark: the same pandemic conditions that hurt one group provided demand tailwinds for the other.

Key Takeaways for DevOps and Infrastructure Teams

• Cloud demand is crisis-resilient. Workloads that depend on cloud infrastructure tend to accelerate during disruption events—remote work tooling, video, streaming, and e-commerce all surge when physical movement is restricted.
• Hyperscale investment signals long-term capacity planning. Data center construction cycles are measured in years. Continued 2020 capex commitments meant these providers were building for 2022 and beyond, not reacting to a single quarter.
• Revenue diversification across cloud service tiers matters. Providers spanning SaaS, IaaS, and PaaS have multiple revenue streams that collectively absorb economic shocks better than single-segment businesses.
• The hyperscale footprint keeps growing. With 512 hyperscale facilities already in production as of end-2019 and more planned, the physical backbone of modern cloud infrastructure was expanding regardless of macroeconomic turbulence.

Original reporting by CRN Australia, citing Synergy Research Group data published March 2020.

What the Research Found

The study was a collaboration of five scientists from Northwestern University, Lawrence Berkeley National Laboratory, and an independent research firm, funded by the U.S. Department of Energy. Rather than extrapolating from demand curves, the researchers took a bottom-up approach—compiling detailed data on processors, storage hardware, networking equipment, software, and cooling systems across global data centers to estimate actual electricity consumption.

Their conclusion directly challenges frequently cited projections that data center energy use could triple or more over a decade. Lead author Eric Masanet described those projections as “simplistic extrapolations” that focus almost entirely on rising computing demand while ignoring substantial efficiency gains on the supply side.

The Cloud Migration Effect

The single biggest driver of improved efficiency is the shift from on-premises corporate data centers to large-scale cloud infrastructure. In 2010, the researchers estimated that 79% of data center computing was performed in smaller, traditional facilities—largely owned and operated by non-technology companies. By 2018, that picture had reversed: 89% of data center computing took place in larger, utility-style cloud data centers.

This migration matters because hyperscale cloud facilities operated by companies such as Google, Microsoft, Amazon, and Meta (then Facebook) represent the most energy-efficient computing environments on the planet. Their scale gives them both the economic incentive and the engineering resources to squeeze maximum performance from every kilowatt-hour spent.

How Hyperscalers Achieve Efficiency

Large cloud providers invest heavily across the full stack to minimize energy use per unit of computation:

• Custom silicon: Purpose-built chips optimized for specific workloads reduce wasted compute cycles and idle power draw.
• High-density storage: Modern NVMe and tiered storage architectures deliver more IOPS per watt than legacy spinning-disk setups.
• Virtualization and containerization: Virtual machines and containers raise server utilization rates dramatically compared to single-tenant bare-metal deployments.
• Ultrafast networking: Low-latency, high-bandwidth fabrics reduce the time—and therefore the energy—needed to move data between compute nodes.
• Precision cooling: Customized airflow management, hot-aisle/cold-aisle containment, free-air cooling in cooler climates, and proximity to large hydroelectric sources all reduce the energy overhead of keeping hardware within thermal limits.

Google stated that its data centers on average generated seven times more computing power in 2018 than they did five years prior using no additional electricity—a claim attributed to Urs Hölzle, a senior vice president overseeing Google’s data center technology at the time of the study’s publication.

A Brief History of Data Center Energy Forecasting

The study places its findings in historical context. From 2000 to 2005, data center energy use doubled. In 2007, the U.S. Environmental Protection Agency forecast another doubling between 2005 and 2010. In reality, researcher Jonathan Koomey estimated the actual global increase at around 56% for that period—already far below the EPA projection—and the new study with additional data revised that estimate downward further.

Koomey, a former Lawrence Berkeley scientist and independent researcher at the time of the Science publication, co-authored the new work. “We’re hopeful that this research will reset people’s intuitions about data centers and energy use,” he said.

Current Energy Footprint

As of 2018, data centers consumed approximately 1% of global electricity output—equivalent, by the researchers’ estimate, to roughly 17 million U.S. households. That is a meaningful figure, but the key point is that it has remained essentially flat even as the volume of computing has grown dramatically.

Looking Ahead: The Next Transition Phase

The researchers caution that the efficiency gains offsetting demand growth are expected to hold for only roughly three to four more years from the time of publication (i.e., through the early-to-mid 2020s). Beyond that window, the outlook is uncertain. Several emerging pressures could change the trajectory:

• AI and machine learning workloads: Training large models is computationally intensive and power-hungry at a scale not fully captured in 2018 data.
• Edge computing expansion: Distributing compute to thousands of smaller edge nodes may reduce per-task efficiency compared to centralized hyperscale facilities.
• Slowing hardware gains: As Moore’s Law matures, the cadence of transistor-level efficiency improvements is slowing.

To navigate this transition, the Science article recommends increased investment in energy-saving research, better measurement practices, and more transparent information sharing by data center operators worldwide. The authors describe the coming years as “a critical transition phase to ensure a low-carbon and energy-efficient future.”

Key Takeaways for DevOps and Cloud Engineers

• Migrating workloads from private on-premises data centers to public cloud infrastructure is not just a cost and agility decision—it generally reduces per-workload energy consumption.
• Right-sizing instances, improving utilization rates through containerization, and decommissioning idle resources all contribute directly to the efficiency gains the study highlights.
• Sustainability metrics such as Power Usage Effectiveness (PUE) and Carbon Usage Effectiveness (CUE) are increasingly published by major cloud providers and can inform vendor selection.
• The efficiency story may not hold indefinitely. Teams adopting GPU-heavy AI/ML pipelines should actively monitor and optimize energy-intensive training jobs.

Original reporting sourced from The Indian Express, February 2020, based on a study published in the journal Science. The study was led by Eric Masanet (Northwestern University / UC Santa Barbara) and included Jonathan Koomey and collaborators from Lawrence Berkeley National Laboratory.

VMware’s Strategic Bet on India

Enterprise software major VMware has identified India’s ongoing digitisation drive as one of its most significant growth opportunities in the Asia-Pacific region. Speaking to IANS, David Wakeman, VMware’s Senior Director for End User Computing, Asia Pacific and Japan, outlined how the company is positioning itself to support both large enterprises and government bodies as they extend digital services to a broader population.

The California-headquartered company had, at the time of the interview, announced a $2 billion investment in India over five years, earmarked for expanding facilities, growing headcount, and accelerating research and development activity in the country.

Where VMware Is Already Working in India

VMware had already embedded its technology inside some of India’s most prominent organisations by 2019, including:

• State Bank of India (SBI) – one of the world’s largest retail banks by customer base
• Bharti Airtel – a major telecommunications provider operating across India and Africa
• BookMyShow – a high-traffic consumer ticketing and entertainment platform

Wakeman highlighted work with Indian banks around workforce inclusion policies — specifically, enabling customers to conduct financial transactions via mobile devices rather than requiring a physical branch visit. He also noted conversations with insurance companies exploring how field and office staff can be empowered through digital tooling.

Workspace ONE: Delivering Any App on Any Device

A central part of VMware’s pitch to Indian enterprises is its Workspace ONE unified endpoint management (UEM) platform. The platform integrates three capabilities in a single solution:

• Access control – identity-aware, conditional access policies
• Application management – lifecycle management for native, web, and virtual applications
• Multi-platform endpoint management – covering iOS, Android, Windows, macOS, and Chrome OS devices

Workspace ONE is available both as a cloud-hosted SaaS service and as an on-premises deployment, giving organisations flexibility based on regulatory requirements or infrastructure preferences. Wakeman noted that VMware operates over 1,000 data centres globally for the platform and established a dedicated data centre in India approximately three years before the interview to support local SaaS delivery.

People Must Remain at the Centre of Digitisation

A recurring theme in Wakeman’s remarks was the risk of treating digitisation as a purely technical exercise. He was direct on this point:

“If we just look at digital for digital’s sake and miss the people a bit, that’s a problem. We’re spending a lot of time thinking about how technology and employee experience can come together.”

David Wakeman, Senior Director, End User Computing, APJ – VMware

He encouraged organisations embarking on digital transformation programmes to evaluate three dimensions beyond the technology itself:

• Employee experience – does the new tooling make it easier or harder for staff to do their jobs?
• Cultural access – does it open new pathways for under-represented groups to enter or remain in the workforce?
• Practical constraints – does it reduce burden on workers, including logistical challenges such as commuting or travel to physical locations?

India’s population of technology-savvy consumers, Wakeman argued, makes it an ideal early proving ground for new capabilities. “Indians are avid consumers of technology, so whenever we do something new or different, immediately you will see that it will show up here in India first,” he said.

Why Cloud Adoption in India Has Lagged Other APJ Markets

Despite enthusiasm for digital tools, Wakeman acknowledged that enterprise cloud adoption in India had been slower than in comparable markets such as Australia and Japan. He attributed this to two structural factors:

1. Regulatory and Compliance Constraints

Government agencies and regulated sectors such as banking have historically faced stricter compliance requirements around data residency and sovereign control. While markets like Australia and Japan had already seen more conservative government and financial-sector organisations begin migrating workloads to cloud, India’s equivalent sectors remained more cautious at the time of this interview.

2. The Cost Perception Problem

The second barrier was a widespread assumption that cloud should be cheaper than on-premises infrastructure. As Wakeman explained:

“Cloud is not necessarily cheaper than what people can do themselves on premise. The value proposition initially around what Cloud offers was first approached by the Indian market as a lower cost way than us running it, and it’s taken some time for the majority of clients to change and think about Cloud having a different set of value and property than just about the infrastructure being lesser.”

David Wakeman, VMware

This is a shift in framing that cloud vendors and their channel partners continue to navigate globally: moving the conversation from cost reduction to agility, scalability, and speed of innovation as the primary value drivers.

Key Takeaways for DevOps and IT Leaders

• Large-scale digitisation programmes succeed when employee experience is treated as a first-class outcome, not an afterthought.
• Regulatory compliance remains a significant brake on cloud adoption in government and financial sectors — on-premises and hybrid deployment options are not going away.
• The business case for cloud needs to be articulated in terms of agility and innovation velocity, not just infrastructure cost savings.
• Mobile-first approaches to service delivery (banking, insurance, government) are proving particularly impactful in markets with large under-served populations.
• Data residency — having a local cloud region or data centre — is often a prerequisite for regulated industries considering SaaS adoption.

Original reporting by IANS, as published by Telangana Today (December 2019).

Atlassian Tools in BizDevOps Transformations

IT professionals attending Atlassian’s Open conference in Boston reported that Atlassian products—particularly Jira and Confluence—had played a meaningful role in their organizations’ BizDevOps transformations. BizDevOps extends traditional DevOps principles by explicitly aligning IT workflows with business goals and measuring delivery outcomes in terms of business impact rather than purely technical metrics.

Atlassian’s product roadmaps at the time reflected this direction, with a stated emphasis on broadening collaboration features for non-technical business stakeholders. However, practitioners also highlighted persistent integration gaps across Atlassian’s growing product portfolio as a barrier to achieving those goals at scale.

A Real-World BizDevOps Pivot: Merrill Corp.

Joseph De Jarnett, software delivery manager at Merrill Corp.—a corporate mergers and acquisitions SaaS provider that had pivoted away from its legacy document printing business to focus on its DatasiteOne platform—described how the company reorganized its product and IT teams around BizDevOps principles during a transition the previous year.

“Our development teams used Jira before our transition as a company last year, but we’ve refined our usage,” De Jarnett said. The team now uses Jira to prioritize software defects, manage incoming feature requests, and share roadmaps with business stakeholders. “We opened up feature development to give the business an opportunity for more feedback, instead of doing ‘closed door’ meetings of developers.”

Atlassian’s Confluence was used for documentation and goal planning, while Statuspage handled customer-facing communication about outages and downtime. The team was also evaluating Jira Align (formerly AgileCraft, acquired by Atlassian in April 2019) for higher-level business visibility into the software delivery process.

“We’re interested in how we can use it to provide more transparency to upper management. We’re interested in its tree model that shows feature development plans, progress and allows executives to dig into each team.”

Joseph De Jarnett, Software Delivery Manager, Merrill Corp.

Users Want Streamlining Across Atlassian Products

Despite positive experiences with individual tools, De Jarnett and other practitioners at the conference expressed frustration with the fragmented experience across Atlassian’s portfolio. At the time, Atlassian offered multiple Jira variants—Jira Core, Jira Software (with both classic and next-gen project types), and Jira Align—each with different feature sets and limited cross-compatibility.

A key pain point was the gap between Jira’s classic and next-gen project types. The Roadmaps feature had been rolled out for next-gen projects but was not yet available in classic projects. Teams running both project types found themselves managing information in silos, unable to link stories across the two paradigms cleanly.

“Right now, there are discrepancies, and we’re in silos with linking to stories in a traditional project from an epic in Jira next gen. We plan to shift to next gen, but it requires changes not all of our teams are ready to make right away.”

Joseph De Jarnett, Merrill Corp.

Atlassian announced at the Open conference that it planned to bring the Roadmaps feature to classic Jira, but did not specify whether managing the two project types would remain a separate administrative concern. Scott Blacker—co-founder of AgileCraft and, following the April 2019 acquisition, head of solutions engineering at Atlassian—acknowledged the problem but stopped short of providing a timeline.

“There has to be continuity of experience. There has to be a common source of truth, especially for value stream management.”

Scott Blacker, Head of Solutions Engineering, Atlassian

Other management friction points raised by attendees included the inability to perform federated search across multiple on-premises Jira Server and Data Center instances, and the lack of seamless account switching between cloud identities within a single browser session. An initial account switcher utility was available for cloud products at the time, but an Atlassian spokesperson declined to comment on plans for on-premises federated search.

Atlassian’s Cloud-First Strategy and Its Trade-offs

Atlassian executives at the conference made clear that cloud customers represent the company’s primary development focus. According to Atlassian president Jay Simons, approximately 100,000 customers used cloud versions of Atlassian products at the time, including roughly 90% of new customers. Centralized user management across on-premises and cloud deployments was not on the immediate roadmap; the two deployment modes required separate products—Crowd for on-premises and Atlassian Access for cloud.

“There’s a long list of things that we need to build, and we need to focus on those that will have the biggest benefit to the biggest number of customers long term,” Simons said.

This prioritization drew criticism from some industry analysts. Chris Condo, an analyst at Forrester Research, noted that competitors including CloudBees, GitLab, and major public cloud providers were marketing end-to-end DevOps toolchain integration with hybrid cloud support—an area where Atlassian’s offering remained fragmented.

“Enterprise customers are struggling with the concept of scaling Agile to multiple teams. Atlassian could bolt together its products much more tightly so people have to worry less about integrating the tools, too.”

Chris Condo, Analyst, Forrester Research

Condo also pointed out that value stream management—a capability increasingly expected in enterprise DevOps platforms—requires end-to-end metrics spanning from idea to production deployment, something Atlassian users could not fully achieve out of the box at that point. He noted the company also faced the challenge of integrating a string of acquisitions, including AgileCraft and the recently acquired no-code automation company Code Barrel, before adding further complexity through additional M&A activity.

“Most developers today spend little time coding, and more time answering questions and building toolchains. People are looking for simplicity.”

Chris Condo, Forrester Research

On-Premises Users and Regulated Environments Left Behind

Atlassian’s cloud-first posture created particular anxiety for customers in heavily regulated sectors. Tanya Christensen, a senior cyber systems engineer at Northrop Grumman working as a contractor for an unnamed U.S. government entity, described being unable to use cloud-dependent products like Opsgenie and Statuspage due to security requirements that even Opsgenie’s Edge Connector couldn’t satisfy.

“We’d love to have an on-premises version of Opsgenie and Statuspage. We’ve had to come up with our own ways to solve those problems on premises.”

Tanya Christensen, Senior Cyber Systems Engineer, Northrop Grumman

Simons acknowledged the concern but expressed confidence that organizational pressures would eventually push even resistant customers toward cloud adoption. “A lot of customers say ‘never,'” he said. “Then there’s an executive shift and they go all in on cloud.”

Key Takeaways for DevOps and Platform Engineering Teams

• BizDevOps alignment is achievable with Atlassian tooling, but it requires deliberate configuration work and process discipline—it does not happen automatically out of the box.
• Multiple Jira product variants introduce friction when teams need to operate across classic and next-gen project types simultaneously, particularly around features like Roadmaps and cross-project linking.
• Value stream management remains incomplete without tighter native integrations across the full Atlassian suite, and third-party integrations often require custom scripting or configuration.
• Cloud-first investment means on-premises feature parity lags, which is a significant concern for government contractors and regulated industries with strict data residency or network isolation requirements.
• Competitors are offering more integrated alternatives, and teams evaluating DevOps platforms should assess total integration effort, not just individual tool capabilities.

Note: This article reflects the state of Atlassian’s product portfolio and roadmap as reported at Atlassian Open in November 2019. Product names, features, and acquisition statuses have changed since then. Readers should consult current Atlassian documentation for up-to-date information.

What Is a Containerized Data Center?

A containerized data center is a self-contained, pre-engineered computing facility built into a standard shipping container or modular enclosure. It houses servers, networking equipment, power systems, and cooling infrastructure in a portable, rapidly deployable unit. This architecture is particularly attractive for organizations that need to establish compute capacity in remote locations, expand existing data center footprints quickly, or maintain resilient disaster-recovery sites without constructing permanent facilities.

Key Market Growth Drivers

According to a market study by Transparency Market Research (TMR), several structural forces are fueling adoption of containerized data centers across industries:

• Demand for uninterrupted communication: In competitive business environments, any delay or degradation in data availability can translate directly into client dissatisfaction and revenue loss. Containerized data centers provide a resilient, rapidly deployable compute layer that supports continuous operations.
• Multi-site operations: Organizations running distributed operations across multiple geographic locations require low-latency, reliable data infrastructure. Containerized units can be deployed at or near the point of need, reducing round-trip latency and dependency on centralized facilities.
• Business process streamlining: Enterprises are increasingly leveraging modular data infrastructure to support complex workflows, real-time analytics, and faster decision-making cycles. The portability and scalability of containerized solutions make them well-suited to these demands.
• R&D investment and technological advancement: Leading vendors are investing in research and development to improve power efficiency, thermal management, and integration with hybrid and edge cloud architectures. Collaboration with academic institutions and standards bodies is accelerating these improvements.

End-Use Sectors

Containerized data centers serve a broad range of end-use verticals. Common sectors driving adoption include:

• Defense and government: Military and government agencies value rapid deployment in austere or forward-operating environments where permanent infrastructure is impractical.
• Oil, gas, and mining: Remote extraction sites require on-site compute capacity for operational technology (OT) systems, SCADA, and telemetry data processing.
• Telecommunications: Carriers and network operators use containerized units to extend edge compute capacity, support 5G rollouts, and provision network functions at distributed points of presence.
• Healthcare: Hospitals and healthcare networks use modular data centers to extend IT capacity, support disaster recovery, and meet data sovereignty requirements.
• Retail and financial services: Businesses in these sectors deploy containerized units to support regional data processing, reduce latency for transactional systems, and maintain business continuity.

Regional Analysis: North America Leading Adoption

North America holds a significant share of the global containerized data center market. Several factors contribute to this regional dominance:

• The region is home to a concentration of major containerized data center vendors, creating a competitive ecosystem that accelerates product innovation and cost reduction.
• Strong enterprise demand for edge computing, disaster recovery, and hybrid cloud infrastructure is driving adoption across sectors.
• A mature and extensive telecommunications infrastructure provides the backbone connectivity that containerized edge deployments depend on.
• Favorable regulatory frameworks and robust capital markets support R&D investment by market players.

Other regions, including Asia-Pacific and Europe, are also experiencing growth as digital transformation initiatives expand and edge computing requirements increase in those markets.

Competitive Landscape

The containerized data center market features a fragmented competitive landscape with multiple large and mid-tier vendors competing on technology differentiation, total cost of ownership, deployment speed, and service support. Key competitive dynamics include:

• R&D as a primary differentiator: Vendors investing in next-generation cooling (such as liquid immersion cooling), higher-density compute configurations, and integration with hyperscale cloud platforms are gaining competitive advantage.
• Partnerships and ecosystem development: Collaborations between hardware vendors, system integrators, and cloud providers are creating integrated solution stacks that lower barriers to deployment.
• Modular and scalable architectures: Customers increasingly prefer solutions that can be scaled incrementally rather than requiring large upfront capital commitments.

What the TMR Market Study Covers

According to the referenced Transparency Market Research publication, the study provides data and analysis across the following dimensions:

• Market segments and sub-segments
• Market trends and dynamics
• Supply and demand analysis
• Market sizing and forecasts (2018–2026)
• Current opportunities, challenges, and emerging trends
• Competitive landscape and vendor positioning
• Technological breakthroughs and innovation roadmap
• Value chain and stakeholder analysis

Summary

The containerized data center market is being shaped by the convergence of edge computing demand, distributed enterprise operations, and the need for rapid, resilient infrastructure deployment. North America leads adoption, supported by strong vendor presence and digital infrastructure investment. As R&D continues to drive improvements in density, efficiency, and integration with cloud-native architectures, containerized data centers are positioned to play an increasingly strategic role in enterprise and carrier infrastructure planning through the mid-2020s.

The Lock Icon Is Not Enough

Security awareness training has long leaned on a simple heuristic: if a website shows the browser padlock icon, it is encrypted and therefore safe. Google’s Chrome browser reinforced this mental model by prominently displaying the lock for HTTPS connections. For everyday users, lock equals trustworthy — a clean piece of skeuomorphic design that unfortunately creates a dangerous blind spot.

Encryption confirms that traffic between a browser and a server has not been tampered with in transit. It says nothing about whether the content being served is malicious. Attackers have understood this distinction for years, and a class of campaigns documented by Menlo Security illustrates just how effectively that gap can be exploited.

Using Legitimate Cloud Infrastructure to Host Malware

Rather than standing up their own command-and-control servers — which are expensive to maintain, easy to fingerprint, and straightforward to blacklist — attackers have begun hosting malicious payloads directly on reputable cloud storage platforms. Menlo Security’s research identified trojan downloads served from domains such as storage.googleapis.com, a legitimate Google Cloud Storage endpoint.

The advantages for an attacker mirror the advantages cloud computing offers any enterprise:

• Low cost: No server infrastructure to purchase or maintain.
• High availability: Cloud providers operate globally redundant infrastructure.
• Trusted reputation: The hosting domain is already whitelisted by virtually every organisation on the planet.
• HTTPS by default: Traffic is encrypted, satisfying both user expectations and many automated security checks.

Why Blacklists and Whitelists Cannot Solve This

Consider the position of an IT or security team when a user follows a phishing link to download a trojan from storage.googleapis.com. From the user’s perspective, the URL contains “google,” the padlock is present, and the download proceeds without browser warnings. From the security team’s perspective, blocking storage.googleapis.com at the network level is effectively impossible. Google’s services are so deeply embedded in enterprise workflows — through Google Workspace, vendor portals, client-facing tools, and partner integrations — that blocking the domain would disrupt normal business operations.

This is not a problem that can be solved purely with technical controls at the perimeter. Domain reputation, IP reputation, and TLS certificate validation are all bypassed by design when the malware is genuinely hosted on Google’s infrastructure.

The Only Scalable Mitigation: User Education

The core defensive lesson is straightforward but requires sustained reinforcement:

A trusted domain hosting a file does not make that file trustworthy.

Users need to understand that Google, Microsoft, Dropbox, and Amazon can all be used as unwitting hosts for malicious content. The presence of a recognisable brand in the URL is not an indicator of safety. Specific training points to reinforce include:

• Do not download executable files, archives, or scripts from links in unsolicited emails, even if the download URL appears to belong to a trusted provider.
• Verify file requests through a separate communication channel before downloading.
• Report unexpected download prompts to the security team immediately.

The Campaign’s Technical Mechanics: VBScript, JAR Files, and Houdini

The Menlo Security research described a campaign that used VBScript and JAR files (sometimes delivered as ZIP archives) to download and execute a malicious payload. The payload was assessed to be related to the Houdini malware family, a remote access trojan (RAT) first documented around 2013.

A few technical observations are worth noting for defenders:

• VBScript execution: VBScript runs on Windows systems via Windows Script Host (WSH). It has no legitimate use on most modern enterprise workstations and should be disabled. Microsoft’s documentation and guidance from vendors such as Trend Micro describe disabling WSH as a straightforward registry change that eliminates this attack surface entirely.
• JAR file execution: JAR files require a Java Runtime Environment (JRE) to execute. If your organisation has workstations with Java SE installed and no documented business requirement for it, this represents unnecessary attack surface. Any system that has been exposed should be treated as potentially compromised and rebuilt from a clean image rather than simply having Java uninstalled post-incident.
• Cross-platform claims: The Menlo report suggested this campaign represented a rise in “cross-platform malware.” In practice, VBScript is a Windows-only technology, so the cross-platform framing requires scrutiny (see review notes below).

Actionable Hardening Steps for Security and DevOps Teams

Regardless of the specific campaign, these hardening measures reduce exposure to this class of attack:

1. Disable Windows Script Host on endpoints where VBScript has no legitimate use. This prevents VBScript and JScript from executing outside of approved contexts.
2. Remove or restrict Java from workstations. If Java is required for a specific application, consider application whitelisting to prevent arbitrary JAR execution.
3. Deploy application whitelisting so that only approved executables can run, regardless of where they are downloaded from.
4. Implement email gateway controls that strip or sandbox attachments and flag links pointing to cloud storage downloads.
5. Use a web proxy with SSL inspection to inspect encrypted traffic to cloud storage endpoints and detect anomalous download behaviour.
6. Train users regularly on the specific risk that legitimate-looking URLs and padlock icons do not guarantee content safety.
7. Monitor for RAT indicators: Remote access trojans like Houdini establish persistent outbound connections. Network monitoring for unusual outbound traffic patterns, particularly long-lived connections to unexpected destinations, can surface active infections.

The Broader Threat Landscape Context

The Menlo report’s accompanying commentary suggested that botnets would decline as RAT-based attacks increased. This prediction deserves some scepticism. The proliferation of poorly secured Internet of Things (IoT) devices continues to provide attackers with enormous pools of botnet fodder. Separately, large-scale router compromise campaigns — such as the VPNFilter campaign that affected an estimated hundreds of thousands of routers — demonstrate that botnet infrastructure remains a live and evolving threat, not one in decline.

RAT-based attacks and botnet-based attacks are not mutually exclusive. The more accurate framing is that cloud-hosted delivery mechanisms lower the barrier to entry for RAT deployment, adding a layer to the threat landscape rather than displacing existing techniques.

Summary

Cloud platforms offer attackers the same operational benefits they offer legitimate businesses: low cost, high reliability, and built-in trust. Security teams cannot blacklist their way out of this problem. The combination of aggressive endpoint hardening (disabling VBScript, removing unnecessary runtimes like Java), network-layer inspection, and sustained user education represents the most practical defence against campaigns that abuse legitimate cloud infrastructure for malware delivery.

Everyone wants to do DevOps these days, but what does a well-humming DevOps environment really look like? What is the vision to strive for?

To date, DevOps has been popping up as a hodgepodge of activities and initiatives across companies, perhaps in the name of doing it because it’s the thing to do. As a result, companies really aren’t seeing the full potential of DevOps. Consistency in DevOps approaches is a rare thing indeed, relates Kurt Marko, citing a recent survey from Computer Economics. The survey finds “that although about a third of organizations dabble in DevOps, almost none do so formally and consistently across the organization or show any semblance of mastering of DevOps practices.”

That’s because DevOps is more than demanding that everyone get together and throwing some new tools into the mix. As Marko puts it: “DevOps is like dieting: it requires changes in values, attitudes, processes and habits. Such changes are hard and must be practiced, not bought. They require education and discipline, not a purchase order.”

The folks at Google/Alphabet, being the trailblazers they always are, are sharing their vision and experience with what they call “site reliability engineering” (SRE), providing some examples of how well-tuned teams of developers and ops people can work together to make things happen. Rest assured, it is baked deeply into the Google culture.

To clarify, SRE is somewhat different from DevOps, but joined at the hip. “Interestingly, the SRE movement emerged separately from the DevOps movement–although there is little doubt that they are part of the same IT spectrum with similar customer value-driven goals,” Jayne Groll observes in DevOps.com. “DevOps focuses on engineering continuous delivery to the point of deployment; SRE focuses on engineering continuous operations at the point of customer consumption. Both domains rely on sharing, culture, metrics and automation. Both require human and automated resources to ensure a seamless value stream and exceptional customer experience.”

A great illustration is provided by Patrick Hill, site reliability engineer with Atlassian:

“Dev teams want to release awesome new features to the masses, and see them take off in a big way. Ops teams want to make sure those features don’t break things. Historically, that’s caused a big power struggle, with Ops trying to put the brakes on as many releases as possible, and Dev looking for clever new ways to sneak around the processes that hold them back. SRE removes the conjecture and debate over what can be launched and when. It introduces a mathematical formula for green- or red-lighting launches, and dedicates a team of people with Ops skills (appropriately called Service Reliability Engineers, or SRE’s) to continuously oversee the reliability of the product.”

In their latest book and videos on the topic, Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Murphy, all with Google, unveil what they have been doing and provide lessons from which every non-Google enterprise can learn. “For sizes between a startup and a multinational, there probably already is someone in your organization who is doing SRE work, without it necessarily being called that name, or recognized as such,” they point out.

SRE “represents a significant break from existing industry best practices for managing large, complicated services,” Beyer and her associates write, noting this is the best way for a software engineer to invest time to accomplish a set of repetitive tasks. At the same time, “it has become much more: a set of principles, a set of practices, a set of incentives, and a field of endeavor within the larger software engineering discipline.”

The Google team explains that they “apply the principles of computer science and engineering to the design and development of computing systems: generally, large distributed ones.” Their tasks range from “writing the software for those systems alongside our product development counterparts;” to building pieces such as “backups or load balancing,” or simply “figuring out how to apply existing solutions to new problems.”

SREs have three missions: reliability, features and operating services.

• Reliability: Reliability is the top priority for SREs. The Google team cites the words of Google’s Ben Treynor Sloss, originator of the term SRE: “Reliability is the most fundamental feature of any product: a system isn’t very useful if nobody can use it.”
• Features: Once suitable levels of reliability are attained, SREs are charged with features and products.
• Operating services: “Finally, SREs are focused on operating services built atop our distributed computing systems, whether those services are planet-scale storage, email for hundreds of millions of users, or where Google began, web search.”

The gap between aspiration and execution comes down to a fundamental misunderstanding of what DevOps actually requires. As Marko puts it: “DevOps is like dieting: it requires changes in values, attitudes, processes and habits. Such changes are hard and must be practiced, not bought. They require education and discipline, not a purchase order.”

Google’s approach to this challenge — Site Reliability Engineering (SRE) — offers one of the most mature, battle-tested models for bridging the gap between development velocity and operational stability. It is not simply a job title or a toolset. It is a discipline, a culture, and a set of engineering principles applied to the problem of running software at scale.

SRE vs. DevOps: Related but Distinct

SRE and DevOps are complementary movements that emerged independently but share the same core goals. Jayne Groll, writing on DevOps.com, draws a useful distinction: “DevOps focuses on engineering continuous delivery to the point of deployment; SRE focuses on engineering continuous operations at the point of customer consumption. Both domains rely on sharing, culture, metrics and automation. Both require human and automated resources to ensure a seamless value stream and exceptional customer experience.”

In practice, the two approaches sit on the same spectrum. DevOps pushes software through the pipeline quickly and reliably; SRE takes ownership once that software is running in production, ensuring it stays reliable at scale.

The Classic Dev vs. Ops Conflict — and How SRE Resolves It

Patrick Hill, a site reliability engineer at Atlassian, describes the historical tension between development and operations teams clearly:

“Dev teams want to release awesome new features to the masses, and see them take off in a big way. Ops teams want to make sure those features don’t break things. Historically, that’s caused a big power struggle, with Ops trying to put the brakes on as many releases as possible, and Dev looking for clever new ways to sneak around the processes that hold them back. SRE removes the conjecture and debate over what can be launched and when. It introduces a mathematical formula for green- or red-lighting launches, and dedicates a team of people with Ops skills (appropriately called Site Reliability Engineers, or SREs) to continuously oversee the reliability of the product.”

The “mathematical formula” Hill refers to is the concept of an error budget — a calculated tolerance for downtime or errors derived from a service’s agreed reliability target (its Service Level Objective, or SLO). When a service is well within its error budget, teams can move fast and ship freely. When the budget is being consumed too quickly, the brakes go on automatically. The decision is data-driven, not political.

What Google’s SRE Team Actually Does

In their book Site Reliability Engineering, Google engineers Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Murphy describe how SRE works in practice at Google. The approach “represents a significant break from existing industry best practices for managing large, complicated services.” It began as a pragmatic response to the problem of repetitive operational toil: rather than having engineers manually perform the same operational tasks repeatedly, Google applied software engineering principles to automate and eliminate that toil.

Over time, SRE evolved into something broader: “a set of principles, a set of practices, a set of incentives, and a field of endeavor within the larger software engineering discipline.”

In concrete terms, Google SREs apply computer science and engineering principles to large-scale distributed systems. Their work spans writing production software alongside product development teams, building shared infrastructure components such as load balancers and backup systems, and adapting existing solutions to new operational problems.

The Three Core Missions of an SRE

The Google SRE team identifies three primary areas of responsibility:

• Reliability: Reliability is the foundational priority. As Ben Treynor Sloss — Google’s VP of Engineering and the originator of the SRE concept — puts it: “Reliability is the most fundamental feature of any product: a system isn’t very useful if nobody can use it.” SREs define explicit reliability targets (SLOs), measure against them, and treat reliability as an engineering problem to be solved, not merely monitored.
• Features: Once a service meets its reliability targets, SREs shift attention to supporting new features and product development. The error budget framework ensures that feature velocity and reliability are balanced rather than opposed.
• Operating services: SREs are responsible for the ongoing operation of services built on distributed computing infrastructure — from planet-scale storage systems and email services handling hundreds of millions of users to the web search systems where Google began.

What Non-Google Organizations Can Take From This

A common objection to studying Google’s SRE model is that it was built for hyper-scale — a context most enterprises will never face. But the Google SRE authors address this directly: “For sizes between a startup and a multinational, there probably already is someone in your organization who is doing SRE work, without it necessarily being called that name, or recognized as such.”

The practical implication is that SRE principles — reliability targets, error budgets, toil reduction, blameless postmortems, and engineering-driven operations — are applicable well below Google’s scale. Smaller teams can adopt the mindset and the practices without replicating the organizational structure.

The key shift is cultural and organizational: stop treating operations as a separate concern managed by a separate team with separate incentives, and start treating reliability as an engineering discipline owned by the people who build the systems. That shift doesn’t require a purchase order. It requires commitment, education, and consistency — the same things that separate real DevOps maturity from mere aspiration.

Further Reading

Google has made significant portions of the Site Reliability Engineering book available for free at sre.google. The companion volume, The Site Reliability Workbook, provides more prescriptive guidance on implementing SRE practices in organizations that are not Google.

The Latency Problem That Cloud Can’t Solve

For the better part of a decade, the dominant model for delivering computing power was elegantly simple: funnel everything through massive, centralized data centers. Amazon, Microsoft, and Google built enormous server farms—sometimes occupying the equivalent of city blocks—and the rest of the industry followed. For web search, social networking, and video streaming, that model works exceptionally well.

But a new class of applications is exposing a hard physical limit of centralized cloud: the speed of light. When data must travel hundreds of miles from a device to a regional data center and back, the round-trip takes roughly 100 milliseconds. For streaming a web page, that is imperceptible. For a self-driving car deciding whether to brake, or for an augmented-reality headset trying to keep a virtual object anchored to a moving surface, 100 ms is an eternity.

Why Milliseconds Matter

The human vestibulo-ocular reflex—the neurological mechanism that coordinates eye and head movement—operates in roughly seven milliseconds. When an AR or VR experience requires a server response and that response arrives 70 ms later, the mismatch between what the eyes see and what the inner ear expects triggers disorientation and nausea. Eliminating that gap is not a nice-to-have; it is a prerequisite for immersive experiences to function at all.

The latency ceiling affects a growing list of workloads:

• Autonomous vehicles — real-time processing of road conditions, vehicle-to-vehicle communication, and collision avoidance requires decisions measured in milliseconds.
• Mobile AR/VR — rendering convincing immersive experiences on a smartphone depends on sub-20 ms server round-trips.
• Cloud gaming — streaming interactive games at 60 frames per second demands latency low enough that controller input feels immediate.
• Industrial robotics and drones — remote operation and autonomous decision-making in physical environments cannot tolerate unpredictable network delays.

The Edge Computing Model

The architectural response to the latency problem is edge computing: distributing processing power geographically so that computation happens close to the devices that need it. Rather than routing all traffic to a handful of mega-datacenters, an edge network seeds the landscape with smaller compute outposts—micro datacenters, cell-tower co-locations, local servers—that can respond in 10 to 15 milliseconds instead of 100.

This is not a replacement for the centralized cloud. Workloads that are not latency-sensitive—batch analytics, machine-learning training, long-term storage—will continue to run cost-effectively in large regional data centers. Edge computing is a complementary layer that handles the subset of work where physical proximity to the end device is critical.

Who Is Building the Edge?

Hyperscalers Moving to the Edge

The major cloud providers recognized the latency problem and began extending their platforms outward. Microsoft announced testing of Azure IoT Edge, designed to push cloud functions directly onto customer-operated devices. Amazon Web Services opened general availability of AWS Greengrass, which extends Lambda functions and messaging to devices running on local networks. Both services require customers to manage local hardware, which represents a different operational model than fully managed cloud—a tradeoff some teams find acceptable and others do not.

Content delivery networks (CDNs) such as Akamai, Cloudflare, and Amazon CloudFront already operate geographically distributed “edge locations” that cache and serve static and streaming content closer to end users. In many respects, CDNs were the first generation of edge infrastructure; the current wave extends the concept to general-purpose compute rather than content caching alone.

Telecom Operators and 5G

Mobile network operators see their 5G infrastructure rollouts as a natural opportunity to add edge compute capacity. Cell towers and central offices are already distributed across metropolitan areas; adding server hardware to those locations means data only needs to travel a few miles rather than hundreds. AT&T, for example, announced plans (at the time of the original Wired report) to build a mobile edge computing network targeting single-digit millisecond latency, leveraging network virtualization software to dynamically balance workloads across the mobile infrastructure.

Startups Filling the Gap

Several startups moved early to build dedicated edge infrastructure:

• Packet (New York City) — founded by Zachary Smith, Packet operates micro datacenters in major cities, offering customers average round-trip latencies of 10–15 ms. The company received investment from SoftBank and, at the time of the original report, was expanding to cities including Chicago, Dallas, Los Angeles, Seattle, Frankfurt, Toronto, Hong Kong, Singapore, and Sydney.
• Vapor IO (Austin, Texas) — builds micro datacenters co-located alongside existing cell towers. Its “Project Volutus” initiative partnered with Crown Castle, then the largest US provider of shared wireless infrastructure, to leverage an existing network of approximately 40,000 cell towers and 60,000 miles of metropolitan fiber. Vapor IO developed automated software to remotely monitor and manage the micro datacenters for high availability.

A Real-World Use Case: Cloud Game Streaming

Hatch, a spinoff from Angry Birds developer Rovio, built a subscription game-streaming service that lets smartphone users begin playing instantly—without downloading an app—and supports multiplayer and live-streaming features. Making mobile game streaming work at 60 frames per second without perceptible lag required solving the same latency problem that faces autonomous vehicles and AR applications. Hatch partnered with Packet to use its edge infrastructure, making it one of the first consumer-facing products explicitly built on edge compute rather than centralized cloud.

The Hatch example illustrates a broader pattern: edge computing’s value is often invisible to end users. Players will not know or care which data center processed their input. They will simply notice that the experience feels immediate—or that it does not.

The Historical Arc: Decentralized → Centralized → Decentralized Again

Peter Levine, general partner at Andreessen Horowitz, described this shift as a “back to the future” moment. The pre-2000 internet relied on a decentralized topology of PCs and client-server systems. Starting around 2005, centralized cloud computing became the dominant model, enabling massive economies of scale. The rise of latency-sensitive, device-rich applications is now pulling architecture back toward distribution—not because centralization failed, but because the problem space has changed.

Cole Crawford, founder and CEO of Vapor IO, described edge infrastructure not as a replacement for centralized cloud but as “a natural extension of today’s centralized cloud”—thousands of small regional and micro-regional data centers integrated into last-mile networks.

What This Means for DevOps Teams

As edge computing matures, engineering teams building latency-sensitive applications need to think about infrastructure architecture earlier in the design process. Key considerations include:

• Latency budgeting — identify which operations in your application have hard latency requirements and trace whether those requirements can be met by a centralized cloud or require edge placement.
• Data gravity and sovereignty — edge nodes may hold a subset of data locally; determine what must stay close to the device versus what can be processed centrally.
• Operational complexity — managing compute across dozens of geographically distributed nodes is harder than managing a single-region cloud deployment. Invest in automation, observability, and consistent deployment tooling (containers, Kubernetes, infrastructure-as-code) from the start.
• Hybrid topology testing — test application behavior under varying network conditions. Tools that simulate higher latency between components can reveal hidden dependencies that will break in a distributed edge topology.
• Vendor landscape — the edge infrastructure market is evolving rapidly. Evaluate managed edge services from cloud providers alongside specialized edge platform providers and telecom-operated mobile edge compute offerings before committing to a single approach.

The Takeaway

The centralized public cloud is not going away. Its economics for storage-heavy, compute-intensive, and latency-tolerant workloads remain compelling. But the expanding universe of applications that interact with the physical world—vehicles, robots, wearables, industrial sensors—operates under physical constraints that no amount of bandwidth can override. Edge computing is the infrastructure response to those constraints: putting the right compute in the right place so that the network round-trip stops being the bottleneck.

For DevOps engineers, the practical implication is straightforward: design for distributed deployment from the beginning, instrument everything, and automate aggressively. The edge is not a single product you buy—it is an architectural principle you build toward.