The COVID-19 pandemic drove massive digital transformation across both the private sector and the federal government. Government organizations and private enterprises, alike, turned to revolutionary new technologies and applications to enable them to work remotely, interact despite physical distance, and otherwise continue to work towards their organizational missions despite the interruption caused by the pandemic.
With so much investment in digital transformation initiatives, it’s understandable to assume that every government system and application has been modernized. But that’s far from the case. There are unique challenges that the government and military face when they look to modernize applications and embrace new, next-generation systems.
One of the largest challenges is that they’re not starting from scratch. Most government agencies and military organizations have already invested heavily in large, monolithic applications that they rely on extensively in their operations.
In the latest episode of the ContinuousX Podcast, hosts Mike Fitzurka, Rick Stewart, and Jason Quattlebaum look at the challenge government organizations face when looking to update and modernize these systems, and explore if new approaches to application development – such as containerization and microservices – are effective when migrating or modernizing these massive monoliths.
Transcript: ContinuousX Podcast (Season 2, Episode 8) on Modernizing Monolithic Applications in the Public Sector
Jason Quattlebaum: Hello everybody out there, this is Jason Quattlebaum. Welcome to another episode of DLT’s ContinuousX Podcast. I’m joined as always with Rick Stewart and Mike Fitzurka. And today we’re going to talk about something that I’ve been hearing out in the public sector around customers and wanted to get Mike’s and Rick’s thoughts about that today and see what their opinions on where we as sales leaders should be our instructing our customers to go, and what paths to look at.
Rick and Mike, one of the things that I keep on hearing time and time, whether it’s DoD, SLED, or civilian customers is that they have these enormous systems, and they’re just reluctant to modernize them, due to fears, costs, or time. Any suggestions you guys have out there for customers like this?
Rick Stewart: Yeah, well, I think it’s important to solve … get to the root problem with the things that cause the drive to modernize. And there’s a saying in the IT industry that applications do not age like fine wine, they age like milk.
And the reason behind that is, the longer you let your applications out there with, let’s say, traditional workloads, maybe old versions of older languages, they tend to build up a series of vulnerabilities and exploitations that hackers, whether they be benevolent, will expose and be able to access your systems, access your data, etc. So, without modernizing, you really are exposing more every day as you don’t modernize, security holes that can be taken advantage of.
The second one, or maybe the second of many, we’ll just discuss a few, is the availability of resources that can support these applications, these monolithic applications. Mike and I are old enough, and I know I am old enough to have worked on COBOL systems. I worked on assembler systems, CICS. These are older technologies, and it’s more mature, veteran-type people that can support those because people coming out of college or being trained, they’re not being trained in those languages and how they operate.
So, the pool from which you can gather resources to support your ongoing systems is dwindling as each year goes by. The reason to modernize is to take advantage of the modern software capabilities that are built-in and take advantage of the resource pool you have out there for your labor costs in order to build applications and use them properly. And to plug up any security holes you may have.
Michael Fitzurka: I was going to comment on “aging like milk” because I enjoy a cheese, a 10-year-old sharp cheddar, that sounds great.
Well, when you’re talking about customers who might be reluctant to modernize, I tend to think then that they’re probably in a technical situation where it might be difficult to modernize. Maybe they have already an existing large monolith or a large … even a service-oriented architecture could be a large scale, that’s difficult to modernize. And so, it’s not maybe a reluctance to it per se.
Everyone wants something modern and new, but how do I get there from here? I’ve got these large systems, what do I do? And one of the … it’s very much a technical solution to the question, but it’s what came out of the time. And, yes, I’ve been around for a little bit of a while, the enterprise service bus / SOA era. One of the things that came out of that, or after that, was the advent of microservices, which helps get people out of, when applied correctly, can help get people out of this monolithic architecture and help to modernize.
Because the problem with large systems is that they can be difficult to change without having unforeseen consequences. Scaling is a problem. If you want to increase your capabilities, you have to duplicate everything. Everything’s in one large architecture. Alright, I’ll make two of them. But now I’ve got more things in some areas that I need and maybe not enough in others. And even a small issue can take down the entire system when it’s all one big application.
So, there are lots of problems with a larger architecture, and a smaller architecture that was born, coming out of that era, was saying, “let’s make a single application out of a collection of very small services”, microservices. And the rule of thumb was, let’s put one service to handle one function. I think that was a bit extreme. That’s a bit of an exaggeration. Really you should … anything that if I change this, I’ve also got to change this … is a component. And if I want to scale this, I need these things to scale uniformly, then that’s a component. That’s something that’s good as a minor microservice. And then you run that in its own container, or its own process, individual, so that you can scale it separately.
You can use containers in there. I mean if you’re going full out, I’d maybe suggest containers in there. But basically, it’s not necessary. You just need it to be self-contained. And maybe use a lighter communication protocol like web traffic and API’s. That all came out of the same thing. And then you create these smaller services to take care of things. And slowly you can drift your traffic from the larger systems to the smaller microservices and then your larger system can size appropriately downward.
Jason Quattlebaum: Now, Mike, microservices sounds interesting, but when you keep on adding, you’re talking about adding more to the equation. And anytime you add more, doesn’t that lead to more possibilities for increased problems and false positives, or operating costs going through the roof, more headcount?
Michael Fitzurka: Yes and no. I will clarify that. Certainly, none of the benefits of microservices come for free. Nothing comes for free. And where you might have one or a dozen large systems or monoliths, you could end up with hundreds, thousands of microservices. And the cost of that, as you pointed out, is the operational complexity. It can really become problematic if not handled correctly. And also, there’s an increase in network traffic. So again, things that you need… As all these things are communicating with each other the network traffic can go up.
So, yes, it’s not for free, there are problems with that, but there are a lot of things that have come out, with cloud resources and containers especially, that can add complexity to the mix. Especially because these things are more dynamic scaling, now they’ve now got things coming up and coming down, and now how do I track it all? Again, operational complexity. But there are a lot of external applications that you could use that help you track and manage these things more uniformly because, again, when you have a thousand different microservices, they all might report differently, or their statistics might be measured differently. They might even be in different languages which are harder to support. But you let the smaller teams then handle that smaller change, and those smaller changes are easier to fix.
So, where there’s operational complexity, you gain benefits in the fact that once you find a problem, you can fix it faster, because you’re only taking down one very small application versus the entirety of the application that has to be planned months in advance. And there’s a lot of applications out there, especially with the advent of the cloud and containers, that can help monitor these things uniformly and report on them, so that it doesn’t necessarily require increased headcount to manage all of these additional operational complexities. You can compensate that with automation and monitoring.
Rick Stewart: From a management perspective, viewpoint, tracking costs across programs and across projects, becomes more and more difficult with microservices. And let me explain a little bit more. I agree totally with Mike, on all the different “whys” you want to do that. But then the challenges from a manager’s perspective, from a financial perspective become very obvious.
From traditional monolithic systems, where you could take a mainframe and you can take IPAC charges, you can split them off across cost centers, and you can divvy up the cost across many different projects and multi-tenant uses of your mainframe, people started going into the SOA environments and buying either their own servers or buying servers and then splitting them up into different virtual machines.
You can easily charge the project or the program for those services or those virtual machines. And then cloud comes along and you can still manage your on-demand charges and you can scale up and scale down as Mike mentioned, but your services were deploying on virtual machines, easily tracked. Now with the advent of containers, we now have processes that are distributed across many different hosts across the cluster. So, you have thousands of processes or containers across hundreds, potentially, of hosts. How does one start to get an expense report of what you’re actually costing your organization?
So, it’s important to have technology… and I agree with Mike about automation… technology that understands that complexity and understands a Kubernetes environment that has the operational things that Mike talked about, making sure the team is up and running, it’s available, it can scale up, it can scale down. But tracking the cost to the organization has to be a technology that understands the infrastructure and how it works.
So, it’s monumentally important when you’re undertaking microservices, to keep a financial perspective in view, because you lose control of costs, you lose control of what’s running, you’ve lost control of your system.
Jason Quattlebaum: So, should my customers start with microservices?
Rick Stewart: Well, I mean, the knee-jerk reaction is yes. It’s the shiny new thing. Everybody goes after it. A realistic viewpoint, especially in the public sector, is you’re rarely starting out in an agency or department with no services, nothing to show. Microservices, if you’re going to do greenfield, yes, there’s a way to do that. But it’s usually private or startups with small teams, creating new projects, creating new innovative products that are literally out of brainstorming sessions. And that’s great because you understand the problem more.
The difference between starting out greenfield in the public sector environment is you have existing services and capabilities already at your disposal. The last thing you want to do as a project team, and from a taxpayer perspective, is to build redundant services within that department. So, if you go out and say, I’m going to create microservices to do a login, etc. Well, that’s probably already built.
So, the key difference is to take an inventory of what’s available and what are you trying to accomplish, and then start breaking down those monolithic systems and strangling them into smaller services to take advantage of everything that Mike said about testability, scalability, all those things. You want to get there, but you can’t start sprinting out of the gate. You have to really understand your domain, your agency, and what you have.
Michael Fitzurka: And they’ve done a lot of testing actually, even for unicorn, greenfield companies, when you start with microservices, that can actually be problematic. That can lead to failure. So, I think one of the leading thoughts that works well with microservices is doing Domain Driven Design.
So, you look at what’s my domain? Am I part of the billing world? Or am I part of the… I’m going to present options to the user? What service are you providing? And keeping those domains, as I was mentioning components, where you want things to scale appropriately.
If I build an application that has certain helpdesk features to it, that might not need any more scaling, that might not need microservices. Just because, as you mentioned Rick, it’s a shiny new hammer. Everything’s a nail. No! You can build a monolith to take care of that help desk functionality, because that’s not going to scale, that’s not going to have different things. Now maybe you’re creating a helpdesk application, that’s the main thrust of what you’re doing, then you might want to focus on that, as that’s your primary domain. Then let me build this out in microservices because I know things are going to be heavily drawing on it.
So, it’s like anything, you want to attack what’s the most important thing first with the best technology offering. And spending all your time building microservices, and all the operational costs that come with microservices, on things that are tangential, or not as important as the main thrust of what you’re doing isn’t beneficial. And a lot of domain-driven design, that gets you thinking about, what are my domains? What’s most important to me? And that pairs well with microservices.
Rick Stewart: One of the things, and I agree wholeheartedly, is when we’re trying to solve for X in the Continuous X equation…
Michael Fitzurka: For the SDLC equation…
Rick Stewart: It’s important to note that you should always be working towards value in your service. If you’re building things for the sake of building microservices, and it’s redundant, it’s already built, or maybe it’s offered as a commercial off the shelf, then that might not be the most beneficial thing to your organization.
There’s no one size fits all. It has to be a unique strategy and a tactical approach, little by little, in order to create value for your organization to accomplish your mission.
Jason Quattlebaum: Well great! Thank you, guys, for bringing me up to date on these topics. This is definitely useful and something that I’m going to take to my teams. And I hope, the listeners out there, you guys have gained something. So again, this is Jason Quattlebaum from DLT. And I’ll let Rick and Mike say goodbye as well.
Rick Stewart: I want to thank you, listeners, for your time and your effort. This is Rick Stewart for DLT, thank you.
Michael Fitzurka: Thank you.
