Platform Engineering
On a new topic, people may differ because, when they only consider it from their own perspective, they fail to see the wider picture. The story of the blind men and the elephant clarifies this IT organisations and software engineering teams are examining platform engineering, a relatively new method to software delivery. There is a lot of disagreement among them over what platform engineering is, what it does, and whether or not you should adopt it.
Google cloud prefer platform engineering because Google Cloud think it’s crucial to approach software delivery from a holistic perspective. Individual teams create broken or troublesome systems when they simply take into account a portion of the issue. Understanding a software delivery platform as an engineering product is the only way to “see the whole elephant.”
Here are five widespread misconceptions regarding platform engineering that google cloud has heard when people aren’t looking at the whole picture. Google cloud will dispel misconceptions regarding platform architecture .
1. MYTH: An internal development platform and a developer portal are interchangeable
Since you most likely already have a developer portal, you could assume that platform engineering is something you’ve done before. However, a developer portal also referred to as a “IDP” is really the interface to the rest of the internal development platform. It’s not a complete solution; it’s simply the front door. Furthermore, there are a few significant distinctions between a developer portal and an internal platform, even though they sound a lot alike. Let’s see how the two differ from one another.
An interface that makes it easier for software developers to locate and utilise the different tools and services that the IDP offers is called a developer portal. Usually, a developer portal offers the following:
- Deploying and configuring infrastructure and apps with the use of self-service templates (sometimes referred to as a golden path).
- A service catalogue to monitor resources that have been deployed along with metadata (such owner and environment).
- Application service status shown visually (e.g., SLOs, DORA metrics).
- Documentation for the application, platform, APIs and even the actual code.
In contrast, developer self-service is made possible by an internal developer platform that makes use of golden paths. The platform uses techniques like defined procedures, establishing configurations for the entire organisation, and implementing security controls to abstract away technical complexity. Every new service that is deployed from the IDP is made instantly available on-demand without the need for tickets, manual approvals, or meetings. Examples of these services are Google Kubernetes Engine (GKE), Cloud Run, Compute Engine, and Cloud Workstations.
Using an existing Google Cloud product, such as Cloud Run, which offers a UI for designing, deploying, and monitoring workloads along with an API for automation or command line access via gcloud, could be a rapid start for an internal developer platform. Furthermore, even if a lot of Google Cloud products might be viewed as platforms, they are frequently insufficient on their own. Organisations may wish to restrict flexibility or simplify their developer experience by combining the use of numerous products into a single interface, in order to apply restrictions or promote specific developer behaviours.
Appropriate constraints should also be provided by internal development platforms. The implementation of golden routes and “sensible defaults” or even limiting the selection of resources and services to those that comply with organisational policy could accomplish this. Resources and settings that are prohibited are either not accessible through the portal or are clearly designated as such, often along with a description of how to “break the glass” and access them.
Developers in this universe mostly use the developer portal user interface (UI), which conceals the development platform below it.
2. MYTH: An internal development platform is not necessary
Depending on what! It’s possible that you already own one, or at least you might need one. Your platform is whatever means you currently use to get your code into production. That might be a chaotic mix of various individuals, systems, and procedures that alter on a regular basis! Google Cloud define “paperwork as a platform” as having a set of tickets to submit to several siloed teams, for instance. Alternatively, you have “people as a platform” (think of Brent if you’ve read The Phoenix Project) if you need to speak with a specific person to launch something.
Rather than expecting every team to become experts in DevOps principles, platform engineering begins with modelling your current process, or an improved version of it, and then designing software to do it for you. Simple CI/CD pipelines are a good place to start, and managed infrastructure services or constant observability can help make it better. When these elements are combined, a platform is created. A platform engineering team’s job is to provide abstractions to development teams so they can better integrate various elements into a unified, useful developer experience. The internal developer platform serves as the tool for this purpose.
3. MYTH: “Just advanced DevOps” is what platform engineering is
Google Cloud can all agree on this: The goals of the organisational and cultural movement known as “DevOps” are to improve service reliability, accelerate software delivery, and foster shared responsibility among software stakeholders. Examples of DevOps methods include
- Version management
- Ongoing incorporation
- Development based on the trunk
- Ongoing examination
- Constant provision
- Building architecture
- Cloud-based architecture
- Testing administration
However, a burdensome infrastructure administration can provide scalability issues for the DevOps methodology. Cognitive overload, developer burnout, inconsistent teamwork, or cultural opposition could result from this.
Today, platform engineering is a natural progression towards “DevOps at scale.” Among the DevOps techniques applied to platform engineering are:
- Adopting a developer-centric methodology
- Infrastructure as Code (IaC) and Automation
- Safety and adherence
- Observability
- Ongoing development
Platform engineering is the process of encoding some DevOps techniques into software. In other words, platform engineering isn’t just more advanced DevOps; rather, consider it as “shifting DevOps down” into the platform, enabling developers to adhere to some DevOps procedures without needing to be specialists.
4. MYTH: “Just automation” is what platform engineering is
Teams can manage their systems with less human intervention thanks to automation. This may be as easy as writing a shell script, or it could be far more intricate, subtle, and scalable. When anything is disparaged as “just automation,” it usually refers to a lot of pointless shell scripts that frequently break.
It’s true that automation can lead to the emergence of new, more challenging issues. As a result, it makes sense to prevent unregulated automation, in which the cause of system failure is not the automation itself but rather socio-technical forces such as incorrect signal interpretation, misinterpreted designs, incorrect assumptions, or misaligned incentives.
However, platform engineering has a much more comprehensive approach to automation than the “bag of scripts” method, taking into account every stage of the system lifecycle, from service development, configuration, and deployment to monitoring, scaling, and final deconstruction.
Platform engineering is therefore automation after all, but the platform isn’t merely tacked on after the fact; rather, it’s given as a product and built for the whole service lifecycle.
5. MYTH: The newest craze is platform engineering
Software development teams now bear a much heavier cognitive load due to the intricacy of building and maintaining a contemporary infrastructure and software stack. The need to abstract the deployment and management of these services has grown to such an extent. When you have hundreds or thousands of micro services dispersed across many fleets of computing resources to manage, it is simply impossible to possess deep knowledge at both the infrastructure and application layers.
These days, platform engineering tackles the following practical issues:
- DevOps overload, also known as cognitive load, occurs when teams struggle to handle the increasing complexity of contemporary software and end up becoming bottlenecks.
- Developer friction is the measurable slowness a team experiences when engaging with policies, procedures, tools, and infrastructure.
Platform engineering addresses an organization’s unique requirements in terms of infrastructure, security, workflows, and processes. Its objective is to improve developer experience by lowering cognitive burden and friction.
In a similar vein, Platform as a Service (PaaS) existed before platform engineering, but not every team was a good fit for it. You might wonder how platform engineering differs from PaaS. Although PaaS offers the tools to quickly develop apps and set up the required underlying infrastructure, its successful adoption requires an ecosystem of people and procedures surrounding it. A team can use platform engineering to construct an abstraction or extension of goods, such as a PaaS, while enforcing the limitations or liberties that make sense for their particular setup. Put differently, platform engineering is an answer to PaaS’s “technology-centric” strategy, which falls short for enterprises that may want more customisation.
To put it briefly, platform engineering is currently taking place as a logical extension of the DevOps methodology for larger systems. Although the “you build it, you run it” model was effective for simpler, smaller systems, platform engineering has become more and more important in today’s world since modern software systems are larger and more sophisticated than they were in the past.
The elephant is beginning to appear in the distance. You should have a better understanding of what a platform is and isn’t after debunking these first five myths. For five additional myths about the functions and limitations of platforms, make sure to read part two.
