Ep. 21 Cultural Nuances of the Major Cloud Platforms with Jenn Bergstrom

00:00 - Introduction to Jenn Bergstrom and Parsons

Dave McKenney
Hello, and welcome to Cloud Currents, where we talk about everything. Cloud computing in an ever changing, ever evolving landscape, if you will. My name is Dave McKenney, and I lead cloud product efforts at TierPoint. With me today, we've got Jenn Bergstrom. And how are we doing today, Jenn?

Jenn Bergstrom
I'm doing fantastic, thank you. How are you doing today?

Dave McKenney
I'm doing good. It's Friday. So, Jenn, your role at Parsons is focused on cloud and data solutions, right? All right, well, why don't you start off by giving us a little bit of a background on Parsons, I guess, in particular, and the company itself, and then maybe a rundown on the types of efforts that you work with in and around and lead and whatnot. We'll start there.

Jenn Bergstrom
Yeah, sounds good. So, Parsons is an 80-year-old company. I like to say we're one of the bigger tech companies that very few people have heard of, which I think is kind of entertaining. We actually are split into two halves of the company. One half does critical infrastructure globally. So things like giant city projects, things like smart cities, intelligent intersections, and all of that fun, interesting work. That's not where I sit. I sit on the other half of the company, which does federal projects. So a lot of government contracting, variety of scope where I sit. We tend to do more with the cybersecurity and cloud computing side of things, but we also do site security and biometrics and some other fun work within my side of the organization.

Parsons grew into working in the federal space largely through acquisitions, which has been an interesting way to grow. So we've had a lot of purchases over the last five to ten years that have really changed the nature of the company and the nature of the work that we do.

Dave McKenney
Yeah, I admit I'm guilty of not having a history of Parsons, but I certainly do now. I'm doing a little bit of research on what you guys do. It's very fascinating. That's great. So glad to have you. Let's talk a little bit about the ecosystem, both you, professionally speaking, and then we'll get into Parsons and kind of bring it all together. You've got a working set of knowledge around quite a few clouds, namely AWS, Microsoft Azure, Oracle, and then, I think, even Google. I think it's impressive to work with one, just with how big these public clouds and hyperscalers are, if you will. But I'm always curious to know, for those that work across multiple, what do you. What are some of the key things that you find that are, one end, strikingly similar across all these clouds?

02:47 - Comparing Cloud Providers: Culture and Services

Dave McKenney
And then there's the things that maybe are strikingly different. I'm kind of curious in your answer here.

Jenn Bergstrom
Yeah, so it is very interesting working across all four clouds and definitely makes my job pretty scopey, we'll say. But one of the core similarities between the cloud providers is that they provide core services, things like compute, networking, infrastructure, basic security. All of those core pieces, they all provide those, and they all are very good at those. And really which one you choose to use depends largely on where you need to deploy and what type of payload you're running. But one of the things that I see that's fascinating to me, that's very different between the four is their culture and the way that their culture particularly drives the way that they interact with their customers and with their contracting companies.

And what I mean by that is if you look at AWS as an example, they're very much a top or a bottoms up type of organization. So they like to talk about their inverted pyramid of leadership, where the technical teams and that staff and their interactions with customers drives how they interact and how they work and the decisions that they make as a company as a whole. Microsoft, by contrast with Azure, is very much an enterprise scale organization. And so their leadership is much more of the top down variety and focused on establishing solutions that work across a broad enterprise and then driving that down through the organization into the rest of the programs that falls within.

That has a big impact, not just on the way that they interact with their customers, but also on the way that they build their solutions and the way that they price their solutions. And another contrast, Google, if you look at the way that they manage things for them, they're used to working at extreme scale, so their products aren't considered successful unless they have more than a billion customers, more than a billion users. Which means that when you're using Google resources, you know that they are absolutely going to handle any scale you throw at them. But it also means that if you're using some of their less popular services, they're always at risk of being grandfather, being mothballed or ended, because if they're not over a billion customers, they're not really considered successfully internally to Google.

So all three of those are examples of just very different cultures that drive different behaviors. If I bring Oracle cloud into it, they know full well that they're kind of a small player in the cloud space currently, and they want to change that. And they also know that they're probably not going to change it by going after customers that are already largely in the cloud. So they're more targeting companies that know the Oracle name, companies that are familiar with the products they've offered and companies that are just now really migrating into the cloud, which is a lot of companies. And the way that they're targeting that is by extensively reaching out to the other cloud providers and actually emphasizing multi cloud solutions and trying to make that easy for customers to do.

So whereas AWS and Azure both tend to say, hey, go with our cloud and stay with us. Oracle is very much of the variety or of the mindset of use whichever cloud services make sense to you and we'll help you make those connections and do that work and make it all work together. So you know, different cultures drive different mindsets and drive very different reactions in how they interact with their customers.

Dave McKenney
That's a fantastic answer. Yeah, like I think that last part first, Oracle being a little more surgical and staying in their lane was a great point. Google, it is intriguing what they find as an interesting thing to work on, right? It's kind of like, hey, you know what, scope wise that's not as all intriguing. Like, you know, automating an airplane, that's one thing, but automating a whole fleet is way more interesting to them. But I love the culture aspect. The, when you first started talking about that, I was thinking like given your role and what you work on in projects in the fed space, just how important is even that culture on the cloud choice in sort of playing like matchmaker with the federal or government entity that you're working with?

Like do you find yourself saying, hey, these guys are, you know, I'm sure best venue does play into it if there's a specific service for a specific project. But you know, how much of that culture is also like, these guys seem like Microsoft would be a much better benefit culturally speaking, versus an Amazon. Does that come into play or is it really more best venue based on service once you get beyond the core services?

Jenn Bergstrom
So it absolutely comes into play. There's some organizations that we work within the government space that are highly innovative, that are driven to try new things, that are creative, that want to play and explore. And those ones tend to land more in a Google or an AWS type of environment. Customers within that space that are very much by the book, we're comfortable with the old way of doing things and we understand we need to adapt and they tend to fall more in line with the Microsoft's or the Oracles in the way that they look at things.

So you know, we definitely, most of our customers focus more on AWS or Azure, and then the other two are kind of niche cases, but there definitely is a cultural aspect to which ones they prefer, and that absolutely plays into the solutions that we propose for them as we're pursuing work and delivering solutions.

Dave McKenney
Yeah, I think you've already started to segue into the second part of the question here, which was in regards to the company that you work for, Parsons, what is the glaring difference in how you might approach cloud strategies for defense and intelligence and federal sector compared to commercial sectors? So you've already mentioned a few things that are key, but there's probably a lot of other things regarding the federal space compared to commercial that are strategically different and decisions people are making.

08:53 - Data Sovereignty and Security in Federal Cloud Solutions

Jenn Bergstrom
Yeah, absolutely. So one of the things that we always have to keep top of mind as we're building out our solutions for our customers is data sovereignty. Where is the data sitting? Who should have access to the data? How can we verify and prove that we're properly securing that data? That's not just applicable on the federal side, that's applicable for our international offices, because we do work both in Kingdom of Saudi Arabia and Qatar and that space. We also do work in Europe and in Canada, and each area has their own laws for data rights protection, data sovereignty, data storage. So we have to make sure that we're considering that as we design our cloud solutions. And it does sometimes drive which provider we use for solutions for a given part of the company.

Because as an example, kingdom of Saudi Arabia right now, the only cloud provider that has a region in country there so can store data in country is oracle. So we're delivering solutions using Oracle cloud over there much more than we are with other parts of the company because of that need for protecting the data. You know, the other aspect for the federal space that really plays a large role in deciding who we're using and how we're delivering our solutions is verification and authority to operate.

And, you know, being able to show that we've properly secured our systems, that we're using software that's safe, that's been vetted appropriately, all of that and that documentation and visibility and collecting that evidence and giving our customer confidence that the solutions we're providing are secure, that oftentimes drives which services we choose to use within which cloud providers, in addition to how we use them and how we document them.

Dave McKenney
You mentioned non US based, you mentioned Canada, obviously close to home here. But do you find that the sovereignty and residency issues really on an order of magnitude different when you are abroad? Because us, we're fortunate with as many regions as we have across the big three and even oracle with that. So let's actually just dive into that. So in the US, like, where do you find the sovereign and data residency issues popping up? Like, is it certain portions of the country, or is it really still relegated by the sector you're working with?

Jenn Bergstrom
It's more relegated by the sector that you're working with. You know, we're working with different types of data depending on which sector that you're talking about within Parsons. So, you know, our critical infrastructure side is dealing a lot with traffic flow and power charts and, you know, various things like that. There's privacy concerns there's security concerns there, but they're very different from the concerns when you're talking, you know, more of the federal government space and the data that they're trying to protect there. So driven more so by the contract, by the customer, and by the domain space that we're working within rather than geographically within the United States.

Dave McKenney
And I feel like I owe it to the conversation to bring up all the things that have been going on with one of our favorite cloud ecosystems, and that's broadcom and VMware. But knowing that a lot of folks have to make decisions, and maybe those decisions are. I've had this estate. It has been private to some degree, but I. Maybe now I'm looking at cloud options. Have you guys noticed any difference in the types of business or the types of questions or projects coming your way yet? Or have you noticed anything, I guess, regarding the VMware world specifically tied to the VMware world?

Jenn Bergstrom
We definitely have customers that we've delivered solutions that use VM products, that are asking us to assess whether we continue using VM products with those, or whether we look at other options, like Openshift or something along those lines? The reality is there's been a lot of mergers recently that impact the type of support structure that you build underneath your systems, because even, you know, Openshift, that has been acquired as well. And, you know, it's a little bit up in the air what the licensing is going to look like for that moving forward. So, you know, yes, there's certainly conversations being had. We haven't seen it driving forced change yet in anything that we're implementing or delivering, but there definitely are ongoing conversations.

Dave McKenney
That's good answer. Anything else you'd like to add on that? I know we really covered a lot more, so more than I even expected. But, you know, collectively speaking, across these clouds, are there any other large challenges that maybe we haven't really hit on here that you're seeing across the multiple cloud providers that you wanted to talk to or. We think we're good.

Jenn Bergstrom
Yeah. So, you know, there's a couple of challenges that come up anytime you start delivering across multiple cloud environments. And I think that they tend to be underplayed industry when you're talking about them. One of them is the skill of your staff. What are they knowledgeable of? How well are they able to deliver solutions given the particular cloud service provider that you're using? The second one is on the security side of things. How are you securing those environments? Because as soon as you introduce secondary clouds into your solution, so you're not just contained within one cloud ecosystem, you have a whole lot of boundaries and network transitions that you're making that impact the way that you design the system and the way that you secure the system. And I think oftentimes people don't think about that when they're talking about flexibility across cloud providers.

But it's a very important part of the conversation because a significant amount of the bandwidth that you use when you're delivering data across multiple networks is dealing with the encryption and the security around the packets that you're actually shipping. Right. So, you know, that's something that I always urge our customers to consider. That I urge our delivery teams to consider as they're designing their architectures for their systems is what is that impact? Is the value that they get by pulling in potentially multiple cloud services from different cloud providers? Is it worth the added complexity and the added cost from a network and a transit perspective pulling that service in?

15:13 - Balancing Innovation and Complexity in Cloud Strategies

Jenn Bergstrom
Or is it a better decision to keep things a little simpler, maybe a single cloud solution so that you don't have to worry about as many boundaries and about as much of the security wrapping?

Dave McKenney
That's a good one. Let's talk about that a little more because I've also heard that as you broaden, so maybe you're taking best venue from two different clouds and you want to build some service that is like the Cadillac, but at the same time, that's also more likely to have more data in transit. Maybe you've got a broader potential attack surface and all these things. So how do you bring up that either balancing act or where does that tipping point sit with? Like, okay, look, that's just, that's too much risk for us to take on, and it's better to take this solution down a peg, but keep it all with one cloud, even if it means that I'm having to give up certain luxuries from using two clouds.

Like where does that decision making process, is it a very technical one, or is it something that's really on the order of more regulatory?

Jenn Bergstrom
So I would say it's both. The regulatory piece obviously has to be considered. Anytime you're making that type of a decision, the technical piece also has to be considered. And then again, you know, pulling back to the culture bit that were talking about earlier, the culture of the organization that we're delivering solutions for has to be considered. Some of the culture or some of the organizations within the federal space that I play in most often are very focused on what they like to call cloud agnosticism or cloud neutrality, which, you know, is the idea of avoiding vendor lock in, avoiding being tied to a specific cloud provider for your solution. Bringing up discussion on choosing services from different clouds with them is a different conversation than one who's much more interested in. I need this data right now.

I need it actionable as quickly as possible, and I need ultimate resiliency. That conversation is a very different one. So how you present it and how you bring it forward to your customers and who's involved in that decision really depends on what the contract is, what your relationship with the customers, and how well you know them and what they really want underneath it all, what their unspoken requirements are for the system.

Dave McKenney
Yeah, I know I've said best venue a few times now. I'll try not to reuse that term going forward, but I want to ask, when it comes to government work, there's this typical stereotype that it's slower going, elongated a lot due to maybe some of those regulatory requirements or just the complexity of all those things brought in. But does that affect selecting services that might be considered bleeding edge at the onset of the project, but maybe, hey, but because of this project timeline, they absolutely will be mainstream later on. Or are you going in at more of a mainstream level, but with the anticipation that maybe these services will be, I won't say dated, I mean, but they won't be bleeding edge. Let's just say that.

So do you find yourselves and your clients leaning more on the bleeding edge because of the length of projects, if that is a thing, or going more mainstream, maybe even for other reasons?

Jenn Bergstrom
Yeah, no, that's a really interesting question, and I'm trying to think of how to answer it concisely.

Dave McKenney
Well, it can be long. We got lots of time.

Jenn Bergstrom
Jack, I think I default to this answer a lot, and I always feel bad about it because I know it's kind of the answer that everybody loves to hate, but it really depends. You know, there are some of the organizations, some of the research laboratories, some of the other parts that are more innovative and more driven to try the new things that want us to lean very heavily into the cutting edge. And so when we're proposing solutions for them, we of course take that into consideration and we look more at the new things that are coming out.

A good example where that's, you know, really at play right now is all of the traffic, all of the media excitement, all of the attention that's been being paid to large language models and generative AI, specifically things like OpenAI and Azure's offering of that and bedrock for AWS and what they're doing with that, there's a lot of interest there. And actually that's more broad spread across the federal space than what a lot of the other newer technology components of cloud have been. So, you know, that one, we're leaning in pretty heavily for a lot of our projects and finding ways that we can incorporate that where it makes sense for programs that are more program of record type, where they're stable, where that's absolutely mission essential, that they are fully operational, very reliable, very dependable.

We oftentimes choose to use the more established technologies that are already available across all the environments we need them in because of the security that gives us. But I will say even within that, we still build innovation in the solutions that we provide. It's just the innovations tend to be innovating and creative ways to use those established services that maybe they wouldn't do on the commercial space as much because they're playing with all the new services that are out there. So, you know, it's still, the pacing is a little bit different from commercial, but it's still a highly innovative environment and it's a very exciting environment to be building solutions for.

Dave McKenney
Yeah, so I really like this answer. When you brought up the generative AI in that landscape, I immediately thought of like the not so distant past of containers and orchestration and that. Right. Kubernetes has become very synonymous in that world, and ubiquitous, rather. But it wasn't that long ago that Kubernetes was jockeying for position amongst other competitors, and it just kind of became that go to the tune that even like AWS and Microsoft rebranded their container service as a Kubernetes based service.

So, you know, you're right that at a time you might have made a bleeding edge decision and picked back a solution that didn't see the kind of the go forward quite like Kubernetes did, and Kubernetes didn't kill off a lot of others, but it definitely became the fan favorite, let's say I want to go back because you did mention also some of the regulatory side of the house at the beginning of this particular segment of conversation, or thought. So you've got quite a working set of knowledge across many clouds that's impressive in its own right and what you do.

But I feel like there's a set of knowledge that you have to have that doesn't go quite as announced, and that's around the controls of the various compliant and regulatory arms, whether you're working with something like the PCI and HIPAA frameworks or you're working in Fedramp and NIST and those spaces. So how do you not only keep up, technically speaking, across these clouds, how do you balance your knowledge in just what goes on in the world of regulatory controls? Is that part of your role? Is it a team that, obviously, I'm sure you have other individuals that come in to marry up, because year over year, those compliance and controls are going through evolutions in their own right. So love to hear how you're balancing that at Parsons.

Jenn Bergstrom
Yeah, I mean, that's definitely a balancing act, and it's definitely challenging. I will say, for Parsons as a company, we have a phenomenal soc organization that is very focused on the security, the compliance, making sure that the systems that we are operating within and the systems that we are building align with all of that regulatory requirement. I cannot say enough good about our organization and what they are doing. I lean very heavily on them for my own knowledge. And a lot of the knowledge that I have that I've garnered is developed from my conversations and interactions with that organization within Parsons. That said, there's also the side of it. That's the higher security environments that are much more limited in their accessibility, but still cloud those ones, rely a lot more heavily on folks that are specialized in that space.

So your cybersecurity, your ATO, your ISIS, if you want to throw around some acronyms that won't make sense to a lot of people. But again, I lean heavily on the knowledge that our experts in those domains have to make sure that I'm tracking. For me, where I sit, my goal is to keep that kind of overarching understanding of what's going on and paying attention to the trends and the conversations that I'm hearing. So I follow OMB and their memos and reports that they write out, especially relating to cybersecurity and AI and, you know, all of that side of things. And then I talk a lot with our cloud service partners because they have to pay a lot of attention to that as well. And, you know, so they're tracking that.

And in my interactions with them, we're talking about what those requirements are, what the changes they're having to make look like, and how that's going to impact the solutions that we build as well. So there's a lot of different sources that I draw from. I'm not the expert in compliance. That's not something I have any sort of bandwidth to manage to be, but I do know people that are, and I lean heavily upon them.

Dave McKenney
Well, let's talk about that part then, because I'm sure a lot of folks would be interested to hear. How do you handle, what does that common language look like? It's one thing to standardize on, say, a public cloud, and maybe by some chance you teach your SoC and teams who are very security minded, all the acronyms, all of the services, all the features, and how, say, Microsoft does things. But when you operate across so many clouds, there probably needs to be a little bit more of a common language. So do you find, like, things like, I think a pretty popular concept is like a well architected framework? I think most clouds have something like that, a blueprint, if you will, that does follow certain controls.

Dave McKenney
Are there certain things like a well architected framework that both sides can point to where you're saying, hey, it follows the well architected framework, and your soc is saying, sweet, thumbs up, we're good to go here?

Jenn Bergstrom
Yeah, yeah, absolutely. And you nailed it with well architected framework. That's something that we rely upon and that we use in our conversations regularly, making sure that we're addressing all of the pillars across that framework matter. Right. So when I'm talking with our financial organization, we're focused on the FinOp side of it, the financial and cost effectivity pillar. When I'm talking with our SoC, we're focused on security. You know, when I talk with our technical teams, we're focused more on using the right services and building in the reliability and the resiliency and, you know, so the well architected framework is one of the first things that I encourage people to learn as they're coming up to speed in cloud, because across the clouds, all four of them, really, five of the pillars are very consistent across all the clouds.

AWS adds sustainability in which none of the others have fully caught up with as far as what they have in their pillar of well architected systems. And so I kind of foot stomp that one a little bit more when we're talking with teams that are working with the other clouds, because I personally think that's a super important pillar to always keep in mind as you're designing systems. But that is a good common language for us. The other thing is a lot of our cloud engineers and a lot of the folks that are doing development work across the clouds and working with the SoC team and with our ISIS and Essos have the security plus certification and have at least a foundational knowledge and what it means to be compliant and to follow those frameworks and do secure by default design.

And so there's a little bit less translation on that side than there is maybe on the financial side. The financial side, we do a lot of translation to help them understand how you do billing with clouds and how you manage those costs, predict them and all of that, because that's very different than traditional hardware procurement.

Dave McKenney
Yeah. Even just like listening to you talk back to me about this, it's just a lot like, now, I definitely didn't do this like, learn multiple languages, but I have heard that once you learn one language, learning that 2nd, 3rd, 4th, if you're that type of person, becomes a lot easier. I can say that is very much true of public cloud, that it is a big hurdle to get one under your belt, but the next one's not so bad. You do start to see very strong similarities and then you also see where they start to diverge.

All right, so let's shift gears to maybe a little bit more of a fun or speculative topic. Let's talk about some emerging things happening in the industry. I think just a little bit ago, you mentioned cloud computing kind of at an abstracted layer. And I know one of these concepts that is sort of on the rise route. There is this idea of sky computing, a level of computing beyond, say, an individual cluster or cloud itself, but treating the cloud at even another layer of abstraction. Given the fact that you work across so many clouds with your clients, do you see this as a viable feature for companies? Do you have customers that are achieving any degree of this level of abstraction where they.

I'm not going to say that something is portable from one cloud to the other, just, you know, drag and drop, but are you have clients that are achieving a level of abstraction across clouds versus just having an integrated set of otherwise isolated public clouds?

Jenn Bergstrom
Yeah. So in answer to that, yes, I do have some of our customer spaces that we're working with that have been pretty successful about being able to deploy their system in a relatively agnostic way, you know, across different clouds, across different environments. Usually for us it falls more on the hybrid environment focus rather than multi cloud focus. So can you deploy in an on prem environment? Can you deploy in an isolated compute environment? Can you deploy in a public cloud or in a, you know, a secured cloud? That's where we see a lot of the success that we've been seeing.

And it typically, you know, revolves around using technologies like containerization, kubernetes, you know, that abstraction, and then isolating the infrastructure component of your deployment just enough from the application component that the application, you just tell it where its infrastructure is when you deploy it and it's fine versus it all being tightly integrated like you oftentimes will see for cloud native solutions. So yes, we have seen some success with that when it comes to sky computing. I love the concept of it, but I also caveat it because I believe that if we enforced the sky computing ideals on all the cloud providers, it would actually slow down the rate of innovation that the cloud providers are able to bring in. Part of it being that one of the tenets of sky computing is a consistent API across all the different cloud services.

So that you're essentially just saying, hey, I need this capability and I don't care what cloud it's running on, go make it happen. So you're accessing it the same way. And that's great for the core capabilities, some of those commonalities that all of the cloud providers offer, you can absolutely say, hey, I need this type of compute resource, go find me the one that's most cost effective or least latency or whatever my driving ility requirement is where it becomes problematic in my mind is that innovation side of things.

So as an example, the generative AI capabilities that the cloud providers have been bringing in, if Microsoft had to tell everybody that they were diving in deep with OpenAI and that they were planning on building copilot into everything and what those APIs looked like, do you think that they would have invested those billions of dollars that they've invested in that as willingly if they knew that AWS knew exactly what those APIs looked like and was going to be going after those and trying to build the exact same type of capability? I don't think they would. I think that pushing that, enforcing that would stifle that innovation, and I think that would be detrimental for everybody that's using cloud globally, honestly.

So where I kind of see sky computing going is there will be that core commoditized component of the cloud providers that is just, everybody provides this. There's really not a ton of differentiation that can happen. Those I could see getting brought in under that sky umbrella and, you know, I could see the cloud providers agreeing to a common API for all of those. I don't think you're ever going to see them agreeing wholesale to, we're going to give you a common API and announce what we're doing ahead of time for everything. I think there's always going to be portions of the cloud that are very cloud specific and that are differentiated amongst the different cloud providers.

Dave McKenney
Yeah, I'm with you. I think that there's certainly the AI example, there's too much, let's just say, money to be made until it becomes more ubiquitous. But at the same time, when you have standards created for, let's take networking as an example, popular terminology, underlay and overlay and networking. You know, VPN came out and VPN solves a lot of problems because as long as you have some of the underlay pinnings for connectivity, it's an abstraction layer really, that can run just about anywhere. And I think your examples were spot on that for some of those core services that are very ubiquitous, that's where we can see. But yeah, I guess, could we ever see an API to rule them all? I don't know. That's an interesting one. I'm sure somebody's out there creating, right?

You have all these cnps, these cloud management platforms that do something to that degree. I have really no idea how successful most of them are these days. But, but that's interesting. What would you say is some of the driving forces when it comes to that sky computing or cloud ubiquity? Do you find the customers or the clients that you're working with? Is location a driver? Like, okay, well, we have to use these separate clouds, so we need it to function across all. Or is it a lock in the sense that we don't want to be fully locked into one vendor, we want to be able to have multiple. Is it price protections, is it resiliency? I'm often going to stop because I'm like leading the witness here, but what would you say is where you find the driving factors?

Jenn Bergstrom
So I would say it's all of the above. You know, again, it really depends on the use case. If you have a system that you're designing that has to be accessible no matter where the user is, whether that's, you know, in a denied environment, where you don't have connectivity or where it's, you know, only in the continental United States or whether it's global. Those types of considerations drive some of the decisions that we make about where we're going to store our data, how we're going to make that data accessible, where we're going to deploy our applications, what form the application is going to be in. You know, are we using serverless, are we using containers, are we using, you know, embedded hardware that can be extracted? It always comes down to that. It depends answer.

And the prioritization of the customer, again, depends on what they really need. So for some of our solutions, ultimate resiliency is what they're seeking. That's really what they need, is assurance that the system is always going to be accessible, always going to be up and running. And that design and where you deploy it and what clouds you use is going to be different than one that is, you know, as I mentioned earlier, we need this data as soon as it comes down, we need it available immediately. We need it usable, we need to be able to take action on it. And latency becomes 100% the driving requirement for those ones, right? You're probably not going to deploy across multiple regions, multiple clouds spread out across the entire continental United States.

If latency is your big driver, you're going to pick a one region with multiple availability zones. You're going to group things together that way with, you know, in placement groups so that you have high connectivity, high bandwidth, and that's going to really drive a lot about where you put your data and how you handle it, you know, so it really does depend on what the priority of the customer is and what the solution that you're delivering for them is, how those decisions are made. A lot of the customers are very concerned about the vendor lock in piece, though. And so we do quite often hear the desire, at least for the system to be designed in such a way that it is as easily portable as possible.

Dave McKenney
Okay, so that's interesting. Right? When you continue on there, that's kind of what I was going to ask. Like, as you were talking about multiple availability zones and those things that are within each one of these clouds in their own right, does that satisfy most of the regulatory requirements? So like, in the whole CIA triad of confidentiality, integrity and availability, like, does that satisfy most the availability controls as it stands today? Or are some of those regulations forcing multiple clouds across vendors to be used? Or to your point, is it more of like a choice? Like, look, we don't have to use, say, Amazon and Microsoft, but we would like to better our position in the market.

Jenn Bergstrom
Yeah, so I think you kind of landed on it with that last little bit. It doesn't necessarily drive us to use multiple clouds to meet the requirements that the CIA requirements. It really, there are some deployments that are absolutely 100% mission essential that have to be highly available where that's kind of our standard way of dealing with it because then if you lose an entire cloud, you're still okay. And I call that a multiple cloud deployment because you're deploying the entire system on each cloud independently and then you link them together and you allow conversation to happen between the deployments. But if you lose any one of the deployments, your system is still up and running in full on the other cloud provider.

The interesting thing to me is a lot of people mix up multi cloud systems, which are systems that pull pieces from multiple different clouds and combine them into one with multiple cloud deployments, which is what I just talked about where you're deploying the entire system one cloud, but then you build it so you can deploy it on multiple different clouds in its entirety. Those tend to get muddied in the conversation, but they're very different designs. There's very different implications, both from the security, from the cost, from the complexity of the system that you really have to be concerned with and think about. And that actually is one of the things that we regularly have to talk with our customers about when they come to us with, hey, we want this to be multi cloud.

And it's like, okay, do you really, or do you want multiple cloud? Let's get some clarity on this, you know, because it drastically impacts the design that we deliver for them.

Dave McKenney
Yeah. And in the back of my head I'm thinking like, okay, I kind of want to make the joke about like, at the end of the day, there still is humans behind a lot of the update management that happens in these clouds. And the sad truth is that's really where a lot of these larger known outages are occurring, is when somebody makes an oopsie or an extra zero or moves the decimal the wrong direction on an update. And you kind of hope that doesn't happen at the same time across multiple vendors. But when an oopsie like that happens, it can take down regions. And I have to think that the more usage of cloud or the speed with which it moves or both, you know, unfortunately will probably bring about maybe more of those situations.

39:26 - Navigating Multicloud and Edge Computing Challenges

Dave McKenney
It's just, you know, more volume, more surface, just can happen, but. All right, we're coming up towards the end here. I was going to say we could talk a little bit about AI, but we can't do that in a minute or two. Let's talk a, just in these last minutes, let's talk about edge, because I am curious. In the federal space, there's probably still quite a bit of requirement around disconnected state or offline state or air gap state. So, and I know there's a private cloud notion here, but really I'm speaking more on the edge cloud use case where you're taking a very cloud service to an edge. So you're trying to pull from a, a cloud native thing and deliver it at an edge because it is a solution that you need. What's it like navigating those waters?

And are you having success there or are a lot of the regulations really a non starter because of some of the cloud connectivity requirements and what have you?

Jenn Bergstrom
So I will say first that yes, we are having success there. It definitely does add complexity to the way that we design the systems and it drives. You know, a lot of our solutions are built using technologies like containerization and, you know, obviously encapsulation and inheritance and all of that type of concept. So, you know, we have systems that we deploy where if they're deployed in the cloud, they use this data store and they use this database and they use this, you know, message bus. But then if we're pushing them out into an edge environment or into one of the regularly disconnected environments, we swap out those elements for something that is edge native, that's optimized for those smaller devices that tend to be there.

So building modularity in and actually microservices and how popular those have become have been a huge enabler for being able to deliver those types of services with that type of flexibility. Because by going to an API driven interface between the components of your system, you really do build a lot more flexibility into how you're building, how you're deploying and where you're able to put those pieces of the application. So we see a lot of use cases, most of our use cases honestly have an edge component to them where we have to consider what does that look like in a smaller compute, a much more resource scarce environment and an environment that isn't always connected with that reach back into the cloud. So, you know, the interesting thing with those in my mind is dealing with the recovery.

When you do get connectivity back, how do you make sure that isolated system syncs up appropriately and effectively without damaging its performance? While it's rethinking to the broader service and the broader system that it's a part of. And, you know, that's where a lot of the innovation happens and that's where it gets really on really quickly, honestly, is in that side of things, getting things back up in sync and making sure that we're not passing bad or out of date information when we do have to deal with disconnect.

Dave McKenney
Yeah, I agree with you. I think folks could do them a load of help by not treating edge cloud synonymous with what we might have built. The private cloud back in the day, where ha. And resiliency and autonomy and all those things were very different in how we handled them. Because what you can do with edge deployments today and how they're handled, it's very much a different design. And I love what you talked about there. About when you lose connectivity, the first thing you didn't say was like, well, everything's down. No, it's just in all likelihood, whatever that design is has services still running, but connectivity will come back online. It's not that it has to be perpetually connected, but, you know, it's been engineered to handle either slow connection or disconnected states and things like that. And it's just a.

It's a very different way of designing around. So. And I'm kind of regretting now bringing that up at the tail end because I'm sure we could have just gone another 1015 minutes on that topic, but let's park it there and leave some stuff to the imagination or whatnot. But folks can head out to Parsons Corporation, you guys website, learn about the projects that you guys are working on, any other sites or material that you want to share with folks to go read up on what you guys are doing.

43:50 - Closing and Resources for Further Learning

Jenn Bergstrom
I mean, really, Parsons.com is a great resource. We have very clear sites that talk about the different parts of our company, the critical infrastructure versus the federal and some of our domains that we operate within. One thing that I do want to point out for folks that are going looking to see cloud in there is that cloud is an underpinning, it's an enabler. It's not necessarily something that we call out that we do on its own. So when you're going out there and looking at our site, you'll see cybersecurity is one of the big things we do. Reality is a lot of that is cloud based, a lot of that is cloud driven. But we don't necessarily highlight that in the website. So for Parsons and for most of our customers, cloud is a core enabler. It's a requirement.

You have to be able to do it. You have to be able to do it well. And because that's where it sits, we don't necessarily call it out anymore, which I think is kind of interesting.

Dave McKenney
Really well said. It's assumed. But our value is not in that cloud. That's what Amazon and everybody else is bringing to the table. These are the solutions we're bringing. But I think that's a very great answer. Well, Jenn, thanks a lot. This went really quick. They always seem to do. But I appreciate the time. And thank you so much for joining us. We'll see everybody.