Screaming in the Cloud - Making a Difference Through Technology in the Public Sector with Dmitry Kagansky

Episode Date: October 5, 2023

Dmitry Kagansky, State CTO and Deputy Executive Director for the Georgia Technology Authority, joins Corey on Screaming in the Cloud to discuss how he became the CTO for his home state and the nuances of working in the public sector. Dmitry describes his focus on security and reliability, and why they are both equally important when working with state government agencies. Corey and Dmitry describe AWS’s infamous GovCloud, and Dmitry explains why he’s employing a multi-cloud strategy but that it doesn’t work for all government agencies. Dmitry also talks about how he’s focusing on hiring and training for skills, and the collaborative approach he’s taking to working with various state agencies.About DmitryMr. Kagansky joined GTA in 2021 from Amazon Web Services where he worked for over four years helping state agencies across the country in their cloud implementations and migrations.Prior to his time with AWS, he served as Executive Vice President of Development for Star2Star Communications, a cloud-based unified communications company. Previously, Mr. Kagansky was in many technical and leadership roles for different software vending companies. Most notably, he was Federal Chief Technology Officer for Quest Software, spending several years in Europe working with commercial and government customers.Mr. Kagansky holds a BBA in finance from Hofstra University and an MBA in management of information systems and operations management from the University of Georgia.Links Referenced:Twitter: https://twitter.com/dimikagiLinkedIn: https://www.linkedin.com/in/dimikagi/GTA Website: https://gta.ga.gov

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats.

What's Runtime runtime insights, you ask? Visit sysdig.com slash screaming to learn more. That's S-Y-S-D-I-G dot com slash screaming. My thanks as well to Sysdig for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. Technical debt is one of those fun things that everyone gets to deal with on some level. Today's guest apparently gets to deal with 235

years of technical debt. Dimitri Kagansky is the CTO of the state of Georgia. Dimitri, thank you for joining me. Corey, thank you very much for having me. So I want to just begin here because this has caused confusion in my life. I can only imagine how much it's caused for you folks. We're talking Georgia, the U.S. state, not Georgia, the sovereign country. Yep, exactly. Excellent. It's always good to triple check those things because otherwise I feel like the shipping costs are going to skyrocket in one way or the other. So you have been doing a lot of very interesting things in the course of your career. You're former AWS, for example. You come from commercial life working in industry,

and now it's, yeah, I'm going to go work in state government. How did this happen? Yeah, I've actually been working with governments for quite a long time, both here and abroad. So way back when I've been federal CTO for software companies, I've done other work. And then even with AWS, I was working with state local governments for about four, four and a half years, but came to Georgia when the opportunity presented itself really to try and make a difference in my own home state. You mentioned technical debt at the beginning, and it's one of the things I'm hoping to help the state pay down and get rid of some of it. It's fun because governments obviously are not

thought of historically as being the early adopters' bleeding edge when it comes to technical innovation, and from where I sit, for good reason. You don't want a code that got written late last night and shoved into production to control things like municipal infrastructure, for example. That stuff matters. It's unlike a lot of other walks of life. You don't usually get to choose your government and, oh, I don't like this one, so I'm going to go for option B. I mean, you get to do that the ballot box, but that takes significant amounts of time. So people want, above all else, I suspect, their state services from an IT perspective to be stable first and foremost. Does that align with how you think about these things?

Security, obviously, is a factor in that as well. But how do you see, I guess, the primary mandate of what you do? Yeah, I mean, security is obviously up there, but just as important is that reliance and reliability, right? People take time off of work to get driver's licenses, right? They go to different government agencies to get work done in the middle of their workday, and we've got to have systems available to them. We can't have them show up and say,

yeah, come back in an hour because some system is rebooting. And that's one of the things that we're trying to fix and trying to have fewer of, right? There's always going to be things that happen, but we're trying to really cut down the impact. One of the biggest things that we're doing is obviously a move to the cloud, but also segmenting out all of our agency applications so that agencies manage them separately. Today, my organization, Georgia Technology Authority, you'll hear me say GTA, we run what we call NADC, the North Atlanta Data Center, a pretty large-scale data center, lots of different agencies, apps, servers all sitting there running. And then a lot of times, you know, an impact to one could have an impact to many. And so with the cloud, we get some partitioning and some segmentation where even if there is an outage, a term you'll often hear used

is that we can cut down on the blast radius, right? That we can limit the impact so that we affect the fewest number of constituents. So I have to ask this question, and I understand it's loaded and people are going to have opinions with a capital O on it. But since you work for the state of Georgia, are you using GovCloud over in AWS land? So we do have some footprint in GovCloud, but I actually spent time even before coming to GTA trying to talk agencies out of using it. I think there's a big misconception, right? People say, I'm government. They call it GovCloud.

Surely I need to be there. But back when I was with AWS, you know, I would point blank tell people that really, I know it's called GovCloud, but it's just a poorly named region. There's some federal requirements that it meets. It was built around ITAR, which is International Traffic of Arms Regulations, but states aren't in that business, right? They are dealing with HIPAA data, with various criminal justice data and other things, but all of those things can run just fine on the commercial side. And truthfully, it's cheaper and easier to run on the commercial side. And that's one of the concerns I have is that if the commercial regions meet those requirements, is there a reason to go

into GovCloud just because you get some extra certifications? So I still spend time trying to talk agencies out of going to GovCloud. Ultimately, the agencies with their apps make the choice of where they go. But we have been pretty good about reducing the footprint in GovCloud unless it's absolutely necessary. Has this always been the case? Because my distant recollection around all of this has been that originally when GovCloud first came out, it was a lot harder to run a whole bunch of workloads in commercial regions. And it feels like the commercial regions have really stepped up as far as what compliance boxes they check. So is this one of those stories where five or 10 years ago, whenever GovCloud first came out, there were a bunch of reasons to use it that no longer apply? I actually can't go past, I'll say, seven or eight years, but certainly

within the last eight years, there's not been a reason for state and local governments to use it. At the federal level, that's a different discussion, but for most governments that I work with and work with now, the commercial regions have been just fine. They've met the compliance requirements, controls, and everything that's in place without having to go to the GovCloud region. Something I noticed that was strange to me about the whole GovCloud approach when I was at the most recent public sector summit that AWS threw is whenever I was talking to folks from AWS about GovCloud and adopting it and launching new workloads and the rest. Unlike in almost any other scenario, they seemed that their first response, almost a knee-jerk reflex, was to pass that work off to one of their partners.

Now, on a commercial side, AWS will do that when it makes sense and each one becomes a bit of a judgment call. But it just seemed like every time someone's doing something with GovCloud, oh, talk to company X or company Y. And it wasn't just one or two companies. There were a bunch of them. Why is that? I think a lot of that is because of the limitations within GovCloud, right? So when you look at anything that AWS rolls out, it almost always rolls out into either US East 1 or US West 2, right? One of those two regions, and it goes out worldwide.

And then it comes out in GovCloud months, sometimes even years later. And in fact, sometimes there are features that never show up in GovCloud. So there's not parity there. And I think what happens is it's these partners that know what limitations GovCloud has and what things are missing in GovCloud that you still have to work around. Like I remember when I started with AWS back in 2016, right, there had been a new console, you know, the new skin that everyone's now familiar with. But that old console, if you remember that, that was in GovCloud for years afterwards. I mean, it took them at least two more years to get GovCloud to even look like the current commercial console that you see.

So it's things like that where I think AWS themselves want to keep moving forward and having to do anything with kind of that legacy platform that doesn't have all the bells and whistles is why they say, go get a partner that knows the things that aren't there yet. That makes a fair bit of sense. But what I was always wondering is how much of this was tied to technical challenges and working within those and building solutions that don't depend upon things. Oh, wait, that one's not available in GovCloud versus a lack of ability to navigate the acquisition process for a lot of governments natively in the same way that a lot of their customers can. Yeah, I don't think that's the case, because even to get a GovCloud account, you have to start off with a commercial account, right? So you actually have to go through the same purchasing steps and then essentially click an extra button or two.

Oh, and I've done that myself already. I have a shitposting account and a, not kidding, Ministry of Shitposting GovCloud account. But that's also me just kicking the tires on it. As I went through the process, it really felt like everything was built around a bunch of unstated assumption because of course you've worked within GovCloud before and you know where these things are.

And I kept tripping into a variety of different aspects of that. I'm wondering how much of that is just due to the fact that partners are almost always the ones guiding customers through that. Yeah, it is almost always that. There's very few people, even in the AWS world, right? If you look at all the employees that have there,

it's a small subset that work with that environment and probably an even smaller subset of those that understand what it's really needed for. So this is where if there's not good understanding, you're better off handing it off to a partner. But I don't think it is the purchasing side of things. It really is the regulatory things and just having someone else sign off on a piece of paper above and beyond just AWS themselves. I am curious, since it seems that

people love to talk about multi-cloud in a variety of different ways. But I find there's a reality that basically, on a long enough timeline, everyone uses everything versus the ideal of, oh, we're going to build everything so it can seamlessly flow from one provider to another. Are you folks all in on AWS? Are you using a bunch of different cloud providers for different workloads? How are you approaching a cloud strategy? So when you say you guys, I'll say, as AWS will always say, it depends. So GTA is multi-cloud. We support AWS, we support OCI, we support Azure, and we are working towards getting Google in as well, GCP. However, on the agency side, I am encouraging agencies to pick a cloud.

And part of that is because you do have limited staff. They are all different, right? They all do similar things, but if it's done in a different way and you don't have people that know those little tips and tricks, kind of how to navigate certain cloud vendors, it just makes things more difficult. So I always look at it as kind of the car analogy, right? Most people are not multi-car, right? You go, you buy a car, Toyota, Ford, whatever it is, and you're committed to that thing for the next four, five, 10 years, however long you own it, right?

You may not like where the cup holder is or you need to get used to something, you know, being somewhere else, but you do commit to it. And I think it's the same thing with cloud that, you know, do you have to be in one cloud for the rest of your life? No, but know that you're not going to hop from cloud to cloud. No one really does. No one says every six months I'm going to go move my application from one cloud to go. But I found even in corporate life

that, well, I like this company better than the other is generally not the best basis for making sweeping decisions around this. What frameworks do you give various departments to consider where a given workload should live? How do you advise them to think about this? No, it's funny. We actually had a call with an agency recently that said, you know, we don't know cloud. What do you guys think we should do? It was for a very small, I don't even want to call it workload. It was really for some DNS work that they wanted to do. And really it came down to for that size and scale, right?

We're looking at a few dollars, maybe a month. They picked it based on the console, right? They like one console over another. They're not going to get into which cloud they pick, but we wound up giving them a demo of here's what this looks like in these various cloud providers, and they pick that just because they like the buttons and the layout of one console over another. Now, having said that, for obviously larger workloads, things that are more important. There is criteria. And in many cases, it's also the vendors. Probably about 60 to 70% of the applications we run are all vendor provided in

some way. And the vendors will often dictate platforms that they'll support over others, right? So that supportability is important to us. Just like you were saying, no one wants code rolled out overnight and surprise all the constituents one day. We take our vendor relations pretty seriously. We take our cue from them before buying software from someone and they say, look, this is better in AWS or this is better in OCI for whatever reasons they have. We'll go in that direction more often than not. I made a crack at the beginning of the episode where the state was founded 235 years ago

as of this recording. So how accurate is that? I mean, I have to imagine that back in those days, they didn't really have a whole lot of computers except probably something from IBM. How much technical debt are you folks actually wrestling with? It's pretty heavy. One of the biggest things we have is we ourselves in our data center still have a mainframe. That mainframe is used for a lot of important work. Most notably, a lot of healthcare benefits are really distributed through that system. So you're talking about federal partnerships, you're talking about insurance companies, healthcare providers, all somehow-

You're talking about things that absolutely positively cannot break. Yep, exactly. We can't have outages, we can't have blips, and they've got to be accurate. So even that sort of migration, that's not something that we can do overnight. It's something we've been working on for well over a year. And right now we're targeting probably roughly another year or so to get that fully migrated out. And even there, we're doing what would be considered a traditional lift and shift. We're going to mainframe emulation. We're not going cloud native. We're not going to do a whole bunch of refactoring out of the gate. It's just picking up what's working and running and just moving it to a new venue. Do they finally build an AWS 400

that you can run that on? I didn't realize they had a mainframe emulation offering these days. They do. There's actually several providers that do it. There's other agencies in the state that have made this sort of move as well. So we're also not even looking to be innovators in that respect, right? We're not going to be first movers to try that out. We'll have another agency make that move first. And now we're doing this with our Department of Human Services. But yeah, a lot of technical debt around that platform.

When you look at just the cost of operating these platforms, that mainframe costs the state roughly $15 million a year. We think in the cloud, it's going to wind up costing us somewhere between $3 to $4 million. Even if it's $5 million, that's still considerable savings over what we're paying for today. So it's worth making that move, but it's still very deliberate, very slow with a lot of testing along the way. But yeah, you're talking about that workload has been in the state, I want to say, for over 20, 25 years. So what's the reason to move it? Because not for nothing, but there's an old, the old saw of, well, don't fix it if it's naive and ain't broke. Well, what's broke about it?

Well, there's a couple of things. First off, the real estate that it takes up is an issue. It is a large machine sitting on a floor of a data center that we've got to consolidate to. We actually have some real estate constraints, and we've got to cut down our footprint by next year contractually. We've agreed we're going to move into a smaller space. The other part is the technical talent. While, yes, it's not broke, things are working on it, there are fewer and fewer people that can manage it. And what we found was doing a complete refactor while doing a move anywhere is really too risky.

Rewriting everything with a bunch of lambdas is kind of scary, as well as moving it into another venue. So there are mainframe emulators out there that'll run the cloud. We've gotten one and we're making this move now. So we're going to do that lift and shift in and then look to refactor it piecemeal. Specifics are always going to determine, but as a general point, I felt like I am the only voice in the room sometimes advocating in favor of lift and shift because people say, oh, it's terrible for reasons X, Y, and Z. It's yes, all of your options are terrible. And for the common case, this is the one that I have this sneaking suspicion based upon my

lived experience is going to be the least bad of all of those various options. Was there thought given to doing a refactor in flight? So from the time I got here, no. But I could tell you just having worked with the state even before coming in as CTO, there were constant conversations about a refactor. And the problem is no one actually has an appetite for it. Everyone talks about it. But then when you say, look, there's a risk to doing this, right? Governments are about minimizing risk. When you say, look, there's a risk to doing this, right? Governments are about minimizing risk. When you say, look, there's a risk to rewriting and moving code at the same time, and it's going to take years longer, right? That refactoring, every time I've seen an estimate, would be as small as three years, as large as seven or eight years, depending on who was doing the estimate. Whereas the lift and shift, we're hoping we can get it done in two years, but even if it's two and a half,

it's still less than any of the estimates we've seen for a refactor and less risky. So we're going with that model and we'll tinker and optimize later. But we just need to get out of that mainframe so that we can have more modern technology and more modern support. It seems like the right approach.

Sorry, I didn't mean to frame that as quite as insulting as it might have come across. Did anyone consider other options just out of course, whenever you're making big changes, like we're going to throw a dart at a whiteboard. It's not what appears to be Twitter's current product strategy we're talking about here. This is stuff that's very much measured twice, cut once. Yeah, very much so. And you see that with just about everything we do here. I know when the state, what now, three years ago, moved their tax system over to AWS, not only did they do two or three trial runs of just the data migration, we actually wound up doing six. Are you talking about adding two months of testing just to make

sure every time we did the data move, it was done correctly. All the data got moved over. I mean, government is very, very much about measure three, four times and cut once. Which is kind of the way you'd want it. One thing that I found curious whenever I've been talking to folks in the public sector space around things that they care about. In years past, I periodically tried, oh, should we look at doing some cost consulting for folks in this market? And by and large, there have been a couple of exceptions, but generally in our experience with sovereign governments, more so than municipal or state ones. But saving money is not usually one of the top three things that governments care about when it comes to their AWS estate. Is cost something that's

on your radar? And how do you conceptualize around this? And I should also disclose, this is not in any way, shape, or form intended to be a sales pitch. Yeah, no, cost actually for GTA is a concern. But I think it's more around the way we're structured. I have worked with other governments where they say, look, we've already gotten an allotment of money. It costs whatever it costs, and we're good with it. With the way we're structured. I have worked with other governments where they say, look, we've already gotten allotment of money. It costs whatever it costs and we're good with it. With the way my organization is set up though, we're not appropriated funds, meaning we're not given any tax dollars. We actually have to provide services to the agencies and they pay us for it. And so my salary and everyone else's here, all the work that we do is basically paid for by agencies, and they do

have a choice to leave. They could go find other providers. It doesn't have to be GTA, always. So cost is a consideration, but we're also finding that we can get those cost savings pretty easily with this move to the cloud because of the number of available tools that we now have available. We have that data center I talked about, right? That data center is obviously locked down, secured, very limited access. You can't walk in, but that also prevents agencies from doing a lot of day-to-day work that now in the cloud, they can do on their own. And so the savings are coming just from this move of not having to have as much locks away from the agency, but having more locks from the

outside world as well, right? There's definitely scaling up in the number of tools that they have available to them to work around their applications that they didn't have before. It's on some level, a capability story, I think, when it comes to cloud. But something I have heard from a number of folks is that even more so than in enterprises, budgets tend to be much more fixed things in the context of, of cloud in government. Often in enterprises, what you'll see is sprawl. Someone leaves something running and oops, the bill wound up going up higher than we projected for this given period of time. When we start getting into the realm of government, that stops being a you broke budgeting policy and starts to resemble things that are called crimes.

How do you wind up providing governance as a government around cloud usage to avoid someone going to prison over a managed NAT gateway? Yeah, so we do have some pretty stringent monitoring. I know even before the show, we talked about the fact that we do have a separate security group. So on that side of it, they are keeping an eye on what are people doing in the cloud.

So even though agencies now have more access to more tooling, they can do more, right? GTA hasn't stepped back from it. And so we're able to centrally manage things. We put in a lot of controls. In fact, we're using control tower. We've got a lot of guardrails put in. Even basic things like you can't run things outside of the U.S., right? We don't want you running things in the India region or anywhere in South America.

That's not even allowed. So we're able to block that off. And then we've got some pretty tight financial controls where we're watching the spend on a regular basis, agency by agency. Not enforcing any of it. Obviously, agencies know what they're doing and it's their apps. But we do warn them of, hey, we're seeing this trend or that trend. We've been at this now for about a year and a half. And so agencies are starting to see that we provide more oversight and a lot less pressure.

But at the same time, there's definitely a lot more collaboration assistance with one another. It really feels like the entire procurement model has shifted massively as opposed to going out for a bunch of bids and doing all these other things. It's consumption based. And that has been, I know for enterprises, a difficult pill for a lot of their procurement teams to wind up wrapping their heads around. I can only imagine what that must be like for things that are enshrined in law. Yeah, there's definitely been a shift, although it's not as big as you would think on that side, because you do have cloud, but then you also have managed services around cloud. So you look at AWS, OCI, Azure, no one's out there putting a credit card down to open an environment

anymore, you know, a tenant or an account. It is done through procurement rules. Like we don't actually buy AWS directly from AWS. We go through a reseller, right? So there's some controls there as well from the procurement side. So there's still a lot of oversight, but it is scary to some of our procurement people. Like AWS Marketplace is a very, very scary place for them, right? The fact that you can go and you can hire people at Marketplace. You could buy things with a single button click. So we've gone out of our way in my agency to go through and lock that down and make sure that before anyone clicks one of those purchase buttons, that we at least know about it. They've made the request and we have to go in and

unlock that button for that purchase. So we've got to put in more controls in some cases, but in other cases, it has made things easier. As you look across the landscape of effectively what you're doing is uprooting an awful lot of technical systems that have been in place for decades at this point. And we look at cloud, and I'm not saying it's not stable, far from it, but it also feels a little strange to be effectively making a similar time span of commitment, because functionally, a lot of us are, when we look at these platforms. Was that something that has already been a pre-existing appetite for when you started the role? Or is that something that you've found that you've had to socialize in the last couple of years?

It's a little bit of both. It's been lumpy agency by agency, I'll say. There are some agencies that are raring to go. They want to make some changes, do a lot of good, so to speak, by upgrading their infrastructure. There are others that will sit and say, hey, I've been doing this for 20, 30 years. It's been fine. That whole, if it ain't broke, don't fix it mindset. So for them, there's definitely been a lot more friction to get them going in that direction. But what I'm

also finding is the people with their hands on the keyboards, right? The ones that are doing the work are excited by this. This is something new for them. In addition to actually going to cloud, the other thing we've been doing is providing a lot of different training options. And so that's something that's perked people up and definitely made them much more excited to come into work. I know down at the operator level, the administrators, the managers, all of those folks are pretty pleased with the moves we're making. You do get some of the folks in upper management and the agencies that do say, look, this is a risk. We're saying, look, it's a risk not to do this, right? You've also got to think about staffing and what people are willing

to work on, things like the mainframe. You're not going to be able to hire those people much longer. They're going to be fewer and far between. So you have to retool. I do tell people that, you know, if you don't like change, IT is probably not the industry to be in, even in government. They probably want to go somewhere else then. That is sort of the next topic I want to get into, where companies across the board are finding it challenging to locate and source talent to work in their environments. How has the process of recruiting cloud talent gone for you?

It's difficult. I'm not going to sugarcoat that. I'm not sure anyone would say otherwise, no matter where you are. You can pay absolute insane top of market money and still have that exact same response. No one says, oh, it's super easy. Everyone finds it hard. But please continue. Yeah. But it's also not a problem that we can even afford to throw money at, right? So that's not something that we'd ever do. But what I have found is that there's actually a lot of people, really, that I'll say are tech adjacent that are interested in making that move. And so for us, having a mentoring and training program that bring people in and get them

comfortable with is probably more important than finding the talent exactly as it is. If you look at our job descriptions that we put out there, we do want things like cloud certs and certain experience, but we'll drop off things like certain college requirements. Say, look, do you really need a college degree if you know what you're doing in the cloud or if you know what you're doing with a database, right, and you can prove that. So it's reevaluating who we're bringing in. And in some cases, can we also train someone, right, bring someone in for a lower rate but willing to learn and then give them the experience knowing that they may not be here for 15, 20 years and that's okay. Well, we've got to retool that model to say we expect some attrition, but they walk away with some valuable skills.

And while they're here, they learn those skills. Right. So that's the payoff for them. I think that there's a lot of folks exploring that where there are people who have the interest and the aptitude that are looking to transition. And so much of the discussion points around filling the talent pipeline have come from a place of, oh, we're just going to talk to all the schools and make sure that they're teaching people the right way. And well, colleges aren't really aimed at being vocational institutions most of the time. And maybe you want people who can bring an understanding of various aspects of business, of workplace dynamics, et cetera. And even the organization themselves, you can transition them in. I've always been a big fan of

helping people lateral from one part of an organization to another. It's nice to see that there's actual formal processes around that for you folks. Yeah, we're trying to do that. And we're also working across agencies, right, where we might pull someone in from another agency that's got that aptitude and willingness, especially if it's someone that already has government experience. They know how to work within the system that we have here. It certainly makes things easier. It's less of a learning curve for them on that side. And we think, you know, in some cases, the technical skills, we can teach you those.

But just operating in this environment is just as important to understand the soft side of it. No, I hear you. One thing that I've picked up from doing this show and talking to people in the different places that you all tend to come from has been that everyone's working with really hard problems and there's a whole universe of various constraints that everyone's wrestling with. The biggest lie in our industry across the board that I'm coming to realize

is any whiteboard architecture diagram, full stop. The real world is messy. Nothing is ever quite like it looks like in that sterile environment where you're just designing and throwing things up there. The world is built on constraints and trade-offs. I'm glad to see that you're able to bring people into your organization. I think it gives an awful lot of folks hope when they despair about seeing what some of the job prospects are for folks in the tech industry, depending on what direction they want to go in.

Yeah, I mean, I think we've got the same challenges everyone else does, right? It is messy. The one thing that I think is also interesting is that we also have to have transparency, but to some degree. And I'll shift. I know this wasn't meant to kind of go off into the security side of things, but I think one of the things that's most interesting is trying to balance a security mindset with that transparency, right? You have private corporations, other organizations that they do whatever they do, they're not going to talk about it,

you don't need to know about it. In our case, I think we've got even more of a challenge because on the one hand, we do want to lock things down, make sure they're secure, and we protect not just the data, but how we do things, right? Some of our mechanisms and methods. At the same time, we've got a responsibility to be transparent to our constituents. They've got to be able to see what we're doing, what are we spending money on. And so to me, that's also one of the biggest challenges we have is how do we make sure we balance that out, that we can provide people and even our vendors, right? A lot of times our

vendors will say, how are you doing something? We want to know so that we can help you better in some areas. And it's really become a real challenge for us. I really want to thank you for taking the time to speak with me about what you're doing. If people want to learn more, where's the best place for them to find you? I guess now it's no longer called Twitter, but really just about anywhere. Twitter, Instagram, not a big Instagram user, LinkedIn, Dimitri Kagansky, there's not a whole lot of us out there. Pretty easy to do a search, but also you'll see there's my contact info, I believe, on the GTA website, just gta.georgia.gov. Excellent. We'll, of course, put links to that

in the show notes. Thank you so much for being so generous with your time. I really appreciate it. Thank you, Corey. Really appreciate it as well. Dimitri Kagansky, CTO for the state of Georgia. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment telling me that I've got it all wrong and mainframes will in fact rise again. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.