When I last looked at System Initiative (SI), in July 2023, it was still in closed beta. But in September this year, it was launched publicly, so I wanted to see what it looked like now. At first glance, it seems more tightly wound around AWS — so what impact will that have?
The project is now described as “an intuitive, powerful and collaborative replacement for Infrastructure as Code.” To be more specific, it is a set of graphical components that are intended to represent their AWS equivalents as digital twins. You describe a component, and SI creates it in the AWS cloud.
In my recent post about LocalStack, a drop-in equivalent to AWS, I noted that my plan was to use LocalStack to test SI without an AWS account. That post talks a little about the AWS components that are needed to support an EC2 instance.
By closely mirroring AWS architecture, developers also take on board the AWS mindset of what cloud computing should be. For an engineer, AWS probably represents the reality on the ground, but a plan stating what exactly the computing needs are for a project should exist separately from the AWS offering.
I was able to log in to System Initiative with my previous account. I watched the “getting started” video, and I’ll follow along with that in this post. There is an early jumping-off point when creating a Workspace: 
If you let SI manage your workspace, you enter your AWS details and that is where SI sends instructions. Then you get the SaaS offering that SI is clearly focusing on, which we will follow here.
If I wanted to use my LocalStack as I set up in that post, I would need to select the “Local Dev Instance” — and you can tell by the name that this is mainly supported for internal building. However, as a compromise, I used someone else’s publicly exposed LocalStack instance, just to prove the path is viable.
Note that if you do follow along with the demo and use AWS directly, you should be able to create an EC2 instance and clean up “without incurring cost.”
The first concept is the Change Set; this makes sense in terms of digital twins. We want SI to be as close to being “the source of truth” as possible, so you design any changes first before implementing them in the real world.
I pressed the blue button at the top. We then get into dragging and dropping AWS “assets.” When Adam Jacob first talked of being inspired by the game development platform Unity, it was this aspect he was thinking of.
First we grab an AWS Credential. This is going to store how we authenticate with AWS:
That number “5015” is an arbitrary GUID. Either way, the user is encouraged to rename this.
We will next create an Access Secret; you will need to find that information in your AWS account. Next we add a region and set this to US-EAST-2 in Ohio.
Next we drop in a Key Pair. As instructed, I changed the component and Key Pair name to “si-tutorial.”
Next we do the big one: Drop in the EC2 instance. This will sit inside the region, next to the Key Pair. Note that you can already tell that we may be doing some shoelace wiring next:
We name the EC2 instance “si-tutorial” and choose the instance type to be a “t2.micro.” (At that point, SI went into maintenance mode for a brief period, so I could no longer add components.)
When things returned, I connected Key Name on both components. Then we drop in an AMI, named “Fedora Core OS,” and use the ImageId shown in the video, which is mighty difficult to make out and as yet not added to the notes on YouTube (although others have asked). Looking at the Discord, it appears to be ami-04000bc04ccee958e for US_EAST-2. We tie the image to the instance:
You’ll note from the red crosses that I have three components that have not “qualified” yet — including the top two. Qualification failure indicates that an instruction did not work at AWS. This is because I had yet to connect to the public-facing LocalStack instance.
When I updated the Credentials component with the right reference, things were fine, except the LocalStack probably did not have the AMI image in its limited records.
On selecting the workspace, we see that two queries have come up. These are the two actions that SI will send to AWS to create a key pair and the instance:
SI understands that when the changes hit the cloud, real costs might be made. But it also understands that these must be applied to ensure the real side is in sync. If I apply the changes, the two actions slowly get called and applied. Some confetti then shoots across the screen to show success.
As I’m not using real AWS, I don’t have to worry about the clean-up steps that are also included in the video.
Behind each component is a command that we can look at. Let’s look at the failing qualification for the image:
So we can see the entry for what I believe is the Image Id but that it has failed qualification. We can then confirm that the image was not found within the response:
So if I had connected to AWS, I would now have an instance ready and infrastructure around it.
Conclusion
While there must be a general model of how the computing you use is held together to serve the business needs of your venture, a digital twin tied to AWS architecture represents what developers actually deal with. The CAD-style diagram provided gives a good 300-foot view that most people can consume.
The SaaS path is satisfying while still giving details underneath. At the moment, building SI locally is not where the focus is, but I showed the jumping-off point for building locally. And I did actually use a publicly available LocalStack to complete the tutorial — if not the one I had prepared!
I think the way this has developed since the closed beta makes it even more likely to attract attention from Amazon — which might lead to direct competition or even acquisition. Either way, it provides a strong possible option for your future infrastructure work.
The post How System Initiative Treats AWS Components as Digital Twins appeared first on The New Stack.
System Initiative is a set of graphical components intended to represent their AWS equivalents as digital twins. We take it for a spin.