Technology works in circles. We seem to have come full circle in the constantly changing field of information technology regarding several crucial facets of how systems are developed and supplied. We began with mainframes and networked systems, then transitioned to users with independent PC power.
With the advent of client-server architectures, we then brought personal computers back into the network before loosening the shackles somewhat with the growth of web-based corporate applications. Fair enough, both of those phases are still in effect, however if we consider where platform engineering is headed next, we may see some cyclicality.
Platform engineering involves interacting with the underpinnings of systems, applications, and services. We are thus focusing on activities that entail and include serverless computing, automated provisioning, programmable infrastructures, Infrastructure-as-Code (IaC), and more in order to modify the functionality of base layer technologies.
We now discuss platform engineering as a method of working on the backend first to produce front-end change, but we used to assume cloud computing was enough of a foundation substrate layer to let us concentrate on front-end user interfaces and experiences in isolation.
Platform engineering is one of the most popular topics in IT, yet there is still some misunderstanding about what it entails. Even so, some detractors believe that platform engineering is merely a trendy phrase that means nothing new and is used to describe anything.
This skepticism is reasonable, asserts David Sandilands, senior solutions architect at Puppet by Perforce, a provider of software configuration management services that is now known by the parent brand Perforce as a private business software solution with origins in open source.
Puppet's Sandilands claims that he has personally heard several accounts where a collection of different (disconnected) outdated technology has been huddled together, managed, and marketed as "platform engineering" by a single technical team. In order to get on the trend, some manufacturers are labeling things that are obviously not platform engineering but are nonetheless claiming to be.
Platform engineering, on the other hand, is a distinct strategy that, contrary to popular belief, is well-defined and provides firms with significant advantages, according to Sandilands. For instance, the most recent State of DevOps Study revealed that 94% of respondents who had implemented platform engineering agreed that it was assisting their companies in better realizing the advantages of DevOps. Although setting up platform engineering internally requires time, money, and effort, the rewards — including cost savings, faster speed of delivery, increased system stability, productivity gains, and higher workflow standards — far exceed all the trouble (when done well).
The Puppet team explains that they have platform engineering expertise from both ends of the spectrum, i.e., with clients and inside its own IT stack and set of services.
Sandilands provides a more thorough explanation of how this method of building technological infrastructure functions and offers an illustration of how platform engineering might be used for actual cloud engineering deployments.
IT teams can now consider moving forward to a stage where internal 'customers'—i.e., people, business departments, or higher level workflows spanning several business functions—can easily order what is, in essence, an IT product by moving from a stage where IT teams are constructing virtual machines (VMs) by hand as a way of building compute instances that run in the cloud. This will enable developers to considerably cut time, effort, expense, and pointless duplication, according to the architect of Puppet solutions.
The opportunity to concentrate on developing toolkits and automating processes across silos rather than simply the requirements of one department is one of the benefits of having a separate, dedicated platform engineering team, according to the author. By using this strategy, the platform engineering team may cultivate the atmosphere in which they can hone their abilities to balance both internal and external computing resources.
Entities seeking to follow the platform engineering path must offer IT teams the time and room to grow. This entails giving them the appropriate training and support, positioning the platform role as a full-time role, and making sure that this is not just a task dumped on people alongside existing roles, according to Sandilands, who obviously believes that product managers are essential to the success of platform engineering initiatives.
Product management in this context refers to having a person (or persons, in the form of several product managers) who is solely focused on the platform they represent, adept at evangelizing and communicating, able to handle politics, able to win over senior management, etc. This persona does not need to be technical, but they should make sure the platform engineering approach has a clear roadmap (which is, after all, a fundamentally sound product management strategy).
It is maybe consoling to know that platform engineering has refocused on the mechanics underneath as we shift our interest and concentration away from cloud application endpoints, user interfaces, and all the flashy gadgets from smartphones to linked automobiles and across the Internet of Things (IoT).