UK public sector bodies including the NHS will be offered discounted rates for Google Cloud services under a new government agreement.

NHS organizations will be among the UK public sector bodies eligible for a discount to Google Cloud services under a new agreement struck between the software giant and the UK government.

A memorandum of understanding (MoU) between Google Cloud and the UK’s Crown Commercial Service (CCS) will see local councils, charities, NHS and government departments and other qualifying public sector bodies able to apply for discounted rates to the Google Cloud Platform.

TOP CLOUD PROVIDERS

Top cloud providers in 2020: AWS, Microsoft Azure, and Google Cloud, hybrid, SaaS players
Top cloud providers in 2020: AWS, Microsoft Azure, and Google Cloud, hybrid, SaaS players

The cloud computing race in 2020 will have a definite multi-cloud spin. Here’s a look at how the cloud leaders stack up, the hybrid market, and the SaaS players that run your company as well as their latest strategic moves.

Read More

Eligible organizations will be offered access to Google Cloud’s full suite of services, including infrastructure, analytics, artificial intelligence, application modernization and development, and collaboration solutions.

SEE: Google Cloud VP discusses unprecedented computing needs because of the coronavirus (TechRepublic)

It also covers access to Google Cloud’s managed and serverless offerings, including its hybrid and multi-cloud Anthos platform.

The advertising to cloud software giant said the agreement would “provide the best value and terms for public sector agencies investing in cloud technology” while encouraging innovation and digital transformation in the UK public sector.

Mark Palmer, head of public sector EMEA at Google Cloud, said: “This is a significant milestone for us, as we see the results of our focused investment in cloud services and solutions primed and tailored for the public sector.”

Neither Google nor the CCS was able to offer specific financial details on the level of discount that would be offered, although Google said discounts would be based on aggregated cloud service demand and expected spend.

The MoU follows a similar agreement struck between the UK government and Microsoft in late April, which sees all eligible public sector organizations in the UK offered discounted access to Microsoft Azure business tools.

Google, Microsoft and Amazon all offer cloud services to the UK public sector under the UK government’s G-Cloud framework, under which public sector bodies can purchase cloud services from a ‘digital marketplace’ without having to run a full procurement process.

SEE: Google wants to make it easier to analyse health data in the cloud

In the NHS, Google has agreements with a handful of organizations, a number of which were transferred over to the tech giant following its acquisition of British artificial intelligence firm, DeepMind.

Royal Free London NHS Foundation Trust is using the Google Cloud Platform as part of its work with Streams, an app designed to alert doctors to early signs of acute kidney injury in patients and prevent their health from deteriorating further.

Google said its latest agreement marked the beginning of “an expanded relationship” with the CCS that would also focus on providing support for UK SMEs that partner with public sector agencies, “no matter where they are in their cloud adoption journeys.”

Palmer added: “The UK public sector is a major focus for Google Cloud, and this is an opportunity to further support Her Majesty’s government in their digital transformation.”

Bengaluru: DevOps Enabler & Co., the company behind an exclusive startup bundle for organizations that want to scale their operations, today announced it has attained a gold Microsoft DevOps And Cloud Platform competency, demonstrating a “best-in-class” ability and commitment to meet Microsoft Corp. customers’ evolving needs in today’s mobile-first, cloud-first world and distinguishing itself within Microsoft’s partner ecosystem.

DevOps Enabler & Co., the company behind an exclusive startup bundle for organizations that want to scale their operations, today announced it has attained a gold Microsoft DevOps And Cloud Platform competency, demonstrating a “best-in-class” ability and commitment to meet Microsoft Corp. customers’ evolving needs in today’s mobile-first, cloud-first world and distinguishing itself within Microsoft’s partner ecosystem.

To earn a Microsoft competency, partners must successfully complete exams (resulting in Microsoft Certified Professionals) to prove their level of technology expertise, and then designate these certified professionals uniquely to one Microsoft competency, ensuring a certain level of staffing capacity. They must also submit customer references that demonstrate successful projects, meet a performance (revenue and or consumption/usage) commitment (for most gold competencies), and pass technology and/or sales assessments.

The DevOps Enabler and Co. startup bundle provides customers with cloud migration and enablement, DevOps implementation, remote working security, and migration of their applications to containers.

DevOps Enabler & Co., an ISO 27001:2013 certified organization, provides software delivery automation to help companies grow their business. With expertise in cloud computing and DevOps, the organization helps its customers manage cloud platforms, provides DevOps automation, big data implementation, and management and staffing services. The Microsoft DevOps and Cloud Platform Gold Competency provides DevOps Enabler & Co. with access to Microsoft technical team members and advisors who can help it make the most of Microsoft technologies for its clients.

“This Microsoft Gold DevOps and Cloud Platform competency is a demonstration of our testament to providing nothing but the best to our customers, even in these uncertain times. It shows our commitment to the technology market and the skill and expertise of Microsoft products that we share,” said Ram Suresh, Vice President for DevOps Enabler & Co. “This gold competency shows how our teams have the knowledge and experience to accelerate our customers’ success. It is a major step in our journey, as it brings the power of DevOps and the cloud to our Windows community and especially our Microsoft-based enterprise customers.”

“By achieving a gold competency, partners have demonstrated the highest, most consistent capability and commitment to the latest Microsoft technology,” said Gavriella Schuster, corporate vice president, One Commercial Partner (OCP) at Microsoft Corp. “These partners have a deep expertise that puts them in the top of our partner ecosystem, and their proficiency will help customers drive innovative solutions.”

The Microsoft Partner Network helps partners strengthen their capabilities to showcase leadership in the marketplace on the latest technology, to better serve customers, and to easily connect with one of the most active, diverse networks in the world.

DevOps Enabler & Co. is focused on providing the best of DevOps services to help its customers in the best way possible. The startup bundle isn’t just a consultation; it’s a holistic growth solution designed for companies that want to scale quickly and tackle the challenges that come their way. DevOps Enabler & Co. provides software delivery automation, cloud enablement and management, and big data and staffing services to its customers.

Anunta Recognized as VMware’s APJ Services Excellence Partner of the Year

Anunta has announced that it received the VMware 2020 Regional Partner of the Year Award in the Services Excellence category for the Asia Pacific and Japan (APJ) region. The award recognizes VMware partners that demonstrate measurable achievements through their skills and service capabilities — spanning consulting, managed services, and subscription services — to help customers maximize the value of their VMware investments.

Recognition from VMware Leadership

Uma Thana Balsingam, Vice President of APJ Partner Business at VMware, highlighted the significance of the award:

“I am honored to recognize this year’s VMware Global Partner of the Year Award winners, which includes an exceptional group of innovative partners. VMware is proud to see Anunta honored in the Services Excellence category, and we are thrilled to see their continued commitment to delivering exceptional customer outcomes.”

Uma Thana Balsingam, Vice President, APJ Partner Business, VMware

What the Award Means for Anunta

Ananda Mukerji, Chairman of Anunta Tech, framed the recognition in the context of the company’s broader focus on next-generation workspace solutions:

“We are honored to be the regional winner of the VMware Partner of the Year Award 2020 for Service Excellence. I thank our customers for their continued trust in our solutions and delivery capabilities and VMware for recognizing Anunta as a partner they can trust. This is a recognition for Anunta’s innovative solutions around workspaces for the next generation users including cloud-based desktop services.”

Ananda Mukerji, Chairman, Anunta Tech

Sivakumar Ramamurthy, Deputy Managing Director and COO of Anunta Tech, added:

“Anunta has been consistently enabling our customers by providing innovative user-centric EUC solutions for complete workplace transformation. We are extremely delighted for this recognition by VMware. We believe this recognition will further provide an impetus to our strong technical competency and will empower us to enable our customers in achieving tangible business outcomes.”

Sivakumar Ramamurthy, Deputy Managing Director and COO, Anunta Tech

About the VMware Partner of the Year Awards Program

The VMware Partner of the Year Awards program spans multiple categories, each targeting a distinct area of partner contribution and innovation. Categories for the 2020 program included:

• Partner Value
• Partner Social Impact
• Services Excellence
• Digital Transformation
• Cloud Platform Transformation
• Partner Trailblazer
• Global Partner for Technology Innovation

The evaluation process was conducted in partnership with IDC, which reviewed and scored award submissions against the defined criteria for each category. Partners were assessed on their ability to drive measurable customer business growth and ROI, demonstrate deep expertise in specific technology domains, and deliver positive real-world outcomes using VMware technologies.

About Anunta

Anunta is a provider of End-User Computing (EUC) solutions focused on helping enterprises migrate from traditional client-server architectures to unified desktop and application services environments. The company’s portfolio is designed to simplify IT operations while maximizing performance, availability, and cost efficiency at the user endpoint.

Key credentials and scale metrics cited by the company include:

• Over a decade of experience in virtualization and EUC transformation
• Management of 80,000+ endpoints across 120,000+ users
• ISO 20000 certification for IT Service Management (ITSM)
• ISO 27001 certification for Information Security Management (ISMS)
• Recognition as a Red Herring Top 100 Global company

Anunta’s focus on cloud-based desktop services and next-generation workspace delivery positions it within the growing enterprise virtual desktop infrastructure (VDI) and Desktop-as-a-Service (DaaS) market.

What Is ksqlDB?

ksqlDB (previously marketed as KSQL) is the streaming SQL engine built on top of Apache Kafka. It lets developers write continuous SQL queries against Kafka topics without writing Java or Scala code, making real-time stream processing accessible to a much broader engineering audience. Common use cases include:

• Stream-to-stream joins — correlate events from two or more Kafka topics in real time.
• Aggregations — compute rolling counts, sums, or averages over time windows.
• Transformations and filtering — reshape, enrich, or drop events as they flow through a pipeline.
• Data enrichment — look up reference data stored in ksqlDB tables and join it with live streams.

Queries run on the ksqlDB Server engine, which handles all reads and writes to and from the underlying Kafka cluster. Developers interact with the engine either through a SQL query editor in the Confluent Control Center UI or directly via the ksqlDB REST API.

General Availability on Confluent Cloud

Confluent announced that ksqlDB moved from preview to production-ready status on Confluent Cloud, available to all customers on usage-based billing plans. The managed service removes the operational overhead of deploying and scaling ksqlDB Server clusters yourself. As Derek Nelson, senior product manager at Confluent, explained at the time of the announcement:

Confluent Cloud ksqlDB eliminates the innate complexities of operating infrastructure in production. We take care of running production-grade infrastructure at scale while you focus on solving business problems with ksqlDB. Transformations, stream-to-stream joins, aggregations, and data enrichment can all be accomplished using ksqlDB with just a few lines of SQL.

Derek Nelson, Senior Product Manager, Confluent

Dan Rosanova, senior group product manager at Confluent, also highlighted ksqlDB’s broader role in the platform when speaking to InfoQ:

ksqlDB is really a new kind of database that has been purpose-built for stream processing applications. We see ksqlDB as an integral service rounding out our cloud offering as a complete streaming platform, beyond Kafka, enabling end-to-end stream processing workloads. It complements our Connect service as well, which enables streaming connectivity to and from many services and platforms. These services all compose together to provide users an event streaming SaaS that they can use to build and run sophisticated and complete modern applications.

Dan Rosanova, Senior Group Product Manager, Confluent

Key Capabilities of the Managed ksqlDB Service

Running ksqlDB as a managed service on Confluent Cloud offers several advantages over self-hosting:

• No infrastructure management — Confluent provisions, scales, and monitors the ksqlDB cluster on your behalf.
• Integrated UI — The Confluent Control Center provides a graphical interface to create streams and tables, browse schemas, and submit continuous queries without leaving the browser.
• REST API access — All operations available in the UI are also available programmatically via the ksqlDB REST API, enabling CI/CD integration.
• Schema Registry integration — Streams and tables are schema-aware, enabling safer evolution of event formats over time.
• Kafka Connect complement — Confluent Cloud Connect can source or sink data to external systems, with ksqlDB handling in-flight transformations in between.

Multi-Cloud Support

Confluent Cloud — and by extension the managed ksqlDB service — is available on all three major public cloud providers:

• Amazon Web Services (AWS) — available since 2017.
• Google Cloud Platform (GCP) — available via the GCP Marketplace.
• Microsoft Azure — available via the Azure Marketplace.

This multi-cloud availability means teams can run ksqlDB workloads in the same region and cloud provider as the rest of their data infrastructure, minimising egress costs and latency.

A Practical Example: Streaming Data Pipeline

A common pattern is using Apache Kafka as the backbone of a data pipeline and ksqlDB to transform events before landing them in a downstream system (a data warehouse, search index, or operational database). Instead of writing a custom Kafka Streams application in Java, a developer can express the same logic in SQL:

-- Create a stream from a raw Kafka topic
CREATE STREAM orders_raw (
  order_id VARCHAR,
  customer_id VARCHAR,
  amount DOUBLE,
  currency VARCHAR
) WITH (
  KAFKA_TOPIC='orders',
  VALUE_FORMAT='JSON'
);

-- Filter and enrich: only USD orders above $100
CREATE STREAM high_value_usd_orders AS
  SELECT
    order_id,
    customer_id,
    amount,
    UCASE(currency) AS currency
  FROM orders_raw
  WHERE currency = 'USD' AND amount > 100
EMIT CHANGES;

The resulting high_value_usd_orders stream is itself a Kafka topic, ready to be consumed by downstream services or sinked to an external system via Kafka Connect.

Who Benefits Most?

As Bart Kersteter, a systems engineer at Confluent, noted at the time of the announcement, ksqlDB is particularly valuable for teams that need real-time stream processing but do not have deep JVM expertise:

KSQL is great for writing streaming data apps, especially for non-Java programmers. It is now fully supported and available in Confluent Cloud.

Bart Kersteter, Systems Engineer, Confluent

Data engineers already comfortable with SQL for batch processing can apply the same mental model to streaming workloads, significantly reducing the learning curve compared to the Kafka Streams DSL or Apache Flink.

Getting Started

To try the managed ksqlDB service on Confluent Cloud:

1. Sign up for a Confluent Cloud account at confluent.io/confluent-cloud.
2. Create a Kafka cluster in your preferred cloud region (AWS, GCP, or Azure).
3. Add a ksqlDB application from the Confluent Cloud console.
4. Use the built-in query editor to create your first stream and run a continuous SQL query.
5. Explore the official Confluent Cloud ksqlDB documentation for deeper configuration options.

Note: Pricing details and free-tier offers mentioned at the time of this announcement (April 2020) may have changed. Check the Confluent Cloud pricing page for current information.

Why Serverless Development Needs Dedicated Tooling

Cloud application development has moved well beyond virtual machines and containers. Serverless — the event-driven, functions-as-a-service (FaaS) model — lets teams run code only when triggered by an event, eliminating the need to manage long-running infrastructure. The trade-offs are real: lower operational costs and greater agility, but also a fundamentally different architecture that can expose gaps in existing CI/CD pipelines and security controls.

Serverless applications are composed of many small, discrete resources stitched together. As Chase Douglas, co-founder and CTO of Stackery, explained to ITPro Today:

“With serverless, you have many different types of resources that you’re piecing together. The most common one that people talk about are functions. Even for organizations that have already started using containers and microservices, they might not have decomposed the workflow as far down as what happens in serverless, where you might have individual functions defined for each route of an API.”

Chase Douglas, Co-founder and CTO, Stackery

To address these challenges, Stackery announced a significant platform update on April 14, 2020, focused on two areas: CI/CD integration for serverless workflows and automated least-privilege security controls.

GitOps-Based CI/CD for Serverless Workloads

Modern DevOps teams rely on continuous integration and continuous deployment (CI/CD) pipelines to ship code reliably and frequently. Stackery’s update extends that model into the serverless domain using a GitOps workflow. Here is how the pipeline works:

1. Code push: A developer pushes changes to their Git provider of choice — GitHub, GitLab, or Bitbucket.
2. Pull request trigger: Opening a pull request in the Git provider triggers Stackery to begin a parallel sequence of automated steps.
3. Source analysis: Stackery scans the source code, identifies all functions in the serverless application stack, and runs runtime-specific code-checking tools to flag security and safety issues.
4. Temporary sandbox: A short-lived sandbox environment is provisioned automatically so that integration tests defined by the team can run in isolation.
5. Preview deployment: A preview environment of the full deployment is spun up, giving developers and stakeholders the opportunity to evaluate changes and collaborate before merging.

“It will also provision a temporary sandbox environment just for the purposes of running integration tests that you’ve defined. Lastly, it will provision a preview environment of the deployment, giving you an opportunity to evaluate your changes or potentially collaborate with others on your team who also can play with that preview deployment.”

Chase Douglas, Co-founder and CTO, Stackery

This GitOps approach keeps the Git repository as the single source of truth for both application code and infrastructure state — a principle that aligns well with infrastructure-as-code practices already common in container-based environments.

Least-Privilege Security for Serverless Resources

Over-permissioned cloud resources are a persistent security risk. In a traditional application, a compromised component with broad IAM permissions can become a pivot point for a wider attack across an entire cloud account. Serverless architectures face the same risk when permissions are not scoped tightly.

Stackery’s platform update addresses this with automatic permission scoping. Developers build serverless applications using a visual drag-and-drop canvas to connect resources — functions, databases, queues, and so on. With the update, the platform automatically limits the permissions granted to each connection to only what is required to execute that specific function.

“So if in the worst case, there was a security vulnerability inside one of your functions and it had a mechanism to access one of your DynamoDB database tables, then the scope of that security intrusion is limited just to that one table and cannot progress further across the entire AWS account.”

Chase Douglas, Co-founder and CTO, Stackery

This principle of least privilege — granting only the minimum permissions necessary — is a well-established security practice. Applying it automatically at the platform level removes a common source of human error in serverless IAM configuration.

What Comes Next: Collaboration and Intelligent Pipelines

Looking beyond the April 2020 release, Stackery CEO Tim Zonca outlined two priority areas for the platform roadmap:

• Team collaboration at scale: Features designed to help larger engineering teams work efficiently within shared serverless environments.
• Intelligent automation: Adding analytical and decision-making capabilities to CI/CD pipelines, potentially automating more steps in the detect-test-deploy workflow.

“One of the things that we will be adding after this launch is more around helping teams quickly scale and better collaborate. Another set of capabilities that we’ve been looking at is, how can we start to add intelligence to these automation kinds of pipelines.”

Tim Zonca, CEO, Stackery

Key Takeaways

• Serverless’s fine-grained, event-driven architecture exposes gaps in standard CI/CD and security tooling designed for VMs or containers.
• Stackery’s GitOps-based pipeline automates code analysis, integration testing in sandboxed environments, and preview deployments triggered by pull requests.
• Automatic permission scoping at the resource-connection level enforces least-privilege IAM policies without requiring manual configuration.
• The platform targets AWS-based serverless workloads, with DynamoDB cited as an example resource in the security model.

What Is Cloud Foundry Platform Certification?

Cloud Foundry Platform Certification is the Cloud Foundry Foundation’s official verification program. It guarantees that any product or service carrying the Cloud Foundry name uses the same core Cloud Foundry software and meets the technical standards set by the Foundation’s technical governing body. Key goals of the certification include:

• Consistency: All certified platforms share the same underlying Cloud Foundry Application Runtime components.
• Portability: Applications developed on one certified platform can be moved to another without re-platforming effort.
• Reliability: Strict technical requirements must be met before the Cloud Foundry mark can be applied to any product.
• Annual recertification: Providers must recertify every year, ensuring ongoing compliance as the platform evolves.

Only products that pass these requirements are permitted to use the “Cloud Foundry” designation commercially.

The Key 2020 Change: Kubernetes as a First-Class Scheduler

Historically, Cloud Foundry used Diego as its internal container scheduler and runtime. The 2020 certification introduces an officially supported alternative: Eirini, a project that replaces Diego’s container scheduling layer with Kubernetes. Providers can now certify using:

• Diego only — the traditional Cloud Foundry container runtime.
• Eirini (Kubernetes-backed) only — replacing Diego’s scheduling with native Kubernetes primitives.
• Both Diego and Eirini — offering operators flexibility to choose at deployment time.

This is the first year that Kubernetes has been eligible to serve as the default container scheduler within a certified Cloud Foundry platform. The intent is to let Cloud Foundry operators and developers benefit from Cloud Foundry’s well-known developer experience — a simple cf push workflow, built-in routing, service bindings, and multi-language buildpack support — while running on a Kubernetes substrate that operations teams may already manage.

“This is the first year the Cloud Foundry Platform Certification allows Kubernetes to be the default container scheduler, giving developers more flexibility to run their apps across any Cloud Foundry instance in the language and framework of their choice. The mission of the Cloud Foundry community is to simplify the developer experience, and we have accomplished this with the new Platform Certification requirements, as we bring the Cloud Foundry developer experience to Kubernetes users.”

— Chip Childers, Executive Director, Cloud Foundry Foundation

2020 Certified Cloud Foundry Platforms

The following seven platforms renewed their Cloud Foundry Platform Certification for 2020:

• Atos Cloud Foundry
• Cloud.gov
• IBM Cloud Foundry
• SAP Cloud Platform
• SUSE Cloud Application Platform
• Swisscom Application Cloud
• VMware Tanzu Application Service

Why This Matters for DevOps and Platform Teams

The Eirini integration addresses a tension that many enterprise platform teams face: Kubernetes has become the de facto standard for container orchestration, but its raw API surface is complex for application developers. Cloud Foundry has long offered a high-level abstraction — developers push source code or a container image and the platform handles routing, health management, scaling, and service injection — without needing to write Kubernetes manifests.

By allowing Kubernetes to underpin that abstraction, organisations can:

• Consolidate on a single container orchestration layer (Kubernetes) across different workload types.
• Leverage existing Kubernetes operational tooling, RBAC models, and infrastructure integrations.
• Offer application developers the familiar cf push experience without exposing Kubernetes complexity.
• Run certified workloads on any Kubernetes-capable infrastructure, including AWS, GCP, Azure, IBM Cloud, OpenStack, and VMware vSphere.

About Cloud Foundry

Cloud Foundry is an open source platform backed by major technology vendors including Dell EMC, Google, IBM, Microsoft, SAP, SUSE, and VMware. It is used in production by large enterprises in manufacturing, telecommunications, and financial services. Cloud Foundry’s container-based architecture supports applications written in any language or framework through its buildpack system, and it runs on a wide range of cloud providers and on-premises infrastructure.

Further Reading

For more detail on the Eirini project and how it integrates Kubernetes into Cloud Foundry, see the Cloud Foundry Foundation website and the Eirini project on GitHub.

Overview

Even against the backdrop of the COVID-19 pandemic in early 2020, cloud computing providers continued to push forward with strategic expansions and leadership changes that directly affected their channel ecosystems. Three announcements stood out: Rackspace’s deepened investment in the Middle East and Africa, IBM’s appointment of a new cloud leader under incoming CEO Arvind Krishna, and Zenoss’s launch of a dedicated EMEA cloud zone. Here’s what each development means for partners and customers.

Rackspace Expands EMEA Presence to Address Cloud Skills Gap in the Middle East

Rackspace — a managed cloud and hosting provider that works across AWS, Google Cloud Platform, and Microsoft Azure — announced a multimillion-dollar investment to deepen its footprint in the Middle East and Africa region. The move was designed to open new opportunities for channel partners, including distributors, master agents, systems integrators, and value-added resellers (VARs) operating in the region.

Lisa McLin, Vice President of Alliances and Channel Chief at Rackspace, told Channel Futures that the expanded investment aimed to bring “additional local resources to help address the dearth of cloud skills in the Middle East.” Rackspace manages private and public cloud deployments on behalf of end users, providing an unbiased, multi-cloud approach that suits the complexity of enterprise environments in the region.

George Pawlyszyn was named General Manager for Rackspace’s Middle East and Africa strategy. According to McLin, Pawlyszyn is focused on “providing trusted and unbiased expertise to migrate customers to the cloud securely, and enhance existing customers’ environments whilst working closely with partners.”

At the time of the announcement, Rackspace already served more than 500 customers in the Middle East. To support growth, the company launched a new hub in Dubai, housing salespeople, professional services consultants, and marketing personnel.

“The cloud market is growing significantly in the region and customers are increasingly requiring unbiased experts to support them on their cloud journey.”

Martin Blackburn, Managing Director, EMEA, Rackspace

For channel partners, this kind of regional investment typically translates to more localized sales support, co-selling opportunities, and access to Rackspace’s multi-cloud managed services portfolio closer to end customers.

IBM Appoints Howard Boville as Senior Vice President of IBM Cloud

In a significant leadership move, newly appointed IBM CEO Arvind Krishna — who himself previously led IBM’s cloud computing division before replacing Virginia Rometty — named Howard Boville as Senior Vice President of IBM Cloud, effective May 2020.

Boville joined IBM from Bank of America, where he served as Chief Technology Officer. Notably, the two organizations had already been collaborating to build cloud platforms tailored for the financial services sector, making Boville a familiar face in the IBM ecosystem.

In his new role, Boville was positioned to lead IBM’s cloud strategy with a specific emphasis on hybrid cloud — a priority that IBM has consistently placed at the center of its competitive positioning against hyperscalers such as AWS, Google Cloud, and Microsoft Azure. He also assumed oversight of IBM’s global cloud infrastructure, which at the time included:

• More than 60 cloud data centers
• Operations spanning 19 countries
• 18 availability zones across six geographic regions

The appointment signaled IBM’s intent to accelerate its hybrid cloud narrative — an approach underpinned by the 2019 acquisition of Red Hat — and to compete more aggressively in enterprise cloud deals where workload portability and data sovereignty are critical concerns.

Zenoss Launches Dedicated EMEA Cloud Zone in Frankfurt

Zenoss, an Austin, Texas-based company that develops monitoring analytics software for cloud, hybrid, and on-premises IT environments, announced the availability of a dedicated EMEA cloud zone for its Zenoss Cloud SaaS platform. The zone is hosted in Frankfurt, Germany.

The Frankfurt location was selected for its strong data protection credentials. Specifically, Zenoss cited compliance with the German Bundesdatenschutzgesetz (BDSG) — Germany’s federal data protection act — as a key factor, alongside alignment with GDPR requirements affecting European customers.

“Zenoss Cloud has taken off domestically, and we’ve been experiencing increased demand for separate instances in other regions. We’re dedicated to serving our customers around the world, and this new zone will provide full-stack monitoring and AIOps with the highest levels of data protection.”

Greg Stock, Chairman and CEO, Zenoss

With this launch, all U.S.-based Zenoss Cloud services became available to EMEA customers from a regionalized, dedicated instance — an important distinction for organizations subject to data residency requirements.

Zenoss Cloud is a SaaS-based platform that provides full-stack monitoring and AIOps capabilities, helping IT teams maintain performance visibility across complex, hybrid environments. The company’s strategic alliance partners at the time included AWS, Accenture, Cisco, and NTT Data. It also offered its software through marketplace partnerships on AWS, CenturyLink, Cisco, Rackspace, and ServiceNow.

Zenoss indicated that additional regional zones were planned following the EMEA launch. According to the company, both partners and customers had already begun using the Frankfurt-based EMEA zone at the time of the announcement.

Key Takeaways for Channel Partners

• Rackspace’s EMEA expansion creates new co-sell and referral opportunities for VARs, MSPs, and systems integrators in the Middle East, backed by a formal hub in Dubai and named regional leadership.
• IBM’s hybrid cloud focus under Boville reinforces the company’s enterprise positioning — partners building IBM-aligned hybrid cloud practices can expect continued investment and messaging support from the vendor.
• Zenoss’s EMEA zone removes a key barrier for European customers concerned about data residency, making the platform easier for EMEA-based partners to position and sell.

All three announcements reflect a broader trend: cloud providers are doubling down on regional infrastructure, local expertise, and partner ecosystems as enterprise adoption of multi-cloud and hybrid environments accelerates globally.

Why Hybrid Skills Now Matter More Than Pure Automation

In earlier DevOps adoption cycles, automation skills dominated hiring requirements. That has shifted. The DevOps Institute survey found that process skills and process knowledge have overtaken automation skills as the primary competency organizations seek. This makes sense: once teams understand what automation tools can do, the harder challenge becomes defining the processes, governance, and cultural norms that determine how those tools are used effectively.

As the survey authors put it, early DevOps adopters focused on understanding the technology and its potential. The next logical step is establishing the processes and rules by which that technology is applied consistently and responsibly across the organization.

DevOps Hiring Is Genuinely Difficult

With approximately 52% of companies actively building DevOps competency through hiring, demand for qualified candidates is high — and supply is limited. Around 65% of respondents reported difficulty finding candidates with the right combination of skills. This is not simply a shortage of technically proficient engineers; it reflects the rarity of professionals who can bridge development, operations, automation, security, and business communication simultaneously.

More than half of all survey respondents described themselves as still in the early or mid stages of their DevOps journey. The reasons are both technical and organizational. DevOps requires dismantling deeply entrenched accountability silos, which can feel threatening to teams and individuals whose roles and authority are defined by those silos. Organizational transformation — not tool selection — is often the hardest part.

Common DevOps Team Topologies

The survey identified three team models most commonly in use:

1. The DevOps team silo (or promotion model): A dedicated DevOps team acts as an intermediary between development and operations. This is the most widely adopted model, though it risks recreating the silos DevOps is meant to eliminate.
2. The DevOps collaboration model: DevOps is treated as everyone’s responsibility across development and operations, with no separate dedicated team. This is the closest to the original DevOps vision.
3. The DevOps toolkit model: A central DevOps team owns and manages shared tooling used by other teams. This is common in larger enterprises standardizing their CI/CD and observability stacks.

Each model has tradeoffs, and the right choice depends on organizational size, culture, and maturity level.

The DevOps Hybrid Specialist Profile

The survey paints a clear picture of what an ideal DevOps candidate looks like today: someone with a holistic understanding of developer concerns, operational realities, and automation capabilities. Human skills, process knowledge, functional IT expertise, and automation proficiency are treated as equally important rather than ranked in a fixed hierarchy.

DevOps hybrid specialists typically draw from a wide area of expertise — from cloud infrastructure and platform engineering, to frameworks like Agile and Site Reliability Engineering (SRE), to cross-functional communication and business awareness.

Key Skills Sought in DevOps Roles

The following data is drawn from the DevOps Institute survey of 1,260 IT managers.

Most Important DevOps Hybrid Abilities

• Process competencies and process knowledge — 68%
• Automation skills — 67%
• Soft skills — 61%
• Functional knowledge (networking, storage, etc.) — 36%
• Specific automation tool expertise — 29%
• Business skills — 23%

Core DevOps Functional Skills

• Compute and operational knowledge — 52%
• Security practices — 52%
• IT infrastructure knowledge — 50%
• Application design and development — 45%
• Quality assurance knowledge — 32%
• Business continuity and disaster recovery awareness — 31%
• Testing knowledge — 31%
• Networking knowledge — 28%

Core DevOps Technical Skills

• CI/CD toolchain proficiency — 69%
• Cloud platform and cloud environment knowledge — 63%
• API knowledge — 41%
• Analytical and observability knowledge — 31%
• Multiple programming languages — 28%
• Experience with UI, web services, and middleware — 28%

What This Means for DevOps Teams and Hiring Managers

The takeaway is clear: organizations building DevOps capabilities cannot hire purely for tool knowledge. The engineers who drive lasting DevOps success understand why processes exist, can communicate across organizational boundaries, and are comfortable operating in ambiguous, fast-changing environments. Soft skills — often undervalued in technical hiring — rank third overall in the survey, ahead of functional and business-specific knowledge.

For practitioners looking to advance in DevOps roles, broadening your skill set beyond any single toolchain or platform is increasingly important. Familiarity with SRE principles, Agile delivery frameworks, cloud-native architectures, and security practices will differentiate candidates in a competitive hiring market.

Survey data referenced in this article is attributed to the DevOps Institute. The original report was published prior to March 2020. Photo credit: Joe McKendrick.

Background: What Is the JEDI Contract?

The Joint Enterprise Defense Infrastructure (JEDI) contract is a single-award, multi-year cloud computing deal issued by the US Department of Defense (DoD). Valued at up to $10 billion over ten years, JEDI was designed to modernize the DoD’s IT infrastructure by migrating workloads to a unified commercial cloud platform. Microsoft was awarded the contract in October 2019, defeating Amazon Web Services (AWS), which had been widely regarded as the front-runner throughout much of the procurement process.

Federal Court Grants AWS a Temporary Restraining Order

On 13 February 2020, a US Federal Court approved a temporary restraining order sought by AWS against Microsoft. The order prevented Microsoft from carrying out “substantial” work on the JEDI contract while AWS’s legal challenge against the award played out in court.

As a condition of the restraining order, the court instructed AWS to set aside $42 million to cover potential costs and damages in the event that the work stoppage was later found to have been wrongfully issued.

AWS declined to issue a public comment on the ruling directly.

Microsoft Expresses Disappointment, Stands by DoD Process

Frank X. Shaw, Corporate Vice President of Microsoft Communications, responded to the ruling in a statement provided to Computer Weekly:

“While we are disappointed with the additional delay, we believe we will ultimately be able to move forward with the work to make sure that those who serve our country can access the new technology they urgently required. We have confidence in the Department of Defense, and we believe the facts will show that they ran a detailed, thorough and fair process in determining that the needs of the warfighter were best met by Microsoft.”

Frank X. Shaw, Corporate VP of Communications, Microsoft

AWS Alleges Political Interference in the Procurement

AWS CEO Andy Jassy publicly stated that “significant political interference” was responsible for his company losing the contract, despite AWS being widely considered a strong favorite during most of the procurement cycle. The JEDI award process itself took approximately a year longer than expected, partly due to protests and legal challenges. Critics argued that the original tender structure had been written in a way that unfairly favored AWS — a claim AWS itself disputed when the shoe was on the other foot.

AWS further alleged that US President Donald Trump had intervened in the later stages of the procurement to influence the outcome against Amazon. In support of its legal case, AWS requested that both President Trump and then-Defense Secretary Mark Esper be called to testify. This request was grounded in part on media reports claiming Trump had instructed former Defense Secretary James Mattis to “screw Amazon” out of the JEDI deal.

AWS’s Statement on Presidential Interference

An AWS spokesperson released a statement outlining the company’s rationale for pursuing testimony from the president and the defense secretary:

“President Trump has repeatedly demonstrated his willingness to use his position as president and commander in chief to interfere with government functions — including federal procurements — to advance his personal agenda. The preservation of public confidence in the nation’s procurement process requires discovery and supplementation of the administrative record, particularly in light of president Trump’s order to ‘screw Amazon’. The question is whether the president of the United States should be allowed to use the budget of the DoD to pursue his own personal and political ends.”

AWS Spokesperson Statement, February 2020

Key Timeline of Events

• 2018–2019: JEDI procurement process is delayed by approximately one year due to protests and legal challenges over alleged structural bias in the tender.
• October 2019: DoD awards the JEDI contract to Microsoft, surprising many industry observers who had expected AWS to win.
• Late 2019 – Early 2020: AWS files a legal challenge, alleging improper political interference. AWS requests depositions from President Trump and Defense Secretary Mark Esper.
• 13 February 2020: US Federal Court grants AWS a temporary restraining order, halting substantial Microsoft work on the contract pending resolution of the legal dispute.

Significance for Government Cloud Procurement

The JEDI dispute raised broader questions about the structure of large-scale, single-vendor government cloud contracts and the risks of political influence in high-stakes technology procurement. The case highlighted how cloud platform selection at the defense and national security level carries implications well beyond technology — touching on competitive fairness, vendor lock-in concerns, and the integrity of government acquisition processes.

For DevOps and cloud engineering teams working in or with government sectors, the JEDI litigation underscored the importance of transparent, criteria-driven evaluation frameworks when selecting cloud platforms for large enterprise or public-sector deployments.

Amazon Web Services is the undisputed leader of the public cloud market, but could its relatively small software-as-a-service portfolio be its undoing in years to come?

As the provider with the biggest market share in the infrastructure-as-a-service (IaaS) sector, it is inevitable that Amazon Web Services (AWS) will cop some flak from various competitors claiming their platforms are a better choice for CIOs.

One of those digs, from the likes of Oracle, Microsoft and Google, could be that AWS does not have its own slate of software-as-a-service (SaaS) offerings, whereas the three companies just mentioned do.

The inference being that not having a SaaS play means AWS does not have a fully integrated cloud stack that would, in the minds of its competitors at least, be easier to use as well as more effective.

Oracle’s senior vice-president for cloud, Steve Daheb, believes, in the long term, the database giant has the edge over AWS because it provides the SaaS layer that Amazon has shied away from offering.

“It doesn’t have applications to speak of, and applications drive a lot of the rest of decision-making,” he tells Computer Weekly.

Meanwhile, Andrew Moore, vice-president and head of Google Cloud AI, sees the SaaS layer as one Google’s strong points.

“We are a consumer company that’s built many consumer-level, high-performance systems, so rather than just providing that low-level infrastructure, we are able to help with things involving computer vision, speech understanding, super-advanced networking and very highly optimised database queries, for instance,” says Moore.

“What we and the rest of the industry have learnt is that rather than just providing APIs [application programming interfaces] to these systems for innovative solutions for companies to adopt, we’re able to give more use to customers by putting it all together ourselves and then integrating that into customers’ businesses processes,” he adds.

Weighing up the differences
AWS has repeatedly dodged questions about whether it would step up its SaaS game, but do users really care about a company having its own SaaS, IaaS and platform-as-a-service (PaaS) offerings, or is it more a case of suppliers squabbling about nothing?

John Lewis Partnership’s chief technology officer (CTO), Andrew MacInnes, says having a presence and offerings in all three layers of the cloud helps, and suggests this played a part in the retailer’s decision to use the Google Cloud Platform (GCP).

“It absolutely helps. We’re not exclusive to Google, so we’ll move where we move, but what matters is the value in the proposition above all,” he says.

MacInnes says a large part of cloud computing can be considered a commodity now, with managed databases, managed SQL databases, queuing systems, message passing and so on. So there is little point in taking a best-of-breed approach if the differences are minute.

“You can argue that you prefer one to the other, but for us the value is stronger in our relationship and in the help and assistance we get, rather than arguing that one might be two milliseconds faster than the other,” he says.

“For us, the value is in our relationship and the help and assistance we get, rather than arguing that one might be two milliseconds faster than the other”
Andrew MacInnes, John Lewis Partnership
In other words, having SaaS, PaaS and IaaS with one cloud provider makes more sense because it means the company can rely on one partner for support.

For others, however, the thought process is quite different.

“I guess I don’t look at it that way [that AWS has less of a presence in SaaS]. I look at the fact that we’re using tools that work for us, meaning we have less people worrying about provisioning hardware, supporting hardware and innovating,” says Just Eat’s director of data platforms, Matthew Cresswell.

“I think from a neutral point of view, I know AWS has some SaaS offerings and I know it has a lot of different products that overlap as well, so I think there’s some element of customer fatigue, whereas with Google, perhaps, because it’s a bit younger in this space, in terms of the tools, it seems a lot cleaner and packaged up in such a way that we want to use it,” he adds.

Furthermore, Google’s Moore suggests customers have switched from being sole AWS customers to using Google Cloud because of its SaaS layer.

“There have been hundreds of customers who have said, ‘We thought we would only use another cloud infrastructure, but what you’re able to do with BigQuery and AI has intrigued us’, and they will then start to build systems on GCP to access that level of performance,” he says.

The AWS SaaS play
AWS does have some SaaS applications of its own. Amazon Kendra, the company’s enterprise search offering, is an interesting addition to this small portfolio, particularly as it doesn’t have a wide range of its own SaaS applications for its machine learning algorithm to improve its search capabilities.

But aside from that, the company has steered away from SaaS, instead opting to enable partners to build SaaS on top of AWS infrastructure, and integrating key partner SaaS offerings with its IaaS. For many customers, this is all they need.

“Arguably, a lot of what AWS does is similar to SaaS-based products – it’s taking Postgres and scaling that out and innovating on top and contributing, for example. I don’t think Amazon necessarily needs to provide these products,” says Suhail Patel, senior software engineer at Monzo Bank.

Indeed, this is the view from AWS too.

“If our customers are telling us that they want us to purely come into [SaaS] and not just rely on a set of really great partners, but they want us to deliver those services, you’re going to see us innovate and do so,” says Darren Mowry, managing director of business development for AWS in Europe, the Middle East and Africa (EMEA).

But nevertheless, it has been a surprise that the company did not announce more when it came to SaaS at Re:Invent, its showcase event in Las Vegas this year.

“In some ways it is surprising that AWS’s business applications portfolio has been very low key at the past two events. Granted Re:Invent is primarily an IT developer and educational event, so the buyers of applications and, in particular, the business audiences who use them, are not the focus, but I think the market is starting to look at this area in AWS’s strategy to see whether it will play more strongly here in the future,” says Nicholas McQuire, vice-president of enterprise research at CCS Insight.

Mowry adds that with the introduction of Amazon Chime and Workspaces, the company is beginning to touch on services that are closer to SaaS.

“In time, you’ll see our capabilities across the stack continue to grow, but I don’t think I can say we have a specific strategy to enter a specific type of SaaS market,” he says.

“Right now, the strategy is doing some interesting things that are close to SaaS, but enabling partners to build great technology, and that will continue to be a part of the strategy, but I can’t say that there’s never a possibility that we wouldn’t get into [SaaS] full-scale,” he adds.

McQuire says Workspaces, Alexa for Business, Amazon Connect and Chime are foundations for SaaS, but these products “feel like second-class citizens to the IaaS business, as AWS has been investing more heavily in areas lower down the cloud stack”.

What customers want
Although AWS’s Mowry alludes to the company reacting to what customers are after, perhaps the reason AWS has lost out on certain clients is because Microsoft and Google have already had a presence in the enterprise through Office 365 or G Suite.

“Microsoft and Google have been winning big cloud deals with customers that nominate them as their preferred cloud partners – AT&T and Microsoft, Airbus and Google Cloud. These customers are focusing on both IT transformation and workplace transformation, so their SaaS applications have been critical alongside cloud infrastructure to winning those deals,” says McQuire.

McQuire adds that while AWS focused on business transformation throughout Re:Invent in December 2019, many companies think of this in its entirety, particularly the C-suite.

“This means they don’t just focus on their developers, they focus on all their employees and the tools they need to drive competitive advantage as well,” he says.

So could AWS not stand to have another entry point into enterprises like this?

Mowry isn’t sure that this type of strategy always works.

“Companies like Microsoft do tend to come in through Office 365 and attach Azure to an enterprise agreement. We’re seeing that this may work sometimes, but we’re also hearing from a lot of customers that it’s not the behaviour they want,” he says.

AWS is not struggling to attract large enterprises, and many of its existing customers see it as a main partner, including BP, F1, Monzo Bank and Vodafone
“I don’t think we’d do it to mirror what Google and Microsoft are doing to just give us an entry point. I think we’ll only do it if the customer says it’s a capability they really need because I’m sensing a bit of a backlash if we’re going to attach these things together. It could be an additional unintended consequence of us doing that, but I don’t think that would be the leading reason for us to do that,” he adds.

It must be noted that AWS is not struggling to attract large enterprises, and many of its existing customers see it as a main partner, including BP, F1, Monzo Bank and Vodafone.

However, in the long run, AWS may need a much deeper strategy to fill certain gaps it has in comparison to Microsoft and Google, particularly as an increasing number of cloud deals are incorporating the integration of SaaS.

“Doing so will enable AWS to support more business processes on its platform, as well as create opportunities to disrupt this area. Of course, AWS will have to tread carefully as many SaaS providers run on AWS and its partner ecosystem and marketplace are essential to its cloud offerings,” says McQuire.

Introduction

DevOps is a discipline that evolves rapidly — practices, tooling, and cultural norms shift almost continuously. Looking back at 2019, several clear trends emerged that defined how engineering teams built, secured, and operated software at scale. Below is a structured breakdown of the ten most significant DevOps trends from that year, many of which continue to influence the industry today.

1. Pipeline Automation

Automation has always been central to DevOps philosophy, and 2019 saw it deepen further. Continuous integration and continuous delivery (CI/CD) tooling continued to proliferate, with GitHub’s introduction of GitHub Actions expanding the ecosystem of pipeline automation options available to teams.

Closely tied to CI/CD growth is the maturation of infrastructure as code (IaC). Tools such as Terraform, AWS CloudFormation, Azure Resource Manager, and GCP’s Deployment Manager became standard practice, allowing teams to provision and tear down environments programmatically — whether during local development, inside CI pipelines, or even in production delivery workflows.

2. Kubernetes Dominance

Kubernetes was virtually inescapable in 2019. Since its release in 2014 and general availability in 2015, it established itself as the leading container orchestration platform, accumulating far more community mindshare than competitors such as Apache Mesos or Docker Swarm.

Major enterprise vendors including Red Hat and VMware committed deeply to Kubernetes support, and an increasing number of software vendors began shipping their products with Kubernetes-native deployment as the default. While Kubernetes had not yet proven itself universally across every class of workload, the momentum behind it remained strong heading into 2020.

3. Service Meshes

As Kubernetes adoption expanded, so did conversations about service meshes. A service mesh is software that manages service-to-service communication within a distributed platform. Rather than requiring each application team to implement their own solutions for common concerns, a service mesh provides these capabilities at the platform level.

Typical service mesh capabilities include:

• Load balancing
• Mutual TLS encryption
• Authentication and authorisation
• Traffic proxying and routing
• Observability and tracing

By moving these concerns out of application code and into the platform layer, service meshes free development teams to focus on business logic rather than distributed systems boilerplate.

4. Observability

Observability is frequently conflated with monitoring, but the distinction is important. Monitoring is an activity — you monitor a system. Observability is a property of a system — it describes whether the internal state of that system can be reliably inferred from its external outputs.

The concept originates in control theory and real-world engineering. For software systems, high observability means that when something goes wrong, engineers can determine the root cause quickly from the data the system already emits — logs, metrics, and traces — without needing to instrument it further after the fact.

Related to observability is the concept of cardinality — the number of distinct values in a time-series dataset. Higher cardinality generally means more granular data, which supports more precise troubleshooting. However, high-cardinality data also carries storage and query costs, so teams must balance richness of data against operational overhead.

5. DevSecOps

Security traditionally sat outside the development pipeline — something applied as a gate at the end, or retrofitted after incidents. DevSecOps challenges this by integrating security practices directly into CI/CD pipelines and making security a shared responsibility across development, operations, and SRE teams.

Key developments in this space in 2019 included:

• Compliance as code tools such as InSpec, which allow security and compliance checks to be written, versioned, and run automatically as part of pipelines.
• Container image scanning tools such as Aqua Security and Sysdig, which inspect images for known vulnerabilities before they are deployed.
• Growing awareness of the need to embed security at every stage of the software delivery lifecycle rather than treating it as a final checkpoint.

The broader portmanteau “DevSecNetQAGovOps” was occasionally floated to describe even more holistic pipeline integration, though DevSecOps remained the dominant and most practical framing.

6. The Rise of Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) is a discipline that originated at Google in 2003 — predating the term “DevOps” entirely. It was later documented in Google’s book Site Reliability Engineering. The core idea is to treat operations as a software engineering problem: SRE teams write code to automate reliability, define error budgets, and maintain service level objectives (SLOs).

Unlike a traditional DevOps team structure where one team owns the full lifecycle, SRE acknowledges that at very large scale, a dedicated reliability engineering function may be necessary. At Google’s scale — hundreds of data centres, vast standardised infrastructure — a single cross-functional team owning every service end-to-end is not practical.

In 2019, job postings for “SRE Engineer” roles reportedly began to outnumber those for “DevOps Engineer” at many organisations. This reflects both the growing influence of the SRE model and a desire by organisations to signal a specific, engineering-focused operational capability.

7. Artificial Intelligence and Machine Learning in DevOps

The application of machine learning (ML) to DevOps tooling began gaining traction in 2019, though the space was still early-stage. Emerging use cases included:

• Anomaly detection: ML models trained on historical application behaviour to flag deviations that may indicate incidents before they escalate.
• Test optimisation: Using ML to determine which test cases are most likely to catch regressions on a given build, reducing CI pipeline duration without sacrificing coverage.
• Predictive infrastructure management: Google published research on using ML models to predict hardware failures ahead of time, enabling proactive remediation.

Products such as ScienceLogic’s SL1 were early entrants in the AI-assisted operations (AIOps) market. The category was still nascent, but directionally significant.

8. Serverless Computing

Serverless computing — popularised by AWS Lambda when it launched in 2014 — continued to grow in 2019 as other cloud providers and open-source projects expanded the ecosystem. The term “serverless” can be misleading: servers are still involved. What it actually means is that the developer does not manage server provisioning or scaling. The cloud provider handles infrastructure entirely; the developer deploys code and pays for execution time.

Key considerations for serverless adoption include:

• Vendor lock-in: Serverless applications are typically tightly coupled to the platform they run on, making portability a genuine concern.
• Cold start latency: Functions that have not run recently may incur startup delays.
• Use-case fit: Serverless suits event-driven, short-lived workloads well, but is less suited for long-running or stateful processes.

9. Shifting Left and Shifting Right in CI/CD

As release cycles shortened, the concepts of shift-left and shift-right testing gained wider recognition.

Shift left refers to moving quality checks earlier in the development process — catching problems as close to the point of authorship as possible. This includes not just unit and integration testing, but also code linting, static analysis, dependency vulnerability scanning, and security checks. The earlier a defect is caught, the cheaper it is to fix.

Shift right refers to testing in production or production-like environments, intentionally surfacing issues that only manifest at scale or under real user traffic. Techniques include canary deployments, feature flags, chaos engineering, and synthetic monitoring. The goal is to discover failure modes before users report them.

10. The CALMS Framework as a Unifying Lens

While not a new trend in 2019, the CALMS framework — standing for Culture, Automation, Lean, Measurement, and Sharing — provided a useful lens through which to evaluate all of the above trends. Each of the nine trends described above can be mapped to one or more of these principles:

• Culture: DevSecOps, SRE, and the organisational changes they require
• Automation: Pipeline automation, IaC, and serverless
• Lean: Shift-left testing, reducing waste in release cycles
• Measurement: Observability and AI-assisted monitoring
• Sharing: Kubernetes ecosystems, service meshes, and open tooling

Summary

The DevOps landscape in 2019 was characterised by the maturation of container orchestration, growing security integration, and the early application of machine learning to operational problems. Many of these trends — Kubernetes, observability, DevSecOps, and SRE — have since become foundational rather than emergent. Understanding where they stood in 2019 provides useful context for appreciating how far the discipline has evolved since.

What Makes a Platform?

Haeussler and Williams opened with a history of container technology, tracing a timeline from chroot in 1979 through to Knative and Project Eirini in 2018. The historical arc frames an important insight: a mature cloud platform is not just an orchestrator — it is an opinionated layer that delivers real value to every role in the organisation.

According to the speakers, a well-designed platform should provide:

• Self-service for developers — deploy, scale, and inspect applications without filing tickets.
• Coherent UX for all support roles — operators, security engineers, and platform teams each have clear, role-appropriate interfaces.
• Automation and monitoring — health checks, log aggregation, and metrics out of the box.
• Self-healing and resource optimisation — the platform restarts failing instances and manages capacity automatically.
• Application focus over infrastructure focus — developers describe what to run, not how to wire up infrastructure.

Avoiding the “Not Invented Here Platform” Anti-Pattern

One of the talk’s strongest warnings was about teams that believe they are not using a platform. Haeussler and Williams argued that if you are not adopting a standard platform, you are implicitly building your own — often without realising it. Custom deployment scripts, internal tooling chains, and bespoke CI pipelines accumulate into an undocumented, undertested DIY cloud platform that nobody fully owns.

Standard platforms do impose constraints, but those constraints exist because they solve common problems at scale. Teams that bypass them frequently end up solving the same problems themselves, at greater cost and with less reliability.

Cloud Foundry: Developer-Centric Deployment

Cloud Foundry (CF) remains one of the most developer-friendly platforms available. The developer workflow is deliberately simple. Core CLI commands include:

# Push an application
cf push my-app

# Scale horizontally
cf scale my-app -i 3

# Open an SSH session into a running instance
cf ssh my-app

The platform handles buildpack detection, container image creation, routing, and health management automatically. Developers interact with logical concepts (apps, spaces, orgs) rather than infrastructure primitives.

Project Eirini: Kubernetes as a CF Backend

Project Eirini is an effort within the Cloud Foundry ecosystem to replace the default Diego container scheduler with Kubernetes. Instead of Diego cells, Eirini deploys application container instances as OCI-compliant images onto a Kubernetes cluster. The result is that operators can choose their scheduling backend — Diego or Kubernetes — without exposing that choice to application developers, who continue to use the standard cf push workflow.

Key points about Eirini:

• Translates Cloud Foundry’s application model into Kubernetes StatefulSets and related primitives.
• Uses OCI images as the deployment artifact, enabling compatibility with standard container registries.
• Preserves the CF developer experience entirely — no Kubernetes knowledge required from app teams.

Project Quarks: Containerising the CF Control Plane

While Eirini targets application workloads, Project Quarks (also from the Cloud Foundry Foundation) targets the Cloud Foundry control plane itself. Traditionally, Cloud Foundry Application Runtime (CFAR) is deployed and managed by BOSH, which treats VMs as the unit of deployment. Quarks repackages CFAR components as containers, making the entire platform deployable on Kubernetes.

The goal is to provide an identical developer experience to a BOSH-managed CF installation, while reducing operational overhead for organisations already running Kubernetes. Eirini and Quarks are complementary: Quarks runs the CF control plane on Kubernetes, while Eirini uses Kubernetes to schedule application instances.

Cloud Native Buildpacks: Standardising the Build Process

Cloud Native Buildpacks (CNBs) is a joint CNCF project that defines a standard interface for transforming application source code into OCI images. The goal is to decouple the build process from any specific platform, so the same buildpack can produce images for Cloud Foundry, Kubernetes, or a local development environment.

CNBs provide several operational advantages beyond basic builds:

• Layer rebasing — update the OS or runtime layer in an existing image without rebuilding application layers, dramatically reducing patch time.
• OS-level updates — apply security patches to base images and automatically propagate them to all derived application images.
• Vulnerability detection — identify outdated or vulnerable layers and trigger targeted updates across a cluster.
• Local and cluster execution — developers can run the same build process on their laptop that runs in CI.

kpack: Kubernetes-Native Buildpack Builds

kpack is a Kubernetes-native implementation of Cloud Native Buildpacks. It uses Kubernetes Custom Resource Definitions (CRDs) to represent build configurations, making image builds a first-class Kubernetes primitive. When source code or a buildpack is updated, kpack automatically triggers a new build and publishes the updated OCI image to a registry.

At the time of the talk, kpack was part of the Pivotal Build Service. It integrates with standard Kubernetes RBAC and works with any OCI-compliant registry.

Open Service Broker API: Plug-and-Play Backing Services

The Open Service Broker API (OSB API) is an open specification that allows cloud vendors to expose managed backing services — databases, message queues, caches — to workloads running on Cloud Foundry, Kubernetes, or other platforms using a common API surface. This gives organisations a consistent way to provision and bind services regardless of the underlying platform, reducing lock-in and simplifying operator workflows.

Istio: Service Mesh for Cloud Native Applications

The speakers demonstrated how Istio can be layered into cloud native deployments to provide traffic management, mutual TLS, observability, and policy enforcement between services. Istio operates as a sidecar proxy alongside each application instance, making network behaviour configurable through declarative Kubernetes resources rather than application code changes.

Knative: Serverless Workloads on Kubernetes

Knative is an open-source platform built on Kubernetes that adds serverless capabilities. It is designed to run event-driven and request-driven workloads efficiently. Key features include:

• Scale-to-zero — idle workloads consume no resources and spin up automatically on incoming requests.
• Autoscaling — Knative Serving scales instances up and down based on concurrency or request rate.
• In-cluster builds — Knative Build (now superseded by Tekton) provided a build pipeline primitive inside Kubernetes.
• Eventing framework — Knative Eventing provides a broker-and-trigger model for routing CloudEvents between producers and consumers.

Knative sits above raw Kubernetes and can be combined with Istio for advanced traffic routing, enabling capabilities like canary deployments and traffic splitting at the serverless layer.

Platform Comparison Summary

Video: SpringOne Platform 2019 Session

The full session playlist from SpringOne Platform 2019 is available on YouTube:

Key Takeaways

• Every engineering team uses a platform — the question is whether it is a well-maintained standard one or an accidental DIY creation.
• Cloud Foundry and Kubernetes are converging through projects like Eirini and Quarks, not competing.
• Cloud Native Buildpacks and kpack provide a portable, secure build abstraction that works across platforms.
• Knative adds serverless semantics — particularly scale-to-zero and eventing — to Kubernetes without replacing it.
• Open Service Broker API reduces vendor lock-in by standardising how backing services are provisioned and bound.

Original talk coverage by InfoQ. Presented by Matthias Haeussler and Dr Nic Williams at SpringOne Platform 2019.

The following four guidelines provide a practical framework for narrowing down edge computing software candidates and avoiding costly mismatches.

1. Start with the Business Problem

Before evaluating any vendor, define the specific business problem you are trying to solve and how an edge computing investment fits within the organization’s broader strategy. This scoping exercise determines the potential value of the project and sets the criteria against which software options will be measured.

Key cost factors to quantify up front include:

• Vendor licensing costs — initial and recurring subscription or perpetual fees.
• Implementation costs — professional services, internal engineering time, and integration effort.
• Security risk assessment — evaluating the attack surface introduced by distributed edge nodes.
• Staff training and knowledge growth — onboarding teams to new tooling and operational patterns.
• Lifecycle and maintenance costs — ongoing patching, hardware refresh cycles, and support contracts.

A custom-built edge configuration may appear cost-effective at purchase time but can carry significant hidden costs when future staffing and operational overhead are factored in. Conversely, adopting a commercial platform may require changes to existing workflows that have their own financial impact. The overall value delivered by the edge setup must clearly outweigh both one-time and ongoing costs before a selection decision is made.

2. Define What “Edge” Means for Your Organization

“Edge” is not a single, universally agreed-upon location. For some organizations it means a regional co-location facility; for others it means a cell tower, a factory floor gateway, or a retail kiosk. Defining this boundary precisely is essential because it directly determines the latency, availability, and connectivity requirements that your software must satisfy.

Latency Requirements by Use Case

Different applications tolerate very different levels of latency:

• Ultra-low latency (<1 ms) — Required for certain real-time IoT and industrial control scenarios, often supported by deployments co-located with cellular infrastructure.
• Low latency (<100 ms) — Suitable for globally distributed application acceleration use cases.
• Standard latency (200–300 ms) — Sufficient for most enterprise applications when a regional data center is available within the same country.

IoT implementations in particular demand that edge software be tightly aligned with operational technology (OT) systems. The software must support stringent latency thresholds for functions such as device health monitoring and real-time performance management.

Evaluate the Cost of Downtime

Availability requirements vary dramatically by use case. A video analytics application may tolerate brief interruptions; a control system for an autonomous vehicle cannot. Identifying acceptable downtime thresholds early helps rule out software options that do not meet your reliability requirements.

“Thinking about these things will determine how you should be processing your data.”

Chris Hinkle, CTO at TRG Datacenters

Local Data Processing and AI Workloads

Evaluate whether candidate software supports efficient local data processing. Look for a capable complex event processor that can cleanse, normalize, contextualize, and align raw streaming data from industrial or IoT sources before it is forwarded upstream.

Some edge platforms also provide tooling to compress or quantize AI models so they can run efficiently on resource-constrained edge hardware, reducing both compute requirements and bandwidth consumption. Newer offerings go further by integrating cloud-based model training pipelines with automated deployment to edge nodes—an important capability if machine learning is part of your edge strategy.

3. Prioritize Visibility and Remote Control

Edge deployments are, by definition, geographically distributed and often physically remote from the IT team responsible for managing them. Unlike a data center or cloud environment, edge nodes may have limited or intermittent connectivity and lack on-site technical staff. This makes remote management and monitoring capabilities non-negotiable selection criteria.

When assessing visibility and control features, consider:

• Remote management — Can the software be configured, updated, and troubleshot entirely over the network without physical access?
• Monitoring and alerting — Does the platform integrate with existing observability tools (metrics, logs, traces)?
• Autonomous operation — Can edge nodes continue functioning and making local decisions when connectivity to a central platform is lost?
• Legacy compatibility — Many edge deployments extend existing equipment and applications. Assess whether the software requires new hardware, a change in cloud provider, or code rewrites to support legacy systems.

Visibility is especially challenging when edge software must coexist with legacy code and older operational equipment. Conduct a thorough audit of existing assets before finalizing a platform choice.

4. Align with Developer Workflows

Edge computing software that does not integrate with existing development and deployment workflows creates friction that can undermine the productivity gains the project is meant to deliver. Evaluate how well each candidate platform fits the languages, frameworks, and CI/CD tooling your engineering teams already use.

“It comes down to working with software languages that your teams already know.”

Mike Hostetler, Senior Director of Engineering at Cars.com

A fragmented deployment model—where developers must follow one process for the data center, another for cloud, and a third for edge—creates operational complexity and slows release velocity.

“If a developer has to deploy one way for data center, one for core cloud and then another for edge, all of that productivity gain will be lost.”

Sean Leach, Chief Architect at Fastly

Look for platforms that expose consistent APIs and deployment primitives across environments, and that plug into your existing continuous integration and continuous deployment (CI/CD) pipelines. The closer the edge deployment experience is to what developers already do for cloud or on-premises workloads, the faster teams can ship and iterate.

Summary: Edge Software Selection Checklist

• Define the business problem and quantify the full cost of ownership before evaluating vendors.
• Establish exactly where your “edge” is and what latency, availability, and connectivity requirements that location implies.
• Require strong remote management and monitoring capabilities; edge nodes cannot depend on on-site intervention.
• Audit legacy equipment and code compatibility before committing to a platform.
• Choose software that supports your existing programming languages and plugs into your CI/CD pipeline.
• Evaluate AI model deployment and local data processing capabilities if machine learning workloads are in scope.

Finding the right edge computing software is a cross-functional exercise. Business stakeholders define the use case and acceptable risk; IT and engineering teams translate those requirements into technical criteria. Bringing both sides together from the start prevents expensive rework after a platform has already been deployed.

At its annual user conference, Teradata Universe 2019, held at the Denver Convention Center, Teradata unveiled a series of significant product and partnership announcements centered on its flagship analytics platform, Teradata Vantage. The headline announcement was a major partnership with Google Cloud, bringing Vantage to Google Cloud Platform (GCP) and completing Teradata’s presence across all three major public cloud providers.

Teradata Vantage Comes to Google Cloud Platform

Teradata confirmed that Vantage will be made available on Google Cloud Platform, extending its existing cloud deployments beyond AWS and Microsoft Azure. With this partnership, Teradata now offers its enterprise analytics environment across all three leading public clouds, giving customers the ability to run Vantage in whichever cloud environment their organization has standardized on.

Under the partnership model, Teradata manages the performance, security, availability, and operations of the Vantage analytics environment, while leveraging GCP’s underlying compute and storage infrastructure. This means enterprise customers retain the managed-service experience they expect from Teradata while benefiting from Google Cloud’s global infrastructure.

“Adding Google Cloud Platform to the global footprint already offered by Teradata will provide customers with unrivaled choice and flexibility with how and where they use Teradata Vantage. Plus, with native support for low-cost storage, organizations will be able to access and query all of their data, regardless of where it is, to get an unrivaled view of virtually every aspect of their business.”

— Ashish Yajnik, VP of Product Management, Teradata

“Teradata customers want to get as much value out of their data as possible, so we are delighted to partner with Teradata to connect them to Google Cloud to reduce infrastructure costs, enhance cloud security, and scale seamlessly. Google and Teradata will work together to tightly integrate Google Cloud services like AI and Google Cloud Storage into Vantage to bring advanced capabilities to our joint customers.”

— Kevin Ichhpurani, Corporate Vice President, Global Ecosystem, Google Cloud

The partnership also includes plans to integrate Google Cloud AI services and Google Cloud Storage natively into the Vantage platform. Teradata Vantage on GCP was planned for general availability in 2020, with a private preview available to select customers in the first half of 2020 upon request.

All Announcements at Teradata Universe 2019

The Google Cloud partnership was the most prominent of several announcements made at the five-day conference. Here is a summary of every major item announced:

• Teradata Vantage on Google Cloud Platform
• Native support for low-cost object storage
• Pay-as-you-go (consumption) pricing for Vantage
• Hadoop Migration Program
• Debut of Vantage Analyst
• Debut of Vantage Customer Experience (CX)

Native Support for Low-Cost Object Storage

A recurring theme across the announcements was enabling customers to query all their data, regardless of where it lives. Teradata announced native support for low-cost object stores, initially targeting Amazon S3 and Azure Blob Storage, with Google Cloud Storage planned as part of the new GCP partnership.

Object stores are commonly used to capture and retain raw data at full fidelity from a wide range of sources — equipment sensors, web clickstreams, customer service call recordings, social media feeds, and more. By giving Vantage native query access to these stores, Teradata allows organizations to analyze data in place without expensive ETL pipelines or data duplication.

Native access to low-cost object stores was in private preview at the time of the conference announcement, with general availability planned for the first half of 2020.

Consumption (Pay-As-You-Go) Pricing

Teradata introduced a new consumption pricing model for Vantage that charges customers only for the compute resources they actually use — billed down to the millisecond — with no upfront commitment required. This is a significant shift from traditional capacity-based licensing, which requires organizations to forecast workloads and commit to resources in advance.

By moving to consumption pricing, Teradata transfers deployment risk from the customer to itself, and aligns costs directly to business value. For enterprises managing unpredictable or seasonal analytics workloads, this model offers both financial and operational flexibility.

Consumption pricing for Vantage was in limited availability at the time of announcement, with general availability planned for the first half of 2020.

Hadoop Migration Program

Many enterprises made substantial investments in Hadoop-based data architectures over the past decade. However, the industry has broadly shifted toward architectures that separate compute from storage, using cloud object stores rather than HDFS. This transition has left many organizations with legacy Hadoop environments that are costly to operate and difficult to evolve.

Teradata’s Hadoop Migration Program offers professional services and migration expertise to help customers transition their analytics ecosystems from Hadoop to cloud-native architectures, with Vantage as the analytics layer and inexpensive cloud object storage replacing HDFS. The program aims to reduce migration risk while lowering total cost of ownership.

Hadoop migration services were announced as globally available at the time of the conference. Pricing is tailored to each customer’s specific environment and requirements.

Vantage Customer Experience (CX)

Vantage Customer Experience is a new application layer built on top of the Vantage platform, designed for marketing and customer experience professionals who need to deliver personalized, real-time customer interactions without managing underlying IT infrastructure.

“Vantage Customer Experience provides marketing and CX professionals with a best-in-class, tailored experience. Using Vantage as an enterprise customer data platform, ensures they have the autonomy and ease-of-use they need to integrate, analyze and activate customer data.”

— Reema Poddar, Chief Product Officer, Teradata

Key capabilities of Vantage CX include:

• Unify Customer Data: Built for citizen data integrators, Vantage CX provides agility to experiment with rapidly changing data while maintaining enterprise-grade governance, scale, and security.
• Turn Data into Insight: No coding required. Marketers can access advanced analytics including Path analysis for understanding customer journeys, Text analytics for sentiment analysis, Cluster analysis for hyper-segmentation, and machine learning for next-best-offer optimization.
• Turn Insights into Action: Customers can be targeted directly from visualizations. Teradata’s existing Customer Interaction Management (CIM) and Real-Time Interaction Manager (RTIM) capabilities have been modernized for cloud deployment and unified into a single integrated application.

Vantage Customer Experience was announced in limited availability, with general commercial availability planned for Q1 2020.

Vantage Analyst

Vantage Analyst is a cloud-based, no-code analytics tool aimed at business analysts who need self-service access to data science capabilities without writing code. It provides a guided environment for data loading, exploratory analysis, machine learning, and hypothesis testing across multiple data sources and types.

“Business analysts lack the tools needed for self-service data loading, discovery, machine learning and other advanced analytics. Teradata now offers Vantage Analyst in the cloud to make it simple to perform guided data science analytics without having to write a single line of code.”

— Reema Poddar, Chief Product Officer, Teradata

Vantage Analyst also surfaces hidden associations and patterns in data through visualization, helping business analysts identify actionable opportunities without requiring data engineering support. By enabling rapid iteration and hypothesis testing, the tool is designed to increase the proportion of an analyst’s time spent generating business insight rather than wrangling data.

What This Means for Enterprise Analytics Teams

Taken together, the Teradata Universe 2019 announcements represent a clear strategic direction: making Vantage cloud-agnostic, accessible to non-technical users, and financially flexible. The Google Cloud partnership in particular signals that Teradata is serious about competing in multi-cloud enterprise environments where cloud vendor lock-in is an increasing concern.

For DevOps and data engineering teams, the most operationally relevant items are the native object store support — which reduces the need for custom data movement pipelines — and the Hadoop Migration Program, which offers a structured path away from aging on-premises Hadoop clusters. The consumption pricing model is also worth evaluating for teams running variable or bursty analytics workloads where reserved capacity pricing is wasteful.

This guide walks through the essential steps: understanding key GKE concepts, deploying your first cluster, and safely deleting it when you’re done.

Prerequisites

Before you start, make sure you have the following in place:

• A Google Cloud Platform account with billing enabled and the Kubernetes Engine API activated for your project.
• The Google Cloud SDK installed and initialised on a Linux machine (gcloud init or gcloud auth login completed).
• A GCP project set as the active project (gcloud config set project PROJECT_ID).

Key Concepts to Know Before You Begin

Compute Zones and Regions

GCP infrastructure is divided into regions (broad geographic areas) and zones (isolated locations within a region). For example, the region us-central1 contains zones such as us-central1-a, us-central1-b, us-central1-c, and us-central1-f. You specify a zone when creating a zonal cluster. The full list of available zones is maintained in the GCP regions and zones documentation.

Cluster Types

• Zonal cluster — Runs a single control-plane replica and worker nodes in one compute zone. Good for non-production workloads where simplicity matters more than availability.
• Regional cluster — Spreads three control-plane replicas across three zones and runs worker nodes across multiple zones. Recommended for production workloads.
• Private cluster — A zonal or regional cluster whose control-plane and nodes are not reachable from the public internet. Suitable for security-sensitive environments.
• Alpha cluster — An experimental zonal or regional cluster with Kubernetes alpha features enabled. Not intended for production use.

Deploying Your First Cluster

The minimal command to create a standard zonal GKE cluster is:

gcloud container clusters create NAME --zone us-central1-a

Replace NAME with a lowercase, human-readable identifier for your cluster (e.g., my-first-cluster). Cluster names must be unique within a project and zone.

GKE provisions the control plane and a default node pool. You may see informational warnings during provisioning — these are normal. When the command completes, the output displays cluster details including the master IP address and machine type.

Useful Options for cluster create

The gcloud container clusters create command accepts a large number of flags. Some of the most commonly used are:

For the complete reference, run gcloud container clusters create --help or consult the official gcloud reference documentation.

Connecting kubectl to Your New Cluster

Once the cluster is running, configure kubectl to communicate with it by fetching the cluster credentials:

gcloud container clusters get-credentials NAME --zone us-central1-a

This command updates your local ~/.kube/config file and sets the new cluster as the active context. You can then verify connectivity with:

kubectl get nodes

Listing Your Clusters

To see all clusters in your current project and their status, run:

gcloud container clusters list

The output shows each cluster’s name, location, master version, and current status. This is useful when you need to find a cluster name before deleting it.

Deleting a Cluster

When a cluster is no longer needed — for example, after a test — delete it to stop incurring costs:

gcloud container clusters delete NAME --zone ZONE

Replace NAME with the cluster name and ZONE with the zone where it was created (e.g., us-central1-a). GKE will prompt you to confirm the deletion before proceeding.

To skip the interactive prompt in scripts or CI pipelines, add the --quiet flag:

gcloud container clusters delete NAME --zone ZONE --quiet

Deletion takes several minutes. Once complete, all cluster resources — nodes, load balancers provisioned by Services, and the control plane — are removed from your project.

Next Steps

With a running cluster and kubectl configured, you can begin deploying workloads using standard Kubernetes manifests or Helm charts. Consider exploring:

• Node pools — Add specialised node pools (GPU nodes, high-memory nodes) with gcloud container node-pools create.
• Cluster autoscaler — Use --enable-autoscaling at creation time to automatically scale node counts with demand.
• Workload Identity — Bind Kubernetes service accounts to GCP IAM service accounts for secure, keyless authentication to GCP APIs.
• GKE Autopilot — A fully managed cluster mode where Google manages the node infrastructure, billing per Pod rather than per node.

Original article based on reporting from TechRepublic (techrepublic.com).

The rise of Kubernetes as the de facto container orchestration platform has been a boon to organizations looking to take advantage of a microservices-based ecosystem but has proven to be a challenge for many vendors. The extreme of that challenge played out late last week as Containership announced it will be docking its boat for good on Oct. 31.

Containership Founder and CTO Norman Joyner explained in a blog post that the company was unable to adequately monetize its operations in light of Kubernetes’ rise. This included a failed attempt to pivot its Containership Cloud operations toward a more Kubernetes-focused platform.

“Ultimately, we came up short,” Joyner wrote. “It has been nearly a year and a half since the Containership Cloud re-platform, and we have failed to monetize Containership Cloud in such a way that we could build a sustainable business.”

Containership launched in early 2015, sparked by a desire to be part of the TechCrunch Disrupt Startup Battlefield event. While it did not succeed in winning that competition, the company’s founders decided to make a go of it by launching its open source container scheduler.

Joyner explained that the company was formed as a way to manage and deploy containers at scale across cloud environments. This evolved into the launch of its Containership Cloud platform that supported automatic deployments into Amazon Web Services (AWS) and Digital Ocean.

The company managed to raise $2.6 million in seed funding and set out to help manage container deployments. It positioned itself in many ways, including as an alternative to Heroku. It also added support for other cloud players like Microsoft Azure, Google Cloud, and Packet.

Unfortunately, the rise of Kubernetes and broad adoption of that container orchestration platform by the large cloud players limited the need of an outside vendor.

Containership Not the Only One

Kubernetes dominance has also impacted larger players in the space.

Mesosphere recently changed its name to D2iQ with a new focus on “day two” operations. This is around the actual support of those platforms running in a production environment.

D2iQ co-founder and CTO Tobi Knaup explained to SDxCentral that the push behind Kubernetes had a “significant” impact on its decision. “Not just the push by the ecosystem, but the pace of advancement in Kubernetes capabilities,” Knaup said.

“Kubernetes is emerging as a key deployment and operations framework for cloud-native applications to help anchor production deployments in both private and hybrid multi-cloud implementations,” explained Paul Parker-Johnson, principal analyst at ACG Research, in an email to SDxCentral tied to the D2iQ rebranding. “To frame its product and services offerings in a way that directly enables ‘day two’ operational capabilities for Kubernetes-based applications leans directly into the main line of where app developers want to go and where operations teams need to go as well.”

And that need is moving quickly. A recent survey conducted by security firm StackRox found that 86% of organizations are using Kubernetes compared with 57% just six months ago. A report from Gartner predicts that more than 75% of global organizations will be running containerized applications in production by 2022 compared to less than 30% today.

Others are taking notice.

Docker Inc.’s recent 3.0 update for its flagship Enterprise platform was based heavily on deeper Kubernetes integration. It also included its own version of a hosted Kubernetes service dubbed the Docker Kubernetes Service (DKS).

VMware last month paid $2.7 billion for sister-company Pivotal Software, which itself recently launched alpha versions of two of its managed platforms and announced plans to move a third to that status later this year. The moves were part of its broader push to ease enterprise management of cloud-native platforms like Kubernetes.

And, IBM paid $34 billion for Red Hat, which has a history of leaning on Kubernetes. IBM quickly migrated all of its legacy software portfolio to be available through Red Hat’s Kubernetes-focused OpenShift platform.

Rackspace as a Cloud Marketplace Guide: Key Themes

As the cloud computing market matured through the late 2010s, businesses faced an increasingly fragmented landscape: public clouds, private clouds, managed hosting, colocation, and a growing roster of SaaS applications from vendors like Oracle, SAP, and Salesforce. Rackspace built its value proposition around helping enterprises navigate that complexity rather than locking customers into a single platform.

The following sections summarise the key points from a TechRadar interview with a Rackspace executive (then serving in a CMO capacity), covering the company’s approach to cloud guidance, customer service, product evolution, and lessons from startup culture.

Why Rackspace Focuses on Multi-Cloud Advisory

One of Rackspace’s core differentiators at the time of the interview was its partnerships with multiple major cloud providers — including Amazon Web Services, Microsoft Azure, Google Cloud, and VMware — alongside enterprise application vendors. This allowed the company to position itself as a vendor-neutral advisor rather than a reseller tied to a single ecosystem.

The executive emphasised that most competitors offered a one-size-fits-all solution, whereas Rackspace’s model involved assessing each customer’s specific business goals before recommending a technology mix. As multi-cloud architectures became the norm for large organisations, this advisory-first posture gave Rackspace a clear story to tell at the C-suite level.

Delivering 24/7 “Fanatical” Customer Support

Rackspace built its reputation around what it internally called “Fanatical Support” — a 24/7/365 customer service model with no exceptions. Key elements of this model include:

• Guaranteed response time: The company claimed a maximum 15-minute response window for customer requests, with prioritisation based on urgency.
• Incident handling: Critical incidents such as network disruptions or suspected security breaches were treated as high-priority escalations, with the goal of near-immediate remediation.
• Business continuity focus: The model was designed explicitly to minimise disruption to customers’ day-to-day operations, reflecting an understanding that downtime has direct revenue impact.

This level of support commitment requires significant investment in staffing and tooling, and it remained a core brand pillar that Rackspace used to differentiate from hyperscale cloud providers, who typically offer tiered, self-service support at lower spend levels.

Evolving to Serve Enterprise and Midmarket Segments

By 2018, Rackspace was deliberately shifting its focus upmarket toward enterprise and midmarket customers — segments that were increasingly looking for a trusted managed services partner rather than commodity infrastructure. Several factors drove this evolution:

• Acquisitions: The acquisition of Tricore (described in the interview as occurring “last summer,” relative to the 2018 publication date) expanded Rackspace’s capabilities in enterprise application management — a high-demand capability for large organisations running complex ERP and CRM workloads.
• Security depth: Growing customer concern about cloud security pushed Rackspace to continuously invest in its security offerings, aiming to stay at the leading edge of industry best practice.
• Professional services growth: The professional services division was reportedly growing at a triple-digit rate at the time, with the company receiving approximately 50 new proposal submissions per week — driving aggressive recruitment efforts in that area.

Automation and Machine Learning on the Roadmap

Looking ahead (from the perspective of 2018), the executive identified automation and machine learning as the two capability areas most critical to improving both service consistency and customer outcomes. The strategic intent was to use these technologies to enhance support operations and reduce manual intervention in routine infrastructure management tasks.

Alongside organic investment, Rackspace indicated openness to further acquisitions — particularly in global expansion and application management — to accelerate capability development.

Brand Transformation: From Hosting Provider to Strategic Partner

A significant part of the executive’s stated agenda was repositioning the Rackspace brand away from its legacy identity as a managed hosting provider toward a full-service cloud and professional services firm. The tactics described included:

• Thought leadership content aimed at C-suite decision-makers undergoing digital transformation
• Presence at industry events with hands-on expert engagement
• Customer story amplification to demonstrate real-world outcomes
• Peer-to-peer engagement programmes to build community around customer success

The underlying message was that digital transformation is no longer optional for any business — and that Rackspace wanted to be the first name that came to mind when leadership teams began that journey.

What Enterprises Can Learn from Startups

Drawing on experience mentoring startups at Capital Factory (an Austin-based accelerator), the executive identified a core cultural gap between large enterprises and high-growth startups: the sense of urgency.

Startups operate in a sink-or-swim environment that forces rapid iteration, risk-taking, and real-time decision-making. Large enterprises, by contrast, tend toward process-heavy cultures that reward caution over speed. The recommendation was for enterprises to deliberately cultivate reward structures that incentivise calculated risk and recognise individuals who drive meaningful change — effectively importing startup agility into a larger organisational context.

This cultural dimension is increasingly relevant in DevOps and cloud-native contexts, where the speed of infrastructure change and the ability to fail fast and recover quickly are competitive advantages in their own right.

Key Takeaways for DevOps and Cloud Teams

• Vendor-neutral advisory matters: When evaluating managed cloud partners, look for providers that can support multiple cloud platforms rather than steering you toward a single vendor for commercial reasons.
• Support SLAs deserve scrutiny: A claimed 15-minute response time is a meaningful benchmark — validate it contractually and ask for evidence of adherence before signing.
• Professional services growth signals demand: The rapid growth of Rackspace’s professional services arm reflected a broader market shift away from DIY cloud toward managed and consulting-led engagements — a trend that has continued well beyond 2018.
• Startup culture principles are portable: Agile ways of working, reward structures tied to experimentation, and a bias toward action can be deliberately introduced into enterprise engineering cultures regardless of company size.

Source: Original interview published by TechRadar, August 2018.

Key Differences at a Glance

The following five dimensions are the most useful for comparing PaaS and serverless platforms when selecting a cloud app development environment.

1. Basic Computing Unit

With PaaS, the fundamental unit of compute is the application. You still provision instances (sometimes called dynos, containers, or cells, depending on the platform), but the platform handles patching, scaling infrastructure, and runtime maintenance. With serverless platforms like AWS Lambda, the fundamental unit is a function or task. The underlying compute instances exist, but they are completely invisible to the developer — you deploy a function, not an app.

2. Task Duration

PaaS is well suited to long-running applications — web servers, background workers, and persistent services that need to be continuously available, even when not actively processing requests. Serverless is designed for short-lived, event-driven tasks that have a clear start and end point, such as processing an uploaded file, responding to a webhook, or transforming a stream record. AWS Lambda, for example, enforces a maximum execution timeout per invocation.

3. Required Metadata and Configuration

When deploying to a PaaS, you typically need to specify the language runtime, framework, buildpack or container configuration, and resource requirements. This gives you more control but also means more upfront configuration. With serverless platforms, the required metadata is minimal. For AWS Lambda, you primarily specify an IAM execution role, the memory allocation, and a timeout value. This makes serverless faster to get started with, though it trades away some configurability.

4. Public Access and API Exposure

PaaS applications are typically exposed via a public HTTP endpoint or REST API by default — users and clients reach your app directly over the internet. AWS Lambda functions, by contrast, are not publicly accessible on their own; they are invoked from trusted internal sources such as other AWS services, event triggers, or an API Gateway sitting in front of them. Direct public internet access requires additional configuration (for example, attaching an API Gateway or an Application Load Balancer).

5. Pricing Model

With PaaS, you pay for the provisioned compute resources — instances or containers — whether or not they are actively handling traffic. This provides cost predictability for steady workloads. With serverless, you pay only for the actual executions: the number of function invocations and the compute time consumed during each invocation. For applications with spiky, unpredictable, or infrequent workloads, serverless pricing can result in significant cost savings.

Side-by-Side Comparison

When to Choose PaaS

• Your application needs to be continuously running (web servers, APIs with consistent traffic, long-lived background workers).
• You want some degree of control over the runtime environment, framework versions, or resource allocation.
• Your workload is predictable and you prefer a consistent, forecastable monthly spend.
• Your team is more comfortable with a traditional application deployment model.

When to Choose Serverless

• Your workload is event-driven, bursty, or highly variable — for example, processing uploads, responding to webhooks, or running scheduled jobs.
• You want to pay only for actual compute consumption rather than idle capacity.
• You want to minimise operational overhead and delegate all infrastructure management to the cloud provider.
• Individual tasks complete quickly and do not require persistent state between invocations.

Conclusion

PaaS and serverless platforms both remove the burden of managing physical or virtual servers, but they serve different use cases. Choose PaaS when you are running long-lived applications, need more infrastructure control, or prefer predictable costs. Choose serverless when your workload is short-lived and event-driven, you want to optimise for cost at low or variable traffic volumes, and you prefer a completely hands-off infrastructure experience. In practice, many production architectures use both: PaaS for the core application tier and serverless for auxiliary event-driven tasks.

Source: Originally based on an article from TechTarget (techtarget.com).

What Is Cloud Spanner?

Google launched the public beta of Cloud Spanner in February 2017, making the service available on Google Cloud Platform (GCP) to help cloud customers maintain consistent, distributed databases across multiple data centers. Cloud Spanner joined Google’s existing managed database portfolio alongside Cloud SQL, Cloud Datastore, and Cloud Bigtable.

The core promise of Cloud Spanner is that it eliminates a long-standing trade-off in distributed systems design: the forced choice between relational databases that provide strong transactional consistency and NoSQL databases that offer simple horizontal scaling and data distribution. Cloud Spanner aims to deliver both in a single, fully managed service.

“When building cloud applications, database administrators and developers have been forced to choose between traditional databases that guarantee transactional consistency, or NoSQL databases that offer simple, horizontal scaling and data distribution. Cloud Spanner breaks that dichotomy, offering both of these critical capabilities in a single, fully managed service.”

— Deepti Srivastava, Google Product Manager for Cloud Spanner

The Technology Behind Cloud Spanner: TrueTime

One of Cloud Spanner’s most distinctive engineering features is its use of TrueTime, Google’s proprietary time synchronization technology. TrueTime relies on atomic clocks and GPS receivers to supply highly accurate time readings to master servers in each data center. These servers exchange readings and negotiate a common reference time, which solves the clock skew and time coordination problems that typically prevent region-spanning databases from maintaining strong consistency.

Traditional distributed databases struggle with time coordination because network latency and imprecise system clocks make it difficult to establish a strict global ordering of transactions. TrueTime addresses this by bounding clock uncertainty, allowing Cloud Spanner to assign globally consistent timestamps to transactions and enforce external consistency without locking across regions.

Proven at Google Scale Before Public Launch

Although the public beta only launched in February 2017, Google stated it had already been running Spanner internally for several years, testing it with hundreds of applications and petabytes of data spread across data centers around the world. At the time of the announcement, Google reported that internal Spanner deployments supported tens of millions of queries per second and underpinned critical services including AdWords and Google Play.

Pricing Model

Cloud Spanner pricing at public beta launch was structured around three dimensions:

• Compute node-hours — billed per provisioned node per hour
• Storage consumption — charged for the total data stored
• External network egress — charged for data transferred out of the service

Key Capabilities and Benefits

Google highlighted the following capabilities for Cloud Spanner at the time of the public beta launch:

• Strong transactional consistency across regions — eliminates eventual-consistency caveats common in distributed NoSQL stores
• Horizontal scaling without migrating to a non-relational data model — teams can scale out while retaining SQL semantics
• Fully managed infrastructure — reduces operational overhead for hardware and software management, allowing engineering effort to focus on application logic
• High availability and disaster protection — data is replicated across multiple zones and regions
• Integrated security — includes data-at-rest encryption, Identity and Access Management (IAM) controls, and audit logging
• Multi-language client libraries — available at launch for Java, Go, Python, and Node.js, among others

Target Use Cases

Google positioned Cloud Spanner as an appropriate fit for organizations running MySQL or PostgreSQL deployments that were hitting the limits of vertical scaling and traditional replication strategies. Specific verticals and workload types highlighted at launch included:

• Global web services requiring consistent reads and writes across geographic regions
• Financial services where transactional integrity is non-negotiable
• Retail, manufacturing, and wholesale distribution — JDA (now Blue Yonder), a supply chain software vendor, was cited as an early customer, noting Cloud Spanner’s ease of provisioning and scalability for omni-channel supply chain solutions

Competitive Context

The launch of Cloud Spanner was widely interpreted as a significant move in Google Cloud’s effort to compete with Amazon Web Services and Microsoft Azure in the enterprise and hyperscale database market. By offering a managed service combining relational consistency with NoSQL-style horizontal scale, Google provided a differentiated option that neither AWS nor Azure matched directly at the time of launch. AWS Aurora and Azure SQL Database offered managed relational databases, but neither used a comparable globally-distributed, externally-consistent architecture at that point.

Summary

Cloud Spanner’s public beta represented a notable moment in managed database history: a production-proven, globally distributed relational database — previously available only inside Google — becoming accessible to external developers and enterprises. Its TrueTime-based architecture, strong consistency guarantees, and fully managed operations addressed pain points that had historically forced engineering teams to choose between scalability and consistency.

For teams evaluating large-scale relational workloads on Google Cloud Platform, Cloud Spanner remains a key service to consider, particularly where geographic distribution and strong consistency are both required.