Platform Engineering - Nutanix: DevOps evolved with centralised control & decentralised delight
This is a guest post for the Computer Weekly Developer Network written by James Sturrock in his role as director of systems engineering for hybrid multi-cloud computing company Nutanix.
Stressing the importance of understanding where platform engineering now comes as an extension, augmentation and evolution of some of what DevOps has always represented (but in reality now, with self-service functionalities through Internal Developer Portals and so much more), Sturrock says that we need to consider this welcome progression across the technology industry as an enabler and facilitator for more effectively delivered and managed hybrid multi-cloud computing environments.
Sturrock writes as follows…
Much of the discussion surrounding DevOps “versus” platform engineering (if there really is that level of antagonism) comes down to this proposition: that the (once considered radical) notion of the DevOps model is somehow at odds with the cloud-native container management model and where it intersects with platform engineering.
A brief history of DevOps
If we look back and indulge ourselves with a brief history of DevOps, the movement and methodology (don’t write in, we know DevOps is a workplace cultural practice) came about because outdated centralised platform technologies – such Java Enterprise Edition (EE) – no longer performed for software engineering teams who needed to use newer languages and development frameworks.
Those new languages might (for example) have been “new” programming languages like PHP and Ruby… and perhaps now Python as well. The issue was that teams weren’t able to run those applications on Java EE. This was of course at odds with the “you build it, you run it” mentality that is the foundation of DevOps. It was also at odds with the “write once, run anywhere” mantra of Java itself… but let’s move on.
The original objectives behind DevOps were the quest for shorter software application development cycles, increased agility and faster processes overall by virtue of automation and the ability to remove the “wall” that developers would toss their application over to the operations team.
The emergence of container orchestration platforms turned this shared ownership model upside down.
Destabilising the decentralisation decree
As we know, DevOps promotes decentralisation, while container orchestration platforms were designed to be centrally managed for maximum benefit. Container orchestration platforms have meticulously designed application programming interfaces (APIs) that separate the concerns of developers and operators.
The idea behind container orchestration platforms was to build a solution that would allow a central team to provide a level of security and resilience that would “abstract away” the complexity of the infrastructure beneath enterprise applications. Software application developers are then able to focus on functionality and improvements without worrying about the backend so much.
Once again, here we get to a point that (in theory and on paper at least) is at odds with DevOps.
Why DevOps needs more
We know why platform engineering came about. It came about because DevOps teams couldn’t keep up with the workload required to manage a cloud-native platform securely. Let’s face it, we know how complex Kubernetes is; production-grade Kubernetes-based platforms require many add-ons to cover functionality such as security, observability, service mesh, applications and more – so it’s obviously way more complex.
When every DevOps team comes up with their own way to deploy and manage infrastructure (and has to essentially reinvent the wheel) a natural lack of consistency and standardisation occurs, which is expensive in terms of skills needed and wasted resources. In those environments, cloud-native projects often end up stalling or failing, especially where they have to wrangle multicloud, hybrid and edge environments.
This reality is exacerbated even further by the spectre of complex workloads such as AI and machine learning.
Centralised control & decentralised delight
As a means of handling the challenges presented today, using platform engineering effectively means some processes need to be centralised, while others need to be decentralised.
When we look at cluster lifecycle management, we don’t need 10 ways to bring up a cluster. This needs centralisation to one single way because it makes adding new infrastructure providers (like another cloud service) much easier. Security is also delivered more efficiently when it is centralised in platform engineering, because shared services – like databases and other core service and infrastructure elements – can be provided in one unified channel.
Governance and policy management can also be centralised via platform engineering, as can observability (for an Ops team’s “god view” of all environments) and cost management is also boosted.
Decentralised processes in platform engineering include choice of programming language, choice of development framework and any other core element of instance, code or logic that comes in a container.
As we have said before at Nutanix, platform engineering provides the “best of both worlds” by giving DevOps teams a centralised platform approach and decentralised DevOps. A Kubernetes API and container-based approach provide a strong interface that opens the way to managing a more intelligent division of labour and enables both sides to focus on what they do best.
