Name: From Legacy to Modern: A Choose Your Own Adventure
Uploaded: 2025-11-25T06:33:03.562Z
Duration: 1 h 10 min 36 s
Description: From Legacy to Modern: A Choose Your Own Adventure

Transcript for "From Legacy to Modern: A Choose Your Own Adventure": Hi, everybody. Welcome to, the webinar today. I'm Mick. I'll just give you all a little bit of, time to, to get settled in. I've already started a poll. So today's session will, have plenty of, q and a and polls going on. So I'm trying to make it really interactive. So, be sure to, put in your vote for, where you are currently in your role. Just give you a little bit of time, and then we'll, kick off the talk. Again, thanks for joining. Alright. So, I'll just do a quick spiel about myself. It won't be too long. I'm Nick Davies. It's definitely, been a bit of a journey in IT. This is year 19 now, and I've kinda worked all across different, industries and segments, with large and small development teams. So, I think I have a pretty, broad view of the world when it comes to, web development. Definitely try and reach out to me, if you've got questions, after this talk, as well as during, but, yeah, love to always connect. I do go to the Cloudflare anycast meetup in Brisbane. If you're ever there, say good day. I just saying just like a PS here, I don't actually work for Cloudflare. I'm just, like, a really big fan, and I've used, the products and and services for a long time now. So, what I've found across different industries is that they don't really know what they can, use it all for, and leverage the power like the, Cloudflare network. So, hopefully, today, you get something out of it. You you might already know some of this stuff, and, and then, hopefully, you have some takeaways where you can get started with the Cloudflare platform. So, let's jump in. So today's talk is a little bit about maybe you've got, some legacy code, maybe you've got a repository that's full of spaghetti. I'm sure we've all seen it, and, and then there's many ways to try and resolve it and fix it and work with it on a day to day. So I just wanna kind of explore some of those, tools and tactics that we have up our sleeves to try and, wrangle that in a little bit. So what approach do we take? Well, as we know in IT, it always depends. Like, taking on a modernization project, it it's a big feat, and and it can be costly. There's a lot of blood, sweat, and tears involved in this process as well. So, what we aim for is to do this as smoothly, as possible, and sometimes those journeys can can be a long period of time as well for your your business. So, I just wanted to bring to your attention some patterns, that we might, utilize to try and make that journey a bit easier from kind of legacy to something a bit more modern that's gonna last, you know, another good decade or so or maybe even radically change the way you, approach your whole, system or products. So we have, like, a a wrapper, the adapter pattern that we can do. It's really great for, like, monolithic framework. Say you've got, like, an old code igniter, or Ruby project, and it's just hanging on for dear life. We can kind of wrap that in, say, inside of, say, Laravel, for example, which is a really modern, big community framework in, say, PHP. And we could always fall back to your old legacy routes, but any new code that you're developing, you can put right in the nice routing section, and, that's a really great pattern. It means you're running the the legacy system plus the new one at the same time, but they're in the same repository, and you're getting all the benefits of a a modern framework that you can kinda roll into your legacy, platform. There is a difference too between, like, the our other pattern that's quite common with, with modernization projects, which is like the strangle of fig tree pattern. So here, what we're doing is kind of deprecating all the functions inside. We're not letting them they'll coexist for a period of time, but, really, we wanna kinda get rid of that legacy platform. So, it'll wrap around it, and you might do one function at a time, and that's a really great way to manage your, developer sprints. So you I imagine most people work in sort of two week blocks. It's a really great way to kind of do bits and pieces, so it's not one giant project and one, big lift. You can do it over time. It's less stress for your devs, which is, like, really critical, and I hope you get that out of today. So I'm just gonna open up another poll as well, and I'd love to get your feedback on this one too. And, of course, yeah, we've got a big bang rewrite. Greenfield, it's it's great. Every developer loves this. Starting fresh, blank slate, clean canvas, and, and and rebuild the app, whether it's mobile app or web platform, maybe, some binary or command line tooling. We love doing it. Obviously, it's a big risk, and we'll have a look at why that can be the case as well now. So, like I hinted at, it's really, really important to think about, your developers and and the teams that they work in and their project managers, product owners, even the designers. So, some of the things I just like to bring to attention and into your mind, there's a lot more, but these ones are kind of pretty important to me as, like, a developer leader or sometimes in my CTO, roles. So, like, trying to understand what skill set you already have. What skills do we have in house? What skills do we need to bring in, to actually make these, like, modernization projects successful and really stress free and easy or as easy as they can be. The other the other point as well is, like, communication and your processes. If you, don't really have, say, strict processes or formal processes already established in the business, this whole project is gonna be way harder than it needs to be. So this is a perfect example of, like, introducing maybe, the two week sprint cycle, which is probably, like, the best part of the and the whole agile thing is, like, let's just work in chunks of time. That's really easy to for devs to understand. Introducing, like, PR reviews and having more than one set of eyes on code, you might not be doing that now. You might not even be testing now, and, you know, we can all be guilty of that. So that's really interesting. The other thing given that we're in, 2025 going into 2026 is what is your actual, usage of AI and and the tooling between your developers? You know, I've list listed a couple here like, Codex, Claude Code. Your team might also use Cursor or Windsurf as their, like, IDA. So that's really important as well of, like, trying to understand what toolings they use right now and what that gap between, you know, what 2026 could look like for AI tools. Because there is, there is a strong case there where it can really speed up your team. And given that their context windows are getting so big now, such as, like, Claude Code and Opus or even Sonnet, you know, there's a lot that it can remember and understand about your project, especially with their core dot m d files. So, that's gonna be really important as well to, maybe leverage these tools to actually migrate from an old legacy system into, the new platform. So as we go, I'll keep asking polls as well. It'll be really interesting to, understand what you guys are all working with. So I've just opened up another poll as well. I'm interested to know. So while you are answering some of those questions of that poll, I just wanna leave this little statement here. You might have seen it, maybe worded in other ways or whatnot, but Conway's Law states that any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. I've seen this firsthand multiple times. If teams don't communicate well, then neither will the microservices you think you need. It'll also be a case of, like, how they communicate, whether it's structured, well communicated, timely. That all trickles back down into code, and and I've seen it. So, it's something to keep in mind. It might be something you're not familiar with, but if you take a 50,000 foot view, and just have a look at how your development teams and maybe the product teams talking to developers actually communicate whether it's on Slack teams, emails, PR reviews. Going through a modernization project, especially if you want to adopt microservices, how they communicate will probably be reflected in that, in code. So whether that's good or bad or indifferent, that's the dealer's choice. So, while we're just doing some of these soft topics as well, it's interesting to kinda think about the things that you might not be thinking about or definitely the developers, we we tend not to think about. We just wanna get in and build stuff. Like, that's what we're really great at. So, I just want to leave this sort of, quote here as well. Slow is smooth, smooth is fast. Sometimes it is really important to to go back a year, and really understand what we have. So just a few more things to keep in mind when you're, starting your journey, on a legacy project to modernize it is, like, what happens to all that business knowledge? Inside of the spaghetti code, that you're dying to refactor, and I am too, there's years of internal business knowledge. There's support tickets of I fix this for this customer and then patch that for this. That affects that. What happens to all that knowledge? So that's really important because there's a lot of years involved, sometimes a decade or more worth of those support tickets and incremental changes to certain functions. And when you go to refactor it, you may miss those edge cases. So that's something really important to keep in mind. Another one that, comes up as well is whether you are prepared to do, like, a big bang switch. So, okay, we're gonna put the site in maintenance mode. Couple hours later, alright, we're back. Here's our new look and feel and and, platform. So, that that is definitely one approach. It's risky, and sometimes it, it can pay off. But we have really great, tools and methods now to potentially not need to do a giant big bang change. We can do a more, softer rollout and slow, and we can introduce new features or parts of the platform incrementally, which is sometimes better for the other people that surround your business, like customer service as well, because when things are new, customers don't know where buttons are, and they're gonna get swamped. So if we can do this incrementally, it's always a good takeaway. And another another thing, just food for thought here is, like, what are you gaining from turning the spaghetti code into potentially, you know, nice refactored functions and classes and, you know, really scalable code? What is the net benefit of this? If there are no, like, strong if you have no strong convictions on this, maybe it's not worth modernizing an old legacy platform just yet. It might not be the time for you. So it's really important to know why you're doing it. Like, it is a lot of blood, sweat, and tears if you haven't done this before. And if you have, you'll know exactly what I'm talking about. So keep that in mind. Now we'll close off this poll. A few of you have voted, so that's really interesting looking at your, your answers there. What I will say as well is, like, whenever we do a clean slate project, like, this is our time to shine, right, as developers or, project managers. We wanna do best practice out of the gate. You know? That's a perfect world, and and we don't live in a perfect world. But we do have, a lot of, books and education, as well as war stories to kinda back up some of these best approaches. Right? So I just wanted to, touch on a couple here that I think are really important. If your current platform isn't actually incorporating some of these tools and techniques, now might be the time to try and upscale a little bit and and improve your team's, like, total skills and abilities. So the first one would be, like, take a look again at the 12 factor apps website and also the solid principles. Just like let's get back to basics in terms of software development. A lot of the time, these are like support ticket requests, and we're just changing things because something else is on fire and we need to make the customer happy right now. And so some of those, like, really great patterns fall to the side, and, and it works for the customer for now. But when the next developer comes around to tweak that code and, you know, say a month's time, there's no comments and there's no patterns. There's no classes. It's just, say, a dirty function doing its thing. So, really interesting to think about, like, the 12 fact factor apps. Look, honestly, and I want this as a two way communication, so definitely leave your, questions in the chat as well. But I don't subscribe to every part of it, and I don't think, there's ever one way to do anything. So, I I think sometimes it's okay to have a monolithic database, and sometimes it's great to kinda split off the database, and attach to a service. There is no right and wrong. Right? It always depends. But that's just, you know, something to think about there. It's a really good reread if you haven't, gone to the 12 factor apps for a little while, and, you'll get a lot out of it. The other thing is, like, we touched on before, code reviews. How you guys are going about code reviews really makes a big difference. Right now, we can let Claude Code go and do a PR for us. So there's another set of, say, digital eyes, to give us an idea of, like, the quality of our code, what sort of coverage it has in terms of testing, any security vulnerabilities. And that might be stuff separate to, say, another developer on your team just reviewing your code and given the old looks good to me, I think it's really important to try and have some positive, feedback loops as well in every PR. Personally, I leave something positive on every PR. No matter how simple it is or how complex, even if it's bad, I try and find something positive in it, to kinda make that developer still feel engaged and happy, and then we do that feedback loop to get it perfect. Testing, I'll leave my little points there on the slide. I'm definitely not your mother. You know if you're testing, and if you're not, maybe during this modernization, process, you can start doing testing. There is some really tangible benefits. We know this. But for me, personally, just my little takeaway is, like, I can kinda sleep at 3AM. I know I'm not getting pager duty or Slack notifications, on the code that I've written test for. And when stuff does come in and there are bugs, we're never perfect, I try and write the test to, prove that, yep, it's a real bug. Okay. Great. Now update the code, fix it. We go through that deployment cycle. It's pushed up, and now I know that bug also has a test as well. There's no point with your team kind of fixing stuff, especially once you go live with a new system and not actually writing tests to cover those those, bugs that have come up that have, you know, missed during QA. Finally, another really good, tool that you've got in your toolbox to use are feature flags. And it might not be something you've used yet given you're probably, you know, on a legacy system or have have some older sort of frameworks or whatnot. But introducing feature flags is one of those tools we have to do that slow rollout. So you might just incrementally, roll out, like, a new look or feel inside your dashboard or a specific page on, maybe your mobile app or even on your front end marketing website. And then you can do AB testing. You can kind of roll back if you need. You can also, like, just tag particular, like, cohorts or segments of of users as well and say, hey. You're in the alpha group. You're in the beta group. You're in, you know, production, and kind of roll this stuff out really incrementally. If you haven't used feature flags, lots of ways to to do it. I know post hog is a really good way of doing it. We'll talk a little bit how we can use Cloudflare as well with KV to do it. You know, even, like, platforms like Laravel have a, you know, first party package called, tenant that allows you to, store your feature flags. So keep that one really handy. It it can really help this whole migration process. So with those routing, what we can do, we can utilize, like, the Cloudflare load balancer, use a lot of them. They're great. Even if your virtual machines aren't with Cloudflare on their containers, you know, there's some boxes spread around the world or even in one data center, the load balancer is a really cost effective tool, to actually distribute your traffic to, where it needs to go around the world. If you haven't utilized, the load balancer yet, check it out in the, CloudFlare dashboard. I've used heaps of them. They're really great. Otherwise, like we talked about, the wrapper or sort of catchall, pattern is really cool here. If you've got the new route, let's go to that. Brand new function, controllers, service classes, whatever we need. If we don't have it, fall back to the old legacy, you know, route, maybe API v one this time, and do whatever it needs to do and return back. So wrapping your legacy system with a modern platform like Ruby on Rails or whatever, Laravel is, a really cool technique. That's one way to do it. The other way to do it as well is that we cannot actually just go straight from a DNS level, and just start pointing, different routes to new services as well and kind of intercept those, using Cloudflare workers. That's a really great technique as well. So a few options for you. And, of course, you know, it always depends. So, talk to your team about what kinda makes sense to, introducing the new platform or features in your network stack. For growing this stuff, look, there's heaps of scalable solutions. Today, we'll talk about, like, Cloudflare, because I think it's a a, it's really easy to work with, and, b, it's really cost effective. So, you know, that's two of the big drivers for myself of learning this system and platform. So, you know, we're we can cover some of, some of the tools there that help with architecture enhancements, you know, more importantly, your customer's experience. Like, really think about that, and that's, like, so critical. You wouldn't even be in this position if you didn't have the customers. So putting them really first and foremost, and and they might not be right now, can really help, shape the way your products are developed. And then also, like, by using some of these, tools and services on Cloudflare, we get really good visibility and logging. Right? So not only do we get, like, a huge amount of, access and growth around the world, there's, like, a 125 countries now, 330 pops of points of presence. So, the servers are always really close to, your users now, so we should leverage that. Like, we don't need to put everything in AP Southeast two anymore. Like, we can be a bit smarter now and not cost a fortune to do it. So let's have a look inside some of the tools that we have access to. And then I'm just gonna kick off as well another poll, to understand what you guys, are really interested in. I'm just gonna find that one. Bear with me. Yeah. There we go. So, what we'll cover today, just some of the the tools I've used personally. You might have used other ones as well on Cloudflare, but, I think I've pretty much played with everything now, or for the most part. And, I have some, like, opinions and, war stories about it all, so I thought we'd get into that today. And as always, just if you have any questions, feel free to, to answer those as well. It'll be really interesting to see what you guys are interested in. So, yeah, today, we'll just cover, like, compute workers, durable objects, containers. I know containers are always really popular. Databases like d one, their SQLite database is is awesome if you haven't tried it, as well as, like, hyperdrive as well, which you might not know about. We'll look at some core staples like object storage, even workflows. And then, today, we'll just wrap up with some AI models as well and, give you some ideas of, like, how you might introduce AI into your platform as you're doing this modernization. Because sometimes it's hard to think, like, what do we do with this dashboard, or what could we do with this dashboard? So I'd love love to explore some of that. Are there any questions so far? Does anyone actually put some QA in? I'll just have a quick drink. Any feature flag providers. Yeah. So I think post hoc is really great for feature flags because it works on front end, back end language, almost agnostic now. I think that's really great. There is probably no reason you couldn't actually build it yourself in Cloudplay, which could be a really cool, like, hackathon or team building exercise as well. Your devs could probably build a pretty robust feature flag in a system in a day or two, using KV and some workers, potentially even a durable object as well. Few ways to skin that cat. Okay. So Cloudflare workers, basically, the gateway drag into the whole, Cloudflare developer ecosystem. Almost everything kinda goes through a worker if it doesn't have a HTTP API. So I think they're great. I've built, like, probably a 100 of these in different shapes and forms and what have you now. And some have been kind of, stand alone, like, kind of mini monoliths. Some have been absolute microservices doing RPC calls, internally and not over the network, and there's been a mixture, in between that. So I think they're really great. You can do them, like I said, as just stand alone. It does one thing really well. That's its job. You might be used to that on, say, AWS's Lambda, or other sort of fast, function providers, but, workers can just do one thing. I kinda feel like maybe you're leaving a bit bit of stuff on the table if it only does one thing. The domain based microservice, so one entity, like, maybe this mini monolith worker does everything to do about users or everything to do about companies or whatever domains are within your business. I find that works really well. And then you might also do just utilize them as that that gateway. So the orchestrator into talking to containers or sandboxes, AI models, databases can kinda be that first port of call, and then you go and do some other stuff and it comes back. So, most of the services here, how we access is, just through bindings, which is great because we don't have to think about environment variables as much. We still have secrets, and we still can add in our own custom environment variables. But the fact that I don't have to put in my database password now to d one, it just knows how to connect to it securely is, is something that, I don't think people really, appreciate it as much as I do. So just with workers as well, like I said, they're very close to users. Typically get, like, a less than fifty millisecond response time. I know I do. I'm on the Gold Coast in Australia and, in Queensland, Australia, I should say, and it's hitting the Brisbane pop, and it's always less than fifty milliseconds of for JSON responses. So that's kind of really great. It means I can build, really useful API services, that are super cheap, and I don't have to think about them now as well in terms of DevOps. Like, once it's deployed, if there is issues in in Brisbane, just falls back to the next pot and cascades that way. So that's taken a huge a cost out of the businesses that I work with, by not having so much, DevOps involved. And, also, it kinda helps all the developers kind of uplift and and really own that piece of software that they're they're developing. So Hano JS, you'll see in the slide here, I think Hano JS is one of the nicest frameworks I've seen. If you've ever used, Express, on a Node, JS sort of server, you'll be right at home. It'll feel very familiar. Works great, really easy to write, you know, secure APIs. All the middleware kind of exists with Conner. It's really good. The other thing workers can do is cron jobs. Right? So we can schedule a whole bunch of stuff as well to run, you know, basically, minutely up into whatever combination of times or recurring times you need, daily, hourly, whatever it might be, once a month. So that's a really great way to just put some stand alone, functionality into one one little deploy, deployed worker and send it away, and you know it's gonna be really reliable. So it's really great. Again, you can deploy all of the all of this straight from your command line. So the power is in your developer's hands. You get environments as well, so you can call the environments whatever you need, but, obviously, we get production out of the box. You can make a staging, a pre prod. You can do, anything, developer environments, previews. So I think that's really great. And compared to, like, some of the bigger frameworks or something say a Laravel or Ruby on Rails where you've gotta kinda deploy this big chunky thing and have engine x running and all that, or PHP server, you can just kinda get this going really rapidly. And that's not to be taken, lightly. I think that's really powerful. What would you say? So I'm just having a look at a quick question. Compliance and data privacy. What would you say is the most important safeguard of government framework? Oh, man. If you've listened to any podcast in the last year, wouldn't I say Vanta? I I don't know. AI capabilities within workers. Look. We'll talk about AI a bit later in this talk. I'll circle back to that. I'll have a thing for you. Just while we're in workers as well, this gives you a quick idea of, like, some of the things workers can actually talk to. So, like, k v d one, r two, all these great acronym names, but they all have really good, functionality, and they they have all the tools you need now on Cloudflare's edge network. It's actually built, like, full stack or microservice, like, large scale systems. Now contain containers and vectorize exist. R two has even SQL in it. So, like, there is almost no real reason now to go down, say, even the Kubernetes route and have all this management of time and effort, and stress in that way. You could kinda just do it straight in workers now. And when I like the little, tidbits you might not know about workers is, like, when they're deployed, you can do, remote procedure calls to another worker, and they don't hop over the network. So, you can kind of deploy a bunch of these workers that are never public. They don't have, like, an endpoint URL, but other public workers, like, maybe, at the, the top of your API stack could actually call in and get the data they need, amalgamate it, and send it back. So it's really cool that you can do this now, and you don't have all that heavy lifting of, like, say, managing Kubernetes, which is stressful. I've done it a lot, and, I I imagine a lot of the people on this on this stream have done it too. So I kinda know what I'm talking about there. So, a lot of you are interested, around containers and a holiday. So, I can give you a boat. It's probably not the boat you wanna go on a holiday on, but I can also tell you about containers. So they're relatively new. I have been waiting for them for a while, and that kinda popped up, proper beta in about June this year. And, you know, there are new features being added to it every day. It does say beta, you know, take that, with a grain of salt. Most things on Cloudflare say beta, and you can kinda use them in production, and it's fine. You know, there's a lot of fallbacks in place, as you can see with the whole platform. But given that your legacy system might be in a virtual machine or it might be on a on prem server, if you can get it into a Docker container, if you can run it locally in Docker desktop, say, on your Mac or Windows or Linux machine, then you can get it up into Cloudflare as long as it's under sort of they do have a caveat of about two gigabyte, image size. But, like, that's pretty easy to kinda squish things down into that now. You can deploy this now and and start moving your existing legacy system up into the CloudFlare ecosystem. So that's kinda cool now that you can attach and, like, work as an orbit around that container and start taking off some of the load from that old legacy system and doing things really fast just in a worker. That's really cool to think about. All containers basically access through a worker anyway, so you do get the opportunity to do some pre and post sort of manipulation of the the response that's going in and out of that container too. So that's something, that maybe not many people are aware of, but that's, like, a really good opportunity as well to, kinda maybe manipulate the output of the legacy system and transform it into the shape that your teams, kind of wants it to look like now. So that's a really cool pattern as well-to-do. And then like I said, yeah, if you've used Docker containers before, you'll be right at home. You can deploy straight from Wrangler CLI, so straight off your computer. And then you can also, do this straight in CICD as well out of, say, a GitHub pipe like, actions pipeline. It's really cool. So the containers, there is some auto scaling. We can scale them down to zero, which is really, unique. So we're not always paying for it. You'll get a cold start, but if it doesn't take too long for that container to kind of get into gear and running, that could potentially save you a lot of money if your platform doesn't actually run twenty four seven. If half the world doesn't access it and they're asleep, maybe it is worth bringing it down to zero. And then that first user that hits it wakes it up, yeah, their experience is a little bit slower. But then the rest, it's awake now and off you go. They also have some, latency aware routing coming. It's in their in their documentation. I definitely recommend checking that out. But that's coming, so that will allow your legacy application to kinda load closer to your users, which might not be something you're able to achieve now based on your current infrastructure. More than likely, if you've got a legacy system, you're probably not able to do that now. So, whether you use a CloudFlare load balancer or move into CloudFlare, like, containers, like, I've had great success with these so far. They've also got, they've grown their size of containers too. So we have, like, a light plan right up to, like, now standard four, and I'm sure these are just gonna keep growing over time. When this first came out, I think it was only four. Now there's six. So, it's growing pretty quick. And I think they're just getting your feedback. So, really try and, understand, you know, that this is a growing platform. It will be, it'll be really interesting to see what this looks like over the next couple of years, but what a great way to, start modernizing a legacy system is, like, just move it in the cloud, start adding orbit, orbital, sort of workers around it. So there's another system as well, an SDK that's out called Sandboxes. So you might not know about these yet. They're a wrapper around containers and, basically, let you do, like, short lived compute. You can run some code you're not really sure of in a container where it's isolated and sandboxed out and safe. And this is really great for, like, AI responses. Right? If you're not really sure what it's gonna do, you can run it in a sandbox on Cloudflare. It'll spin up, do its thing, and then kind of just end shutdown. So you don't have to think about turning off that container. Now it's like, it will die, and you can change that period of time. You can make it live forever too. That's, an option in their SDK. But I think this is really cool, and it changes the way you think about doing things. So developer previous is one that I'm, like, currently using Sandbox SDK for, where I can just utilize, like, the Git functions that are built into this lightweight container, pull in a, you know, a private repository with the secret key, build it up, let it run, do all the apt install stuff that you normally do, say, in Ubuntu, run it all, and then check if I got the right output. And if I did, sweet. It just dies off. Send the response back to to the GitHub PR. Like, this is a really cool and interesting, system that I haven't had much access to in past, so, I'm kinda loving it. I I've found bugs myself in the SDK, and other people have too. But, like, reporting, I mean, GitHub seems to get, pretty fast resolutions to it too. So, I definitely recommend testing our sandboxes, this week or over the next sprint and, see what you think. It's really interesting. A lot of use cases for it. Lots to do with that. Just ask another poll as well. So, I would love to know if everyone could, kinda put in their vote here. Where do you currently deploy? Sorry. I've gone back a few here. No. No. Sorry, guys. So while, while you're answering that that question, I'll just bring up the topic of durable objects. So, it's a complex topic sometimes. I don't think a lot of people really understand, what they can be used for and why they exist. But, hopefully, I can help just kinda bridge that gap, quickly for you. So, it's basically individual compute, and then we access it by some sort of unique identifier. Could be like, a UUID, could be an ID. You might have some other repository of information like a database with those IDs, and then you can self contain everything that you want about that, entity in one place. So it kind of really changes the way you think about how you develop, like, platforms and products and grow them. They definitely provide long living state, so you can do single light, inside of a durable object. And so that durable object can go to sleep. You might hit it a week later. It comes back. All your data is still there, safe and sound, which is really interesting. So anything to do with that entity can just live in one place, which really just changes the way you think about, like, say, the monolithic databases. And now, hey. If you've got a 100,000 customers, yeah, they all have settings and social media accounts and files and addresses, all that stuff, that can live stand alone for that. Also, really, smooths out, like, the attack vector as well. Like, instead of going to one place now, you would have to go to hundreds of thousands, millions, of sort of mini databases. Right? So that's a really interesting thought pattern of why. Now it's really complex, and now logging would flag it much, much earlier than if they only have to go to one single place to dump your database. Right? So we'll just try and think security first, where we can. So I'll give you some, ideas and examples of durable objects to get your mind, thinking about this. So, yeah, real time WebSockets. Look. That's like the common sort of, you know, example. You can have, like, a say, a chat room or look. I've used this in in, live sports betting before as well. So, anywhere where a a number of people have to, all look at the same data and have that data be as up to date as possible, this is a really great way to, store that data. But, like, in a, say, a a whiteboard or a chat, you might have, like, concert tickets, something like that. So you might do a durable object for every, event. You know, there's a gig in Brisbane, there's a gig in Sydney, gig in Melbourne. That could be three separate durable objects, and they're storing people, you know, purchasing tickets within just Brisbane or just Sydney, for example. The centralized entities sort of, concept is really interesting. I've explored it quite a bit, and I think it really changes the way platforms can be architected. It's like multitenant platform, but also, rather than just based on a single customer, it's kind of based around, like, the business domain itself, like, whether I've got examples here of, like, your users, maybe your projects. Each project could potentially be a durable object. And the beauty of these, right, is that they're deployed as close to the user that's requesting access to the first. So, there's no point if you've got customers over in Sydney, that, like, they might, on your legacy platform, be hitting your, like, Oregon, E C 2 box. But now they could spin up, everything to do with their company in a dashboard that they access daily Close to Sydney, it would be in Sydney or the Brisbane or Melbourne pop. So, I think that's really cool way to, think about application development. Finally, you know, if you're doing agents or containers, they actually, like, have durable objects behind it. So if you access those, you're kinda using a durable object behind the scenes whether you know it or not. I'll give you some examples here. So this is like that many entities. So you might have a virtual machine, monolithic database, a single company's table, and they might have some, like, left joined on tables as well, like addresses, projects, stuff like that, just a foreign key reference. But all your companies now live in one place. And to just flip that into, say, a durable object context, you might have a a company service durable object, maybe it's just called company, whatever, company DO, and you can utilize its internal SQLite database. So now that company table just has one record, and it's the company that we've accessed the durable object with, say its ID, and anything that belongs to that company is in one place. So now you can just extend it with some, some nice RPC functions, APIs, essentially, that you can open up, from a worker, hit it, and return that data. But it's nice that it's all in one place and it's driven by a single entity. Feel free to ask questions as well about this stuff. It is complex. Like, I I personally haven't seen very well, like, described examples of Dios or or how how else you can use them outside of, like, a chat. Like, you know, there are already chat systems. We don't need more chat. Like, we wanna do stuff that's radically new. So, inside a durable object, I've just done a quick example here for everyone to take a quick look at. Yeah. It's really easy to just spin up their SQLite storage. You can you can see it. There's context dot storage, squeal. And then we just kind of, like, build out the tables that we need. Here, I'm inserting some data, but you don't need to do that. You could do that through a a function, like, say, a post request in a in a worker and insert it in and away we go. And then, like, another little tidbit in in this is, like, you'll notice in that info function, I don't even do an await. So because the SQLite is attached to the durable object, we don't need to do the whole async await thing. It it's like got access to that SQLite directly. So, that sort of zero latency thing is really cool. There's no network request to that database. It's like, it's right next to the compute. So just some other examples that you might kinda utilize DOs for, like, we talked about earlier today. You can build a feature flag system with one really, really simply. It's unique identifier would be like maybe the website that you're, deploying. It might be a particular flag ID or whatever. You might even just reference it by flag name. Maybe you just, like, slugify the flag name with dashes or something like that. And, that's a really cool, project that you could could utilize DDoS for. Queue notifications is one I've I've used before where, like, a worker might do something in a cron job or send some stuff into a queue. Once it's done its processing, kind of go and hit a durable object, and it can go and, send notifications out to anyone who's kinda connected to the dashboard or platform that that DAO is connected to. So, I've done that for notifications. And when the person isn't connected, because we have that SQLite, that that state, right, in the DO, if they don't get the message, we can just still store it. And so the next time they log in, now we have a nice notification. We can just do a quick poll. We'll go, give me any messages, or notifications that I haven't read yet. Awesome. Right? So, you can just build that straight in, and no one ever misses a WebSocket because that's something no one thinks about. Like, if they're not online to get the WebSocket, they don't get the WebSocket. So this solves that. And another thing that you can maybe do is, like, maybe some individualized recommendations. You could have a deal kind of built around every entity of users in your system, and all the information about that user is in one place that you can bring up by their UUID or their integer ID, whatever it might be, their email address or phone number. I think that's kinda cool and and, actually, maybe stream over WebSockets, real time updates or recommendations while they're, say, shopping through your online store. I haven't really seen much of that, to be honest, and I think that's really cool. Something we could, I would love to see more of, like, AI recommendations that's really tailored to, say, my account. Any other questions so far? Might open another poll as well, if everyone can kinda leave their answers. Also, take note to Cloudflare. I've, kindly put on some, docs. You'll see in your, chat window, there's two sort of, PDF documents to take a look at as well. They're really great. Kinda give you some insights into sort of modernizing applications as well. Quick read, really easy to grok, and, and then you can always reach out to your CloudFlare reps as well, if you got more questions too. Alright. So I know we're low on time at the moment. I'm just trying to run through a couple of quick things, and then we can get to QA if that's alright with everybody. So, d one databases, it's all SQLite managed. They have point in time recovery, really cheap, like, exceptionally cheap. Can, you can kinda hint at where you want them to be deployed and what region as well. And now, Cloudflare also offer global read replicas in beta as always, but just start using it. Sweet. So, yeah, I put that tip in there, the multi, multi tenant application you've been putting off for so long. Yeah. It's hard to spin up lots of databases. Right? Like, we know RDS is not a cheap exercise, and it's a big scaling beast, all that stuff. So, yeah, the fact that you can kinda spin up a d one really quickly, access it whether, like, locally or through direct bindings in workers and workflows and stuff. Yeah. Really cool. And it does help, like, promote that 12 factor app process of, like, here's a microservice and here's its database. Any information that, it needs is in one place, and it's all together, and you can just kind of access it from one spot. So check out d one if you haven't. Hyperdrive might be the secret to your legacy to, modernization sort of, migration flow as well. So hyperdrive lets you connect to your existing managed database, wherever that might be, on prem, in the cloud, somewhere. It'll do it securely, and it allows your workers now to go and call that same, say, Postgres, SuperBase, MySQL, sort of database. Right? And so that can be one way where you still got your original source of truth of data, but now worker can access it and do whatever it needs to do. Maybe that worker becomes the start of your API v two. So I think that's really interesting. It's a great tool. It's worked really well for me in the past. I've used it quite a lot. I like that you can actually set a period of vacation. So before I'd kinda wrap maybe a single call, in, like, some sort of Redis, as well. So you get faster response times back for users, but, CloudFlare can actually, let you choose how long you wanna cache select queries for. And, like, I think the default's sixty seconds. That's, you know, fine. But you can change it to zero or, a little bit longer, maybe five minutes as well if your data is not changing often, but they'll cache it closer to your users too. So if user requests, you know, some data from a worker and it knows it's gotta go through hyperdrive and they're in Sydney and maybe your colleagues already accessed that same data, in Sydney as well, instead of going all the way, it'll just grab the data straight from the Sydney pop and bring it back. So I think that's really cool. It just takes so much more of the, heavy lifting of, like, caching things out of out of the mix. Cool. Art two, object storage. This might be your first, foray into switching or modernizing your legacy platform. Like, if you're storing stuff on hard drives now, it's probably not the best, way to scale. This is a really good way to scale. The fact that r two now is has an equivalent, you know, s three API, so you can you can do a quick, like, full switch over from AWS's s three onto r two and everything. It'll just keep working. Like, I've I've done this, like, number of times now, had no problems with it. The fact that they're actually still developing on it, they've got, SQL now for Apache Iceberg, in beta. But, having that is really interesting too. That's just simplifying your whole stack. Like, doing these big queries now, but in r two is something's, like, mind blowing now. And because it's so cheap as well, to store files and serve files from caches. The other, like, tidbit that I think is really interesting is, like, I don't think about CloudFront anywhere near as much anymore because the CloudFlare CDN is caching those assets near my users. So, it's another thing I don't have to worry about. Like, wherever it, that asset's coming from that r two bucket, it's gonna be close to the user as, those users in that area keep hitting it. So this might be a way you could definitely just change over from s three to r two, in a couple of days. They have a tool called Big Slurp that'll copy all your existing s three data. Kinda put it over to r two four, which is really handy from the Cloudflare team. So that might be your way into starting on that Cloudflare network. So due to time, I would rather look. We can keep going. We're right near the end end, actually. Let's just wrap it up. I think this would be great, and then we can do some q and a, with, our Cloudflare rep, John Sik. So, just before I wrap up, there's a ton of AI models that they've got now right on the edge, run out of all their pops. So I I've used the Leonardo AI, which are bunch of Aussies, which is really cool. I've used their models for image generation, on, education app. You can use, the OpenAI OSS, like, one twenty b model as well to get really good data. Look. I'd say if you're gonna use these edge models, and I've used a lot of them now, the most important thing is your system prompt. Like, if you have a really strong, strict, to the point system prompt, these LLMs on the edge really behave really well. So, it might be something to while you're modernizing your platform, it's actually enhance it with some AI. How to do that? Look. Anyways, just skin a cat, but, I think, like, using, content driven stuff, maybe, like, sentiment analysis, like, all that will really add to your customer's user experience. So, as I wrap up, yeah, before you make a tremendous mistake, meet with your devs and your products team to actually talk about your current pain points, and issues with your your legacy system and and what it might look like, once it's fully upgraded and and what that world view looks like. The last thing you wanna do is tear down a bridge. There's a fun story about that, and there's a nice AI image for it too. As I mentioned, totally many ways to skin a cat, and how we go about this looks different for every business. But, yeah, I think the most important thing is starting these conversations and, and and talking to your your team about how you might go about it. And like I said, you might just do s three to r two. That might start your journey. Your team might just spin up a single microservice using a worker that just takes a lot of the heavy lifting from maybe one or two or three, like, high traffic endpoints and puts it to the edge closer to the user. And now you might not have those traffic spikes, and you might be able to actually decrease some of your infrastructure costs too. So, yeah, reach out if you need. I really appreciate you taking your time out of your day to listen to me. I hope, you've got something out of it, from there. And, yeah, happy to just bash some ideas around as well. So, yeah, I'll, let John, join, our conversation, and, yeah, feel free to ask any questions. So we've got a Cloudflare rep, and then also I'm happy to just give you, my anecdotal evidence or or, experience. And thank you as well. So we got some QA. Regardless of use cases per d one, d o, sports, you know, thinking of making d o the first choice instead of d one. Any quick thoughts on what we'll miss out with this approach? Yeah. John, do you wanna just reanswer that, Yeah. Trouble object is a single dragon object. It runs on one pop only. Like, you can make as much as possible. Like, it has an unlimited number of objects you can create, but each object is running in single thread. So if you have a too much concurrent connection to a single object, it will fail because it has a certain limitation that it can only run. And that is the basically difference between d u and d u. And. on the other hand, d one can have a read replica all over the globe. So if it's just a read replica, you can just have it as much as possible. Yeah. Just kind of unlimited. Yep. I saw there was also well, actually, just for that one too, I'd also, maybe suggest depending on your data, if it is public data, you might be able to just put it into and it doesn't change often, put it in KV. Right? And now it's gonna be cached everywhere, really close to your users. That's really affordable as well. Mhmm. So I think, like, not everything has to be in a database now, and we're so used to, like, just put it in a database, like, in rows and columns. That's our jam. But, actually, like, keys and values are really cool too. Right? So and modern CPUs are so fast at, like, decoding, and encoding JSON. Keep KB up your sleeve. Might be, an interesting one too. I saw another question there for long running tasks, like fifteen minutes plus. What would be suitable between workers versus containers? So do you wanna just reiterate on that one, John and Sue? It really depends on the task. If the task itself is actually waiting on a request from external API, meaning, Walker does not consume any CPU, it's just waiting for the in, the request, then it's okay to run walkers because that will be out of your CPU cycle. But. if you actually have to process something, do something on the memory, Walker has a 120 megabytes of a memory limit, as well as a CPU time can be only run-in a ten minutes. So so that is the limitation it has. So if it's longer than fifteen minute, if it's running, like, for one hour, probably, you should go with the containers. Yep. Yep. I think that's, that's a fair call. Look. And now containers are becoming, you know, production level or standard on on Cloudflare. Like, that is a game changer. Like, I was waiting and hanging out for that to come because that was the last piece of the puzzle for me. Was like, how do you run, say, a monolithic platform like, Ruby on Rails or or Laravel, with all the other cool workers stuff I have? Or you couldn't pry the containers, but now that's there. That's the entire loop done now. There isn't really anything left for me as a developer. You know, my background, you know, what I like to work on specifically is either microservices or, say, Laravel or node, sort of platforms. This, like, suits everything now. So, yeah, definitely long running stuff. Just chuck it in a container. It's fine. And then when it's done, it'll shut down too. So you're not paying for it, which is kinda cool. And it'll be close to user because it can give it the, region hints. So I think that's really interesting. Were there any other takeaways from my talk, Jonesik, that you thought, I got wrong or, you thought were, Are you totally we? need some more explaining? Yeah. You're totally right. Yep. Yep. Yep. And, Yep. well, yep. So use a deal for, like, the meet already mentioned that it has a hibernation. So, like, if you have a web socket that's running wrong running task, it's probably a good idea to use a deal. Yep. Yeah. Are there, are there any interesting durable object use cases you've seen, as a CloudFlare insider, like, from other some of your customers, where you're like, oh, that's actually really cool. I never thought about that. What are some of the, like, interesting ones that you've come across? Well, I it's like the typical users. Like, I saw them some of the, like, Bitcoin handling company that's actually doing some of the, like, cryptocurrency using long running task using the web service. And I also saw some people actually use it as a distributed database. I mean, just, like, each user got each DO, and each DO has a, like, a database itself, but they are using distributed database using the DEO instead of using actual DB. But it has a limitation, like, global search won't work or stuff like that, but it it can fit in your cases. Yeah. I think that's kinda cool. That definitely is something for people to be aware of is, like, wherever it gets requested from, it's gonna kind of spin up closest to that first request app. So, you might you might have a really good experience, but maybe maybe you're doing, like, some sort of, like, collaborative whiteboard app or maybe you're all just dropping, like, maybe collaborative tags in, like, a a sprint, you know, wrap up or something every two weeks. Your guys overseas are probably gonna have more latency and, slightly less as good experience because it might be spun up in Sydney or Brisbane for me, and it feels really snappy, sub fifty milliseconds, but the latency might be, you know, hundred to three hundred milliseconds for them. So it's just something to keep in mind. There's also quite I didn't cover it in this talk too, but while you're modernizing, you know, an old legacy platform, people are really used to, like, video and audio now. So, that might be something as well to kinda introduce into your platform is, like, maybe you interact with your dashboard through voice. Maybe you, instead of using, say, an external video provider like Zoom or Google Meet, maybe you just use, the web, real time kit that Cloudflare provides and just put it straight into your dashboard. So maybe your customers can just talk to customer service straight on the platform that having to go somewhere else or something like that. Like, I I really haven't seen too much of that in the wild now, like, from a customer support perspective or anything radically cool like that. Even just, like, talking to your dashboard now and letting an l l like, between an LLM behind the scenes and asking for, like, data through, say, behind the scenes SQL queries, that's really cool. Right? That's what we've always wanted. Like, that's the cool use of AI, not just, you know, making, Ghibli studio images or or some of the images I've made, you know, for today's slides. So, maybe have a think about some of that stuff because that's kinda interesting. And I also showed the one, GitHub on our chat. We do have a a doom markers that's using durable object, but you can try that out too. Is that a, fun video. game? Yeah. Doing the video again You can run of our markers and durable. Yeah. That's unreal. That's really great. That's a really good share. I don't think many people would have seen that, but you can run Zoom on everything, even durable workers. Yep. Very cool. Alright. Well, there is there much more? I don't think anyone else there's still just a poll open. It'd be interesting to to see what, everyone's, like, predominant languages are. But, yeah, if there's no other questions, we can we can wrap up. And, yeah, if you wanna, follow-up or anything like that, feel free. Or if you want access to the slides or whatever, yeah, we can definitely add that. I can find a link for you as well and share that with you. And, again, thanks for having me as well. This is, it's my, third talk with Cloudflare. And, yeah, I really enjoy the platform. It just takes so much stress away. That's why I like it. I've tried all the others, so I wouldn't be talking, so highly of their platform unless it was actually good. So hope you guys can get something out of it too. Yeah. Thanks, guys. Have a good afternoon. Again, really appreciate your time. Gotcha. Thank you.