T-Systems has expanded its collaboration with Deutsche Telekom’s T-Systems to accelerate cloud migrations for T-Systems’ customers.

At AWS re:Invent 2020, the companies announced a multi-year strategic collaboration agreement to enable faster cloud migrations of applications, compute and storing solutions, and security for T-Systems’ cloud solutions. T-Systems broadened its relationship with AWS to better manage the digital transformations of its customers at a faster and more efficent rate.

The Covid-19 pandemic has accelerated businesses’ digital transformations as they move more workloads and applications, such as Microsoft 365, SAP and Salesforce, to the cloud.

RELATED: Deutsche Telekom takes back some of T-Systems’ operations as part of re-org

Frankfurt, Germany-based T-Systems was founded in 2000 as a subsidiary of Deutsche Telekom. Last year, Deutsche Telecom took back responsibility for corporate telecom clients as part of a restructuring plan for T-Systems. The revamped T-Systems focuses on IT and digital services.

RELATED: Google Cloud and T-Systems team up on managed services for businesses

T-Systems, which has also worked with Microsoft Azure and Google Cloud, is also supporting Deutsche Telekom by migrating an increasing amount of its internal IT workloads to the cloud. AWS is one of the preferred cloud providers for those migrations.

T-Systems is also the service provider for several business units within Deutsche Telekom, and has delivered migrations and managed cloud services to those units, including network and security solutions on AWS.

“Since the beginning of our relationship with AWS, we have built up expertise in AWS technology and combined it with our extensive experience from major transformation projects. Our customers appreciate this,” said Adel Al-Saleh, member of the Deutsche Telekom Board of Management and CEO T-Systems, in a statement.

T-Systems’ customers can benefit from its ability to migrate automated applications on a large scale due to its own expertise for developing cloud-native applications. T-Systems has bundled its entire cloud expertise into its Cloud Migration Framework, which includes migrating and managing multi-cloud systems.

T-Systems has roughly 2,200 cloud architects and an additional 1,000 AWS experts. The collaboration agreement supports T-Systems’ plan to build out its capacity in both solutions and people through a training and enablement program. The ICT service provider plans to train 3,000 additional AWS experts as part of the new collaboration.

T-Systems won the AWS Partner Network (APN) Consulting Partner of the year award in the DACH region this year.

Background: Microsoft Acquires LinkedIn

Microsoft acquired LinkedIn for approximately $26.2 billion in 2016 — one of the largest technology acquisitions in history at the time. In the years that followed, LinkedIn continued to operate with a significant degree of independence, maintaining its own engineering culture, data center infrastructure, and open-source initiatives. That arrangement eventually gave way to a major strategic shift: a full migration of LinkedIn’s workloads to Microsoft Azure.

The Decision to Move to Azure

LinkedIn’s senior VP of engineering, Mohak Shroff, announced the migration in a blog post, framing it as a response to the platform’s continued growth rather than a directive from Microsoft’s parent organization.

“Today’s technology landscape makes the need for constant reinvention paramount, especially as we look to scale our infrastructure to drive the next stage of LinkedIn’s growth. With the incredible member and business growth we’re seeing, we’ve decided to begin a multi-year migration of all LinkedIn workloads to the public cloud.”

Mohak Shroff, Senior VP of Engineering, LinkedIn

That public cloud is Azure. Shroff noted that LinkedIn had already been selectively using Azure before the full migration announcement, applying it to specific use cases such as accelerating video post-delivery, improving machine translation in the Feed, and detecting and removing inappropriate content.

On why Azure was the right choice, Shroff said: “Moving to Azure will give us access to a wide array of hardware and software innovations, and unprecedented global scale. This will position us to focus on areas where we can deliver unique value to our members and customers.”

What Happens to LinkedIn’s Data Centers?

At the time of the announcement, LinkedIn operated a corporate-owned data center in California and four leased colocation facilities in Texas, Virginia, Oregon, and Singapore. Shroff acknowledged in an interview with VentureBeat that the fate of those facilities was not yet determined:

“The exact end state for those data centers is unclear. In some cases, we will vacate them. In some cases, we may find new uses for those data centers. All of our activities that currently happen in our own native data centers will migrate into the Azure public cloud.”

Mohak Shroff, VentureBeat interview

Shroff also pushed back on the notion that the Azure migration was predetermined by the Microsoft acquisition, stating that LinkedIn’s engineering teams retained decision-making independence throughout the integration period and that the move to Azure was ultimately their own choice.

However, it is worth noting that Microsoft’s original investor slides from the 2016 acquisition did explicitly highlight that LinkedIn would benefit from “access to Microsoft’s scaled cloud infrastructure and technology stack” — suggesting the Azure migration was at least anticipated, even if not formally mandated.

LinkedIn’s Open Hardware Legacy: The Open19 Foundation

One of the more significant open questions raised by the Azure migration concerns LinkedIn’s long-standing investment in open hardware standards — particularly through the Open19 Foundation, which LinkedIn co-founded in 2016.

Open19 was created to accelerate innovation and standardization around the 19-inch server rack form factor, a specification that is ubiquitous in enterprise and colocation environments. LinkedIn was consistently the Foundation’s most active contributor and advocate.

Open19 vs. Open Compute Project (OCP)

Open19 is distinct from the Open Compute Project (OCP), which was originally backed by Facebook and initially focused on a less common 21-inch rack specification. Over time, the two groups moved closer together:

• In 2018, LinkedIn became a Platinum member of OCP.
• In 2019, LinkedIn announced that its Open19 technology specifications would be contributed to OCP.
• Despite the closer relationship, the Open19 Foundation remained legally and operationally independent from OCP.

LinkedIn’s head of infrastructure engineering, Zaid Ali Kahn, described the OCP contribution as an opportunity to share engineering learnings and find convergence opportunities between the two communities.

Open19’s Edge Push and Broader Adoption

Around the same time as the Azure migration announcement, Open19 was actively expanding its scope to include edge computing deployments. Yuval Bachar, Open19 Foundation president and LinkedIn’s principal engineer of global data center infrastructure architecture, indicated at the Foundation’s May 2019 summit that two major data center operators were evaluating Open19 technology — a significant milestone for the initiative.

Whether Azure would adopt Open19 hardware at scale remained an open question. Microsoft is not a member of the Open19 Foundation, though it has been a Platinum member of OCP since 2014.

Microsoft’s Own Open Hardware Contributions: Project Olympus

Microsoft has a substantial history with open hardware through OCP. In 2016, the company disclosed that approximately 90 percent of servers it procured were based on OCP-contributed specifications. That same year, at a Data Center Dynamics event in London, Microsoft unveiled Project Olympus — a hyperscale server hardware blueprint developed in collaboration with the OCP community.

Project Olympus was notable for being released at an earlier-than-usual design stage, allowing the open source community to participate in shaping the hardware before it was finalized. The project was later contributed to the Open19 initiative as well, with LinkedIn’s Kahn noting: “The combination of Open19 and Project Olympus allows data centers of any scale to enjoy high efficiency and advanced open standards with their existing EIA19 racks.”

Key Takeaways for DevOps and Infrastructure Engineers

• Large-scale migrations take years: Even a well-resourced organization like LinkedIn committed to a multi-year timeline, reflecting the complexity of migrating custom-built, on-premises infrastructure to public cloud.
• Hybrid use before full migration: LinkedIn used Azure selectively for specific high-value workloads before committing to a full migration — a practical pattern for de-risking large cloud transitions.
• Open hardware contributions don’t automatically follow ownership: LinkedIn’s significant investment in Open19 does not guarantee that Azure will adopt those same hardware standards at scale, highlighting the risk of tying organizational open-source contributions to infrastructure decisions.
• Acquisition goals and operational independence can coexist — up to a point: LinkedIn maintained engineering autonomy for several years post-acquisition, but eventually aligned its infrastructure strategy with its parent company’s cloud platform.

But maintaining multiple cloud platforms simultaneously adds real complexity to IT environments already crowded with diverse technologies, applications, and processes. While enterprises are increasing investment in multi-cloud for business-critical workloads, a significant share of those same organizations report experiencing operational and deployment issues along the way.

The core difficulties cluster around three recurring problems: underestimating the need for cultural transformation, failing to close the skills gap, and attempting a DIY approach to cloud management without the right tooling. Addressing each of these deliberately is what separates a multi-cloud strategy that delivers value from one that quietly collapses under its own weight.

1. Make Culture Change a Priority

Cultural transformation in a multi-cloud context goes well beyond shifting the budget conversation from capital expenditure to operational expenditure, or simply selecting a cloud vendor and announcing a strategy. It requires dismantling the knowledge silos that naturally form across disparate IT teams—teams that may have deep expertise in specific vendors, legacy systems, or emerging technologies, but rarely share that knowledge across boundaries.

Achieving faster application development and shorter time-to-market depends on building trust between those teams. Concretely, this means equipping central IT with modern processes and management platforms that prioritize visibility and resource governance, while simultaneously giving developers fast, reliable access to the compute, storage, and networking resources they need. Governance and developer velocity are not opposites—a well-designed culture treats them as complementary.

Cultural maturity in a multi-cloud environment also accelerates DevOps practices in specific ways:

• Eliminating workflow bottlenecks through better process definitions and automation
• Advancing self-service provisioning so teams are not blocked waiting for infrastructure tickets
• Consolidating resources to reduce sprawl and redundant spend
• Integrating security into development from the start, rather than treating it as a gate at the end of a release cycle

Without deliberate culture work, even a technically sound multi-cloud architecture will be hampered by inter-team friction and slow decision-making.

2. Invest in Multi-Cloud Expertise and Emerging Technology Skills

The more cloud environments an organization operates, the greater the demand for specialized skills. Cloud platforms have commoditized many baseline capabilities, but meaningful differences still exist between providers in areas such as managed services, pricing models, compliance tooling, networking constructs, and geographic availability. Exploiting those differences to align workloads with the platform best suited to them requires people who understand the nuances.

Key skill areas to build or hire for in a multi-cloud context include:

• Containerization and orchestration — Kubernetes has become the dominant orchestration layer for multi-cloud workload portability, making expertise here foundational.
• Microservices architecture — Decomposing applications into independently deployable services is what makes it practical to run different components on different clouds.
• Serverless computing — Understanding the trade-offs of serverless offerings across providers (AWS Lambda, Azure Functions, Google Cloud Functions) allows teams to select the right execution model per workload.
• Infrastructure as Code (IaC) — Tools such as Terraform and Pulumi enable consistent, repeatable provisioning across cloud environments, reducing manual configuration drift.
• Cloud cost management — Tagging strategies, reserved instance planning, and rightsizing analysis all require dedicated attention as multi-cloud environments scale.

Investing in a cloud management platform that supports self-service provisioning also pays dividends here: it frees both administrators and end users from repetitive low-value tasks, giving skilled engineers more time for higher-order work.

3. Select the Right Cloud Management Platform

A cloud management platform (CMP) addresses the inherent complexity of hybrid and multi-cloud environments by providing a centralized control point. Rather than having separate teams log into separate provider consoles to provision and manage resources, a CMP creates a consistent operational layer that spans environments.

Key capabilities to evaluate when selecting a CMP:

• Broad connectivity — The platform should connect to public cloud providers (AWS, Azure, GCP), private infrastructure (VMware, on-premises bare metal), and container orchestrators such as Kubernetes from a single interface.
• Unified inventory and provisioning — Administrators should be able to discover existing resources and provision new ones across all connected environments without switching tools.
• Self-service catalog — Enabling developers and end users to request pre-approved resources on demand reduces IT queue depth and accelerates delivery.
• Single pane of glass visibility — A consolidated view of resource utilization, health, and cost across all environments is essential for proactive governance and spend optimization.
• Legacy and modern technology support — Enterprises rarely operate in a greenfield environment. The CMP must bridge existing on-premises systems with modern cloud-native services without requiring a full migration first.

The goal is to abstract complexity away from the people who consume IT resources—developers, data engineers, business analysts—while giving the IT and platform teams the visibility and control they need to manage it responsibly. Complexity does not disappear; it gets managed in the right place, by the right people, using the right tooling.

Putting It Together

A multi-cloud strategy that succeeds in the long run treats culture, skills, and tooling as mutually reinforcing investments rather than independent check-boxes. Culture change enables the collaboration that makes cross-cloud operations possible. Skills investment ensures the organization can actually exploit the capabilities each platform offers. And the right management platform ensures that the operational complexity of running multiple clouds is contained and controlled, rather than distributed across the organization as a source of daily friction.

Enterprises that approach multi-cloud with this three-part discipline are far better positioned to deliver on the original promise—agility, performance, and cost efficiency—without inadvertently creating more problems than they solve.

Why Kubernetes Has Become Central to Multi-Cloud Strategy

Kubernetes has moved well beyond experimental status. IT leaders across industries are deploying it in mainstream production environments, using it to bridge on-premises infrastructure with public cloud platforms. A significant driver of this adoption is that major cloud providers — AWS (Amazon EKS), Microsoft Azure (AKS), and Google Cloud (GKE) — have all embraced Kubernetes and offer it as a managed service. This lowers the barrier to entry, allowing teams to experiment incrementally and scale consumption on a pay-as-you-go basis.

The result is a growing ecosystem of tooling, community knowledge, and integrations that continues to accelerate enterprise digitalization. But with opportunity comes complexity. As Kubernetes use cases expand, three considerations stand out for teams operating in multi-cloud environments.

1. Evolving IT and Developer Roles Demand a New Operating Model

The shift to multi-cloud and multi-cluster Kubernetes environments has fundamentally changed what IT operations teams manage. Applications are increasingly decomposed into microservices and packaged as containers — but not all workloads are ready for containerization at the same pace. This means IT teams often manage hybrid environments where containerized and non-containerized workloads coexist, sometimes across multiple clusters and clouds simultaneously.

For application developers, Kubernetes introduces genuine workload portability. Because it operates as a consistent abstraction layer across public and private cloud infrastructure, developers can target Kubernetes APIs regardless of the underlying provider. Combined with a large open-source community, rich documentation, and widely available tutorials, this portability increases developer velocity and reduces friction when moving workloads between environments.

The practical implication: both operators and developers need to upskill. Platform engineers need to understand multi-cluster networking, policy management, and federated workload scheduling. Developers need enough operational awareness to write applications that take advantage of Kubernetes primitives — health checks, resource limits, rolling deployments, and service discovery — from the start.

2. The Network Security Surface Area Is Expanding

Running containers in production — especially on bare metal — pushes the boundaries of what traditional networking and security tooling was designed to handle. Container workloads are ephemeral, horizontally scaled, and communicate extensively over internal service meshes. Each microservice boundary is a potential attack surface, and in large deployments those surfaces multiply rapidly.

Kubernetes is designed for continuous delivery, zero-downtime deployments, and high availability. These are valuable operational properties, but they also mean the environment is in constant flux — pods spin up and down, IP addresses change, and network policies need to reflect the current state of the cluster at all times. Static, perimeter-based security models are inadequate in this context.

Security teams working with Kubernetes environments should focus on several layers:

• Pod security: Use Pod Security Admission (or equivalent policies) to restrict what containers can do at runtime.
• Network policies: Define explicit ingress and egress rules between namespaces and services using Kubernetes NetworkPolicy resources or a CNI plugin that supports fine-grained policy (e.g., Calico, Cilium).
• Image security: Scan container images for known CVEs before they reach production. Implement admission controllers to block non-compliant images.
• Secrets management: Avoid storing secrets in environment variables or ConfigMaps. Use a dedicated secrets manager and integrate it with the cluster via a CSI driver or sidecar.
• Audit logging: Enable Kubernetes API audit logs and ship them to a central SIEM for anomaly detection.

As microservice architectures grow, mutual TLS (mTLS) between services — often implemented via a service mesh such as Istio or Linkerd — becomes an important defense-in-depth measure, encrypting and authenticating east-west traffic inside the cluster.

3. DevOps Adoption Is Accelerating — and Kubernetes Is a Catalyst

DevOps aims to unify application development and operations across the full software lifecycle: planning, coding, building, testing, releasing, deploying, operating, and monitoring. Kubernetes contributes directly to this goal by providing a common substrate that both developers and operators can target, removing the “it works on my machine” problem at the infrastructure level.

Practically, this means developers can use the same Kubernetes manifests or Helm charts across local development environments, CI pipelines, staging clusters, and production — reducing environment drift and accelerating release cycles. Operators, in turn, gain standardized interfaces for observability, scaling, and rollback rather than managing bespoke deployment scripts per application.

The growing Kubernetes ecosystem reinforces this collaboration. Tools like Argo CD and Flux bring GitOps workflows to cluster management. Prometheus and Grafana provide a consistent monitoring stack. Tekton and other Kubernetes-native CI systems let teams define pipelines as code in the same repositories as their applications. This convergence gives DevOps teams a coherent, auditable, and repeatable delivery pipeline from code commit to production.

Looking Ahead: Kubernetes as Enterprise Infrastructure

Kubernetes is no longer a cutting-edge experiment — for many enterprises it is foundational infrastructure. As adoption matures, the ecosystem of tools, managed services, and community knowledge will continue to expand, making it easier for organizations at every stage of the journey to adopt and operate it effectively.

For IT leaders planning their multi-cloud strategies, the three considerations above are not one-time checkboxes. They require ongoing attention as cluster scale grows, as new workloads are onboarded, and as the threat landscape evolves. Organizations that invest in the operational discipline to manage Kubernetes well — across roles, security, and DevOps culture — will be better positioned to deliver software faster and more reliably across both private and public cloud environments.