Cycloid today added a managed environments capability to its internal developer platform (IDP) that makes it possible to centrally control how application developer environments are provisioned.
Additionally, Cycloid is providing more federated visibility into projects that span multiple instances of its IDP, along with an ability for the artificial intelligence (AI) agent that Cycloid provides to centrally manage Model Context Server (MCP) server plug-ins that platform engineering teams have deployed across their application development environments.
Cycloid founder Benjamin Brial said the Managed Environments capability added to the platform provides an alternative to allowing application developers to self-select which approved components will be included in their application environment. Instead, platform engineering teams will determine which components are to be included to provide more consistency across application development teams.
In effect, platform engineering teams can replace an unstructured, ticket-driven approach to provisioning with a framework where production, staging and development environments come pre-wired to the right cloud accounts, regions, permissions and tags for tracking costs in a way that only needs to be defined once.
Otherwise, developers will spin up new environments without enforced naming conventions, consistent tagging, or clear links between an environment and the cloud account to which it should be deployed. That fragmentation then results in platform engineering teams being forced to clean up inconsistencies, chase down ownership, and field a steady stream of tickets every time a developer needs to deploy.
In the future, Cycloid plans to extend the capability through its Terraform provider, allowing environment creation itself to be codified as a stack so that provisioning a new development environment, attaching its cloud accounts, and setting its permissions becomes a single, automated operation.
It’s not clear to what degree or depth software engineering teams have adopted IDPs. In some instances, platform engineering teams have standardized on a single IDP, while others have multiple instances that have been adopted by disparate teams. Regardless of approach, as it becomes simpler for application developers to write code in the age of artificial intelligence (AI), the number of times an application development environment will need to be spun up will only continue to multiply.
The challenge, as always, is convincing developers to buy into the concept of platform engineering versus having to impose it. Many developers still prefer to either configure their own development environments or self-service the components they will use to construct it from an IDP. Other developers simply want to focus as much time on writing and reviewing code as possible.
Regardless of approach, the more diverse the application development environments are, the more difficult it becomes to collaborate. Just as critically important, the less standardization there is across those environments, the more likely it becomes that there will be some type of compliance issue that arises later on. Each software engineering team will need to decide how much time they want to devote to managing application developer environments, given the personal preferences of their teams, but in the final analysis, every minute spent on this task is one less that could have been spent on another task that provides more value to the business.