There is no Shift Left without Platform Engineering

0
5


Luca Piezzo, IT Operations Lead, Bank ABC

Recently, all major companies in the cybersecurity field have been developing their products, more specifically CNAPP solutions, using a Shift Left paradigm. This approach aims to reduce vulnerabilities and overall risk exposure by identifying issues during the development and build stages. The goal is to prevent developers from using Docker images, runtime versions, and libraries affected by known vulnerabilities (CVEs), blocking the build if such components are present and recommending remediations or alternatives.

Shifting responsibilities to the left, meaning relying on developers to address topics such as vulnerability management, release management, and sometimes even IT operations, is not a new trend. Over the past decade, many of the most impactful technologies have shared this same goal: empowering developers to unlock their potential without being slowed down by the infrastructure team, which is often seen as slow-paced or resistant to innovation.

Why is that? Mainly because the two teams have different objectives: developers aim to release features as quickly as possible, while system administrators focus on increasing system reliability. These priorities can be at odds, since every release may affect reliability.

If the industry is shifting more responsibility to developers, how should sysadmins support this transition? Should they fear losing their jobs as much as developers fear AI?

I’m not in a position to make those kinds of predictions. What I can say is that sysadmins should start viewing IT infrastructure for what it has become, an ultra-commoditized set of services. Regardless of the underlying technologies such as Kubernetes or virtual machines, the core objective of the IT infrastructure team, including network administrators, system administrators, and database administrators, is to set guardrails for infrastructure services, defining how developers are meant to consume them through templates, playbooks, predefined pipelines, and similar mechanisms.

This is the essence of platform engineering. While often associated with Kubernetes or other container-based services, understandably, since these paradigms are often pioneered by tech giants with highly paid developers raising the global bar, the same principles apply to large, traditional organizations such as banks, insurers, and retailers. However, adoption in these environments is not as easy due to several factors:

• Technical debt: Many legacy applications still rely on technologies such as mainframes, Solaris, AIX, and AS/400, which are not well-suited to these paradigms. Modernizing them is far from simple.

• COTS: Many core applications are commercial off-the-shelf products. They cannot be containerized or automated due to their architecture or licensing constraints.

• Operating model: Large enterprises often compare themselves to tech giants that follow a product-based operating model with fewer silos. But the two are not directly comparable— tech giants are young, whereas traditional enterprises have been operating for decades or centuries, making transformation more complex.

Moreover, container-based application adoption is still not widespread. This shouldn’t be a problem as long as the principles above are also applied to “traditional” VM-based datacenters, whether cloud-based or on-premises.

Immutable infrastructures, along with Environment-as-Code (EaC) and configuration management, enable sysadmins to delegate the consumption of basic infrastructure services, such as networks, load balancers, virtual machines, storage, and databases, to developers in a controlled, programmatic way. This allows developers to automate provisioning without direct sysadmin intervention.

From a security standpoint, this is the only way to truly empower developers, shifting to them all security-related responsibilities, including those traditionally handled by sysadmins such as operating systems, middleware, and databases.

In conclusion—can we really implement Shift Left without all of this? The answer is no. How can we shift left if accountability is still scattered among siloed teams? We can’t.

As always, the key to enabling this transformation is not just implementing “fancy” tools, it’s driving a cultural shift that aligns two worlds with different objectives, working together toward business agility.