Cycloid this week added a plug-in capability that makes it simpler to customize its internal developer platform (IDP).
Company founder Benjamin Brial said this capability will be used to create 25 official plug-ins that will be supported by both Cycloid and its partners, as well as plug-ins that individual customers will build and support on their own.
That approach will make it simpler for platform engineering and DevOps teams to extend the scope of the Cycloid IDP via integrations with a wide range of software engineering tools and platforms, he added.
Those teams can leverage plug-ins developed in any language, including Python, Go, JavaScript, using a set of open application programming interfaces (APIs) and libraries that Cycloid makes available, he added.
While IDPs have been around for some time, the rise of platform engineering as a methodology for managing DevOps workflows at scale has spurred adoption. Platform engineering teams are using IDPs to expose a standard set of tools and platforms that application developers can use to self-service their needs.
The overall goal is to both increase efficiency and reduce costs. In fact, a recent survey conducted by The Futurum Group finds platform engineering as a methodology for building and deploying applications at scale is gaining significant traction. More than a quarter of respondents (26%) have mastered platform engineering, compared to 41% who are still working toward applying platform engineering across multiple projects. Another 24% are still working toward operationalizing a set of best practices for platform engineering, while 7% are just getting started.
There is, of course, no shortage of IDP options. Many organizations have adopted open source platforms only to discover the cost of maintaining and updating them is significant, noted Brial. In contrast, the Cycloid platform is designed to be both easier to deploy in a way that reduces the overall amount of time and effort required to simply maintain the IDP, he added.
Each organization will need to determine to what degree deploying an IDP makes sense, but the more DevOps teams there are, the more pressing the issue tends to become. Many DevOps teams have acquired separate tools and platforms that in addition to increasing overall expense tend to make collaborating across various teams a challenge. The issue, of course, is convincing often fiercely independent DevOps teams that they have more to gain by embracing platform engineering than they stand to potentially lose. The more platform engineering teams make it possible for application developers to experiment with new tools as they see fit, the more likely it becomes they will embrace platform engineering. Conversely, the more platform engineering feels like a return toward an autocratic approach to managing IT, the more likely it becomes that those same developers will set up their own shadow IT environments.
Ultimately, the organizations that manage to strike the right balance when it comes to platform engineering should benefit most as long as they remember that application developers are not just end users of a platform but rather actual customers that need to be kept happy.