Management functions are an upcoming new capability in System Initiative, that allows a model to manage its own attributes; create, update, and delete components; and enqueue actions. In their first iteration, they’ll be used for three big use cases: importing existing cloud resources, modular templating, and management of existing components. This blog post will fill you in, but if video is your thing, you can watch the readout of the opportunity on YouTube.

If this is your first exposure to how we communicate about the on-going development of System Initiative, welcome! You can learn more about what opportunities are, and how we work on System Initiative on our docs site. You might also find our vocabulary page useful.

Importing existing cloud resources

Not all projects are green-field projects - frequently, a whole range of existing infrastructure is already in place. With management functions, you can add an asset to the canvas, set its resourceId property, and then run the Import management function. The function will then look up the resource in your cloud provider, use that information to populate the properties of the component, and then schedule a refresh of the resource when the change set is applied.

Under the hood this is fairly straightforward to implement. We will:

• Add a new function management function type
• Add a universal /root/si/resourceId property to every schema
• Allow them to set component properties of the model they were called on
• Allow them to enqueue an action for the component

You’ll then execute the import management function either by right-clicking on the component in the living architecture diagram or selecting it from a list of management functions in the attribute panel.

You can compare this functionality to things like terraform import or pulumi import, but rather than trying to fit the resulting code into your source code, it simply updates our underlying data models.

This work is underway now, and you can follow our progress in our weekly demos posted to our changelog and on Discord.

Templating

The use case here is universal - you have a best practice for some common infrastructure (e.g. an AWS standard 3 public/3 private VPC or an HA EC2 architecture) or a common application architecture (e.g. a company standard java application deployment). You want to turn that common infrastructure or application architecture into a reusable asset with a set of higher-level properties that drive lower-level configuration. In this case, you’ll have a management function that creates all the necessary components, specifies their properties, configures their relationships, and sets their relative position on the living architecture diagram.

This work builds on the initial work for import:

• Extends the return type of management functions to allow them to specify components properties, edges, and position.
• If you execute a management function that creates components, you’ll have a ‘ghost’ component you can drop on the diagram, which sets the 0,0 position for every component specified.

The resulting flow will be to select an asset, such as an AWS Standard VPC from the asset panel. Drop it on the diagram. Set its properties, such as how many public/private subnets and a base CIDR block, then run the ‘Create components’ management function and drop the new components wherever you would like on the diagram.

One thing I really like about this design is that it solves what is frequently the most frustrating part of using templates - when the results are almost right but a little wrong. With most systems templating mechanism, you can’t manipulate the results without also extending the templating layer. System Initiatives' underlying philosophy of building 1:1 models means that you can quickly lay out some components, but then easily manipulate them directly for that last (and frequently crucial) customization.

You can compare this functionality to things like terraform modules or pulumi packages, but with results you can readily observe and manipulate.

This work follows the import work directly and builds on its foundations.

Management

A unique property of building System Initiative on top of a hypergraph of functions is the ability to manipulate the graph and have things recalculate automatically. By extending management functions one more time, from just creating components to managing existing ones, we can express complex ‘day two’ management tasks.

My favorite example here is application deployment. Imagine you write a component that describes the properties of your application - its version number, maybe an action to trigger a build, things like that. You could then write management functions that describe deploying the application, restarting it, changing the trace level - whatever you need, expressed as a transformation over the components linked to your application. You might take the application version as an input, update a container version on a docker image, and then schedule a trigger for a rolling deployment, followed by an action to do a smoke test on the results. The entire deployment process would then be laid out in a change set, ready for you to inspect and execute by hitting apply.

A unique property here is that management components can manage things they never created! “Managing” something is just another relationship - all the management component needs to understand is what schemas it accepts. There’s a lot of raw potential here.

This work builds on the work for templating, although depending on how the implementation goes, it may land at the exact same time:

• Extends the return type of management functions to support updating and deleting components, edges, and positions

You can loosely compare this to tweaking the inputs to a terraform module or a pulumi package from your own code - but it’s far less constrained, since you can encode any kind of transformation you want, and schedule actions in a much more granular way. Perhaps the best comparison is that it’s like your package learned how to be scripted. Tell me your thoughts on discord, so I can write nice documentation. 🙂

When can I expect this to land?

This opportunity has a budget of four weeks, ending October 25th, 2024. You can follow along with our progress by watching our weekly demos, posted every Monday on Discord, YouTube, and our Changelog. You can always find this, and every other active opportunity, in our Road map.

I’m looking forward to hearing what you want to build with management functions and helping you make it a reality.