Reviewing the System Initiative

One of the many exciting things about starting a new company is that you get to do a lot of cool things without being bogged down. As CTO for Helixiora one of my jobs is researching what is available on the market technology-wise and if/how this could be used for our customers. Combine that with a love for researching new things and 20+ years of being in deep tech and I think you can understand how it’s one of the things I love doing.

A while back I saw this blog post by Adam Jacob. Adam was previously co-founder of Chef and a person I’ve been following for years as he always has smart views on whatever is happening in his corner of the tech-world (and well beyond it too). So when he started talking about the System Initiative he immediately had my attention. Let’s dive into what it is, and how it fulfils this promise of a second wave of DevOps tooling.

The current release of the system initiative (SI) is a super early release that is more to show the concepts than it’s close to production ready. This showed in my testing, and you can see this in my live tweets of the review [here](). For this blog post though, I don’t want to focus too much on that part as it’s not productive to point to flaws in something not production ready and say “look, this doesn’t work!”.

SI felt like coming home to that old Delphi world: a visual designer for your (cloud) architecture. I love that idea, and the idea of a continous check in the background that tells you wether it even makes sense to hit a deploy button

Instead, I’d like to talk about my first thoughts when using the product. At the very start of my career I was a Delphi programmer (tell me you’re old without telling me you’re old) and I loved all of it. The Delphi IDE was well designed, the language easy to read yet extremely flexible, the presence of a compiler and debugger meant catching so many issues before ever getting to production. The strong-typed language of Turbo Pascal meant you couldn’t just assign an integer to a string and act like the world is whole. Anyway, before I go in old-man-yells-at-cloud mode: SI felt like coming home to that old Delphi world: a visual designer for your (cloud) architecture. I love that idea, and the idea of a continous check in the background that tells you wether it even makes sense to hit a deploy button. Given enough effort is put into this compiler, I’m convinced this could be a game changer.

I do have really strong feelings about the implementation choices that were made so far. I know we live in a web-based world and there’s reasons to go for a web interface, but I solidly think this is the wrong choice here. You miss out on the rich UI options that an OS provides, as well as local disk access; you are sandboxed into a browser tab. Right now you see that the backend runs a bunch of tech locally, which is a very heavy way to get around these browser tab limitations. I hope this will be revised in the future.

This leads me to my second small gripe: the resource usage was so heavy it brought my 2019 MacBook Pro with 16G RAM and i5 processor to it’s knees. It made testing SI much more difficult and while this falls under the accepted early issues, I do want to mention that it regularly took 5 mins+ to validate a resource model of 10-20 resources. This needs to drastically change if this tool is to be enterprise ready and handle models spanning many tools and environments without hampering productivity.

This leads me to the next area of concern: how will this scale? And I mean that in a number of different ways; in Adam’s second wave of devops blog post he mentions better integration across tools and processes. If the SI wants to be this tool, it will need to integrate with many existing systems. It also needs to be able to scale to an enterprise-size model, possibly containing tens of thousands of resources across many environments. That is a big ask and while not impossible, performance and scalability is going to be paramount, as well as smart UI choices that allow you to only see the part of the model that is relevant to your current context. It will need a good Role Based Access Control mechanism so people can see each other’s work without being able to cause damage to it.

Something I saw early signs of, but I think will be key across the board is: a plugin system that allows people to extend the system in all kinds of manner. Wether it’s supporting your own flavour of public cloud, an external build system or that archaic enterprise tool you are forced to use, if SI can’t live with it (and ideally you can create plugins to support it) it will ultimately not be a better integrated tool.

I see huge potential here, but also so many things that need to go right before we can all use SI as our day-to-day tool.

And that leads me to tie it all back to Adam’s blog post. Is this really the 2nd wave of devops? What does that even mean? I see huge potential here, but also so many things that need to go right before we can all use SI as our day-to-day tool. When you think about it, maybe SI is taking too much challenge on: it’s not only trying to introduce a new way of working with this IDE-approach, but also manage the tech underneath it, even if it relies on Typescript. This is a tall order, and one I’d love to see them succeed on!