Cloud Infrastructure as Code

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, you're listening to yet another CTO Advisor podcast, following up with our speakers from the CTO Advisor Virtual Conference in April 2020. Today we have Patricia Pecknett, SVP of Customer Experience at Blue Cat. Patricia, thanks for joining us today. Well, thanks so much for having me back. So you had one of the popular sessions at the virtual event. I didn't get a chance to meet you personally. I apologize. You've met some of the team, but not you personally.

I think you're one of the few speakers I had not met with personally. But first off, thanks for doing the virtual event last year. Yeah, it was exciting and unfortunately it was virtual. I mean, love to get to meet our people in the networking space and contacts in general. But virtually, I think we're all getting used to it at this point. I've got a conference next week that's going to be virtual yet again. So definitely want to get back.

Yeah, I attended my first in-person event. That was an event. Of course, we did the road trip, but I did my first in-person event earlier this week. It was wonderful. It was just a handful of people, but it was nice to see people and do things. I'm looking forward to it as we're recording this AWS's government conference is Monday and I'm debating whether or not to make a last minute appearance there. But I like seeing people in person and doing things that we've done in the past.

For sure. Speaking of doing things that we've done in the past, we're talking automation and cloud today. This is a big theme that we've talked about in the past few podcast episodes, and I'm sure we're going to beat home this concept. We need to run at cloud speeds, but most of our infrastructure is still not cloud application based. So we have a lot of stuff that we need to continue to do a lot of the blocking and tackling. Yet we need to be ready to accept these and support these cloud based applications that don't quite fit into the constructions of our operations.

That creates a people problem. Patricia, what are you seeing on the ground as you talk to customers? What are their major problems? We definitely see this a lot with our customers. We talked about the customer journey for cloud transformation about a year ago, and they were taking baby steps into it. To your point, the overall speed that has happened in the industry has just increased. A lot of times what we see with our customers is that they are trying to organize customer or business unit purpose within the cloud, but still, to your point, maintain it from a networking perspective, trying to make it fit in the box, and the reality is it will never fit in the box.

That box is gone. We need to start figuring out how do we move at the pace of cloud. A lot of what we see in different arenas is really the customers having their business units use cloud, doesn't matter which public cloud or private cloud, they're kind of all over the place. So no egg in one basket, it's all over. And application developers are just moving faster than the network side of the house. So ultimately, network is having to catch up, and they're having to catch up from different perspectives.

One, providing their service, because everybody is starting to move towards an infrastructure as a service model into the cloud, that's one part that we're seeing, but they're also just trying to get visibility into what their organization has done in the cloud, because those that have adopted and absorbed the cloud have just run, and a lot of people are playing catch up to see what's happened in the cloud, what's out there in the cloud, how do they protect what is in the cloud, how do they make sure that it's secure, and at the same time follows some of the rules that they try to have on the networking side, but it just needs to change the pace of it.

And so a lot of customers right now are struggling it. They're kind of feeling their way through it, and we try to partner some of these customers up to talk to each other and find lessons learned and best practices. So a lot of it, I will garner to say in my journeys, like no cloud journey is the same. So it's very difficult from an advisor perspective to say, hey, you need to do these three, four tactical things, because it can be different for everyone.

Everyone's kind of chosen to deploy public cloud differently, at least when I'm thinking of something like a virtualized data center, we all deploy a virtualized data center in kind of the same ways. AWS, I wrote on the CTO short this morning, AWS has over 200 services. So customers literally have 200 ways to build different things, and no thing is alike across customers. However, as we think about network concepts, network concepts, while in the public cloud, that box may be different, it's still a box, it's still getting packets from point A to point B.

I may no longer have the concept of a static IP address or static service, like Lambda is coming from almost anywhere. But I still have the concept of IP addresses, virtual protocols, et cetera, et cetera. What are some of the common components that we can use as building blocks operationally across the private data center and the public cloud? So great question, and the concepts are what are constant. So when you talk about the IP spaces and the concept of an IP, that is constant.

What we're finding with customers in the cloud is the way they use that is different. And what I mean by that is they may use the same IP multiple times within the cloud because they've set up environments where they're kind of cornered off from anything else. So you might have an IP in one VPC that might be reused by a different group in another VPC, but it doesn't matter because those VPCs are independent from each other and they don't have to talk back to the network.

So what we're starting to see is that there's a lot of this kind of overlapping network concept that's happening, and it works perfectly in the cloud as long as the clouds are independent. Where customers are starting to run into concerns is when they're trying to bring things back to the data center because there's no customer that we have that is to date 100% in the cloud for every single application, every single network service that they have. Everybody is in a hybrid position where some is on-premise and some is in the cloud.

And so when those concepts start having to interact with what is on-premise, they need to maintain the standards of it. You can't, otherwise you're going to create your own network conflicts. So that's one of the areas where I think, you know, from a standards perspective, organizations have to figure out the common language that they're going to want to use. Are they okay with that? Is their vendors able to handle that overlapping IP space as an example and make sense of it and not it create a lot of confusion.

But you're right, everything is a snowflake and everybody does it differently. So let's dive into that use case because I want to ask one clarifying question. When you say move something back to on-premises, I think of repatriation. So let's say that I have my development space in the public cloud. There's an application that is more or less going to be static, but I need the agility of the public cloud to build it. I go to my platform group, they give me a template for a VPC.

8 IP address scheme. And no matter who comes to me, that's the IP address scheme. And when I'm ready to put that into production or move the application from the public cloud into the private data center, as a developer, I'm just going to lift and shift that VPC, that IP address scheme and everything into my private data center. Is that kind of generally the concept? That's one of the concepts, but another concept that we see a lot with application development is that there are some services that might still be on-premise.

And the biggest one that we sometimes see is authentication, right? They might have to authenticate back to on-premise because organizations have not necessarily moved their entire authentication structure into the cloud. So although they have a VPC that has that private endpoint and it's their space, if their application needs to communicate back to any data set, any application that's on-prem, you need to make sure that that routing is available, that that structure is available, and there's no conflicts in that. That's the most common use case that we see with a lot of customers who are doing application development in the cloud.

They may need to connect to something still within on-premise for the other services. If they haven't done, again, a full VPC or shared services where they've put everything in the cloud that that application developer is going to need. Yeah, so as I think about this, I think about some pretty practical challenges. If I was an enterprise architect that was in charge of designing from the ground up a private data center design and a VP design, I'd work this out. But again, I've been in this environment where I've gotten application, it is a snowflake that the marketing team had built and they threw it over to IT to manage after they've gone out of the active development of the application.

And there's a ton of different challenges. Authentication, let's drill into that. It's one thing I can fix with NATing like duplicate IP addresses. Okay, I've done that. But what happens when it's a headless service like a Lambda? And the marketing organization didn't build the application to spec the way we would use Lambda going through application gateway, blah, blah, blah, blah, the way that I can control it. That becomes a serious operational issue because now I have this snowflake that I have to support.

And this is where I'm starting to like think like, man, what am I going to do? Like literally, what am I going to do? I don't have a choice. But I used to be able to and this is real world. I used to be able to say no marketing organization. I'm not going to support that app. It's just too much of a snowflake. I can no longer say that. I have to now support that app. What do I do?

And this is very common. Like you either end up having to support a ton of snowflakes, which nobody wants because that's just not scalable in any way, shape or form. Or you rewrite those portions of the application that don't work in the way that they need to to be put into an on-prem or production environment. Or the last option is and what we're finding customers starting to do is try to set up a level of standards that everybody has to develop against.

But the first step to figure that out is to understand from a visibility perspective, what's already out there, right? Because the cloud teams, the app development teams, they are moving at light speed. And so they have already started developing their own processes, their own procedures of how they start doing things. And if organizations don't take that and start looking at that quickly and soon, the time is going to pass. The horse is going to be out of the gate. And to bring to your point, to bring that back in after the fact requires a lot of rework that nobody has time for or has an ability to do with applications that they weren't involved in the original design.

So, you know, most customers need to start looking at this from the perspective of, one, what is already out there? Two, what do they want to create as standards to use? Not to control because the reality is there is no control in the cloud because it just moves way too fast to try to put a control plane in. But ultimately, make sure that when you do have people moving to the cloud and that they're starting to use the resources in the cloud, they know what they can and can't use.

Like you said, there's 200 plus services in AWS. What's to stop anybody from using any of them? Nothing. They're all available. They all have purpose. And so as an organization, you know, there's got to be some boundaries or some guidelines. So I think we've kind of backed into a concept that we talked about before we hit the big red button to start recording, which is DevOps. When we think about or at least a couple of years ago, when we read about DevOps, it was this very clean concept that came from you're building a single application.

There's a development and operations approach to combine approach to managing that operations. Then out of that was born the role of the SRE, et cetera. As we translate that operationally to the enterprise, this is the reality of DevOps is that we're getting applications that we weren't necessarily part of the creation of it. But we have to make these snowflakes fit into a scalable operation model. And I think that's the main difference between DevOps that was written about four or five years ago versus DevOps and what we're seeing in the enterprise.

Is that what you're seeing? A hundred percent agree with that statement. And I think it goes a little bit further in that with the addition of the speed of the cloud, DevOps needs to move faster. And they have also expanded their skill set. Because if you think about the DevOps of four to five years ago, cloud concept was always there. It's been around for years and years and years. But there wasn't anybody that was driving fast enough necessarily to need DevOps who understood all of cloud on top of all of networking, on top of all of the standard concepts that you need to do.

Now the specialization doesn't exist anymore. You have to be the jack of all trades as a DevOps person because there's just so many things going on so quickly and the technology just keeps changing and there's constant additions. So a hundred percent agree with your statement. The DevOps team has shifted from four to five years ago to now an even more critical role and purpose in organizations to handle this shift between application, cloud production, non-production, on-prem. It's just exploded in an expansion of areas and focus.

So as I think about that from a CIO, CTO perspective, I don't have the people for this. Like the number of people needed with that skill set is just impossible. I was just talking to a Google partner the other day and the Google partner said that I could have as much work as I wanted to, but a single organization needs 300 resources. 300 resources for a single transformation project. I don't have 300. This is me quoting the partner. I don't have 300 consultants in my practice.

So when companies come to me with this challenge, I respond with automation. We have to automate the things that don't differentiate so that we can give the resources that we have, we can augment them with these superpowers. Where are you seeing the maturity level of automation in achieving that aspirational goal? So the automation conversations have significantly increased with large organizations. They are hitting the same roadblocks that your partner that you were talking to is hitting. They too don't have enough resources to get to these DevOps people to have that level of specialization.

And so most organizations are automating out the trivial tasks immediately. The demand for APIs, the demand for just general activities to be pushed out of the day-to-day activities has increased significantly. And that exists both in our own internal organization as well in our customers. The level of expertise that you need is not something that gets taught at school anymore. I get that question from customers all the time. Where do you find these people? There's no one course that teaches all of these things.

I wish there was because I would totally, like every other organization, take every single graduate out of that course, but it doesn't exist. So the reality is we need to take the people who are specialists and turn them into jack-of-all-trades. So look at the people who are cloud specialists who may not have the networking side and teach them on part of it. Or flip side, maybe network expertise and specialists and not have cloud, so teach them on cloud. But at the end of the day, automation is the only way that organizations are going to do it because there's no other way to fund these headcounts.

If I'm a CTO or a CIO, my budgets aren't going up just because we need DevOps people. I mean, I wish they were, but they're not. And so we need to take out the repetitive tasks and just create this focus, this hyper focus on operational efficiency. Yeah, I think we can save this conversation. I think I'll have this conversation with our career development specialists that spoke at the conference, which is I foresee us running out of specialists one day. We can convert our specialists, our networking specialists to cloud DevOps folks, same thing for storage.

They have these deep expertise that really are foundational when you need to think about DevOps and the roles of the future. But there's only so many of those folks. What happens when we need to take from the ground up and teach someone coming in new all the skill that they need to be a DevOps specialist? That really concerns me as I look at the overall health of enterprise IT. But we'll save that conversation for another day. Patricia, people want to find out more about Bluecat and what you guys do and how you help solve these problems.

How would they do that? com. I'm very happy to connect on LinkedIn as well and happy to talk to anybody in the industry because I think there are a lot of commonalities between what we're all going through in different areas of the business. So any of these would work as well as contacting through yourself, through the CTO organization and working with you as a partner. I'm happy to facilitate conversations through that. All right. If you want to learn more about the CTO Advisor, you can contact me on the web.

com is the website. At CTO Advisors, the Twitter handle. DMs are open. So if you want to reach out to Patricia via the CTO Advisor, just DM me and I'll be more than happy to make the introduction. Make sure to rate us on iTunes. We are very serious about getting more grandmothers involved in our podcast. So if you visit grandma for the holidays, make sure to add us to her podcatcher. Rate us in our podcatcher and she'll thank you for us.

Thank you for it. Believe you. I've gotten many, many sweet notes from many grandmothers. Until then, talk to you next CTO Advisor podcast.