Gartner predicts that 80% of software engineering organizations will have platform teams by 2026
DevOps and Platform Engineering
DevOps is a culture and a philosophy. Platform engineering is the only way we can achieve **"who builds, who runs"**. This is the core original intention of DevOps, and it is also the basis for the realization of enterprise-level scale and cloud-native era. The focus of platform engineering is not necessarily to teach you how to use tools, but to build a platform that can realize this self-service capability. With platform engineering, the core software engineering department has the opportunity to gain self-service capabilities . This change in concept determines that we should regard the platform as a product for construction.
The original idea of DevOps is very simple. The basic goal is to remove the barriers between developers and operators and promote collaboration between the two parties. The way to achieve the goal is basically to do a left shift and realize "who builds, who runs". When all these cloud-native trends come together, you have cloud-native, Kubernetes, containerization, infrastructure as code, GitOps, etc., the situation is completely different.
Why Platform Engineering is Needed
In the face of complex tool chains, developers do not need to be comprehensive experts. On the contrary, the complexity of the underlying infrastructure should be abstracted from developers, and an optimal path should be provided for them. Developers themselves can decide the most suitable context. hierarchy.
In the enterprise, the promotion of platform engineering will encounter difficulties, especially problems related to cognitive load. First of all, developers are at a loss and keep asking the operation team for help, and finally the operation team becomes the bottleneck of the business; or senior engineers will quietly take over the operation task in their own way, becoming a "shadow operation" and not devoting all their energy to coding. These two ways can fall into a vicious circle and eventually become technical debt. Therefore, we recommend establishing the role of the platform engineering team and considering the construction and use of engineering platforms.
What kind of team needs an engineering platform
If you only have about 20 engineers on your team, and not everyone is familiar with helm, IaC, Terraform, or Kubernetes, PaaS is a good choice. The basic requirement of DevOps "who builds, who runs" can be realized. But PaaS can only provide one path, and can only support relatively uncomplex use cases with simple settings.
The pain points that the platform helps to solve really start to emerge as businesses move from dozens to hundreds of developers. Pain points arise, friction arises, and if there is no platform yet, it is time to act. If you already have a PaaS solution, you may wish to consider gradually transitioning to a self-built internal developer platform, or use a more mature external product with the same values.
How to build a platform project
Set up a platform engineering team. The mission and vision of the platform engineering team is to build, achieve, or introduce a product whose customers are developers.
Second, the platform engineering team should pay attention to communication skills. When talking to developers, emphasize how to reduce wait times and improve the development experience. And when talking to the operations team, tell them how to reduce stress and process tickets quickly. When communicating with management, the most important point is to inform how to shorten the time to market of products and reduce operating costs. This metric is similar to setting an ROI for a platform.
The goal of the developer platform is to provide engineers with a PaaS-like usage and development experience. But it's based on a more complex stack of tags and tools, figuring out what combination of technologies is in the toolbox. Take over the entire stack, complete the last mile optimization , and build the best context path for developers through fine-tuning.
Platform engineering should not be a shackle to the development team. On the one hand, it is necessary to reduce the threshold of cognition and use through standardization and popularization, so as to realize self-service. At the same time, it is also necessary to ensure that the way developers use infrastructure resources is consistent with the platform standard requirements . Here, the same configuration file is consistently output for dynamic configuration management. The essence is that the configuration file can be dynamically generated each time it is deployed, including who deployed what, where it was deployed, and what was output. Dynamic configuration management also enforces policies and standards with every Git push, establishing constraints between deployments and more. If you don’t have a clear idea and the foundation is weak, or you don’t want to invest in non-main business costs, you can evaluate and choose an external product that has a complete interactive console, practices a set of agreed methodologies, and most importantly is willing to maintain Through communication and continuous iteration, customers can move towards the final state of platform engineering together with the product.
Productization Trend of Platform Engineering
Overseas, the open source community is very popular, there are many open source tools such as Argo CD, Backstage, especially the plug-in system around Backstage is very rich, there have been hundreds of plug-ins; there is also a platform editing product Humanitec, serving the enterprise platform layer The core engine of the internal developer platform, one of the solutions in platform engineering, teams and organizations. In contrast, the domestic tool chain is relatively complex. In order to fully improve the end-to-end experience, an integration layer or platform layer is usually needed to better combine these tools. **And domestic platform engineering is mainly centered on code and self-brand, such as Tencent Cloud's CODING Orbit and other products.
Starting from the developer's perspective, it is built around core features such as code management, project management, requirements design, defect management, test management and product management, continuous integration, continuous delivery, and application management/observation. In these platforms, the transfer of code and artifacts occurs more between different product modules. Each product has a very rich functional mechanism inside, and this kind of gameplay of commercial software cannot be achieved by open source platforms. Do domestic and foreign tools and platforms eventually evolve and converge according to the demand scenarios of platform engineering? let us wait and see.
Welcome to scan the code to add CODING official assistant
Get the 2023 Platform Engineering Report
