Getty Images

Chef founder's new venture: IT infrastructure digital twins

System Initiative, out in private beta this week, visualizes complex IT environments in digital simulations where users can test updates before real-world deployments.

As co-founder of Opscode, later Chef Software, Adam Jacob had a front-row seat to the first generation of enterprise DevOps tools. Four years after leaving Chef, he's back with a new tool aimed at making life easier for the next generation.

System Initiative came out of stealth this week with $18 million in venture funding and a private beta release of its infrastructure management software, with plans to offer a commercial SaaS product in the coming months.

The company's eponymous tool creates a virtual representation, or digital twin, of production IT infrastructure, where IT ops teams can test configuration changes and deployments before releasing them into the real world.

Companies in the networking space, such as Extreme Networks, Cisco, Juniper Networks and HPE Aruba, market digital twin simulations for their network products. Atos Syntel and Microsoft Azure offer digital twins for business and IoT environments.

System Initiative is focused on configuration for IT infrastructure as code. Its visual interface shows immediate warnings if it detects configuration errors and automatically adjusts dependent IT infrastructure resources in response to changes. Once a working model is configured, System Initiative software can continually update the production environment to match the digital twin and vice versa.

TechTarget Editorial spoke with Jacob, CEO of the company, about his new venture, and why he feels that the current DevOps toolset is doing it all wrong.

Editor's note: The following was edited for length and clarity.

Did you leave Chef with this idea?

Adam Jacob, CEO, System InitiativeAdam Jacob

Adam Jacob: I knew the problem was that the way the whole system worked, the entire workflow was our problem. It wasn't 'this tool is wrong, or that tool is wrong.' It was that the way we work is wrong.

What we wanted to do in the enterprise was help everybody get to a place where they were collaborating better. They were getting this fast flow of work into production, they could deploy hundreds of times a day if they wanted to, with safety and security … and we weren't getting it. It wasn't because the tools weren't great -- the tools were awesome. It was s because the way we put them together caused the way people worked to be wrong.

When I left Chef … I knew that I was not done with the operations and infrastructure and development. … I knew I was going to start a company. But I didn't know exactly what the right angle was.

A lot of what has happened over the last four years has been just relentless prototyping. We built so many versions of System Initiative that just weren't good enough, to be honest -- where when you looked at the workflow you got out the other side, they weren't better than the status quo. It took us a little more than two and a half years to land one where we were like, 'Oh no, this is better.'

Then you must back into, 'How do we make it as powerful, fundamentally, as all the things we do today?' which is another huge ask. It's one thing to be like, 'Here's a workflow that's better.' It's another thing to be like, 'This workflow, we're convinced, has the bones to eventually work at Citibank or Facebook.'

Low-code/no-code is a buzzword now. Would you put System Initiative in that category?

Jacob: No, I wouldn't. Usually those products target citizen developers, and they look like System Initiative. But those tools are usually designed to take a complicated thing and make it simple for people who don't understand what's happening. System Initiative takes a complicated thing and makes it more powerful for people who know what to do. It's a power tool designed for experts to do expert-level things.

Over time, it'll grow and change the semantic scale at which it operates for different people. … But the system scales all the way down to the detailed bones.

Would it be correct to call it a digital twin?

Jacob: That'd be accurate. The reason people go to low-code/no-code is because we are building a powerful visual interface that lets you deal with complexity. But in many ways it has more in common with the complicated visual interfaces you see when people do visual effects, pro audio or pro video, or build triple A video games, right? Complicated systems that use multimodal interfaces.

What is under the covers that's modeling the infrastructure and generating configuration code?

Jacob: It's a combination of Rust, Typescript and Postgres.

The best way to think about it architecturally -- the heart of it -- everything you model is put into this giant graph. Every value is a point on a graph. But it's a call to a function that generates the value. Then they take inputs from elsewhere in the graph. Other configuration values or state transitions are fed as inputs to those functions. Whenever one of those inputs changes, we automatically reroll those functions that depend on them. That whole process cascades. It's like how React or Vue work, only we're doing it at the layer of these big complicated configuration models.

System Initiative interface screenshot
System Initiative creates a digital twin of IT infrastructure where IT ops teams can test configuration changes and deploy them automatically, including dependencies.

From the demo, it seems focused on Day 1 -- initial deployments or updating an existing deployment. Obviously, you have to start somewhere. But are there Day 2 possibilities for the future?

Jacob: 'You have to start somewhere' is exactly the answer. It's easy to build a toy that looks great but doesn't let you deal with all the complex things that need to happen later. We've put a lot of effort into making it land with that complex use case.

Part of getting it shipped is doing all the work to get those foundations right while also recognizing that we're going to have to do some discovery together with the community about what's the best experience. But it's designed more for Day 2 than it is for Day 1.

We're tracking both the state of the model in the simulator and the real world at the same time and letting you see that visually and reconcile it.

If somebody changes AWS, we'll detect that they made a change to that resource. We can show it to them visually and say, 'Hey, this thing has changed. What do you want to do about it? Do you want to update the model so that it reflects what the real world is? Do you want to update the real world so that it looks more like the model?'

We're collecting a ton more data than the traditional tools do and then we're using that data to present you with new user interfaces and provide better user experiences to all the different people who need to collaborate.

How are you collecting that data? How is this deployed?

Jacob: In a bunch of different ways, depending on the consumer. When we open source it, you'll be able to just run it on your own gear. But then shortly thereafter, we'll launch a bring-your-own-cloud SaaS, where you pass us some credentials and we'll go build you an instance that we manage in your cloud provider. Shortly after that, there'll be a full multi-tenant SaaS.

For security-conscious folks that don't want to hand over credentials, would they go for the open source version?

Jacob: Just like with Chef, our business model is that we sell [a commercial version of] System Initiative for money, so there won't be an open source version that you can run from me. But I may give you a liberal license to my proprietary distribution.

The other part built into the design is the executors -- the agents that are running these functions for you. You can run them in your own environment. One of the good things about bring-your-own-cloud SaaS offerings is that what we're running is the control plane, and then you have lots of control inside your own account of what it can or can't access. You can design that security boundary. If you need to run the software completely yourself and isolate it, you can, but most people won't.

What happens when something goes wrong, either with the underlying system or with the System Initiative tool itself? What's the troubleshooting story?

Jacob: Traditionally, the way that works is there's the tool you're using, and then there's the language it's written in. If something goes wrong, you have to drop down to the language -- you have to go hack on the Rust code to solve your problem. You can do that with System Initiative. It's open source; you can come and hack on it or tell us about it.

Most of the time, though, you don't want to change the software's source code. You just want to change how the models work and change its behavior. That customization is built into the product. … You click a button, and it turns into an IDE that's loaded with TypeScript. You just write TypeScript functions, and that describes the entire functionality of everything. That's one of the things we're tracking for the open source release -- that authoring experience. We want to make it a little better and a little smoother, and then we want to have an integrated publishing experience. You'll also then be able to save those changes and reapply them to new workspaces or share them with the external world.

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.

Dig Deeper on DevOps