DevOps needs support. The Rise of the Software Engineering Platforms
Smart but desperate companies invented how to avoid ineffective DevOps implementations. They built Internal Developer Platforms (IDE), a layer upon the set of tools and workflows of DevOps. With a dedicated team of developers, it turned into a new concept: Software Platform Engineering.
It looks like high hopes for a great jump in the effectiveness of the software development process thanks to DevOps adoption have evaporated. DevOps will not be a common standard for developer teams across industries. Dis disillusionment and frustration are growing among once enthusiastic followers of Google, Airbnb, Amazon, and other digital senseis. But there’s a new hope: Software Platform Engineering rises to correct DevOps weaknesses.
What went wrong with DevOps (r)evolution?
For over a decade, companies commonly embraced DevOps to control the software development process end-to-end through its self-serviced DevOps teams. “You built it; you run it.” To raise effectiveness, awareness, speed, and quality of their software products. To end “over the fence” communication, delays, and failures. To face the digital business challenges and opportunities: work within the cloud-defined environment, open to and explore innovation, reduce time-to-market, and enable quick and flexible adoption to a rapidly changing landscape.
Instead – DevOps engineers got stuck between a fast-changing environment, deployment pipelines, configuration, and environment management, fighting with its rising complexity and toolsets heterogeneity, unable to stabilize teams mixed of over-skilled seniors and under-skilled juniors. DevOps teams became ineffective in the way that highly skilled developers were used on the one hand, and the other – it turned out to be too challenging for those inexperienced. Interestingly, attempts to reinforce and patch DevOps with concepts like Site Reliability Engineering bring more harm than good.
The misconceptions and errors in DevOps adoption were observed and commented on from the very beginning; thus, we know, for example, 12th DevOps Anti-Patterns. A more elaborated, evidence-based typology of DevOps Anti-types was established by well-known authors of “Team Topologies” Matthew Skeleton and Manuel Pais.
One such misinterpretation is the DevOps Silo model, appointed “between” existing Dev and Ops units; it may be a good solution for a start, but no longer than 12-18 months. The other – Dev Don’t Need Ops model – arises from the arrogance and ignorance of developers and its management teams who assume Ops skills and competencies belong to the past in the Cloud Era. At the opposite extreme, the low maturity of the entire organization and the arrogance of Ops may result in a Rebranded SysAdmin model. Authors of this typology noticed that it becomes more and more popular as many ex-Ops rebrand and try to catch waves of the DevOps hype. This mimic becomes even more open and impudent in the Fake SRE model, where Ops renamed themselves SRE Team and do nothing more. History makes a circle in that case, as the company returns to a separate Dev and Ops scheme.
There and Back Again
The root cause of these problems was already mentioned: a deficit of highly skilled developers. Digital champions suck in the biggest talents in a truly out-of-proportion way. DevOps is too demanding for the rest of the teams and companies.
Companies decided then that there is no pure DevOps – as life shows – achievable to all, but a master-level model for companies like Google, Airbnb, or Amazon and customized DevOps. Consequently, DevOps as a model splits into several types and keeps dispersing into new subtypes. The DevOps model itself is adopting a “local” context rather than proving to be the “global” standard, mighty enough to set the tone of IT evolution and force the adoption.
And still, it’s reasonable. Software development teams use many tools provided by various vendors. Automation of the software development process requires it. The scale of complexity is the individual case of the company situation. Usually, we meet environments consisting of many components, including legacy ones. Usually, it is a mix of some public cloud elements, on-prem, hybrid solutions, and many others. The landscape is huge. Managing such complexity devours the time DevOps engineers should devote elsewhere.
Recently, I spoke to a developer from a mature IT organization (the international bank), frustrated with the ineffectiveness this situation generates. The team leader said: DevOps works as a high-level abstract idea among high-rank managers. It might be a way to make things done, but it turns out to be a time-consuming, costly, and competences-wasting manner of managing the software development process. Highly skilled developers should be focused on code quality instead of being distracted by such things as environment setup or managing the entire software delivery process.
Enhanced DevOps or IDE
Both smart and desperate companies invented how to unlock their ineffective DevOps implementations. They started to build the Internal Developer Platforms (IDE), as a layer upon the set of tools in the DevOps team’s portfolio. A platform was designed to fulfill the self-service mode for developers, providing all necessary systems and platform integrations, tools, and workflows, covering the entire application’s lifecycle. This required a new team dedicated solely to building and maintaining the platform and the interface developers’ teams may work on.
This new team is based on an equally new paradigm: taking the developers’ perspective to ensure that the process will be smooth from their point of view.
It gets even worse when the company following its strategic business, needs to hire developers with advanced, specific skills. Their skills are not used effectively, not fully, and are underutilized.
That’s how and why a developer’s platform concept arose and reached its own identity: Software Engineering Platform. The cornerstone of it is a team dedicated solely to managing/administering the platform. The platform offers automated and easy-to-configure environments for developers. This change establishes different roles based on different skills. Platform developers’ team creates an integrated, secure, dynamic, and easy-to-use workspace.
In this model, software engineer concentrates on their primary aim – to develop a decent system with decent technology. Platform team, on the contrary, focuses on its prior customer – developers, to make their work easier, smoother, and more effective.
Interesting to notice that a typical DevOps team works reactively on tickets, such as “there’s a code to deploy.” The Platform Engineering team, in contrast, focuses on building a platform that will allow developers to avoid problems. The developer remains the one who decides about certain parameters and may easily choose the options or actions from their interface, except for those issues and options that are arbitrarily settled by the platform for architectural, regulatory, or other reasons. The developer is now supported in the entire range of features his code needs to be equipped with. They may start to act similarly: to help users avoid problems and win business opportunities.
We’re talking about building a standard and self-service product that doesn’t require coders and platform developers to communicate every day. There’s a platform with a catalog of services – and it doesn’t need the typical developer to do additional configuration, change pre-configuration scripts, etc. The venue is easy to onboard newcomers, who may quickly become full-fledged team members.
We are at the beginning of an exciting journey. Our customers have started to talk about the necessity of the Platform Engineering approach in their software development process. Some vendors have begun to provide off-the-shelf platforms. Platform software engineering is an approach that should look to avoid vendor lock-in.
It raises the question: is it still DevOps – Enhanced-DevOps perhaps – or is it something new? Why did this become a notable trend called Platform Engineering, which Gartner defined as an “Innovation Trigger” and locates on an ascending curve of expectations, predicting it to reach the productivity plateau in 2-5 years?
A platform of high expectations
Platform engineering offers answers to many challenges regarding software development but also helps manage tech competencies and enables businesses to design and implement new digital products. We want the Software Engineering Platform to act like a factory, with established rules and assured integration, where engineers are easily onboarded. Why? Because software development has become an important part of the business, and there’s no place to accept it as a chaotic, unregulated, and inefficient area.
All companies with 50+ developers staff should consider the adoption of Platform Engineering to boost productivity. Why does it pay off? The salary of a Platform Engineer is higher. Still, a regular developer will spend much more time and effort on coding instead of carrying out all tasks that a properly created and automated platform should do for him.
Platform Engineering might be an argument for HR/team leaders – it allows the developers to focus on important tasks instead of minor issues. Developers working in a modern environment which helps them improve their skills are less likely to look for another job. It’s worth taking a step back from the DevOps pathway – as we expect things to be better from now or get worse if we leave it unchanged. It will be easier to step back now than in two years.
The decision to start IDE/Platform Engineering and change in the software development process has to be made on the operational layer and requires a high-level sponsor.
How to design and deploy the Platform?
The platform should be customized but follow some general rules, as most functions need to be intuitive. It’s like driving a new car. You can drive a new car… but fully learning to use all its features will take some time.
The main challenge is the complexity of the organization. The most probable deployment scenario will be the incremental one, switching team after team to work on a Software Engineering Platform. This gradual roll-out will also enable the company to continuously fix and optimize the platform.
Also, the process of user adoption is incremental. Pioneers should learn the platform from scratch, “next generations” will probably be onboarded more smoothly, based on early adopters’ experience.
How to create such a platform? Mindbox works with market-leading tools which specifically address certain elements of the development processes. We recommend establishing a new platform team and not relying on existing DevOps teams. Of course, they know the job and the products. But they often work in a managed service mode, concentrating on finishing received tickets. It would be a dead-end journey, as many DevOps engineers represent this typically administrative attitude.
We need a competent staff who knows the job but would be able to level up. They should know how the developers like to work and watch the process end-to-end. Platform developers have to treat it as a product for an internal customer.
Thus, we should look for a person who will become a product owner and a leader for a newly established team. They have to cooperate with DevOps engineers, especially when designing and implementing platforms, but not allow them to dominate. They should represent an architectural approach. The Software Engineering Platform they will create, provide, maintain, and optimize will become a strategic solution for the company. It must act like a black box, efficiently offering functionalities and supporting a chosen range of commonly used tools but guaranteeing that it will remain a technologically agnostic solution.
ANY QUESTIONS?
LET'S TALK!
We will answer all your questions!
Podobne wpisy:
Are you a Cloud Native organization?
Cloud native leads to innovation
What went wrong with DevOps (r)evolution?
Project management in times of pandemic