How Can Enterprises Shift From Ticket-based to Self-service IT?
The key to DevOps speed is minimizing ticket-based deployment and infrastructure changes. That means providing a central set of shared automated services to developers, security, ops, and networking, so that engineers can deploy new apps or resources themselves. The key is 'policy as code,' smart workflows, and the right tool suite.
Speakers
Dave McJannetChief Executive Officer, HashiCorp
Transcript
The key element of the transition to the cloud model for infrastructure is largely around going from ticket-based provisioning of infrastructure and security and networking to self-service. It all comes back to the idea of speed. In an ideal world. I want to create a common process for my teams to deliver applications, but I want them to have the implicit approval of the ops, security, and networking teams before they deposit those applications into this low-trust environment with infrastructure on demand.
If I can use an example of how many customers do it, if I want to deliver an application, my team has to:
File a ticket to get a virtual machine created
They must then file a ticket to get the infrastructure elements installed and deployed
After the application gets deployed, someone has to then open another ticket to have the firewall rules updated so that application can see traffic
That whole process could take 12-weeks. It doesn't matter how fast you can build an application if it takes 12-weeks for the application to see traffic. I think that shift away from this ticket-based model to more of a self-service model is one of the reasons why the cloud is so attractive. On cloud, I can spin up the infrastructure when I need it. I can route traffic instantly to that application.
Now, the downside of that is how do I balance this speed plus a control element? I think there's a famous Pirelli ad that said years ago, “speed without control is nothing.” That, I think, is the challenge that people are trying to solve . In our experience, what people do is they say, “Great, if I can decompose the problem into: ops, security, and networking have to be comfortable with this new model of running infrastructure on cloud, how can I put in place a common infrastructure element that allows for self-service?
So that I can say to my development teams, “If you use, for example, Terraform for provisioning, and you only use this approved template, you can deploy 100 times a day. Number two, if you use Vault as the way you store all your credentials, again, you have my implicit sign-off. You can deploy 100 times a day.
If you use something like Consul for service-based networking so that I can trust that when this artifact gets deployed, it is okay to see traffic, then you're good to go.
I think if you combine those three things, you enable the self-service model with control, which I think is the thing that everyone's trying to get to. That's often what we refer to as this foundational investment that's required. “How do I put in place a central shared service of infrastructure that allows for this self-service model by giving the implicit sign-off of ops, security, and networking so that all 500 development teams in your company can safely deploy as if they were a 10 person company?”
