Joksan Flores • 00:02

Hello, everyone, and welcome to another Itential webinar. I’m excited to have you join me for today’s live demo on orchestration of cloud load balancing services using AWS CloudFormation systems combined with ServiceNow and notifications using the Itential automation platform. My name is Joksan Flores. I am a senior solutions architect here at Itential. Today, I’ll be walking you through step-by-step how the Itential automation platform can help to orchestrate cloud services by combining native APIs, but also native infrastructure as code functionality such as CloudFormation. Here at Itential, we believe firmly on using the right tool for the right job. There’s a lot of tooling for cloud automation and infrastructure as code, such as CloudFormation, OpenTofu, Azure ARM templates, et cetera.

Joksan Flores • 01:00

We firmly believe in combining those through the power of API integration to achieve your goals. There is no right or wrong tool. Sometimes we have to use some of these tools or even some of the native tooling that exists in, for example, EC2 APIs and so forth. And the whole idea behind this is to show how using the Itential automation platform and all the provided integrations, you can implement your business logic for your use cases. The idea behind this demo is to demonstrate how we can orchestrate using the platform, integrating all these services that we discussed before, using CloudFormation, even native API calls from the platform itself, but not only so, as well as integration with ServiceNow and Change Management. approvals, Microsoft Teams notifications, and also very importantly as well, leverage Itential stateful capabilities to implement the two operations on the services that we’re going to create. That’ll be the latter part of the demo.

Joksan Flores • 02:07

At the end of the demo, you will have seen the capabilities Itential provides, and also how we help our customers achieve their X as a service goals for all their IT systems. We focus sometimes a lot on networking, but we also have a lot of capability and do a lot of work with our existing customers around security, Cloud automation, infrastructure work, etc. Today, we’re going to show that. In the past few years, software developers and their tooling have gotten very sophisticated. DevOps processes involving pipelines have evolved to be very effective when the developer builds the code, they do code sanity testing, linting, code gets merged, it gets tested through a pipeline, and it also gets deployed through a pipeline to an end system a lot of times. When it comes to infrastructure and more specifically network infrastructure, there is a bunch of places where we face bottlenecks. And this is something that we discuss a lot with our existing customers, especially when it comes to orchestrating the network infrastructure pieces along with the required approvals and the rest of the system requires to affect a particular change.

Joksan Flores • 03:27

After an application is deployed to a particular server or in this case, an EC2 instance, right? So this is the starting point of today’s discussion is we have an application that has been coded, it’s been deployed to an EC2 instance in AWS. There is a bunch of stuff that needs to happen before that application gets published. We have to provision load balancers. We have to create load balancer policies and health checks, etc. We have to allocate public IPs. Sometimes we have to have those public IPs be recorded in our Infoblox tools or our IPAM tools internally.

Joksan Flores • 04:07

DNS records have to be created and advertised using our preferred DNS providers, and SSL certificates need to be created and designed. A lot of that work is most times not implemented within the pipeline tooling that the developers use, and they use disparate systems that need integration through APIs. AWS CloudFormation, among other infrastructure as code tools, offer mechanisms to automate the infrastructure, which is great, so a lot of these changes we can do with CloudFormation. But integrating it with other systems when it comes to following the organizational process, such as using ServiceNow for approvals and keeping track of changes. Perhaps integrating with notification systems like we’re going to show today, like Microsoft Teams, maybe integrating with IPM toolings, as I mentioned before, and others, is a big challenge. This is something that we work with a lot of our customers to solve. Sometimes our customers use Cloud Management Platform tooling, which is great and helps a lot with some of these motions of creating the infrastructure.

Joksan Flores • 05:18

But then again, when you start putting these things through the business process where you have to execute approvals and record changes, and perhaps leverage things such as CMDBs and so forth, then those tools start falling off from their faces. This is where we think Itential brings a lot of value to this entire process. In this demo, we’re going to showcase Itential’s capability not only to integrate with Cloud Native Infrastructure Xcode, but also to integrate with other Cloud Native Infrastructure Xcodes that we’re Azure Cloud Platform 2.0, Azure Cloud Platform 3.0, We’re going to show you how to do that in Thank you very much for watching. tools such as CloudFormation and others, but also how do we orchestrate over the top to integrate change management, as I mentioned before, with ServiceNow and notification systems. Itential, specifically the platform itself, will be in charge of creating a change request in ServiceNow as well as documenting the change. and wait for the change approval. One of the things we’ll do is we’ll actually launch the automation.

Joksan Flores • 06:14

We’ll see the ticket being created in our notifications. We will actually go through the change approval motion of moving the ticket to review and executing the proper approvals. We’ll actually also see how the platform will document the ticket along the way, and we’ll add updates to it depending on the different steps that the automation moves through. We will have that integration with Microsoft Teams to track the state of the request. Later, we can discuss how the Itential Automation Platform, specifically using the Lifecycle Manager functionality, can track the state of the service after the fact, after it’s been deployed, and we can discuss how we can implement the two actions on that resource that we have deployed. For the CloudFormation bit, which is what Itential will be orchestrating over, we will trigger a stack creation that will create a target group in EC2. It will create an HTTPS listener.

Joksan Flores • 07:14

It will assign a self-signed cert that we have pre-created for this demo. Self-signed certs are best used for the demonstration purposes. The real certificates take quite a long time to deploy. For this demo purposes, we’re going to rely on a self-signed cert. We’re going to create a Route 53 DNS A record and wait for it to propagate, allocate an Elastic IP in EC2 for the load balancer, and then we’ll tie it all together with the load balancer itself. Now, let’s jump into the platform and start looking at the demo. This brings us back into the Intentional Automation platform using Operations Manager.

Joksan Flores • 08:00

Here we have a few things that I want to key on a little bit before we go ahead and launch the automation. This automation, I have created a form that we’re going to use to launch this. This form can be used for triggering the automation manually directly from Operations Manager, which can become the operator portal for users that want to leverage this automation as a service, or this form can also be exported to other systems, as it’s been demonstrated before on previous webinars, using our ecosystem applications such as ServiceNow. But also, one important thing that I wanted to key on on this that we’re not going to show, but also the capability exists here is that I have created an API trigger. The Itential automation platform gives you the ability to reuse a particular automation in many ways, and one of them is I can create that manual trigger as I specify, but I can also create an API route for this service, which means that now for that developer that is using that pipeline to perhaps deploy their application to the infrastructure and to the EC2 instance, for example. In this case, they can actually integrate that request into their pipelines, and they can call the Itential automation platform on this particular route here in a pre-negotiated payload in order to launch this automation and consume it as a service. So just keep that in mind as we go throughout here that there’s multiple ways of triggering this use case, and we can go ahead and leverage it that way.

Joksan Flores • 09:38

So we’re going to go ahead and launch our automation to get started with the actual demonstration, so I’m going to provide some data that I need here. Let’s see. This is going to be webinar app. and we’re going to call it WebinarApplication, and this is very important. This will actually be what we use for our DNS, and this is what’s going to be allocated as part of the Route 53A record that we will see later on pop-up in our Microsoft Teams certifications. Our EC2 instance, we’re going to use a demo instance that we have created already. It has a web server, it’s fairly basic. It’s just posting a single web page, but it gets the idea across.

Joksan Flores • 10:22

For our VPC, we’re going to pick up, we’re going to use the sc-lab-vpc. These are all correct, sc-lab-demo-subnet is the one that we want to use, and security group is going to be sc-lab. Now, one of the things that I also want to highlight is these here, the VPC subnet security group, as well as the instance, all these fields can be API calls into your AWS API, which means that I can pull directly from what’s provisioned over there. I can provision an infrastructure piece in AWS with my application code deployed in it and dynamically pull what that EC2 instance is from AWS directly and populate it on that form. That’s an important piece to highlight as well. That can be enabled there. Business justification, I will populate here.

Joksan Flores • 11:11

This will actually be used on our servers now with change request and it’ll be used by our approvers if we were using this as a normal request. So we have our business justification populated, and let’s verify that all our inputs look good, and we can go ahead and launch this automation. Now, we’ll see messages being populated on the right here in my Microsoft Teams notification change window. The first thing that will happen is we’re actually going to go ahead and create a change request into service now and wait for the approval. So as you can see here on my Microsoft Teams window, I get my notification and this is an HTML window that will actually give me links to my ticket. So this could be sent to a chat room where approvers sit and review or this could be changed to management or whomever controls some of these approvals, and I have my description here. Service request to provision an Elastic Load Balancer service with DNS.

Joksan Flores • 12:21

Application is called Webinar App, and my justification is Webinar Load Balancer service for this application. So I’m going to go ahead and click on my service now ticket. Now, I’ll probably speed through this and execute the approvals fairly quickly. The approval process itself is not necessarily the focus of the webinar, so I’ll move through this fairly quick. I’ll move these to assess. One thing that’s important to also note is that we are populating descriptions and so forth with all the details, as well as justifications in the ticket. That is waiting for approvals.

Joksan Flores • 12:58

I will go ahead and approve that very quickly here. After this is approved, one thing that you know quickly is my ticket moved into implement. If I go and see notes, Itential has actually added some notes saying AWS Web Apps for Creation request been successfully approved, and the automation itself will actually move the ticket to implement. If I go back here, the automation has progressed past that ticket creation and approval waiting. It’s moved, it’s updated the ticket, and passed the approval, and it’s starting to launch the CloudFormation stack creation. One of the things that’s super important about executing these orchestration jobs is the fact that we need to validate what we’re doing. The stack creation call itself is pretty quick.

Joksan Flores • 13:44

It executes fairly quickly. But after it does, the stack creation takes a few minutes. What we do is we actually have retry logic built into the workflow itself that says, if the stack has not being fully created or fully finished, go ahead and reattempt. This will happen every 30 seconds until we see that this is done. Now let’s jump into CloudFormation really quickly just to see what’s happening over there. When I refresh my CloudFormation, I see that my webinar app stack creation is in progress. It has a description here, AWS CloudFormation template, create load balancer, target group, listener, allocate an elastic AP, and attach an instance to a target group.

Joksan Flores • 14:30

We’ll go ahead and drill into this a little bit more. If we look at events, we can see all the stuff that’s happening. Some of these things take a little bit of time. And what we’ll do is we’ll just watch it and see when it finishes. Okay, so some of the assets that have been created are complete now. We have seen there’s a lot of stuff that’s going on through here, a bunch of timestamps, and let’s look at what resources have been created so far. So at this time, it looks like everything has been done.

Joksan Flores • 15:04

Let me refresh the page just to make sure that CloudFormation is fully done. Still not done there, still set screen. Oh, our REV53 record’s still in creation. But we can see here that by using this stack creation process we have allocated all those things that we were discussing earlier during the slide portion of the discussion. So we have allocated a physical IP, an elastic IP. For this service, we have created an HTTPS listener for that load balancer with all those attributes that we were using before. And keep in mind also one of the things that’s important is that we’re using that application name in a lot of these services in the way that we key them all in during the stack creation.

Joksan Flores • 15:51

That’s gonna be extremely important. We’ve seen the load balancer service being created and our DNS, which is I believe the final piece that should be happening. It’s almost done there, as well as our self-signed search has been matched into the service in the target group. One thing that’s super important, so now our service is complete. One thing that’s super important to remember is that a lot of these services we’re actually going to need to record for later. When we start looking at the Itential automation platform stateful capabilities, one of the things that we’ll look at that’s very important is, we’re going to have to remember a lot of these parameters. Some of these are dynamically created along the way via the automation, or some of these are allocated such as the URL.

Joksan Flores • 16:38

This FQDN is actually dynamically created via the automation and passed on to CloudFormation. But the Elastic IP is just generated and allocated by AWS services and we have no control over that. We have to remember some of those so that later we can keep them in our stateful capabilities so that we can do things such as troubleshooting and so forth. Let’s jump back into the platform and see what happened over there. Now that we jump back into the platform, we can see that our job actually evaluated a handful of times. We can see how many times it actually took to. Let’s see here. It actually took eight retries.

Joksan Flores • 17:17

That took about four minutes to create the entire service. What the platform was actually doing was constantly validating that the stack was actually finished creating. When it was finished, it decided to proceed. It described the stack one more time and it picked out the load balancer Elastic IP. This is one attribute that we will remember later for our stateful capability showcase. Going back into the parent automation that’s controlling this, once this CloudFormation job finishes, after the four-minute mark or so, we’re actually going to transform some and pull some of that data and extract some of the data that’s important that we need for later. We’re going to update the change requests with nodes.

Joksan Flores • 18:00

Let’s go ahead and see that now. I can actually go and look at my change request and see how it was transitioned from implement to review. This will be the final piece where this change gets sent to whomever the requester is and said, hey, go ahead and verify that your service is working properly and we’re actually going to go through that in a second. As well as something that’s really important is that we’re adding nodes throughout the whole motion of the automation. If you look at whenever we did that change, that update in the automation platform, using our ServiceNow integration, we have the capability of posting all this data. Notice that this is all HTML, and that’s because we’re reusing some of the data that we’re sending to Microsoft Teams. but you actually have self-documentation of the whole change saying, hey, your application has been published, we have a reference URL, and we also have an Elastic IP that has been allocated.

Joksan Flores • 18:55

We have a fully operational website after this, and we’ll see that in a second. From there, we can go ahead and actually jump and see since this operation is all finished and the change has been updated in service now, we can actually go and look at Microsoft Teams and see that our load balancer creation service has seen an update. Our applications has been published. This is the same message that we saw in service now. But what’s actually cool is we can do things such as use that HTML. capabilities to from here facilitate the requester’s job and say, hey, this is your application URL. They can go ahead and ping that IP if that was provided initially in the original permissions.

Joksan Flores • 19:37

But from here, I can actually click on my website link. Like I said before, we’re using a self-signed search for this. This can definitely be used with a certificate signed by a certificate authority. It’s not a big deal there. We got our basic website populated here. Our DNS has been allocated, advertised, and all map into all our services that we created in the AWS portion of it. Going back into Operation Manager, we see the Microsoft Teams update is sent.

Joksan Flores • 20:10

Arguably, one of the biggest pieces of this automation, that’ll be the second part of this demonstration, is the fact that we actually record the request state, and that’s that last task here. This workflow, fairly tiny, using a lot of modular automations, a lot of these are actually pre-built. But one of the last operations is this one, which is recording the request state. This will actually leverage Identical Automation’s platform lifecycle capability, not only to remember some of the attributes that CloudFormation already remembers, CloudFormation already has a certain state capability, but also come over the top and remember a lot of the request attributes. If I go to my Lifecycle Manager overview here, now I can see my instance that has been created. We’ve decided that our instance names was WebinarApp, and that’s what’s being used for this view. I can create multiple instances, so keep in mind that this is very much a reusable automation.

Joksan Flores • 21:14

I can use this to tie it to a lot of applications. It can be 10, or 20, or 30, or 100. There’s no limit to that, and each one of these will create a particular instance. Once this service starts growing and I start building all these, I got to remember some of these attributes and parameters. One of the things that’s really big here, at least for me, is to showcase the attributes that we’re able to remember. Not only the things that we’re able to submit through the form, but also other things that are super important for this particular change. We’re able to keep track of the instance ID that was used.

Joksan Flores • 21:50

This is the application itself that actually has that HTML code running in it. We have the load balancer IP, which is dynamically allocated by the AWS EC2 service. We have that application name which are provided by the user. The subject ID, which was mapped entirely from what we picked. Just keep in mind that when we run this, we actually picked the names of the servers, which are the mnemonics. What we also in the backend, we need to track the IDs, which are the ones that are referred to the actual AWS assets. We remember the VPC ID that was used, that this is justification.

Joksan Flores • 22:25

But more importantly, this is where it comes in. The real value of the tooling here is we’re able to remember some of the attributes that are specific to this particular job from the automation platform perspective, not just to call information. So we’re able to tie the two together. So from here, we have the stack name, we have all those things, but we also have the potential platform job ID. So this is really important for audit logging and tracking purposes. So I can refer to that job ID later on. We also have the security group ID, which was selected at the beginning, the application URL.

Joksan Flores • 23:01

Now, later down the road, 20, 30 days later, 60 days, 100 days later, when my application developers misses that change request or they missed the notification, somebody had misplaced it, or they’re trying to figure out what this application is, we can refer to all this data as important to this. I can also track the initiator of the automation. In my case, this is admin at Itential because I’m not using any particular tie-in to authentication. But if I was using my e-mail, it would show joxon.Itential.com. Here’s the initiator, so we can also keep track of who did that. Also very importantly is the change request for service now. We can now tie together the different pieces.

Joksan Flores • 23:45

If I need to figure out which service request maps into which CloudFormation service that was permissioned, I have all that information into the platform. The second piece that is super important when we start looking at some of this functionality in the Lifecycle Manager piece of the application are the actions. Based on all of this data that I have done here, I can actually implement actions to act on this data as I see fit. There’s a bunch of services that could be implemented. After the fact, whenever we create an application and it is published, there’s a bunch of stuff that needs to be done to it, and there’s potential for a lot of that to be automated, because now we can remember a lot of those actions and we can act on. One of those is we have the creation action which happens in the automation itself, but we can also implement day-2 actions such as change DNS record. If after the fact, somebody comes and says, I want to modify my DNS record from webinar app to JAXA’s app, then we can come ahead and implement this action, and from here, we can actually go and trigger it for the particular automation.

Joksan Flores • 24:53

I’ll show you how those are triggered in a second. We can do things such as change as a self-certificate. For this demonstration, we actually used a self-signed certificate, which obviously shows up as not secured and those kinds of things. If we were to allocate a certificate using a proper certificate authority, we can go ahead and use this automation to change that. we can update the registered targets. If we needed to add height availability capability to this application and add other instances to that target group in AWS, the requester or the owner of the application can actually come and do it here as a service rather than then having to go to the Cloud Engineer or the SRE or whomever to actually go and execute those changes on the stack. Typically, there’s a gap there where the application developer will not have the appropriate access to go and modify their services in AWS.

Joksan Flores • 25:49

This platform can become the Azure service. Lastly, some of the other sample actions that we programmed in here is the update security group. I can actually have addition and removal of rules to security groups, say that I need to open, instead of opening just 443 for that application, which is what we’re using right now, for that load balancer listener, I needed to open some other URL for that application, perhaps for troubleshooting purposes and so forth. Lastly, we have a delete action, which actually lets me execute a CloudFormation delete on and that will destroy the whole service. Namely, all those assets that we saw before that were created. I can actually issue a delete on this because I have this stateful capability, and rather than relying on that in Cloud Engineer, I can actually do it from the Lifecycle Manager app or from the Attentional Operations Manager and delete all these services and decommission my application when the time comes to do that.

Joksan Flores • 26:45

That wraps up the demo. Let’s go back into the slides and discussed everything that we’ve shown so far. During the demo, we showcased how the Itential Platform can seamlessly integrate with Cloud-native tooling like CloudFormation, orchestrate the entire process very efficiently. We demonstrated how IAP can orchestrate, including things such as creating change management integration with ServiceNow, and update that change, adding documentation, wait for approvals using Microsoft Teams certifications integrations, use CloudFormation to automate the essential creation of the entire services. One of the other things that I would like to add here is that this does not have to be specifically CloudFormation. This is something that can be done with Azure ARM templates like discussed before. It can be done with things such as OpenTofu and Terraform and so forth.

Joksan Flores • 27:43

Any of the infrastructure as code tools that are out there in the market can be integrated in such a way into the platform so that you can execute all that service orchestration and start creating use cases as a service. This holistic approach not only addresses the bottleneck, but also streamlines the entire deployment, exposing it as a service and ensuring that we’re actually validating and executing that publishing of the application of those assets as a service. By leveraging Itential stateful capability, we can also implement those day-two operations that we mentioned before, ensuring that we can actually manage those deployed resources in an automated fashion. In conclusion, I think it helps our customers achieve their service goals across various IT systems. It could be network load balancer, it could be an F5 load balancer, it could be a cloud load balancer, security services, cloud, by automating the entire infrastructure from A to Z and integrating with that cloud management process. Thank you for watching, and thanks for tuning in.