DevOps has established itself as a significant milestone in recent history in the software world. The abbreviation DevOps stands for Development (Dev) and Operations (Ops), and the debate about whether DevOps is still a technology or a methodology continues to remain fresh. This concept, which has permeated the world of software to such an extent, is still struggling to be defined clearly. The mystery surrounding what DevOps really is, in a way, contributes to its ongoing relevance and vibrancy. Some consider DevOps a technology, while others view it as a community of tools, and still, others regard it as an approach. Setting aside the conceptual debates, we can describe DevOps as a combination of tools and methods aimed at accelerating the development process.
So, what was life like before DevOps?
Until the early 2000s, things worked as follows: A developer would have to go from door to door to find a system administrator to run their application. They would request the necessary resources from the system administrator, and quite often, these conversations took place in a language unknown to either party. At the end of the day, developers persevered, albeit reluctantly, in the face of requests that were met with varying degrees of success. In other words, developers were responsible for the operation that extended from the development of the application to its deployment within their organizations. This arduous journey from development to deployment was complicated by numerous inconsistencies and deficiencies. However, this way of working quickly became outdated due to rapidly evolving technologies in the sector. The emergence of cloud systems, the transformation from monolithic architectures to microservices, the diversification of environments (dev, test, qa, uat, pre-prod, prod, etc.), and the increasing need for business continuity, disaster recovery, and redundancy all made the existing process inadequate. Consequently, this painful installation and transition process evolved into a separation of development and operations. Thus, developers were no longer involved in the operations (OPS) aspect, but they could manage the end-to-end processes of their applications. Depending on the organization, this situation gave rise to various models.
First Model
In this model, the OPS team consists primarily of system experts, meaning the OPS process has been transferred to the system teams. Consequently, the DEV and OPS workflows have been separated. Communication and collaboration issues between DEV and OPS teams persisted in this scenario.
Second Model
In this model, DEV and OPS teams are separated, but unlike the first model, the OPS team consists of developers. In other words, the OPS process has been handed over to developers. However, this situation led to serious problems as developers who lacked sufficient experience in installations and transitions faced significant challenges. Live environment issues saw a considerable increase in this setup.
Third Model 
In this model, DevOps is seen as a set of tools. The DevOps team is generally composed of middle-tier experts. Although this model achieved the separation of the DEV and OPS processes, it also resulted in isolation between these two teams.
Aside from these three models, there are other DevOps models such as OPS as-a-service, temp OPS, DEV+OPS, and SRE.
Of course, it’s not possible for a single DevOps model to fit every organization. This is because the workings, processes, and policies of organizations are unique, and the best practice varies accordingly. Therefore, a DevOps model that works very well for one organization may not be successful in another.
The emergence of different DevOps workflows can be understood quite clearly through Conway’s Law. Melvin Conway proposed that the systems being built reflect the organizational communication within the teams. According to this perspective, there is a relationship between how communication is established within an organization and the outputs or products produced. In other words, communication and collective skills extend beyond just meetings and also affect the applications being developed.
“If you have four teams working on a compiler, you’ll get a four-pass compiler.” • Eric S. Raymond
The origin story of DevOps, ‘you build it, you run it,’ meaning the removal of the Ops component, has not been effectively implemented by many organizations. The major issue here is that responsibilities were often assigned to the most experienced developers during the process. This resulted in the inefficient allocation of the most costly and valuable resources within organizations.
So, what if the Ops process were self-service? Imagine a universal platform that is free from any non-code elements. This platform would eliminate the need for evaluating which environment the application will run in, gaining expertise in tools, or dealing with infrastructure configurations.
During the development process, different teams often have different tools, frameworks, or programming languages. Therefore, this diversity requires developers to invest time in learning and adapting to these tools. As a result, developers often struggle to find enough time to focus on actual development. This is where a platform comes in, enabling developers to concentrate solely on writing code. This internal Developer Platform (IDP) provides developers with a self-service system that offers all the resources they need from code to deployment. Those who create and manage this structure through the integration of various technologies and tools are referred to as Platform Engineers.
Platform engineering is a process that allows developers to autonomously carry out operations throughout the SDLC. Platform engineers create and manage the necessary tools and workflows to enable developers to swiftly and efficiently move their applications to the production environment. They act as an intermediary layer between developers and infrastructure, preventing infrastructure issues from affecting developers.
Platform engineers aim to implement the best practice of eliminating the Ops process from developers’ responsibilities, in line with DevOps’ philosophy of ‘you built it, you run it.’ Consequently, by maximizing the benefit from developers, the goal is to achieve better application development and rapid deployment to a live environment.
Who knows, perhaps Platform Engineers will build the “Golden Path” for developers and push DevOps to its natural limits in the world of technology.
References:
https://platformengineering.org/