The German Certification Office for Research Allowance (BSFZ) has recognized the development of Polycrate as a research and development project under the German Research Allowance Act. This confirms ayedo's in-house research and development work on an automation framework that brings existing tools and technologies together in a shared technical model. ayedo has received the red BSFZ seal for this development work.
Research and development as part of our work
At ayedo, we work every day on provisioning, automating and operating IT infrastructure. We rely on established open-source technologies such as Kubernetes, Ansible and other tools from the cloud-native ecosystem.
These technologies reliably solve many tasks. Integrating them into complex operational environments, however, brings its own challenges.
Deploying an application often requires several interdependent steps. Infrastructure must be prepared, software configured, credentials managed and different tools executed in the right order. Different versions, customer-specific configurations and maintainability requirements add to the complexity.
The individual tools are usually available. The harder part is organizing how they work together so that automations can be reused, traced and executed independently of individual local development environments.
Polycrate grew out of these requirements.
What is Polycrate?
Polycrate is an automation framework developed by ayedo with its own execution environment, built on Ansible. It allows applications and IT infrastructure to be divided into reusable components, configured and managed through defined actions.
Polycrate does not replace Ansible, Kubernetes or Helm. Instead, it connects existing tools in a shared automation model.
Three concepts are central to this model: Workspaces, Blocks and Actions.
A Workspace represents the context of an infrastructure environment or application. Blocks contain the technical implementation of individual components. Actions define which operations can be performed on those components.
This separation is essential to Polycrate's technical approach: the implementation of an automation is separated from its specific use.
For example, a team can develop a Block that configures a Kubernetes cluster. Other teams can use that Block in their own Workspaces without having to change the underlying Ansible playbooks or fully understand their internal processes.
The technical complexity does not disappear. It is managed in a defined place and does not have to be implemented again each time it is used.
Workspaces: A shared context for automation
A Workspace is the central organizational unit in Polycrate. It contains the configuration of an environment along with the Blocks, references, credentials and artifacts needed to manage it.
The central configuration file is called workspace.poly and uses YAML. No additional proprietary configuration language is required.
A Workspace can specify, for example, which infrastructure components are used, which registries they come from and which parameters they should run with.
The Workspace can be managed as a Git repository. This allows changes to infrastructure configuration to be versioned, reviewed and synchronized between team members.
This model is particularly relevant when managing multiple environments. Development, test and production systems can use the same technical building blocks while maintaining different configurations.
Polycrate also takes the management of sensitive information into account. Secrets and other confidential artifacts can be encrypted within the Workspace. The documentation includes encryption based on age, among other options.
Configuration, execution and the handling of sensitive data are thus organized within a shared model, without having to store unencrypted credentials in version control.
Blocks: Reusable infrastructure components
Blocks are Polycrate's modular building blocks.
A Block can represent, for example, the installation of an application, the configuration of a server, the management of a database or the provisioning of Kubernetes resources.
It contains the automation logic and configuration needed for its task, along with the definition of the available actions.
Existing Ansible playbooks, Python scripts and other automation mechanisms can be integrated into Blocks. Automations that have already been developed therefore do not generally need to be rewritten.
Packaging using the OCI standard is an important element.
Blocks can be provided as OCI artifacts and distributed through compatible registries. These include Harbor and other OCI-compatible registries.
This allows infrastructure components to be versioned, published and reused in different environments in a similar way to container images.
Versioning plays a central role here. Instead of always obtaining an infrastructure component from a changing development state, a Workspace can explicitly reference a specific version.
This makes it easier to control changes and reduces the risk of an update to a shared component unintentionally affecting other environments.
Actions: A consistent interface for different tools
Another element of Polycrate is its Action model.
An Action describes a specific operation that can be performed with a Block. Examples include installing, updating, checking or removing a component.
The actual implementation can consist of multiple Ansible tasks, scripts or calls to external tools.
Externally, however, a defined action is available.
Such an action can be executed with the following command, for example:
polycrate run nginx install
The person invoking it does not need to know which individual Ansible roles, configuration files or other tools are used internally.
This is particularly relevant for teams in which different people work with the same infrastructure. The technical implementation remains with those responsible for the respective Block, while the intended operational actions can be invoked consistently.
This approach also allows existing automations to be integrated into Polycrate gradually, instead of having to rebuild an existing infrastructure from scratch.
Reproducible execution instead of individual tool configurations
Differences between execution environments are a common problem in infrastructure automation.
An Ansible playbook may work on one development machine and fail on another because of different Python versions, missing dependencies or different tool versions.
Polycrate addresses this problem with a containerized execution environment.
The required toolchain is provided in a Polycrate container. This can include Ansible, kubectl, Helm and Python, among other tools.
As a result, execution depends less heavily on the individually configured working environments of individual developers.
Combined with versioned Blocks and defined Workspace configurations, this creates a foundation for reproducible automation workflows.
Reproducibility does not mean that every operation necessarily produces the same result regardless of the state of the target systems. External APIs, networks, permissions and existing infrastructure states remain relevant factors.
Polycrate therefore focuses on the elements that can be controlled: the tools in use, the automation components and their versions, the configuration and the execution context.
Why the development goes beyond conventional software integration
The technical challenge with Polycrate is not to provide another tool for running Ansible playbooks.
Ansible itself already offers extensive automation capabilities. Established solutions also exist for package management, containerization, version control and secrets management.
Rather, the development work on Polycrate addresses how these different concepts can work together in a consistent model.
A Block must be able to be developed and versioned independently of a specific Workspace. At the same time, its execution requires access to the configuration, dependencies and, where necessary, sensitive information of the respective target environment.
The tools in use must be available in a defined environment. Changes to individual components should remain traceable. At the same time, the model must be flexible enough to integrate different types of infrastructure and existing automations.
This creates technical requirements for packaging, dependency management, configuration processing and execution.
These requirements cannot be met simply by calling existing command-line tools one after another. What matters is how their responsibilities, inputs, dependencies and execution conditions are brought together.
This architecture and its technical implementation are precisely what ayedo is working on with Polycrate.
Open standards as a foundation
In developing Polycrate, we deliberately rely on existing technologies and open standards.
Ansible provides the foundation for the automation logic. YAML is used to describe configurations. OCI enables Blocks to be packaged and distributed through compatible registries. Git supports versioning and collaboration.
These decisions have practical reasons.
Companies often already have extensive automations and experience with these tools. A new platform that required their complete replacement would create additional migration costs and dependencies.
Polycrate therefore takes a different approach: existing implementations should be reusable and capable of being integrated into a shared model.
This reduces the need to redevelop working automations and makes gradual adoption easier.
Open standards are also a prerequisite for technical freedom of choice. Companies can use compatible registries, version control systems and infrastructure tools according to their own requirements.
What BSFZ recognition means
Under the German Research Allowance Act, the Certification Office for Research Allowance assesses whether submitted projects meet the requirements for research and development.
The assessment considers factors including the novelty of the knowledge being sought, scientific or technical uncertainties and a systematic approach.
The development of Polycrate has been recognized by the BSFZ as a research and development project under this law.
ayedo has received the red BSFZ seal for its in-house research and development work.
This recognition relates to the research and development work. It is not a certification of product safety, a general quality assessment or a statement that all Polycrate functions are technically unique.
Rather, it confirms that the assessed development project meets the legal requirements for research and development.
For ayedo, this is important recognition of the work that has gone into the design and technical implementation of Polycrate.
What comes next for Polycrate
Polycrate grew out of concrete requirements we encounter when developing and operating complex IT infrastructure.
With the framework, we continue to pursue the goal of connecting existing automation technologies so that infrastructure components can be reused across projects and environments and operated in a controlled way.
Further development is guided by practical technical requirements: managing different infrastructures, integrating existing tools and reliably executing automations.
For us, recognition by the BSFZ therefore marks a confirmation of the research and development work carried out so far, rather than the end of development.
Polycrate demonstrates what we work on at ayedo: we do more than use existing open-source technologies; we develop our own solutions to technical problems that cannot be adequately solved by using those technologies in isolation.
The official recognition of this work as a research and development project is good news for our team.
Further information