In this episode, Quali CEO, Lior Koriat discusses the finer points of infrastructure automation for software delivery and how to future proof your DevOps practice to keep up with an evolving industry. Check out the video and full transcript below!
Future Proofing Infrastructure Automation
Q: What do you consider to be a major problem in the market?
A: So, with the growing wave of application modernization and digital transformation, which is more than just about buzzword, there is a growing demand for agile infrastructure and agility altogether. And while we have great technology that is constantly evolving and growing and new technologies being introduced, whether it started from cloud and then containers and serverless and service mesh, it allows you to do a lot of great things. But it also introduces a great complexity and great threat, if you will, of cost and security.
So that complexity started to slow organizations down. And you will either find yourself gated in bottleneck because somebody has to control that cost, and somebody has to control that infrastructure. Or you'll find yourself really building a huge DevOps or automation team that is the size or the cost of your developer teams, just in order for you to go and get through that complexity and automate the infrastructure for it to be available to the developers, so they could actually develop the applications. That this is your business and what you're trying to do.
So, I would say the main problem today in the world of DevOps is the fact that the infrastructure complexity slows DevOps processes down. And that's what we're here to solve.
Q: How is Quali's approach to infrastructure automation different than infrastructure-as-code solutions out there?
A: Infrastructure-as-code is a great way to really address tactically automating small sets of infrastructure, that might not be entirely associated with the business objective of the company. And while you could automate almost everything with infrastructure-as-code, that still requires a lot of knowledge, deep knowledge of the infrastructure. And it also, again, introduces the burden and accountability and liability on the cost of that infrastructure and the security of it, of whomever is coding it.
So, in a way, it doesn't solve the problem of the complexity of the infrastructure, it actually introduces a new challenge and a new barrier of skillset. So, our approach is really to offer a managed service for infrastructure. And with the complete accountability for the entire life cycle of the infrastructure, from setting it up to tearing it down, to the security and the policies around it. So, you could actually really just consume infrastructure as a service and keep on developing what you need to develop, your application or your service that you spin up on that infrastructure. So, our approach is really to enable business through technology, rather than focus on the technology itself.
Q: What do we do better than anyone else in the market?
A: So, we offer really the only platform in the market today that combines the three key pillars to automating infrastructure. A, obviously you have to be able to automate, but you need to automate it in a way that is technology agnostic. Technology constantly evolves, and you need to make sure that you stay future proof in that sense, and you're not just tied to a specific way of doing things.
Secondly, you need to really deliver a self-service to the developer, to the source of the demand of that infrastructure, because it's the developer and the application that infrastructure, and the infrastructure is just the train tracks on which you ride. So, the self-service itself, which sounds trivial, is not so much trivial because you need to think of the developer and have him in mind. And thirdly, you will never provide and give anybody self-service without a strong controlling governance.
And that's what we offer. So, we're pretty much the only company out there in the market that offers all three in a DevOps-oriented fashion. The way we do it is really, our secret sauce is what we call environments, which are a higher-level entity that entail the application itself be coupled from the infrastructure, and with the state of that environment, which is usually the data that it has to rely on. And if you have that environment, it truly allows you to both drive infrastructure in context, because you'll spin it up in context. Whether it is the application, what exactly you are doing along the lifecycle of it, you're spinning it up. It's unit testing, it’s development, it's testing, it's staging it is the production side.
So, you really can track and tag in context of what you're using and when you're using it. It gives you greater control and visibility. And it also gives you the ability to deliver management aspects of role-based access control. Meaning who has access to what, how much does it cost me, policies around costs and security, et cetera. So, the combination of business context and control and governance that is provided through this secret sauce, is what makes us unique.
Q: Automation is such a widely used word. How does one sift through all of the noise with it and all the other tools and buzzwords like CI/CD Jenkins, Chef, Puppet, Ansible?
A: So, the DevOps space is really cluttered, and you have tons of tools and a lot of automation out there. But the world has started to look into DevOps more in the context of value streams. And that makes a lot of sense because, you break it down into the different functions that you would like to get out of this automation. So, you'll have obviously the value stream of release automation and pipeline management that takes care of your lifecycle of the application.
And you have other automations associated with configuration management. Although the Puppets and Chefs are not exactly DevOps solutions, it's more a static thing, but they are being used and utilized for Dev. And you have elements like source control and artifacts, and security as code or policies for security are starting to also become part of an automated DevOps process.
So, if you look at that and the different value streams, the one thing that is missing in a big way is the infrastructure itself. Those are the train tracks on which the train is riding, and that has been taken for granted for the longest time. You have clouds that go ahead and do whatever you need to do. But now with this becoming a bottleneck due to complexity, what we're trying to do, and what we're doing, is actually turning that into a value stream by itself. So, you could streamline again that complexity and have a smooth ride all the way through DevOps.
Q: What does open source mean to automation? And where is its sweet spot, at what point does it hit a wall, and the use of enterprise software becomes valuable or critical?
A: So, a lot of open-source solutions today around infrastructure automation really take the shape and form of infrastructure-as-code. And back to my point earlier, that introduces just another great deal of hassle. It does not solve the problem of how to make that infrastructure accessible, it just allows you to automate it. But what it requires from you, is a great deal of additional knowledge and skillset that the organization now has to acquire.
Still, cost and security remain a very big challenge and consideration and a burden. So, if you're a small organization, and if you have 10 20, 50 developers, I would say that's the limit. And you're agile as an organization, and you can actually allow your developers to get the keys to the cloud because you trust them, then you might get by with automating things through infrastructure-as-code then, putting the burden and the accountability and liability on those developers who are doing that.
But as you grow as an organization, you run into two challenges of scale. One is that skillset becomes an issue, so that they need to really maintain a DevOps or an automation team that is as large as your developers team, because they really understand and know how to focus on building applications, not necessarily infrastructure. That becomes really costly and slows you down. Or you would say, "You know what, at some point I cannot even scale back too much, it's just too costly. Then how do I make infrastructure accessibility in a safe and productive manner to those thousands or hundreds or tens of thousands of developers?"
And this is where at that point in time, you really realize that you need to go for an enterprise solution, that starts to think about the business process and address the need to deliver that infrastructure in a safe and productive manner. Rather than just saying, "Okay, it's very cool to code it." And it just becomes unscalable. So, this is where usually you might still continue to use open-source solutions to automate specific elements inside a specific environment, but then you just have to take a different approach to make it self-service to those developers.
Q: If you were sitting with a CIO, CTO, or any other IT leader, what would be your advice from a DevOps perspective?
A: So, DevOps is a practice, more than anything. In order to practice that you really need to have adoption across your organization. And you need to be agile, not only in the infrastructure that you have, but also in your approach in how you do that. And many organizations really, or many cultures, are still very much siloed. And if you have many applications in your organization, or if you have many groups or many teams, each one might adopt a different way of going about automating your infrastructure or automating your DevOps processes. And you end up with a lot of different islands of automation, which are the only islands you don't want to be on.
So really the advice is that as a C-level, you need to listen to your team for sure when it comes to the technology that they want to use, but you really need to make sure that that does not take away from your ability to scale as an organization, and not eventually get stuck with those silos. Probably you still have not only super modernized the applications, but you have a mix of also some monolithic or even mainframe applications. And you really need to think about the overall business of your organization and how you were about to deliver that.
And you should choose something that is future proof, because you know that the technology is also going to change. Because when it was just private cloud, you thought that was the answer and already we're a few years after, and you have service mesh and serverless. And that's even way more advanced than DMs and the public cloud. So, technology is going to change very rapidly. You have to choose something that is future proof, that allows you to focus on the business, and just adopt new technology that would be enabling rather than slowing you down.
Q: When you think infrastructure automation, what is the first word or phrase that comes to mind?
A: Infrastructure automation at scale.
Arta Shita: I love it. Wonderful. Thank you so much for your time today, Lior, it's a pleasure to speak to you as always.
Lior Koriat: Thank you very much.
To learn more about future proofing infrastructure automation, visit quali.com or request a demo of CloudShell Colony.
