(So you can skip ahead, if you want.)

00:00 Introduction and Team Evolution
01:45 Infrastructure Automation Evolution Discussion
04:43 Platform Teams Orchestration Approach
05:37 Zero-Touch Deployment Workflow Overview
07:13 Azure Landing Zone Concepts
09:53 ServiceNow and Terraform Integration
11:26 Infoblox Network Automation Integration
14:08 Terraform Apply and Notification
18:12 Day Two Operations Lifecycle
21:44 Wrap Up & Platform Evolution

William Collins • 00:08

Good afternoon, and welcome everyone on this fine but frigid Wednesday. And you know, you know what? Like freezing cold weather, honestly, is probably the best time, I think, to um both record and and listen to an exciting webinar. Um where it’s nice and warm. Uh I’m William, director of Tech Evangelism at Itential, and with me is a new face, Donnie Page, a new Itential light that you might have not seen around before. Uh how long have you been around, Donny?

Donnie Page • 00:40

Uh yeah, a quarter or so of the year. So I you know, I started late last year.

William Collins • 00:46

Awesome. And you’re gonna have you’re gonna see Donnie here in quite a few webinars around some really cool stuff. Um infrastructure is code specific. So really glad to have you with us. And you know, you have a ton of uh expertise doing infrastructure as code, uh clout specific stuff here in the in the recent past. And it’s just so funny thinking about that the evolution of automation in general, because it used to be um hey, like I have my team, I have my tools, I’m doing my thing right here. I’m kind of like working in my own little pocket and help other teams.

William Collins • 01:24

Do they automate? Do they not? I don’t know, none the wiser. You know, but this tooling. And then the teams, the way the teams work together and the teams were structured to support the tooling. Like, oh, that’s kind of evolved and changed. Um, what are what are your thoughts there as someone that’s worked on um both sides of that coin?

Donnie Page • 01:45

Yeah, and you know, thanks for introducing me. Thanks for having me. I’m kind of glad to be on, you know, uh a webinar here at Itential. Pretty excited with uh you know the prospects here and and uh what I’ve learned over the few months. Um, you know, when you when you’re talking about sort of the evolution of automation, um you’re also talking about the evolution of the teams that have supported infrastructure over that period of time. You know, the introduction of IEC and the ability to sort of code or declare your infrastructure through code um in a declarative fashion was, you know, was very transformative. Um really, you know, provided efficiencies and and increased competitiveness for a lot of organizations that were trying to get features out the door quickly or new product out the door, right?

Donnie Page • 02:36

Um and I think what happened is you you started seeing these teams. uh automate in different fashions. So you had a network team that, you know, was using tools like Ansible or or Python scripts or something like that to start automating some of those network changes. And then you had the infrastructure teams or the cloud teams that were starting to, you know, use IAC tools. And then from a security side, you know, same thing. You were having them automate, you know, via some sort of scripting language. And those individual domains were all, you know, going down a path and and automating a lot of the work so that they would they weren’t spending as much time, you know, starting from scratch and they were able to then work on more strategic projects.

Donnie Page • 03:22

And you know, I think that evolution of code helped, but then you started seeing teams like DevOps teams and whatnot change and become, you know, DevSecOps or, you know, then you saw an introduction of like S or T SRE teams and broader SRA teams. And eventually what I think we’ve come to is we’ve come to organizations looking at creating a platform team that you know is sort of overarching all of those all of the infrastructure and all of those teams. Um and then and then you, you know, they they have a need now to take all those great automations those teams have created and sort of stitch them together um and manage them and create um standard standards or or uh practices across the board. Um you know, and and as we continue and evolve and continue and uh to go down this path, we need something like an orchestration tool, right? That a platform team can take and uh take all of those great automations and stitch them together into a single workflow and remove that barrier in between those teams, which consistently has been a ticketed system, right? Of I need a network, I need, you know, uh uh security rights, I need these things to be able to complete this deployment.

Donnie Page • 04:43

And we’ve taken uh particularly a passed um tickets between those two. So um I think we’re at a stage now, you know, from an infrastructure standpoint where we need to bring it all together, have a single team, have a single platform that we can utilize those domain specific um automations, you know, in a more effective way.

William Collins • 05:08

I love that. Uh extending the value, extending the control, bringing everything together, and you know, not working in those little pockets anymore. Yeah, thinking in zooming out a little bit and taking it to, hey, like I have a service, like what is all the automation that has to happen to bring up this new service across all these teams and have that like really well oiled and executed. What are we what are we actually gonna do or look at today? You want to frame it up for us?

Donnie Page • 05:37

Yeah, so William, thanks. I you know, I what I’d like to do today, and you know, the title of this is one touch cloud deployment. Um we don’t necessarily need to focus, you know, generally from an infrastructure standpoint anymore on, you know, cloud specific deployments with automation because a lot of the automation capabilities today can uh thrive across you know, on-prem or hydro kind of deployments as well. But today we’re gonna we’re gonna sh show you a a workflow that could be driven, you know, from a um CI C D pipeline, right? Via a commit from a developer, maybe it’s uh a tag or a commit to a branch, and that will actually trigger, you know, an API endpoint into Itential to run a workflow to deploy a landing zone for that particular application and use those dope domain specific um automations in a way that those Automations don’t need to be recreated from scratch. We’re going to use what has already been created.

William Collins • 06:47

I love that. And I guess one thing our a lot of our audience is probably network engineers, infrastructure practitioners. And they see that Azure landing zone in the the title there for that workflow, and they’re probably thinking, what in the world is an Azure landing zone? And is someone that has like Just tons of experience in cloud and operating cloud. Can you kind of give us the rundown of what is this Azure Landing Zone Day?

Donnie Page • 07:13

Yeah. So I think as as cloud deployments evolved and as organizations were trying to figure out like how do I, you know, continually or repeatedly uh deploy to the cloud in a fashion that I don’t need to redo it every time. I don’t need to, you know, go through the process. I can just have uh a landing zone configuration already created so I know what it’s gonna look like uh conceptually to deploy an application that adheres to our standards as an organization, right? So think of a landing zone as sort of that that environment that’s already created that already has sort of a network um guideline around it and a security guideline around it, so that when the when the deployment happens, all of those things are already automated. And pushed to the cloud. All the public cloud entities out there have their concept of a of a landing zone, right?

Donnie Page • 08:19

They have their architecture standards, and that’s generally more or most organizations are following, you know, their as they create a landing zone for a deployment, whether it’s to you know, a test um um region or uh uh a production region or where however they’re deploying it, but if we’re gonna always stick to this landing zone concept um to sort of generalize, you know, hey, I these are my standards for deploying to the cloud.

William Collins • 08:50

Excellent. Okay. Yeah, thanks for thanks for clarifying that. Sorry for interrupting. And I guess go ahead and just take us through this then.

Donnie Page • 08:59

Yeah, yeah, no problem. Um, so again, you know, conceptually, the way I I looked at this and you know, think about a cloud deployment is I think about it from a from say a software company that has um you know developers that are creating new services on a regular basis. Right. And and everyone wants a you know, sort of a developer self-service approach or an easy button for the developers, right? The developers create a service and they now need to that service to be deployed, whether it’s to test or production or whatever it is. So from an ITENTRO standpoint, right? That you know, maybe based on a commit to a branch, triggers an API call to a workflow and it’s all right.

Donnie Page • 09:53

So that would be the starting point to this. That trigger then comes in and starts this workflow. And in this workflow, you know, I have individual automations that are created or would be created by those domain specialists. Right. So I start off right away by having a ServiceNow . Automation that creates a change request based on that incoming uh request from the pipeline. Right.

Donnie Page • 10:26

So now I’m I’m adding to my source of truth. I’m saying, hey, we’re gonna make a change request, we’re gonna add to this environment. And then the 2nd job there that we’re looking at is an HCP Terraform job, right? So this could be Terraform code, it could be open tofu code. In this particular instance, I chose to actually go through the process of using ACP Terraform API to create a workspace. Um and attach the code to it, the code base to it, to that actually will um produce that Azure Lame Ezo. Then, you know, as as most organizations, as they’re standing up their landing zone, you know, as a platform team, I generally, you know, I’m going to go through that process, but I may then have to open a ticket to my network team and say, hey, I have a landing zone for a particular um application.

Donnie Page • 11:26

I need to know what the next available network is so I can associate it to this to this landing zone. And so, you know, again, I have a an infoblox um automation here that was created by a network engineer, and all I’m supplying to that workflow is the size of the network I’ll need for that for that particular appointment.

William Collins • 11:48

And I only make a distinction here. I think something that’s really interesting is each one of these boxes, it’s kind of a you have the platform team that’s kind of like putting everything, pulling everything together, architecting the whole process end and end, but the control is still with the right teams that own that technology that have built the automations that’s just being inserted in here, right?

Donnie Page • 12:11

Correct. Yeah. And think about it, we’re we’re not trying to change how these individual teams standardize, you know, the or put guardrails in place. Some instances, right? Where they start dictating, like we have to apply these standards because we have this um uh uh tool that we’re using that requires us to have the same across the board. You know, in these instances, we’re saying, hey, ServiceNow team, whatever those guardrails are, whatever those needs are from uh from us to be able to to create that change request or whatever it is that you need from our compute team and i apologize i say i’m saying us uh you know i come from the infrastructure infrastructure side primarily so you know i’m the one that has made those requests to the network keys requesting the next available network um but you know the they’re using their standards their guidelines to to create you know whatever it is that the request coming in from the other team um and and so we’re not changing their processes we’re not changing how they’re doing it right we’re not changing the script detour again this is this particular infoblox workflow is is using the API but it could easily be uh an Ansible script that we’re pulling in that does the same thing with infro blocks but again it was developed by the network team and we’re we’re um living by their standards from a network perspective and we’re just tying all these together to ensure that

Donnie Page • 13:56

You know, as an organization, we’re following everyone’s domain expertise guidelines when we’re building these uh environments.

William Collins • 14:06

Got it. Love it. Thank you.

Donnie Page • 14:08

Yeah, no problem. And just to continue along, so after we have this information, we’ve created the ticket, or we’ve created created the workspace, um, we take the information that we we’ve gathered, the network, the workspace. Um, and now we’re going to Apply that to the next run, which is actually going to be a run and apply um within Terraform, within HCP Terraform to actually create that Azure landing zone and actually uh deploy that application, maybe deploy a database, um, deploy the compute, maybe it’s a um a Linux um uh device. Um and and from an HCT HTP Terraform standpoint, um, we’re actually not changing that as well, right? The Terraform is still gonna apply um its state to its state file. So if you’re using you know that tool to be able to look at or manage, you know, state from that particular instance, it’s still there, right?

Donnie Page • 15:15

We’re just again using an API to use the tools that the organization is already using and not changing the tools those you those are organizations are using. Again, this could easily be open-tofu script that sits in a uh a repo, right? Or it could be Ansible uh run book that sits you know in a repo or through uh Ansible automation platform. So we’re not changing how any of these domains uh automate or create these automations. And then the last two boxes there, right? We’re going to post a Slack message. You know, uh, the owner of Slack has is created, you know, a workflow that I can then just populate that workflow with the message I want to send to the requester.

Donnie Page • 16:06

And it’s going to now send them a message to let them know their environment’s available. And then the last one there, we’re gonna we’re gonna update that ticket, that ServiceNow ticket, and close that ticket. So what’s great about this workflow is I’ve updated my source of truth. If there’s dashboards or reports or whatever that readership licks at from uh, you know, a ServiceNow or whatever your source of truth is, that was automatically updated and created through this process. An engineer doesn’t have to Take this in, go in and look at the ticket, update the ticket, right? It’s already generated because we already know what needs to happen based on our standards and guidelines that were created as an organization.

Donnie Page • 16:52

Um and and we also know that whether or not it was completed or not, because itention is smart enough to know that it was completed and continue on and and close out that ticket. You could do, you know, some human human on the loop kind of uh pieces in here as well, where you maybe have the workflow stop before the Slack message is sent, just so someone uh then needs to look or you know uh review the landing zone to make sure that whatever I have in Azure or whatever I’ve deployed in AWS or whatever I’ve deployed in VMware on-prem is is is accurate and stable and and then I can continue on with that workflow.

William Collins • 17:36

I love that. So you can kind of build up that comfort level. Like, hey, I don’t want to run it all the way through the 1st time and you know without having a set of eyes on it, so you can just make sure it’s doing exactly what you think it should be doing and what it’s supposed to be doing, and then you can yank that out at some point when you do have that comfort level. This is a great like day one exercise. Um, how do you operationalize this? Because all these different teams, you know, it’s easy to say, hey, yeah, we have this tool, it’s easy for all the teams to use, you know, yada yada yada. But how how do you actually operationalize there?

William Collins • 18:10

What does that look like?

Donnie Page • 18:12

Yeah, so I mean if you think about it, right, with with IEC tools and the automation process, they were they’re really good at day one, right? They’re really good at deploying something. But typically there’s challenges with day two, with you know, maybe changing that network configuration or maybe restarting um uh that compute instance or changing out that compute instance, right? Maybe we need to maybe we need to move from Linux to restandardize on our you know Windows Web Server uh deployment. Um and all those things can be, you know, a challenge with that with that declarative, you know, process where we deployed it and now we have to take it back. What I’m showing here within the iTenso platform is is actually our our studio, right, which is the design studio to be able to create these workflows. Um within iTenso, we have the ability, you know, to operationalize this and and create, like I mentioned early on, like an endpoint, so that this could be particular instance could be called via um an API call, right?

Donnie Page • 19:20

But again, we’re still talking about day one. Within iTension, we have the ability to create a life cycle around this workflow. Right? We have a tool called lifecycle management. And within that, we can actually define things within this workflow that we believe we want to um we want to manage, we want to uh understand the history of those items and maybe change those items. So I can actually make day two objects out of this workflow. As I mentioned, it could be a network change.

Donnie Page • 19:56

And then all I would have to do is run that particular uh instance or a workflow to change the network, and it I don’t have to affect anything else, you know, in that workflow. And I also now have the history of that workflow of those changes, when they were made, who they were made by. And again, I can update that in the source of truth, so you still have, you know, I I’ve updated that ticket to say we now, you know, change this particular instance, and these are the changes. So, you know, I think ultimately for um for platform teams, you know, they want to be able to do day one deployments, but day one changes without having to scrap or or reset or anything by just making those those sort of micro changes that you can make from their environment.

William Collins • 20:51

I love that. You mentioned life cycle manager and a few of the other parts of our our platform. We’re gonna have to uh dive into some of those in future episodes. Uh and oh, you know what, I just signed you up for a ton of work with our marketing team because we know our marketing team’s listening to this. You know, you’re you’re automatically now signed up for like 10 more of these. So sorry, sorry for that. But yeah, I I would love to continue this discussion um in the next one and just kind of see how it evolves and you know how the the different parts of the platform contribute to you know the overall infrastructure lifecycle, infrastructure health, infrastructure consistency, you know, all these things, compliance, you know, all the all the great boxes that we have to check.

William Collins • 21:35

So yeah. Yeah. Um do you have any other anything else to top of mind before we we hang this up for the day?

Donnie Page • 21:44

Uh um, you know, not at this point. I mean, I think, you know, you know, I I think for me, top of mind is again, you know, this evolution and and trying to um, you know, bring those two things together, the evolution, you know, of automations, you know, to an orchestration level now, and then those platform teams that uh have to manage all that, right? To me, those things marry really well together. And I think you know, any platform team out there that’s that’s trying to create additional efficiencies and trying to um you know help their engineers become you know more strategic, you know, they they’re gonna look for things like this. And I think this is, you know, a perfect evolution of of infrastructure management.

William Collins • 22:33

Awesome. Well, you know, congratulations on the 1st uh the 1st itential webinar being in the books. And uh thanks everybody for uh tuning in.