VOOZH about

URL: https://thenewstack.io/system-initiative-could-be-lego-for-deployment/

⇱ System Initiative Could Be Lego for Deployment - The New Stack


TNS
SUBSCRIBE
Join our community of software engineering leaders and aspirational developers. Always stay in-the-know by getting the most important news and exclusive content delivered fresh to your inbox to learn more about at-scale software development.
REQUIRED
It seems that you've previously unsubscribed from our newsletter in the past. Click the button below to open the re-subscribe form in a new tab. When you're done, simply close that tab and continue with this form to complete your subscription.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.
Welcome and thank you for joining The New Stack community!
Please answer a few simple questions to help us deliver the news and resources you are interested in.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Great to meet you!
Tell us a bit about your job so we can cover the topics you find most relevant.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Welcome!

We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.

What’s next?

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

PREV
1 of 2
NEXT
VOXPOP
As a JavaScript developer, what non-React tools do you use most often?
Angular
0%
Astro
0%
Svelte
0%
Vue.js
0%
Other
0%
I only use React
0%
I don't use JavaScript
0%
Thanks for your opinion! Subscribe below to get the final results, published exclusively in our TNS Update newsletter:
NEW! Try Stackie AI
From clobbered drafts to real-time sync
Apr 14th 2026 10:00am, by David Moore
TypeScript 6.0 RC arrives as a bridge to a faster future
Mar 14th 2026 9:00am, by Darryl K. Taft
Mastra empowers web devs to build AI agents in TypeScript
Jan 28th 2026 11:00am, by Loraine Lawson
2023-07-22 04:00:00
System Initiative Could Be Lego for Deployment
DevOps / Operations / Software Development

System Initiative Could Be Lego for Deployment

Adam Jacob, who previously created Chef, has a new DevOps 'power tool' called System Initiative. Could it be Lego for the deployment world?
Jul 22nd, 2023 4:00am by David Eastman
👁 Featued image for: System Initiative Could Be Lego for Deployment
Image via Unsplash

Listening to Adam Jacob talk on the Changelog podcast, I was interested in his reference to how Unity (the game developer platform, and competition to Unreal) uses a GUI hierarchy model to tie together code, configuration and components. He wanted to do something similar to help DevOps make more sense. Adam Jacob is the guy behind Chef, so he knows about infrastructure woes.

So what is System Initiative (SI)?

System Initiative is a collaborative power tool designed to remove the paper cuts from DevOps work.

This isn’t a very arresting elevator pitch, initially.

Now Mr. Jacobs’s theory is that with so many “best in class” systems that have no common glue between themselves, big projects tend to get knotty fast. He talks about ‘paper cuts’; these are the many small annoyances that add up to frustrated deployment paths. For example, one tool stores data in JSON, another in YAML. One tool allows scripting in Ruby, another in Python. But deeper than that, they choose to reveal state at different times, making overall conclusions about a system difficult — think of all the “dashboards” that have come about just to make simple assertions about your deployment.

As a consultant, I’ve seen devs try to write all-encompassing toolchains, with the result that they slowly lockout existing solutions; sometimes, solutions that are used elsewhere in the same organization. Mr. Jacob correctly states that most organizations don’t deploy more than once a week — although that is almost certainly down to political theatre. Rapid deployment means rapidly cutting people out of the loop, which is one less thing for said people to write in their performance reviews. So people are probably DevOps-ing hard enough. But the complexity of operations does affect basic agility. This is where SI could gain headway.

Because loosely coupled systems have, by design, no knowledge of each other, it tends to be hard to make them collaborate or share intelligence. Feedback loops can be long, and context switching between different tools can be mind-numbing. Strangely, this setup is not too dissimilar to the siloed departments DevOps was designed to break down!

You can see the arguments laid out in a historic context in this previous article.

The video at the SI site shows you the diagram and asset sets that the user manipulates. The eventual example deployment is a website for a dubious cat delivery business; but at the end of the day we are all just delivering cats.

👁 Image

System Initiative chooses to go down the digital twin route — this allows a nice diagrammatic representation of common components (and their relationships) to represent their backend real equivalents. Creating all the “real objects” like EC2 assets can be done when the frontend model is ready. So SI allows you to connect your frontend twin components via a diagram and a library of common assets. Assets can be things like EC2 images, security groups, regions, etc. Because of the connections between these frontend components, SI can make intelligent guesses about names and intentions. For example, a Docker image’s exposed port can be connected to an AWS Ingress component with a single-line connection.

An important point comes out early on — that both the twin and the “real object” have to be considered sources of truth. The trick is to keep them in sync, or inform the user quickly when they are not. Differences are referred to as “qualifications”. Sometimes the designed frontend design is “ahead” of the actual backend. Think of this like differences in git.

The standard lifecycle of a digital twin in the industry is probably not quite the same as here. For instance, if you have a twin of a wind turbine, clearly the real object is considerably more expensive than the digital version, but the real-world environment can be reasonably modeled. If sensory equipment on the turbine reports something anomalous, this can be compared with the expected modeling at the twin. You can see how these facts are quite different from, say, an AWS security group not working. If Jeff Bezos’s operation does something “anomalous”, you won’t send out a helicopter full of engineers to save your asset.

There is an interesting trend with dev guys finally learning from game devs to take UI seriously, and what would have been a poorly written diagram app a few years ago now looks fairly slick. And with powerful laptops, managing powerful frontends is getting much less precarious.

There is a beta available, which I applied for. In order to check flexibility, I first wondered if they supported, say, Digital Ocean. And there in the beta sign-up was:

👁 Image

The system is in closed beta, but anything I experienced there just helps to give an added hands-on sense of reality for the project as a whole.

The mapping of SI to Unity development is probably as productive as thinking about digital twins. In Unity, you maintain a hierarchy of game objects and components, behind which you write code in C# to control the behavior. (I think SI is mainly written in Rust with JavaScript components.) Initially, I was a bit reluctant not to control everything within the code, but then it dawned on me that was a fairly hidebound way to control all the various data-defined objects. Dragging an image into a frame was not some type of demonic sacrifice to an evil system, it was just convenient. Sometimes the Unity model has difficulty holding together lighting, sound, physics, animation and all the other multifarious objects needed in even a modest game. DevOps components by contrast have many fewer degrees of freedom, allowing for a much better understanding of user intention.

Inevitably a project like SI can get “captured” by the makers of its most required components. Nobody would be surprised if AWS bought them up as they matured. But to escape that, it might make a wide spectrum effort to maintain an ecosystem of as many components as possible — maybe the Lego of the deployment world. As with Lego, the large set of interconnecting components defines the business. Either way, those cats need to be delivered.

👁 Image

TRENDING STORIES
David has been a London-based professional software developer with Oracle Corp. and British Telecom, and a consultant helping teams work in a more agile fashion. He wrote a book on UI design and has been writing technical articles ever since....
Read more from David Eastman
SHARE THIS STORY
TRENDING STORIES
TNS owner Insight Partners is an investor in: Docker.
SHARE THIS STORY
TRENDING STORIES
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.