The 3 paradoxes of cloud native platform engineering

BrainBlog for Chronosphere by Jason Bloomberg

Platform engineering, developer productivity, and cloud native architectures benefit organizations, but requires a strategy to achieve success in each area.

Balancing software and business goals

Cloud native computing has come to dominate enterprise IT for every organization that requires dynamic, flexible infrastructure at scale.

Kubernetes and the rest of the cloud native ecosystem Kubernetes enable companies to build and deploy applications faster, more reliably and at a lower cost but can be complex and difficult to master. The promises of speed and scale may seem out of reach when development teams get caught up in the details. To build such software, developers require all the help they can get.

DevOps practices and tools are essential but are merely the starting point. To succeed with DevOps in cloud native environments, organizations hope to build out internal developer platforms (IDPs) following still-nascent platform engineering best practices.

The goal of platform engineering is to improve developer productivity. And if development teams are productive, then they should be able to deploy software at the velocity and scale that the business requires.

Even with IDPs in place, however, the goals of cloud native development set a high bar for the organizations that seek its benefits. For every step forward, they seem to take one step back.

An excessive focus on developer productivity can backfire. Platform engineering can counterintuitively drive developers away. And the more complex cloud native deployments become, the more difficult they are to manage.

This article – the first of a series of three – will explore these paradoxes. How can organizations achieve the business goals for their software efforts when so many pitfalls threaten their success?

Click here to read the entire article.

SHARE THIS: