Accelerating App Modernization: Balancing Agility, Innovation, and Security

Hi. Welcome everybody. Thanks for joining us today.

Thanks for joining us on this, uh, special edition of the the last Great Cloud Transformation show. Uh, we do both recorded episodes and live episodes like this, and we're happy to be here with you. You've got a great topic.

Um, I think something that's gonna be, you know, resonate very well with a lot of folks 'cause we're, a lot of people are dealing with modernization types of efforts for applications and infrastructure and a lot of things. My name is Mitch Ashley. I'm VP and practice lead at the Futurum Group for ai, I'm sorry, at DevOps and application development, including how we're changing that with AI and, uh, software security, supply chain security, things like that.

My background is a product creator, creator as well as a practitioner, uh, myself. So good to have you here. Uh, I do wanna say thank you to our, uh, sponsors at CloudFlare, who, uh, help us put this program on sponsor, putting it on, and, uh, we appreciate their support in creating a forum to have these kind of discussions.

And we've got some really good folks to do that. Before I, uh, have the panel introduce themselves, a couple things I want to take care of for housekeeping. We are recording this.

It'll be available to, you know, anyone that's registered either now or maybe someone who comes by later and registered. So you can share the registration link with a friend and we're happy to have them watch. Uh, but the folks that are here in real, real time, uh, you'll get to do something special.

And that is, we love to have you comment in the chat. We'd love, love to hear what are your thoughts, what's your reactions to what we're saying? Do you have an experience like that?

It's a different experience that maybe isn't fall in line with what we're saying. You've got a different perspective. And then of course, question and answer, and we'll try to incorporate that as we go.

It doesn't, we have to, don't have to hold all those things to the end. You know, if we're in the middle of talking about data and how, what the challenges are of lifting data to where it is, to where it's gonna be, and you have an experience, you wanna say something about, type that into chat and, uh, or question about it into q and a. We'll be glad to, uh, incorporate that into our discussion as much as possible.

So we'll see us interacting on chat as well too. So with that, I'd love to, uh, get things rolling. Um, let's start out by doing some inter introductions.

Um, Johnny, while you were away getting water, I said you were gonna be the first person. I'll have do an introduction here. So if you would introduce yourself, that's about you and, uh, the company you're with.

Sure. My name is Johnny Khalifa. I'm CTO.

We are a software development firm. Our focus is on the multi-cloud and cloud infrastructure space, ab modernization and such. Uh, we are proud sponsors of the Cloud Native Foundation and I'm excited to be here today.

Fantastic. Good to have you and all of your experiences with us. Of course.

Sai you, would you introduce yourself? Sure. Um, I'm s Krishna or Sly, um, product marketing at CloudFlare.

Uh, CloudFlare is a unified, uh, global platform that helps customers connect, protect, and, uh, build new experiences and existing experiences for their customers and users. Uh, we are excited to be sponsors for this, uh, tech Techstrong show. Um, and I've been in the cybersecurity space for the last decade or so, so excited for this conversation.

Very good, great to have you. Thanks for being part of this. Cy and Tracy Reagan, Fran colleague, tech strong, uh, regular.

Thanks for being with us today, Tracy. Absolutely. Yes.

I am the CEO of Deploy hub. Uh, we are building a digital immune system to help your software self heal when a a code level vulnerability comes along. Uh, I am involved in the Linux Foundation quite a bit, including the Open Source Security Foundation and the Continuous Delivery Foundation.

I have a strong belief that we're gonna solve this problem by marrying the two security two real DevOps, uh, and start building tooling in to start, uh, automating some of these steps because we're gonna be seeing an onslaught of code level vulnerabilities over the next five years. Very good. Awesome.

Great. Some great experiences here. Um, go ahead and type and chat where you're joining us from today.

Love to hear, you know, you're in Vancouver or Dallas or London or wherever it might be. Love to hear from you. Uh, join in there and again, feel free to comment and go.

So to kind of kick things off, you know, we, we went through the covid experience, which has kind of accelerated a lot of move to the cloud adoption of a lot of, uh, SaaS applications, sometimes, uh, a little hastily, and we have to kind of go back and do some, uh, course corrections. Now it's a little bit different environment, right? We, we have a lot more focus on what is the ROI, what are the benefits to, to modernizing an application or putting it at a cloud, or even if it's in the cloud, maybe, uh, doing some modernization there.

Um, I'd love to hear, hear from the panel and, and Johnny, if you would maybe kick things off, what are some of the key drivers you see, uh, the people that you work with, customers you work with, and why they're modernizing. And we, modernizing is pretty broad, right? It could be lift and shift, but more often it's, it's, yes, trying to architecturally take some advantage of the cloud and the hyperscalers, maybe redeveloping portions of it to be cloud native, maybe just kind of architecting to be a more, more cloud savvy.

Um, what are your thoughts or why do people come to you and say, Hey, we, we need to modernize this stuff? Because I, I think it touch on a great point that it's the architecting for the cloud during covid. One of the things that we've seen the most is like, Hey, we might not even have access to our data center like we are locked down or whatever.

So we are moving to the cloud. If you do a lift and shift the way, you know, I'm running three boxes that have 128, uh, 128 gigabytes of RAM and all that. Uh, it will be crazy expensive.

It's not free, right? Like, it's not free and it's not a carbon copy of what you are currently running. So most of people come to us with these, uh, desire to modernize and to actually tap into the cloud the way it should be.

Meaning that elastic in a way that if we have a lot of traffic, we'll scale out, otherwise we'll scale down. And, you know, being cost conscious using only what you need and making sure that you have the controls and, and everything that comes with it to make sure that you, you're using the actual value of it, which is this elasticity to meet the demands. Otherwise, you just end up with an uncontrolled data center owned by somebody else that it's like 10 x of what it will cost you to run it OnPrem.

So that's kind of the way we see it. And modernization is key because hardware is super cheap. And when you're running your own thing, uh, there might be things that you don't pay attention to in terms of consumption and elasticity and how, you know, you know that you're getting a lot of traffic or not, and how do you scale in and out.

So those are the key things in terms of modernization that are aligned with innovation, cost consciousness, but also the agility, right? I, I believe that, uh, the way we go into production and we establish the ops pipelines and all that, it's also changing the actual, you know, landscape of the business, if you will. Nice.

Jump in. Who, whoever would like to comment next. Uh, well there's, there's a part that is you, you, some companies are fa facing the fact that some of the monolithic applications are becoming obsolete because of the hardware that they run on, and the software is no longer supported.

So in many cases, you're kind of forced to, um, rebuild. And when you look at rebuilding, you're looking at modernizing, and it does improve security. So when we're talking about, um, security and moving forward, uh, a more modern architecture is always gonna be better.

Uh, the monolithic has a lot of security flaws And, sorry, sorry. I, I think that the Tracy's point, another big driver that we've seen is like, we are no longer supporting dotnet three or Java whatever, or Python X, and it's like, you need to do it. And the app side in terms of security and all that is huge because you've been running something that's 20 years old, you never touch it because it just work and then you're forced, right?

Like you just need to go do it. Okay. Jump inside there.

No, I was gonna say that I think that's, that, that the, when you're forced to do it is probably some of the worst times to be in because you're not planning for it as a business. And that's when what we find is that the app modernization is a tricky and sometimes daunting, sometimes risky kind of transformation. It's not a, just something that is just been done by everybody and therefore there is a clear path for you to go do it.

Hopefully it is in some of your applications, but it's not always. And it's the worst case scenario is when you're forced to do it because, um, of technology reasons or compliance reasons that you're not looking forward to. Um, and I think the other thing that we find is customers think that, um, you just get security by default by going to the cloud.

That is somewhat true, but actually what we find is because it is a different construct that you have to think about that you can make a lot of different mis missteps. And so you'd still need to be thinking about your security models, your threat models, and be planning for that. As you think about your app application modernization journey, There's a human factor in this too.

If you really wanna retain talent, you're not, you're not gonna get good talent if you say, yeah, you come, come manage and maintain our modernize our monolithic application. If you wanna bring in good talent, um, which we all do, it has to be an environment where they wanna, they can see that they can learn and grow from. Uh, and it, to me, that's one of the, a a primary drivers for companies I talk to is that they, they wanna make sure that they're bringing in the, the brightest and the best.

And they're not gonna take on a, a monolith, Chris, I, and being forced to do this as that's how we, we do everything, but we're forced to do everything. Most companies get into this at a point in time that they have to do it. I mean, I will say the corollary to that is, um, there it is very difficult to find developers or they're quite expensive to, to, who will write COBOL and maintain your mainframes.

But then it is equally as expensive right now to get developers who are very conversant in the latest AI technologies or AI infrastructure. So preparing for that, at least through experimentation, we'll talk more about it I'm sure, but as we think about application modernization, breaking it down and kind of doing more experiments so that you are kind of dipping your toes and, uh, trying various things is very helpful, uh, before you have to make a major change. And I, and I think it goes back to your point s in terms of, uh, when you haven't planned for it, uh, or, or you are forced to do it, uh, then it becomes even more expensive because as you said, right?

Like, I just need to go find people that know the latest and greatest. I I haven't planned, I haven't planned for it, I didn't want to even wanna do it, and now I'm forced to do it. So it becomes like, you know, uh, a vicious circle in terms of like, okay, let's try to do the least minimum amount of changes because we are paying these developers by the hour and they are really hard to find and we didn't wanna do it, but we are forced to because of compliance or maintenance or whatever.

Uh, so I think it's, it's, it's this mentality of, um, agile, right? And, and, and I spoke with Mitch about it, uh, a couple of days ago in terms of, think of it as it and increment, right? Like there is no trauma modernization if you need to be rewriting the whole thing the whole time, right?

It's more like an experiment based thing, thinging, where you just, you know, step by step try to, let's change this and let's change that and let's make sure that we are more secure and we pass this test or that other thing, rather than like, sure, we become, we became, you know, obsolete or our stack is no longer maintained. Let's think from scratch how we want to do it, but also we need to keep up with our roadmap and our product feature and, you know, you have a business to run, so you cannot be rewriting the whole thing the whole time. So, uh, I think there is a quota of modernization that needs to go into the day to day, like how you keep up with things rather than thinking in terms of this big bang thing that, you know, yeah, sure.

Two years from now we are going to rewrite the whole billing system, as Mitch was joking with, That's a career ending move. I can attest to that. Not that I tried to do it, but I've seen that before.

One of the things we aren't, haven't talked about yet is, um, you know, the perception of the flexibility of the cloud. You mentioned elasticity, Johnny, um, mean you can certainly move something in cloud, not getting those benefits. So whether it's in the hyperscaler Excel itself or, you know, through a network like CloudFlare, part of that is, is summary architecting.

Some of it is also just a mental model of how you think about solving problems. Um, I I know you think about the human side of it a lot, Tracy, I, what, what's the cloud mindset that you, you wanna apply to a modernization effort? So we have to start thinking about features.

Um, we have to be focused on delivering smaller features and having feature teams. So from a culture perspective, you know, when I was developing software, we had application teams and application team wrote everything themselves. Um, there was a, there was a point in time that we tried to do better shared code across different application teams within an organization.

But now in a modern, in, in, when you start modernizing, um, you really have to start thinking about a domain structure and feature teams. Uh, it, it's a big shift. It really, you really have to rethink from, from a human perspective.

Each developer has to start wrapping their brain around if they write a piece of code, is it a feature or is it something that's just for their application? And as companies move down this road, the more that they can focus on domain driven design and understanding what those features are and start breaking teams up into feature teams, the more successful they become. Because they're not developing applications.

They may have a team that's assembling an application and write code features for that particular billing system, for example. But they're, we're, we're building a Lego set, right? We can go borrow pieces that are already written.

And that I think is one of the biggest challenges for developers because every single developer that I, I, I have worked with, they have this mental state of not invented here, and they think they should write it themselves. And that goes back to being a monolithic application. So developers, we have to think of domains, we have to think about tiny features and more microservices, more APIs and more microservices.

And you don't have to write it yourself. You don't have to go find it in a GitHub repo that's that and, and try to change it. And that, that, that's just a, been a struggle with any kind of common code design.

And I think we still see it. I love that idea. Um, Tracy, because one of the things I learned, um, as I, I learned it in a very hard manner because I was the product manager for a, um, it failed at start and then we picked back up, and I luckily when I left, it was, it was in good hands, but it was an application modernization.

We were modernizing our customer service, um, application that we were, um, at, at a previous firm. And one of the things we learned, this was still mid 2000 tens when the cloud was still much younger in, in its, um, maturity. And we had a sense that we had to go build, rebuild everything.

And we did the good thing of kind of, uh, breaking down our application into its component parts, but then we thought we had to rebuild every single piece of it. And there, there wasn't a, a thought process as you were talking about, which is, can we cobble something from, use something from elsewhere in either in the company or in open source land, um, then we can cobble the application together, uh, much better. And that was a learning that we had to go through because it took us much longer.

It took a, what was supposed to be a year and a half project took three years, um, because of that build it here kind of mentality. I noticed that Got your attention there, Johnny, you were smiling. What, what's that about?

Yeah, lot, lots of stories and, and, and a lot of things I agree with, uh, starting with the feature team. We working, uh, at South Works, we work with what we call the fire team, right? These are teams of three people, and everybody ask me like, Hey, why don't you use five or 10 and I need six developers.

And it's like, no, it's two teams. Because you need to break it down to the level of a problem. And that's why I like Tracy talking about domain dream design, break it down to a problem in which is manageable and you know what you're doing and you're solving a problem, building a feature, call it the way you want to call it, but it's code.

And it's not a crazy thing when you keep pouring, you know, more people, more time, more lines of codes and, and so on and so on and so forth. The other thing that, that I find really interesting about these red writing stories is I, I remember working with somebody that once told me, if you know where the trash is, then it becomes easier to take out the trash. Meaning that when you go into these, like as Tracy was saying, like no longer monolith, you don't need to rewrite the whole thing.

Let's start by putting an API on top of it and let's start by defining a contract and you know, that's trash and eventually you need to rewrite it, get rid of it, replace it with an open source project or whatever, but know what it is and define a contract. Like otherwise. It's like, uh, the, the Pandora box effect, right?

Like, sure, we'll rewrite these, but now that you're at at it, why don't you just rewrite that other piece and that other piece. And I say, as I said, six months become two years and two years become five. And we've seen that because we, we usually talk about modernization as this, you know, balancing, uh, where you want to be plus the technical debt aside from the, the, the actual like rewrite of the thing.

There, there might be some things that you want to do that your system doesn't do right now. And I hate the phrase of like, why you are at, at it, why don't you, and it's like, yeah, that's the beginning of the end, right? Because it's like, sure, let's keep, you know, throwing things and, and, and I think that that, um, slice it and dic it as an approach and having good APIs, good contracts, microservices is a deployment model that works for all of it.

It's a very beginning. And then integratively, you can start swapping out pieces and, you know, getting rid of the things that, that you might not need. But, uh, doing all at once, it's never a good idea.

Yeah. The, uh, infamous scope creep, right? Well, while we're at it, let's, let's throw in the BA billing system, rewrite that, you know, it, one of the things that also changes pretty substantially is how you think about, um, communications both within applications like microservices and APIs, and kind of the network is inside the app in many ways.

Um, but also, um, when you're dealing with hybrid and multi-cloud kind of situations, um, you know, I, I grew up in, early in my career, the network part of this was always kind of the erector set of connect point A to point B with this level of speed of service over this technology and B2C and Ed. And, you know, you kind of build this pathway that was a fixed network, and now we interconnect those, right? And it's all done through routing, but a lot of, a lot, a lot of security, for example, is in the cloud itself, not necessarily in our own infrastructure.

Um, but it also starts at the app level. Um, Tracy, I'd love to hear your thoughts on how do you think about security when you're building an app, uh, that's gonna be kind of cloud native or cloud aware versus something that's external to your app? Okay, so we, we talk about all the fabulous things that a cloud native architecture and microservices brings to the table.

And it's essential to go there. We have to, in order to continue modernizing and with, you know, we're being, you know, everybody's trying to do something with ai, so there's a lot to do right now, there really is. But we have to understand that when you start breaking out your application into these smaller containers, every container has a workflow.

So what does that mean? It means that your DevOps, uh, you're gonna have a, a lot of workflows, uh, not just one monolith monolithic workflow that built the entire application, which by the way, would've generated one software bill of material report. And you could manage vulnerabilities quite tightly because you're not duplicating.

When we duplicate, we duplicate workflows. Everything, every, every container, um, every microservice is independently deployed. It has its own SBO m and it may consume the same open source packages, but different versions, then another container that's in the same application.

So organization and visibility and the ability to aggregate data up to an app, a logical application level is essential for us to start tracking this stuff, understanding how the pieces are put together and track the versions because a vulnerability is associated to a version. And then that particular version could be installed in 50% of your containers, not all of them. So which ones do you need to patch?

So this is what we think about at Deploy hub is how when we, when we, you know, put a hand grenade in the middle of our applications, and now there's, you know, hundreds of little pieces, how did that change the life of a DevOps engineer, the life of a developer and the life of an, an ops person who is now managing many, many more deployments, getting pushed through the pipelines all day long, which is a good thing, but it also can be hard to manage. So how do we do that? How do we evolve DevOps and how do we start including security in that and aggregating data up so that we still don't throw away kind of the baby of the bath water?

We're still delivering applications to our end users. How do we see that application now and how do we manage it? Those are the challenges that we see.

I, Yeah, I, I'll add a story on this is, um, so different AppSec application security perspectives on, on this one as the bad way to do this is to run your scanners and essentially get duplicates of the, of those vulnerabilities across all of the services that you're now running. Um, and then pile that onto the development teams. Um, that is a bad approach to kind of take towards this.

Um, because as, uh, Tracy, you were saying there's no context. Does this all, is this all related to that same version? Is it a different version?

Is it all related to one application, a logical application? If, if, or even is it related to that same microservice? Is there a reachability, is there a, uh, kind of, um, a priority to this?

That is what we saw when, uh, just personally when I, in that, uh, as a product manager, when we were trying to push this new application through, because the number of vulnerabilities just shot up, um, because there was, there's so many different services, um, that we were using. The better way that we found was can we identify in that threat model what is the most likely to be exposed to our customers first? That was a business decision we made most exposed to our customers first, then most exposed to the, the majority of services.

And last, that is much more, uh, that's much less reachable for, for a better way, uh, to put this. And, um, one of the things as I've come to CloudFlare, uh, I've realized is the value of while you are having making these changes in your application, it may, the application may still be running it, you know, you're still serving your customers, can you put in place some more restrictions? Or can you put in place some more defenses, uh, in depth, whether at the network layer, application layer, identity layer, um, and that, that's something that CloudFlare has had a lot of success with for customers during their transformations, whether it is from, you know, cloud to multi-cloud or in the multi-cloud, rewriting those applications.

Um, all of those, uh, kind of situations. I think that, um, there is, there is this thing about, you know, uh, we talk a lot about DevOps, right? Like, and, and we've been talking about DevOps for the last 10 years, and continuous integration, continuous delivery, automation monitoring, all these things that back then, or as we went through this journey, were nice to have.

If you don't have them now, that will kill you, right? Because if you have 50, 60 GitHub repos with different sets of vulnerabilities, with different versions of those dependencies that each and every one of them have, and you need to orchestrate a, a, you know, a deployment or a patching of all these thing at the same time without breakability and without these contention nets of like, sure, before we, you know, deploy, we run a bunch of tests and we make sure that things work and we know what things can break and all that. As Tracy was saying, in terms of data, like you can look at all the dependencies and where is the overlap with those that are, you know, to something that was recently found, and then how a streamlined way of queing and delivering those into production.

And you just, instead of doing that, you just rely on people that will go look into that data and will orchestrate the process and will follow a checklist. Well, that won't do because these microservices, you know, containerized world of multi-cloud without different operators and things like that, it's really hard to operate and to maintain and, and it needs to be automated. And it's no longer a matter of like, Hey, shall we have it?

It will be nice to have, it's like, if you don't do that, then you're done, then you're done. Like, there is no other way of doing it. And I, I know that it seems like, you know, I've been doing DevOps my entire career.

We used to call it configuration management, right? You know, it just has been given a new name every, you know, every 10 years it gets a different name. But I wanna point out that when we are in, um, hype cycles, like the investment going into ai, um, and, you know, maybe the coming years we'll see more startups.

These companies don't necessarily do DevOps. It sounds crazy, but they're being pushed to deliver an app, deliver a solution, deliver a solution. They're not like a larger bank or an insurance company or a telecom who has the resources to put together a DevOps team or build out a DevOps process.

So I'm seeing more and more is in particular around startups, this idea that, uh, you just described this automation not being a priority. So while, you know, modernizing your app, ha it has a lot of benefits. And some of it, you know, with a company like CloudFare Flare, you're going to get, you know, application firewalls and some zero trust security, which is huge 'cause it solves a lot of, of those problems.

But when it starts coming to the code level and making updates and pushing things across, it's not just vulnerabilities that are, can be a problem. It can be two containers that were built, uh, with similar code that somebody pulls in and tries to use and it doesn't work, and you can't figure out why. So DevOps is still really important.

And for anybody out there who's in a startup, you know, don't discount it, don't discount the automation. And in fact, I would say that's where you should start your application development, is to build the factory floor first and then start building the products. You know, I, I completely agree.

And the other day we were having this conversation with Mitch, in which I said, like, that's where you should start. Even if it's pushing just a simple HTMA file that says it works, but you have the pipeline because the more time you take to, you know, commit to it, the complex the system will be, and the harder it will be to try to, you know, retrofit that into your existing process. And that's how, like, if you don't start from there, you eventually have these like, well, you know, it will take us too long to do it, and, but the more time, you know, passes on the, the, the harder it will become.

And it's, for me, it's like the way to start building the, the factory ground like floor or ground zero or, you know, deployment number one, it works, but otherwise, like, it's this thing of like, okay, it's really hard and it's boring and it's super complex and will require a lot of time to do it now. So we will just keep postponing it until it just breaks. And, and as you said, Tracy, it, it breaks because nobody know why it's broken, like nobody knows.

Like sure, it's two containers that have dependencies with each other, but different versions that are tagged from different things and it becomes impossible. So I completely agree with that. Even before you write the first line of code, like knowing how those lines will make it into production, it's the way to start with this.

Otherwise, it, it's just too complex. You know, one of the interesting parts is, um, so CloudFlare is often brought into, um, conversations when customers are going through modernization, whether it is network or application modernization. In this context it's application modernization.

But one of the things we tell our customers is, have you got your planning, basic planning? You may be under time pressure, so you can't do everything understood, but do you have a plan for how you're gonna have visibility into what the logs and the traffic that is gonna flow through your, your newly built system, whatever your newly built system, or whether you are refactoring your code or whether you are just replatforming and trying to use some new services. And the second one is on the threat model side, do you have a sense of how your, the most common threats gonna affect your systems?

How much more exposed are your systems? Are you, you know, what are you doing in those kinds of contexts, um, both for your internal and external systems that you may be, uh, kinda replatforming or, um, or re rebuilding in itself. And so I think that is something that often if you don't do that, you may have brought in companies like CloudFlare too early into the process, um, and you don't, you're not ready for, um, that kind of pro um, that kind of process.

And there are many, um, examples of this that, that happen. And obviously we can help, uh, anybody can help get you through that process, the thinking, but once you have that, it becomes easier to take that first experiment to rebuild or rewrite or, uh, refactor. Um, and that, that that's what we have seen at least.

You know, Cy, you had a, you brought up an interesting question in the green room before we got our, our webinar started today, um, about projects getting stuck. I'd love to have you kind of pose that question again. Yeah.

Um, what the que question is really, there's a lot of excitement around application modernization projects, but the data is quite clear that a vast majority of them are stuck, deliver unclear or failed. ROI. So is the biggest challenge in application modernization, rewriting your applications or actually getting stuck in one of those phases as you're going through it, you just have made mistakes, whether it is refactoring your code, re-platforming, uh, or even rehosting, even if that's, that's the easiest kind of form of this.

Um, I wanted to just put, throw it out to, uh, Johnny and Tracy as well, You know, in, in our experience when we see that it's, um, it's usually not a technical reason, right? Like there are bad decisions that you can make throughout the journey, but what we find as the most interesting thing when facing these projects is having a clear definition of done what, you know, what done means in that context. Call it phase one, call it beta, call it alpha, call it like, you know, B zero or whatever.

But having a clear statement of what done means in this modernizing modernization context is crucial. Otherwise, it's not that you just get stuck, is that you have a floating blob of scope that becomes bigger and bigger and bigger and begins, you know, swallowing other pieces of the system that were originally in scope. And all of a sudden you're redesigning the network and changing all your firewalls and rewriting everything in rust, because why don't we just, you know, look at performance and all those things happen because there is no, uh, a north star where you can say like, sure, B one will be, I have these containers, I want to run them here.

I will have these pipelines that we don't have today and that we'll call it success. We'll celebrate on Monday morning, we'll come back and look into, you know, adding the web application firewall. We'll call this test next Monday, we'll come back and we'll celebrate.

And we have these, you know, quick wins done, built on top of each other. Uh, and that's a clear definition of success. It's something that as a team, when you're working at it, you have something to celebrate.

You have something to enjoy and to call it done. And then you go, you know, relax, recharge, and come back thinking of what's the next problem. Otherwise, you are just like, you know, it's this thing.

And, and we as developers tend to, you know, underestimate the fact that time is finite, right? That, that, you know, at some point you need to sleep, you need to eat, you need to, you know, go do something else. So we start with these things like, hey, but we aren't talking performance, or we aren't, you know, doing a deep dive on security, nor we are having like software defined networks that can, you know, reroute traffic if something happened in multi-region, multi availability sets.

And it's like, are you running multi availability sets, multi-region? No, but what if we want to? And it's like, sure, that's the beginning of the end.

Yeah. So what oftentimes it happens is we underestimate when we, when we look at our, um, our legacy applications, we underestimate how connected those applications are. You know, you're a bank, you have, you know, mortgage and fraud connect with, with, uh, you know, I don't know, um, merchant, uh, uh, balancing.

So you have these monoliths that are sharing data, and when you go to try to break them apart, you, you find out, well, if we, there's a dependency structure. If we change this one, do we also have to change this one? So what happens is we get over ambitious, right?

So we do have these, you know, over ambitious goals instead of focusing on how to do it incrementally. In other words, agile, agile practice applies not just to writing one soft piece of software, but it may apply to looking at how to modernize your, your technology from a broader perspective. That's why, and I'm gonna bring it up again, um, really looking at your system and building out a domain structure and a domain driven design becomes important, and making sure that what you're touching may not have dependencies downstream.

And maybe it's, it stands alone when you're in, in your first application, because once you start touching applications that have interdependencies, that you become over ambitious, and that's how you get stuck. I, I'll say I, I, um, some of our best customers, especially in the finance space, they have so much legacy, but they've also had so many experiences, maybe some failed experiences as well, um, in the past. But one of the things we have seen, especially when they're rewriting, uh, when in that kind of rewriting of applications, they've actually done a couple, at least a couple of experiments, um, on parts of that.

So you were talking about, you know, the mortgage and fraud, and then there may be a credit line that is, uh, related to that. And one of the things that we saw was they were taking parts of those applications and just having a team experiment with some of the new technologies to, to see what they learn. And this is kind of set aside from the mainline, uh, part of the business.

And these experiments were, you know, frankly speaking, ai, when you talk about AI being used by applications, a lot of banks were experimenting it with it in 20 23, 20 24, by with these types of projects where they were not part of the mainline, but they were learning a lot, uh, that were being brought back to the, um, the, the core development teams. Um, and that, that's something that we have found, uh, has been really helpful. Um, obviously this only applies to organizations that have a very large, um, developer base that can, can afford to do these kinds of things.

You know, I, I, I agree on the approach, and I don't think you have to be super huge to go do a spike and fear out, because at the end of the day, one of the things that we've seen, and I have had a lot of discussions with customer either ruling out one of the, you know, technologies or making strong statements about like, this doesn't work. It's that you don't know whether it is the technology not working or your system not being prepared for it. So that learning of like, Hey, here is a container, let's deploy a simple hello world.

Does it work? Is it running? Like, can we, you know, monitor?

And it's like, okay, now let's think in terms of our applications, because we tend to mix both. We try like the, the first impulse is like, you know, let's contain it as my big monolith thing. And it's like, it doesn't work.

So oftentimes it's just a couple of hours. Uh, and, and I think it goes back to the point, uh, on the talent, on the talent point that Tracy made at the very beginning, that you cannot be working on the edge or having your system on the edge every single day. But those are opportunity, those are also opportunities to, you know, have the proper talent with enough room to experiment and to try new things and to figure out how to bring those back into your whole system.

So I don't think it's a matter of size, it's a matter of practice. It's something that, you know, we need to, uh, we, we need to start looking at, at it closely. And, and it's like, okay, I'm learning this technology in this context, let's, you know, separate my current problem with how the technology would work.

And, and I was, you know, as, as Tracy was talking about these monolith applications and the dependencies and having that design, uh, we have found cases in which applications talk to each other on shared memory spaces, and there is no, you know, piece of code nor architectural diagram that would describe that. And it's like, sure, we are living this in memory and we have a background job that it's running on a, you know, a span of thread that has access to that space. So we read those numbers from there.

It was technically impossible, like we didn't understand what was going on. And I, everybody prepared nice diagrams for me, and I was like, okay, what's going on? No, we have this dependency.

And I went crazy. I was like, two days without sleep. It's like, I cannot understand why this is not working.

So those are the things that I will fight first, because those are the ones that, you know, uh, are becoming really stressful. And, and, and, and we reached to a point, and I remember with this customer in which it was either we fix it now or we just abandoned the project because it's too complex. And it's like, you know, doing this domain design or the components, and even if it's like outdated, all code, whatever, having an API knowing this will talk to this component, figuring out how you will slice it and then doing it, it's kind of the way to go.

Because otherwise you would spend like me three days or two days without sleeping, trying to figure out why the background job had access to a table that was running in memory without no API calls. I even put like white shark. And I was like, this is maybe calling a TCP endpoint that I don't see until I found out that since it was a threat start from the current threat, it had access to a static hash table that was running in memory and that almost killed me.

So Johnny, that is such a good example of why teams get stuck in trying to modernize. We've written, you know, we don't try to, I mean, I, I really believe that everybody does their best to not make things complicated and not over-engineer. But we are, as developers, we like to tinker.

I worked with developers all my life. I'm one myself. We like to play with things, we like to tinker, and sometimes I think we have to reassess the goals.

We have to step back and say, are we delivering a better solution to our end users? Is this in line with the business? And sometimes we're like, well, it doesn't matter if it's in line with the business, we really need to modernize because in the future we're gonna do X, Y, and Z.

Well, that might be the case, but don't try to do it all at once. And, and I think it touch a, a great point there in terms of the business, because one of the things that, that I've seen, uh, running these modernization projects for 15, 20 years now, um, is that oftentimes you go meet a CEO that would say like, where is the business value? net three two net core in containers running on Linux.

Instead of buying windows, instead of paying Windows licenses. I don't care about, you know, the bottom line optimization, where is the business value? And I think we need to, you know, develop the muscle of explaining that these are the things that will eventually kill you.

Like people won't go to your competition because you might be missing a feature, but if you have a huge data leak, you'll be big trouble. And you are out of the game. And, and I've seen this, you know, back and forth with different CEOs or business people trying to, you know, win an argument that rewriting the whole thing or patching vulnerabilities or having a dev, a DevOps process in which you can go into production in five minutes, that's not deliver real business value.

And it's like, it's one of those things in which like, you know, that if you don't do that, like you might be out of the game completely one day, like when you're at least expecting it, it will happen. And that, that's like the point of no return. You know what I mean?

It's that thing that in which like, sure, all our passwords are now published on the web that that's game over, right? And, and we have these feature product mentality that comes with like, okay, how many blows and whistles we can put into the apps and make it more shiny? And the way we are not gaining more customers is because we are missing that thing.

And sometimes we overlook the fact that not doing these things, not having a proper threat model, don't like not having a vulnerability map or dependency map in which you can track your bilities not having a process to go into production one day. You wake up, you open your email, and it's like you impound and game over. No matter how many new shiny features you have put into your app, it's over.

I I'll say I, I I, on that point, it's a very, very important point of resilience. Um, that is so very critical. So one of the things that we, we are learning is, and it's back to Tracy's point, developers are trying to do their best at, but what happens is over time you build something, it is used for a long shelf life, hopefully, but especially some things that are successful, they may be a hack, it start, but then they're used for a long period of time.

And what happens is you may not have been testing everything at the start, but when it then grows into such a critical piece of software for the organization, now testing becomes so much harder. And, you know, having visibility and observability around it becomes so much harder. And that's when if something goes wrong, now your resilience is at stake.

And it's not just even security problems. I, I obviously, uh, CloudFlare cares about security issues, but even basic problems such as you have not tested it, there's a new release that breaks, um, the app or breaks that service causes huge resiliency problems for your customers down the line. And that's, that takes a lot of work.

And we know a lot of organizations in 2024 had to spend a lot of money to try and build back that credibility, um, with their customers. Yeah, it's gonna take a while before American Airlines builds back credibility for me. I had a friend stuck in Dallas for, from Christmas Eve at one o'clock in the afternoon, and he didn't get to Al Albuquerque, which by the way is away a nine hour drive for 24 hours later, Christmas Eve and Christmas day he spent at DFW because somebody, somebody maybe didn't do contest, it was just a report.

It wasn't, it was, it was an hour outage. So yeah, all of these things matter because I'm still irritated with American Airlines for that. It's a horrible thing to put people through.

And if they're practicing good DevOps, I can't imagine anybody suggesting they do a release on Christmas Eve. That's a good thing. That's common sense, you know, like that, that's just common sense.

And I, and I, I remember these like, and it's, you know, uh, it's one of those things like no, no releases on Friday sort of thing. Uh, but you need to build the confidence. Although one thing is like, you know, being confident about your process and the other one is trying to ruin, you know, Christmas day, Christmas Eve for everybody else.

So that will be like common sense sort of Thing. Common sense, Absolutely. But at the same time, you know, in our earlier discussion about DevOps, I still feel that we we're starting to forget the importance of DevOps and the importance of automation and the importance of going through the proper channels in the effort to get new features out.

And maybe all those features, those shiny new objects, as you said, Johnny are not that important, right? Then. Yeah.

And, and, and one thing that that, um, I've been talking about for, for the last year or so when it comes to DevOps versus developers and stuff like that, is this idea of, you know, as a developer, we are at a day and age in which you need to be accountable for the whole thing from the docker file of your container up to the line of code or the unit test that happens there. That world in which we wrote things in vacuum and pass it on for somebody else to deploy it won't do because it's a Lego set. Like my kids have these like 1000 pieces Lego thing, and it's like, daddy, I want to build a dinosaur.

And it's like we just have that, you know, weird piece that comes in, like there are three of them, and I need to go through a thousand to find the dinosaur head to build that dinosaur. If you are deferring like the deployment and orchestration and monitoring, I, I'm not talking about the real ops, uh, like the real time operations. I'm talking about having awareness and accountability on top of your docker file, your, you know, pro uh, endpoints and those sort of things.

Then you are like me and it's like a, you know, Sunday morning trying to, uh, do scuba diving on a Lego thing to find out the dinosaur head because you have a thousand pieces, right? Like these microservices and each and every one of them have like a few hundred lines of code plus a docker file, plus a dependency file, plus a unit test, plus this thing plus the manifest that goes into like an Argo. So you have that versioning thing, and we can no longer defer that and say like, sure, somebody else will take care of that.

It's part of the accountability of the team that is the role of the oversight of the whole, you know, flow. And it cannot be like, sure, we decided on Christmas Eve that we are going to re-release our data access microservice sort of speak, but it cannot be fire and forget like, sure, we wrote this, somebody will pick it up and build a container. So I think that that balance, it's, it's that thing of like, it's not that we are underestimating dev ops.

It is that we are putting a lot of pressure on the live ops team that should live with us developers at some point to, you know, understand how we are running our thing, understand how we are building our thing, understanding how that will go into production and eventually have the proper mechanisms in our code to facilitate that for somebody else to send it into production. So we don't have that crazy Christmas Eve story happening again. But We never should have that.

Absolutely never. I, I agree. I agree.

But it's this thing about accountability that oftentimes, like as developers, we just overlook that and we say like, yeah, the code works. It's the old, I remember when we started, and it was like 15 years ago, we started working with a build and everybody was talking about continuous integration and it was like, it works on my machine sort of thing, right? So that doesn't happen because we use a cloud and we use container, but it's like it was working on staging like that.

We try it out and it worked. It, it will no longer do, right? Like unless you want to be, you know, looking for that dinosaur head on the Lego thousand Lego pieces box, just, you need to have the accountability and the vertical view of your whole thing as a microservice, you are operating a service, you are a service provider within an organization.

You are no longer like, yeah, sure, I'll write the code for this feature and be done with it. I have a feeling you've been on that dinosaur head hunt a few times in the Lego bin. Johnny, I think it's a great analogy.

I used to, uh, use the, the analogy of a junk drawer. People write microservices and they throw it into a junk drawer. And so if you wanna use it, you gotta go through and dig through and find, you know, the, I don't know, the chewing gum wrapper, the, the letter opener, a stapler, where is it Covered a lot of ground here.

We're just about outta time. Maybe there's just, if I could share a few thoughts to kind of wrap things up. Um, one, one of the things is earlier in my career, at some point I developed this sort of axiom, my own axiom belief that any deliverable schedule for 90 days or more was guaranteed to be a like a hundred percent of the time.

And part what sort of led me to that belief was actually not that 90 days. That was if you make something too big to get it all the way through the process, everything else happens along the way and it's in, it's by in and of itself, it sort of craters under its own weight, which laid led me to another belief, which is there's, there's nothing more valuable than getting something into production, even if it's not a production app, but going through the whole process, right? You don't have to do it all at once.

Maybe it's just getting through A-C-I-C-D pipeline. Once you just getting it into the test environment, maybe getting through the automated testing, maybe deploying the whole world into a production environment, maybe it's putting the security controls on top of that. So by the time you're really doing it, you know, for real, for the code, you do wanna get into production.

You've done it a dozen times or maybe a hundred times. Um, but you, it's not the first time when you have to do it that you, you're, you're learning everything, uh, for the first time. So that, that's really one of the ideas behind DevOps is that repetition is, is part of what builds experience, builds quality, builds in security, or can help you get there along the way.

So, you know, never make a deliverable more than 90 days out and you know, get some ship something as, as soon as you can as office. You Know, you know, I used to have these, these thing that that, uh, we started, like for me, having developers going through that, you know, deployment process is one of the most important thing. So we used to have this backlog of things that we will call the good first commit, there will be target.

And when somebody join the team, it's like, pick one of those up and you, you know, you'll do something and we'll go through the process. Oftentimes it had the problem of, you know, we might break the bill because it was a good first commit, but it might be like an issue. So eventually what I did was like, we used to have like a JO file with the, our team thing on the website that will show the website and we had a hardcoded unit test that will have the same list of names.

So you will break the build on your first day and you will fix it and you will push into production. The first day it was just putting your name on the wall, right? But there is nothing more satisfying than that.

Like when you see the logs flowing and everything and, and it feels good. Everything is green and you see, you know, uh, containers provisioning. So, uh, I think 90 days it's even way too much.

I would do it in like 1, 2, 3 weeks. No more than that. I agree with that.

Well, thank you Johnny. Thank you very much. Um, Sai, thank you so much and to you and the CloudFlare team for absolutely sponsoring our conversation today.

And uh, Tracy, thank you as always. Um, super enlightening having you on part of the conversation. Oh, My pleasures, It's It's all of ours.

So thank you to all three of you. Thanks to our audience, we got some questions and, uh, good. Some participation.

We hope this has been valuable to you. You know, modernizations are, efforts are rarely anything but large undertakings. I mean, they're involved and you're always better by chunking things down into smaller elements, problems, whether it's the code or just the problems that you're tackling.

So, um, working with some folks that, uh, have maybe have done parts of that before is also a good strategy. So whether it's hiring the talent that might have gone through, part of what you're looking to do, working with partners, um, or just learning from others that are colleagues in the industry. You know, the good thing about our technology industry is we get to share a lot with each other.

It's part of what this forum is about. So thank you for joining us today for the, uh, the last great Cloud transformation and being part of this conversation, and we hope you'll join us again. Thanks.

I, uh, Tracy, everybody have a good day. Thank You. Thank you.

Thank you.