Infrastructure is now declarative language-based rather than defined through the use of screwdrivers. While the software life cycle revolves around the CI/CD pipeline, deploying all elements of the software stack from app to infrastructure can be done through GitOps. Loris Degioanni, Sysdig CTO and founder talks with Mitch Ashley about infrastructure-as-code (IaC), shift-left security, GitOps, Sysdig’s recent acquisition of Apolicy and the announcement of Sysdig’s automated service integration for open source Prometheus automated discovery, labeling and metrics. The video is below, followed by a transcript of the conversation.
Announcer: This is Digital Anarchist.
Mitch Ashley: I have the great pleasure of being joined today by Loris Degioanni, who is CTO and founder with Sysdig. Good to be talking with you, Loris.
Loris Degioanni: My pleasure. Great to be hear.
Ashley: Love to hear some more about you. Tell us a little bit about yourself and tell us a little bit about Sysdig.
Degioanni: Yeah. So I’m the founder of Sysdig. Sysdig is my second company. My first company was called CACE Technologies and was the commercial entity behind an open source network analyzer called Wireshark. So I’ve done open source my whole life. With my first company more like revolving around network packets, and with Sysdig, my second company, revolving more around security and visibility for containerized Kubernetes and cloud infrastructures.
Sysdig is a secure DevOps company and we’re a product family that specializes in tools that follow the life cycle of applications that are deployed for containers and for the cloud, and also we offer shift left and real-time security. We offer on-time security and we offer also forensics _____ in a complete lifecycle.
Ashley: Fantastic. Yeah, it’s sort of the whole infrastructure-as-code in containers, of course. Super popular. Very hot topic. Let’s do this. I’d love to get your thoughts on sort of the state of infrastructure-as-code, because now we’re talking about essentially the full range of what all the kind of products and tools that you have operate within, because I’ve been doing a lot of talking about how DevOps needs to think of itself as a dynamic.
Everything is changing, right? It’s a fluid, it’s not a solid. And that’s very much the world as infrastructure-as-code, because anything can change at any time. It can be ephemeral. So the ability to know what’s happening, what happened, where you’re going is a different model. It’s a different kind of thinking. What’s sort of your assessment of where we are, where we’re heading?
Degioanni: Yeah. So from this point of view, definitely the world is changing. The way we are writing our software is changing. The pipeline, the CI/CD pipeline is becoming the king, the center part of our existence as developers, which we do everything. We do our builds, but we also do security. We do our management. The tested with the lifecycle of our software revolves around CI/CD pipeline. And infrastructure-as-code sort of follows, in my opinion, the trend. We are moving from the time when infrastructure, deploying and delivering infrastructure, it was something that was related to screwdrivers, inputting servers on the rec. Now we’re moving –
Ashley: Rack and stack.
Ashley: We don’t say that much anymore, do we? [Laughs]
Degioanni: Exactly. You and I are probably old enough. The young generation doesn’t even know what that is anymore. Now you provision your software typically from a datacenter or even more likely nowadays from a cloud provider. And infrastructure-as-code is the evolution of this that allows us essentially to specify, to declare our infrastructures as a piece of software, as a declarative language. This is from one point of view in its evolution, because since we are just provisioning software on somebody else’s infrastructure, we just need to give instructions for what we need.
And the best way to give instructions to some external service is a code, is an API, is a definition. But at the same time it’s revolutionary because when we start treating our infrastructure really like it’s code we also start having all of the potential approaches with our code. And for example, GitOps is one of them. Right?
Ashley: Oh yeah, very much so. I mean, that’s only possible because when we become all software very much so.
Ashley: So often when we say infrastructure-as-code folks immediately go to Terraform. That’s what it is, and it’s much more broadly defined than just one tool, as great as Terraform might be. As you talked about the heartbeat of software being that CI/CD pipeline, is there a way that you think of infrastructure as code across that pipeline? Is that sort of how you build a mental model of it? How do you define it?
Degioanni: Yeah, very much so. And Terraform, of course, is super popular and super important. But to Terraform, which is becoming more and more like the cornerstone of declaring your infrastructure, for example, for the cloud, I would also add Kubernetes. Because in practice, when we are running services on top of Kubernetes, Kubernetes is completely declarative. So while maybe Terraform is more like at the machine level, Kubernetes allows us to declare our infrastructures at the service level, at the team level, at the dependency level.
So it’s more like these two files really coexist more and more and cover two very important aspects. And of course that ties to your comment about the CI/CD pipeline, because then when both our, let’s say, host declarations and infrastructures and also our services are all essentially stuff that is more or less YAML files then it’s very natural to put them and version them on a server like Git server or something like that, and then you can start doing with them stuff like, for example, Security-Net, which is something that Sysdig specializes too. Because the same way we talk about shift left when we secure our code and get closer and closer to where the culture resides, where the developers essentially manage this code in the Git repository, same with infrastructures. We can go left and we can start securing them early on in consistent way that reduces the mistakes and makes all of us more efficient.
Ashley: A mental model I’ve started to use, talking about this when people ask why is this so different than how we normally think about software architectures, how we create apps, I describe it as think of a solid cube and think of it as a Rubik’s cube, of a lot of elements comprised together that can be mixed in a variety of – and that’s changing constantly, and that’s kind of the environment that we’re in. And so you bringing up the security topic too, oftentimes security is sort of one of those last steps. Testing, security, compliance, documentation, we’ll talk to those folks at the end. Now of course shift left, that’s got to be built into that fabric, that architecture, that software architecture, that infrastructure throughout it, because that’s why we have the observability and things like that. It’s that you can’t treat it as looking at it from the outside, right?
Degioanni: And this is even more for infrastructure, because with code at least at this point it’s pretty well accepted that, okay, it’s a good thing to start worrying about security early to expose security to the developers. And security at that point can really not only be an afterthought but can also be something that is actively recommended to you. With shift left security, we can have, for example, security tools automatically open a pull request for you, so when they detect something that you’ve committed that is not right from the security point of view. And as a developer that is actually a great benefit.
Imagine applying these two infrastructures. So there’s a lot that we can do in terms of defining policies and good practices for our infrastructures in terms of – imagine something very simple, but making sure that no machine gets started with a default password, for example, or with some unhealthy network configuration settings or stuff like that. We can encode these into policies and then we can tailor where to locate. Whenever one of my development teams declares an infrastructure for Terraform, for Kubernetes and so on, go and enforce that and maybe open a PI so that the developer doesn’t even have to ever worry too much about this, just accept the PR and that can be fixed for you.
Sysdig just acquired a company called Apolicy, which does exactly this. Because we really think that this is the future, and not only for vanilla code, like your Java, your Gocode, but those are for your infrastructure declarations. Shift left is going to be revolutionary.
Ashley: Tell me a little bit more. I’d love to hear more about what was so attractive and why you decided to acquire Apolicy.
Degioanni: Yeah. I would give you three reasons. The first one is that like Sysdig their technology is built on open source. We really believe at Sysdig that one of the biggest revolutions that we’re living in computer architectures right now is that the operating system of the cloud, Kubernetes, is an open source, community-driven initiative. So we really believe that also the ancillary components like security, like visibility, like observability and so on need to come from the community in the form of open source.
So Apolicy is an open source engine which is based on OPA, the open policy engine, which is a fantastic way to essentially define these policies in a flexible way and make them essentially controllable by defining a user, and that’s something that’s really based on community standards.
Ashley: It kind of fits that declarative model and open source. Similar DNA, so some good fits there.
Degioanni: Exactly. Because then you get policy-as-code, right? And so your policies as well that will check your infrastructure-as-code, those are also in Git as well. So it’s all part of the same workflow. And the other thing that we loved in Apolicy is that they have this fantastic remediation workflow. So again, for DevOps or for developers, but they essentially look at your infrastructures, they validate your activity on Git when these infrastructures are a version of Git, and automatically they remediate for you by opening PRs, by doing fixes and all this kind of stuff.
Actually, let me add maybe a fourth reason, which is they have a phenomenal team, a great culture for this team. Very smart people. And so we’re looking forward to working with them.
Ashley: Fantastic. Wish you the best for both you and Apolicy team in that acquisition.
Degioanni: Thank you.
Ashley: I think you have a release either coming up or that’s already out, something around automation and monitoring. Tell me a little bit about that.
Degioanni: Yes. Actually this week Sysdig is announcing the first automated cloud native service integration for Prometheus monitoring. What does this mean? This means that more and more – we were quickly touching on observability before – more and more teams around the world are standardizing on Prometheus as their way of collecting metrics. Any kind of metrics. But observability is more and more important and more and more like a key, a foundational aspect of modern infrastructures.
And Prometheus is quickly becoming the default way. At the same time, Prometheus can be complex, can be changing. So Sysdig offers a managed Prometheus service that allows people to have a solid partner when it’s a matter of centralizing, scaling, and managing essentially their Prometheus metrics collection. And this week we are announcing a bunch of features for this solution, that includes automated discovery of Prometheus integrations, which can sometimes be a challenge. It includes a PromQL Explorer, so a tool that allows people to experiment and learn queries in the Prometheus query language, which can sometimes be complex.
And so this helps and decreases essentially the barrier to entrance in writing Prometheus queries. And then we are announcing a system of automatic labeling, auto for Prometheus, that allows us to simplify up to 90 percent the data ingestion and the queries that people do on Prometheus. So it’s our Prometheus server managed for our users that is becoming better and better, and this week we have these next features that will be released.
Ashley: Fantastic. I’m curious. When you do your releases, like this one or others, do you often do some open source part of a release and then more of a commercial part of a release or are these things on top of open source? How does that structure work?
Degioanni: So very much Sysdig actually believes that the foundation of our commercial solution should be open source. So we base our commercial solution on a bunch of open source tools; open source Sysdig, which is for troubleshooting in forensics and gave the name to the company; Falco, which at this point is a cloud native computing foundation project we donated to the CNCF a couple of years ago and now we are waiting to graduate it. Falco is like the agent for run-time security that is a fantastic open source project but is also essentially the core for our commercial product. And then of course Prometheus for metrics.
These are our projects from one point of view we base our commercial software releases on. But we also contribute as a company and we participate essentially to make our releases, especially for Sysdig and for Falco, together with the rest of the community so that we are sure that our commercial users rely on products that offer the best adherence to the community best practices and also the smallest possible vendor.
Ashley: Cool. Well, I wonder if I can ask you to take your crystal ball out for a minute, [laughs] your Magic Eight Ball, your crystal ball, and talking about GitOps and going back to that topic. There’s a lot of interest around it. There’s a lot of folks who maybe aren’t into a full software-declarative environment to be able to do a GitOps kind of approach. What are your thoughts?
Are we moving to a world where everything’s going to become GitOps or is that going to be a more specialized corner case? Is that going to be for certain kinds of scenarios? Where do you think we’re headed with that kind of an approach?
Degioanni: I really think that it’s going to be exactly like with code, like computer software and Git and the CI/CD pipeline. There’s no way five years from now that anybody will write and deploy software in a way that doesn’t revolve some kind of CI/CD pipeline and automation. The GitOps is exactly the same. In my opinion, it is so revolutionary, so powerful. Think about initially GitOps for us was just a way to declare our infrastructures on Git so that we could be more efficient and maybe make less mistakes.
Now the new wave that is already starting that is sparking is the security, exactly like shift left security. We are going to have shift left security for infrastructures and all of our infrastructure security will revolve around the CI/CD pipeline and around GitOps. But then there’s the longer term, and it’s like imagine what you can do when you can maybe tie observability and metrics to GitOps and the ability to take information from your running application, your running services, your running software, and create a _____ group to your infrastructure declarations maybe to have the proper capacity, cost optimization, enforcing of the practices. You name it.
But there’s definitely a big potential, and Sysdig is already investing into this, to really take these infrastructure definitions and tie them to what you’re learning when these infrastructures are running or what you’re learning from perspectives from other users and just feed this back. And ideally this makes our software better, more powerful, more secure, and since software is powering the world, hopefully this also makes the world a better place.
Ashley: I definitely agree. I also just wanted to say thank you. I mean, there’s so many whom have the benefit and use either open source directly or build on top of that stack, so I appreciate all your contributions and continue to move, not only where we’ve been, where we are, but moving that ball forward. So Loris, it’s great to talk with you. Loris Degioanni, CTO from founder from Sysdig. So good to talk with you. Hopefully you’ll come back again and we’ll chat some more.
Degioanni: Thank you very much for having me.
Ashley: You bet. Thank you.[End of Audio]