There has been a lot of hype lately about Platform Engineering and we have even seen a premature obituary announcing the death of DevOps. This blog looks at the two practices and finds that they are not mutually exclusive. It also shows how much of the Platform Engineering has a reduced effect in Enterprise SaaS platforms.
The driver behind Platform Engineering has been the overwhelming number of tools available. More than 1,000 by some estimates. It is in their nature for developers to develop, so many can't resist building their own or customizing an open source tool that is close. This gives the developers the choice to use exactly what they want, but it makes life difficult for the Release Management and Operations teams. Platform engineering is a response to balance the needs of all the stakeholders in the Software Development Lifecycle (SDLC).
Attributes of Platform Engineering
Platform engineering is a discipline within software engineering that focuses on designing, building, and maintaining the underlying infrastructure and tools that enable the development, deployment, and operation of software platforms. A platform, in this context, refers to a set of core technologies, services, and frameworks that provide a foundation for developing and running applications or services. This is usually called an Internal Developer Platform (IDP).
Platform engineers work on creating and maintaining areas such as:
■ Infrastructure Design and Provisioning
■ Automation and Configuration Management
■ Developer Tooling
■ Monitoring and Observability
■ Security and Compliance
■ Scalability and Performance
■ Service Integration
Platform engineers create a robust, scalable, and efficient IDP that supports the development and delivery of applications or services using a "Golden Path." The golden path is a set of best practices, guidelines, and prescribed workflows provided by the platform engineers or developers to ensure efficient and effective usage of the platform. It defines the standard procedures and configurations that users should follow to achieve optimal results and avoid potential pitfalls or issues. It helps ensure consistency, maintainability, and scalability across applications and services built on the platform. It simplifies development and deployment processes, promotes code reusability, and helps users take advantage of the platform's features and capabilities in the most productive manner.
The good news for enterprises building on SaaS Platforms is that much of this work is either minimized or eliminated completely. The infrastructure is provided by the vendor. Likewise the heavy lifting of automation and configuration, monitoring and observability, and scalability and performance is also provided by the platform vendor. That's what Platform as a Service (PaaS) is all about. It's the remaining aspects of Platform Engineering that we want to examine a little more closely.
Enterprise SaaS platforms have embraced the power of Low Code configuration and App development. It enables non-technical people to build and maintain custom functionality and entire applications on the platform. So the low code tooling is provided by the vendor as well. Most of these platforms still require some traditional code development for service integration and more sophisticated automation, but they usually support industry standard tools such as VS Code, Git, and Jira for managing the development process.
Most programmers have a favorite IDE and Version Control system. The philosophy of Platform Engineering is that the platform engineers should create a set of tools to choose from and the individuals or teams should use the ones they like in a self-service fashion. In large enterprises however, the IT organization generally standardizes on a single family of tools such as Azure DevOps to ensure interoperability over time. This also enables an individual to move between teams without having to learn new tools. Most companies can show that supporting multiple tools of the same type is more expensive and less efficient. Standardizing on a single platform is the trend for most large companies, even though it would make their developers happy to use their favorite.
Monitoring and Observability
Monitoring and Observability of the infrastructure is indeed provided by the PaaS vendor, but that doesn't mean the enterprise should forget about monitoring application performance and usage. There is a huge benefit in verifying that the PaaS provider is meeting their up-time requirements and that the end users are satisfied with the responsiveness of the system. In fact, many of the performance issues are introduced by developers who build on top of the platform using architectures that are inappropriate for PaaS. Application usage monitoring is also important to ensure the users are actually using the applications provided.
The PaaS vendor is also responsible for the lion's share of the Security, but not all of it. Network security and authentication are covered, but each of these systems provides Access Rights Management in the form of Profiles and Permissions. Ensuring that the right users have access to the right information is the responsibility of the Administrators of the Platform.
Compliance is another area where the vendor provides basic capabilities, but it is on the enterprise to ensure that their internal policies are enforced.
It is rare to find an enterprise SaaS platform that is isolated from other systems. Companies generally choose one vendor for CRM, another for ERP and Finance, and a third for HR management. And in general, each of these systems is integrated heavily with the others. They are even likely to be integrated with other smaller third party applications running in the cloud or even on the same SaaS platform. Providing a consistent Service Integration framework is an important part of ensuring that these integrations work properly and are robust enough to withstand the constant changes to the underlying systems.
So What About DevOps?
There seems to be a belief that Platform Engineering is replacing the need for DevOps and that they are mutually exclusive philosophies. This couldn't be further from the truth, especially in the Enterprise SaaS space.
DevOps can be defined as a set of practices and cultural philosophies that aim to improve collaboration and communication between software development teams (Dev) and IT operations teams (Ops). It promotes the integration of these traditionally siloed functions to achieve faster and more reliable software delivery.
At its core, DevOps emphasizes the automation of software delivery processes, the use of agile methodologies, and the adoption of a continuous feedback loop. The primary goal is to enable organizations to deliver high-quality software more frequently, with shorter development cycles, and greater reliability. DevOps encompasses several key principles and practices:
■ Culture and Collaboration
■ Continuous Integration and Continuous Deployment (CI/CD)
■ Infrastructure as Code (IaC)
■ Monitoring and Feedback Loops
■ Security and Compliance
■ Continuous Learning and Improvement
It's important to note that DevOps is not a prescriptive methodology or a specific set of tools. It is a philosophy and a mindset that promotes collaboration, automation, and continuous improvement in software delivery. Organizations can adopt and tailor DevOps practices based on their specific needs and goals.
You will see there are a few overlapping categories like Automation, Security and Compliance, and the use of Infrastructure as Code. But let's take a deeper look.
DevOps is about more than tooling, it is about people and process as well. Look at the bookends of "Culture and Collaboration" and "Continuous Learning and Improvement". These are all about People and Process. They could and should be adopted by the Platform Engineering Teams to develop their deliverables.
As we pointed out above, the use of IaC is somewhat obviated by the use of PaaS, but in those services which are not hosted on a SaaS platform, both DevOps and Platform Engineering agree on the need.
Likewise, Monitoring and Feedback are shared principles, although in DevOps, monitoring also refers to capturing the DORA metrics of:
■ Lead Time for Change
■ Deployment Frequency
■ Mean Time to Restore Errors
■ Change Failure Rate
These metrics are key in the Continuous Learning and Improvement part of DevOps. They are part of a wider practice known Value Stream Engineering that seeks to optimize any process in the enterprise.
Automation is a common practice in both DevOps and Platform Engineering. CI/CD can be thought of as the full realization of automation as it applies to the integration and delivery of changes. Again, completely in line with the Platform Engineering philosophy.
DevOps integrates Security and Compliance practices into the software delivery lifecycle, from the early stages of development through to deployment and operations. This ensures that security measures are implemented throughout the process and that compliance requirements are met. Platform Engineers may have a role in designing and implementing the tooling for it, but DevOps is all about ensuring that they are part of the actual process.
Instead of thinking that Platform Engineering is at odds with DevOps, I hope you can see that they are overlapping concepts that are fairly aligned with each other. Enterprises that build on top of SaaS platforms will find that much of the infrastructure related aspects of Platform Engineering are simply not relevant and those that are will be handled by a well implemented DevOps practice.
So instead of giving up on DevOps and hoping that this "next big thing" of Platform Engineering will solve all of your problems, take a step back and evaluate whether your company has truly implemented a robust DevOps practice. Generally it is not a lack of tooling that is at the heart of the problem, but rather the people and processes. Make sure that the Processes are well defined, the People are trained properly to follow them, that you are measuring the real outcomes with DORA metrics, and learning from any mistakes. Then take a look at the remaining Platform Engineering principles and see which ones will enhance your process further.