Greg Irwin  0:18  

We run. And we've been very fortunate to be running a series here with EnterpriseDB. These guys are enterprise class supported Postgres, which is one of the standard database structures, one of the most broadly used database structures on the planet. And they're really at the forefront of where people are going with data data architectures, and the analytics and production systems that you can run on top of that. So very happy to be here with Gunjan Goel, and Julian Moffett. And we're going to be talking really about the future of data architectures. And it's predicated on open source databases, and what these guys are doing to harden those systems. So but before I get into it, I'm gonna introduce your Gunjan and Julian here in a moment, let me first give a little overview on the format, because I'm sure you all are, you know, you have been joining zooms and webinars, plenty for the last couple of years, we've been doing this about 10 years. And the the format we run is interactive. That's the whole idea. The whole idea is people learn when you talk people learn when you ask questions, and you get a little messy with, you know, questions that in areas you don't fully understand. And it's more fun and more interesting that way. So what we're going to do is go around the group and really ask everybody, what they're doing around their their systems when they do and around their data. And hopefully, everyone can learn kind of, from actual practitioners, what other companies are doing. So not to learn directly from BWG, or EnterpriseDB, but to hear from you each other from each other. So I have one request of everybody. First, you look around the group, I'll ask you to, to venture to make new contacts across this group. So as I go, and I get others involved here, something interested, interesting, all recommend that you reach out directly or let us at BWG help connect people. So you walk away with some new relationships, people doing similar things and similar jobs in different parts of the company, different parts of the country, my goodness, surely is. Also, let's use the chat window. So this is an interactive session. Let's make sure we take advantage of that. You can ask questions on the sidebar, or you could just jump in with a you know, questions live. There's no preset presentation here. We're not here to present slide decks, where preset ideas. It's really to learn and network. And we're going to do that over the course of the hour. And my hope genuinely is that you all walk away looking at this as as as a productive session. But Gunjan and Julian are going to help me co host today. It's time for me to bring him in. Gunjan, you're overseas right now. Thank you so much for joining us. Give a personal intro and an intro in EnterpriseDB.

Gunjan Goel  3:30  

Oh, yeah. Hi, Greg. Sorry, I wasn't good. Thank you for having me here. Sorry, I apologize. So the hotel room setting and everything got you know, two deaths in the family in last two weeks. So I had a rough draft fly over to India device on you know, all over the place just there's a little bit of a thing but I couldn't miss this opportunity to socialize and understand from the practitioners here or what's happening in the real world. I am actually myself I'm a partner with a midsize consulting firm Prolifics. So I help and work with clients in the space mostly that are banks on these questions of what open source strategy means for them, what are the challenges ahead of them? How they you know which bottle another issue they're experimenting and why and why not? Things like that. So I'm happy to share what I'm seeing on the field and happy to learn and you know, build ideas on top of it. Excited for the discussion ahead. Thank you.

Greg Irwin  4:30  

No, no full sales pitch but tell us what is product, talking about the organization?

Gunjan Goel  4:35  

It's a it's a we've been in business for about 40 plus years. We are like any other Accenture in why Capgemini that things we do good there are things we do bad we take pride and I think I'm a practitioner myself in developed from PwC Accenture on the backs of those. So I get my I roll up my sleeves and get deep in that my as well. So I take pride in crisis management and how fast we respond when something goes back. I want my clients to feel that they're the person is the person who want to be in the battlefield. Well, that's, that's the intent. But we got some solid practitioners and data analytics, mainframes to, you know, open source migrations, those kind of efforts, Postgres, you know, stuff like that. We got, we got deep expertise and all of that. But I'm sure all other consulting firms do as well. That's kind of what we have.

Greg Irwin  5:29  

And tell me around data architecture, database analytics, how many projects do you have in flight right now? Is it five to 10? Is it 30? Like what's gonna give us a sense of how much activity is going on right now?

Gunjan Goel  5:46  

In my patch itself, probably about 10. But in the history, if I've had to kind of, you know, put them aggregate them together, that'd be quite a lot. As a firm, we would have done over 1000s 2000 migrations, hundreds of these projects, in all levels, from machine learning to AI to open source deep architectures to you know, plain vanilla simple ETL database. So we got a heavy mix of those practitioners. Actually, a lot of my senior guys who are deep in this are the folks that may be part of the product team that wrote a lot of this products are very open source as well. So we had those kind of, you know, heavy lifted as well. So yeah, but tonnes of projects on this.

Greg Irwin  6:37  

We're happy to have you here again, Gunjan. Thank you. I look forward to the conversation. Julian Moffett is CTO for the banking vertical, an EnterpriseDB. Julian, great to speak with you. And please give a quick intro. 

Julian Moffett  6:52  

Thanks, Greg. Yeah, no pleasure to be here. Nice to meet everyone. Look forward to the conversation. Yes, so I actually relatively recently joined EDB, just at the turn of the year. Prior to that I worked in a company called UBS, which is a kind of global wealth manager investment bank, in technology for a long, long time, longer than I care to admit. But probably 15 plus years, at least, and did a whole bunch of different roles, both from an application delivery perspective, from an infrastructure perspective in the CTO organization. And I think probably most recently, and probably most relevant for this audience, I actually did kind of three things primarily in our data space. So I set at the time, the bank's strategy on open source database usage. We, in our case, specifically, we position Postgres as the go to relational database of choice. And then, for my sins are a CIO at the time said, Yeah, that's great. Now you set the strategy now, now you're on the hook to deliver it. So I was responsible for actually building out the private cloud offering and our public cloud offering with our CSP partner. And then finally, they were like, Yeah, great. So you set the strategy, you've built the platforms, no, move everyone to the platform. So I ran the program to move us off our incumbent database onto onto the new platform. So lots of battle scars, got lots of T shirts, and lots of experience, hopefully, that's that we can share today as relevant with folks. And yeah, looking forward to the conversation.

Greg Irwin  8:19  

What was that legacy data database that you migrated from?

Julian Moffett  8:24  

The classic Oracle, of course, so that was the that was the primary one we were trying to reduce. I think, and I'm sure this may resonate with some of the folks on the call. A lot of the big Fs companies have, let's say, historically, a zoo have database vendors in their enterprise. And you're trying to do a consolidation across a number of different vendors, but oracle was the primary one that we were trying to move away from,

Greg Irwin  8:44  

were you actually so let's spend a minute because this is this is exactly what we try to get at in the session is kind of the real story of a migration or the real story of an adoption. So how did it go actually getting off of work, both in terms of maintaining the functionality and all of the custom code, I'm sure that you've built out over the years, as well as actually saving the license cost and being able to say, Great, we're off. We're no longer paying the licenses. How, how did each of those two fronts go?

Julian Moffett  9:17  

long have we got? That's a big question. Yeah, no, so So yes, exactly. So let's start with a driver. So the driver in our case was cost reduction, clearly, and I think we, everyone probably knows that Oracle can sometimes be a challenge to work with. So cost was one thing, the commercial relationship perhaps wasn't where we wanted it to be. So that was the big driver. We had a lot of initiatives that kind of helped us in that journey. So there was a few and then this may be the same for folks in the coal. We were running a whole modernization exercise, and the bank at the time was still running modernization exercises digitization exercises, and there was a big push Upload. So that was actually a big help for us because it gave us the opportunity to kind of reevaluate the existing application stack and kind of deconstruct some of the big monolithic applications or take the opportunity if we're going to touch the app stack to go to cloud in in case to go and replace the incumbent database vendor. So in some cases, we were able to profit from some of that. So the pushback was, was less frankly from from some of the application teams, because I think the default reaction is when you go to the to the application teams and say, Yeah, we want to make this infrastructure, the change that the natural reaction is going to be, well, what's the business benefit for me? I've got a list this long of business deliverables I need to do. You're telling me to change the database, which is ultimately going to give me the same thing, what was the value? So there's what I find in the migration is the technical challenge is probably 10% of the problem. It's there, it's getting the application to the database migration itself is realistically not that hard. I mean, I'm trivializing it. It's still complex. And yes, there's lots of work to be done. But logistically, it's that's more of a challenge. Just simply getting application team buying, being able to demonstrate the the business case for it. And yes, your point. So on costs, our goal was to remove costs. So I think it's important, you've got incentives for your teams, you need to have some kind of internal chargeback mechanism that makes at least the the new offering more attractive. I think what we also did was we looked for various other options in terms of can we improve the level of service we give our internal consumers? Can we improve the provisioning time? Can we improve the time to productivity for application dev teams? Can we fundamentally provide a more reliable and a more stable platform, those are big things. Obviously, when you when you kind of start with a blank page, you can learn from all the things that you've done in the past and that have that have kind of evolved over a few years and try and knock some of those out of the park straight away, which is exactly what we've tried to do with with the new platform.

Greg Irwin  12:07  

All right. So look, we've set this up around enterprise class, Postgres, and I know Postgres as open source, relational database, the idea that it's maturing into an enterprise class platform, I think we want to learn a little bit today about how far it's come. And the kinds of applications it's, it's supporting, and the maturity. But before we get into it, I'm going to ask for group participation here. So everybody, do me do me two favors first. In the chat window, what's the one thing you must want to hear about today? Now, again, not particularly from Prolifics, or EnterpriseDB, or BWG, but from each other? It might be a use case, it might be can IT support these types of workloads, it can be technical, it could be operational, but I'm going to ask everybody participating today. Well, if you're spending the time to listen to this call, let's make sure that we're hitting the one thing that you most want to learn about, or at least guide us in that direction. So, I appreciate that. Thank you for getting us started. I'll ask everybody to follow him and audience, one thing that you must want to learn about, and I'll do my best to guide and guide this conversation around around these ideas again, so that this is a useful function. Let's go over to Julian and Gunjan, what have you seen in terms of the depth and breadth of of third party, third party tools to monitor?

Julian Moffett  13:35  

I think that's a really good question. So that's the most important thing in the world is that when you implement Postgres, it's not just about the database, it's the entire ecosystem. It's how you provision your Postgres. It's how you automate that. It's how you do that reliable, reliably. It's how you back it up. It's how you monitor all of those things are absolutely critical. So to completely understand the Ask some prompts, just to answer your question. Yeah, look, I've operated and we, as a company operate Postgres for mission critical applications. So I think that's the thing that's changed over the last few years is Postgres had a perception as being kind of an open source database for lower tiered applications? And I think, to your point, there are a number of tools out there to help you achieve some of the kind of RPO and RTO objectives that more high tier applications typically have. So I've used historically Patrone for high availability, that's not a full that's not a five nines solution. There's still a period Well, while you're doing some kind of failover in the event of an issue, we EnterpriseDB have some tools as well, we have something called EFM, which does a similar job. We also have perhaps interestingly, a multimaster solution, which is Torkel BDR beta, we call it currently bi directional replication. And that's at a database level which is which is is perhaps preferable to try to do this at a storage level. I've tried in my past and failed on a couple of occasions to do this at a storage level, because it's very complicated. And if you can have that manage the database, I think that's possibly preferable solution. So yeah, I think from a, the way I look at this, when I look at the tooling landscape for supporting Postgres, I always think of okay, what's, what are my availability solutions? So yeah, there's a number of things around kind of primary and secondary kind of failover. There's super high availability zero downtime solution, which is BDR type solution, backup, and monitoring the monitoring one at Yeah, PGM. And, of course, I think that's a perfectly SIEM tool. Again, our company, we have some tools, we have a tool, which is kind of our version of Oracle Enterprise Manager, which lets you have a little bit more of an oversight of just the entire state lets you drill into kind of the health of your different databases and gives you an ability to do some degree of troubleshooting, I will be be very candid and say, yeah, it probably doesn't go as deep in the diagnostic as we might want it to at this point, but certainly goes there. So. So yeah, there's, there's a world of stuff out there in the market, from from an open source perspective, but one of the things that we tried to do in our company is to kind of augment the core of the really solid open source database platform with a set of tools that help you operate at an enterprise grade. So and I think that's partially the challenge with with managed cloud offerings, and Iris as well. So EDB has cloud offering called big animal, we will offer some metrics out of the box, and we kind of give you in building that our equivalent of Pim, Postgres Enterprise Manager, which is our equivalent of Oracle Enterprise Manager. And what we'll do is we will push all that log information into into Azure monitor so that you can then basically build the dashboard to get the visibility on what's going on. So an RDS I'm sure there's something similar. If there's, if you run, and some people do if some people run the databases themselves on the cloud providers, I asked that form as an example, where the cloud providers Kubernetes platform, then yeah, there's potentially some opportunity to plug in more tools. But I think the slides, one of the slight drawbacks of going for a fully managed offering is you kind of get what you get, because the providers will say this is the offering take early, that type of thing. Yeah, so I think there's there's kind of infrastructure level, let's call it infrastructure level performance. And then there's application performance, and I think they are distinct things. Again, yeah, we offer a great kind of depth of expertise, where we can kind of do some tuning work in your databases, and try and understand. Often what happens is when people if if you're porting from another platform, particularly if it's coming from Oracle, when you when you push it into Postgres out of the box, it's not going to run as optimally as it has done an article, because the chances are, you've changed your Oracle database over the last 20 years, and it runs beautifully on Oracle. But now you're on a different platform. So. So yeah, typically, when we go through the migration process, if it isn't migration, the first thing we will suggest is that we do work with your application teams to actually tune the application level query that's going into into the database back end.

Gunjan Goel  18:31  

I think one thing that I would probably add to that is that some of my clients at this object at this point of opportunity, also line up and say, Is this a simple shift and left migration, or we are doing this for some possible future growth in the open source at a bank level. So it's not just a cost business case, but a new business model revenue case, when in some, when some of the clients are considered that they are using this migration opportunity to say how they need to redefine maybe the data structures themselves, because now they have to incorporate both structured and unstructured data together as well. So I don't know if that is also something that's coming in your side that that will probably be part of the restructuring, and then fine tuning on top of it. When I have been I've had clients and some of the client with other bigger banks, they tend to do a lot more of belt code, there's a traditional mindset that they differentiate on the application and the structure that they build. And it's all with a conversation when you see some, like, you know, new thing, new groups like Rocket Mortgage and others, which are coming in and they are leapfrogging these monolithic in organizations, because of the nimble as well. While they're innovating and how fast they are moving, right, so the reason I bring that up is that if if you see organizations which are willing to, you know, embrace, and looking at the dilemma of you know, Best Buy, I would always encourage, it's almost a combination between building, but more with an open source mindset where you can actually don't have to lock yourself and to preset product, like, you know, and build on top of that, but use the open banking space, and use that to jumpstart a lot of these systems, because these mortgage services are coming in as a service available that you can actually build on top of like Lego blocks. So something like that can help, you know, sustain the maintenance, or the development team that we require moving forward, like I had this one bank, when I probably can name the bank, one of the top US banks, and they have a mortgage system, they had bought, like a full, you know, the suite of products for the yellow s for the orders or for all of their loans, loan servicing and everything. And now they're in a constant challenge, that they are at the mercy of Accenture, in this case, to provide them with the tail end, which is depleting with with moving time, so they don't have the right talent to support that native code, which seems to be a problem, just, you know, about to happen. So I would, I would probably just, you know, think harder about going towards that space. If if I don't know where you are in your lifecycle. But that's sort of, you know, some of the questions that some of the clients are talking about also as well.

That could be a cost on the line and a big risk factor. Like, you know, I will save it from the sales page here. But profits, one of the business that we do have is on the market, that was one of the area that we foundation pillar that we developed on like we became be with a country wide. Not that great, sorry, but the whole market division or countries or Bank of America was run all the backend system, everything was done by us. So we do have the deep expertise. And now we work with a lot of these newer organizations, which are, you know, coming up with, it's this whole business of mod gate, and they're helping them develop and this open space a lot. So do I do have experts on that, I mean, we'd love to have a follow up if we need to, I can have some of my guys, you know, working with you on that

Greg Irwin  22:52  

syndrome. I know, it's not within scope. But we've done so many series around low code development, that I've learned that the pace of development right now, really, particularly for front end customer portals has been templated and supported through set libraries in a way that the development really is much faster than it's ever been in the past and able to be maintained. So I it's a much lead to much less lift than I that I grew up with in terms of what would it take to code and these things from start? And again, Gunjan, what have you seen in with some of your customers? Yeah, so

Gunjan Goel  23:31  

let me just what I understood so far is we have a three tier architecture, I'm assuming the the front end API layer and the database layer, and you have divided up your performance into three pieces. And is there a, what percentage of performance is on the database layer? Like where's the biggest bang for the delays normally, like, what, which is the one that's a focus area, because of database itself was the lowest one and the business logic is all in API's. And that's where the real time consumption is, then performance to US business argument wouldn't justify any migration, right? I'm just trying to understand how the performance is spread between the three layers, assuming if this is a three layer architecture that you have.

The there was someone who said earlier about us talking about natively growing in Postgres grown up so I had I've seen clients who are mostly in the situation, they have not had the luxury to grow natively in the new environment. And they are being pulled getting pushed over as you are, it seems to be that with the volume and complexity, both being added and now our ecology is almost bursting the seams there, right now, so with this one client, what they started to do is as they started to figure out and say what data structures they can put on cloud, what they can keep on prem because of their reservations of security, which technically can be proven, but you know, culturally, they were not okay with it. Right. So what we ended up doing was we ended up creating, and in decades, as far as your we, we took up MVP approach and say that for, you know, an MVP that reflects all data types for one of your key applications, string setup, how will the performance work? So it took a lot of back and forth theory for some deprecated libraries to figure out what data structures to be designed on prem and what on Cloud to make the business case on how the performance could be enhanced, as they move from Oracle and their situation to their target platform. So basically, you know, it became obvious that a lot of the new structure volume, the you know, the volume of data that's coming in, and what logic needs to be inputted on top of that, with the complexity of the new data types and everything else. The you just have to design the new target platform, and the back and forth pipes in their case, because if your bank is open to on moving everything, then it will become much faster. But in their case, they had a combination. But we did an MVP approach that took almost 10 months, because it was just way too much stuff to figure out. But that did prove performance improvement in their case. Because Oracle's not really designed for a lot of those pieces. I think the cost argument almost gets defeated, because the value argument, we know increases a lot the performance definitely we have seen in practice to be better.

Julian Moffett  27:08  

Just I can add a little bit, Gunjan, so I think I heard you're obviously running a heavy relational workload with kind of high availability, high performance requirements on prem. Are you running that as an example on EXA? datas? But the short answer is, look, you can replicate that performance on the cloud providers, all of the cloud providers will offer you a variety of different compute options that will enable you to do that. And to your point, I think it depends on what costs so. So maybe one of the fundamental questions I would ask myself, if I was in your shoes was like, what am I trying to achieve with this move? Are you are you having to move the database because the application tier is moving to the cloud and you want to have the to kind of co located or is there some other driver that that's pushing you to kind of think about an alternative to Oracle?

Think often the only way to do that in any kind of cost effective manner is to do some application refactoring, which is a big investment in itself, because so typically, you'll you'll kind of deconstruct that model and break it down into smaller, more manageable pieces, which makes your database costs at least a little bit more manageable. But you know, this as well, as I do, that's an investment upfront, is there? Do you know, in your company, is there an appetite to do that kind of level of application?

Greg Irwin  28:29  

Drilling is the baseline question of when you've undertaken this in the past? And you have people who have have tuned Oracle environments, and they go through the migration, and they put them on EDB? Can you match performance levels? Simple, because obviously, it's going to require tuning or application development, and you know, and work. But are you getting there? Yeah, so

Julian Moffett  28:57  

the short answer is yes. But but it doesn't happen overnight, right? When you turn it on, initially, it's going to run like a dog and it's going to be unpleasant for everyone, then you're probably your developers are going to go What the hell is this new platform you've put me on, but ultimately, you can get there. I mean, my, the last company I worked in they My experience was we tried to build up a new Postgres service. And we had very, very deliberately chosen kind of lower tier applications with lower performance requirements, lower availability requirements, to kind of get the service embedded. My CIO at the time, kind of strong armed us into supporting this mission critical application, which was basically a mobile phone authentication mechanism for everyone to log on to their desktops every morning. So we're talking to like 100,000 people in every continent in the world in 50 plus different countries. We ran the Postgres database under the covers, so it's possible to achieve those levels of eligibility and those levels of performance. But yeah, it just takes a little bit of work to get there. So yes, your answers yet you get there. The question is that well cost. And for John's, from John's perspective, yeah, I totally get it. It's is there value for the application teams doing this that that, for me is honestly, one of the larger challenges in this, it's having the application teams understand the benefit. And one thing, John, maybe maybe relevant in your space is just kind of, are there other other options that might be appealing for them? So I don't know what they do they have a risk position currently that is there an end of life problem on their current platform? Are they going to have to invest in that database already? Is there money, they're going to have to spend in any case that you can perhaps redirect to the refactoring.

The mainstream says, look, there are some apps and they're typically smaller, lower priority, where a straightforward lift and shift is viable and cost effective. But it seems like just the nature of the apps you're describing, that's not going to be the case, just definitely, it sounds like there's going to be some work that's required. And I think your approach is 100%, right, in terms of trying to find the full picture of investment that needs to go into those applications and redirecting that to your target platforms.

Gunjan Goel  31:13  

I think one thing that can be added on top of it would be if there could be new business models or revenue model that can be associated to these applications that, let's say we get to a cloud native or Postgres solution, and that allows you to fail fast to to provide, you know, mute every models or, you know, leverage the open source community. So that, for example, if somebody is, you know, develop some, you know, regulatory rulings or service, you are developers don't have to develop that functionality on a on an ongoing basis. So that saves on development efforts, like stuff like that, if if some new business model or revenue model can be added to it that can augment the business case, for that. And in terms of the initial question, I think, great that you're asking, is it capable, you know, apples to Apple's Yes, when the performance can be met easily. And in my opinion, it gives you those plus additional flexibility of unstructured data and other things that can be natively be part of that which is not in your previous data architecture, in which case, you have to combine them at an API layer sometime that adds time delay. So those arguments could be broad stroke arguments that can bring in the money. But this is a big effort.

Greg Irwin  32:32  

You know, data growth has always been a concern around your Oracle environment, because you have somebody who's thinking about just, you know, scope creep, and the fact that this environment is getting too big and going to cost too much. The fact that you move it over to something like enterprise Postgres, that that question comes out, just off the table, and it opens up more opportunities for the pilot. Gunjan, you said proximately, 10 projects underway, how many of them are migrations from Oracle from, from SQL, from Hana, from, you know, a legacy, relational,

Gunjan Goel  33:14  

sir. So they are about couple of two or three of them are massive migrations, from a whole mainframe, monolithic in our setup to Azure and did a whole series to it from bad job and all combinations to it. Specifically, right now, there's one on the data side, which focus more on the data side is is known from Oracle actually data, EDB two and combinations that we are moving, moving it, you know, onwards to a data lake setup. So that's where, you know, the guys are investing effort. And, and one of them is with the Azure the one I was mentioning earlier, that we ended up doing an MVP to figure out, we had to cut across the data and say, We got to be on prem and which part had to be moved over to the Azure service and figured out how do we leverage the services provided by as you're like the cloud providers, going to be re recreate all the services and rebrand and then we lose the benefit of the cloud. So that took a lot of workings. So the two of them were like that.

Julian Moffett  34:34  

I will say there's a number and this may not be an option for you guys. There's a number of different providers out there. I'm sure Gunjan knows some as well who can help with that migration. There are some open source tools out there or TPG. Is that is the standard one, it will get you so far. It may not answer all your questions, but I think that you hit on something really important though, if you've got databases that are 100 terabytes. And first of all, if you're going to break them up into smaller pieces. I think that's good. That sounds like it's more manageable in any case. But if that's not the case, then I think we have to ask yourself the question is Postgres the right target for those, those applications and those databases, I'm very keen to make sure that we don't kind of push a square peg into a round hole or Postgres is very good for certain workloads. But I think if you're running high kind of data warehouse type environments, Postgres may not be the right answer, depending on your workload. So that's perhaps something to try and think about. But I think your approach of breaking it down into small pieces. Yeah, absolutely. Postgres can can absolutely cater for those. But I would, I would definitely investigate. If you have an opportunity to just perhaps try and get some support in the migration, we can do that as well, by the way our EDB offers support. We also offer products, I'm not going to do a big sales pitch, but we offer a product, which gives you an Oracle compatibility layer on Postgres, so we have a version of Postgres called E PERS, EnterpriseDB Advanced Server, which basically makes that migration easier. So maybe worth doing a little bit of googling on that, or we can connect offline and I can, I can share some more information for you that that may ease that transition for you.

Greg Irwin  36:12  

We're gonna wrap it up here. Gunjan, and Julian guys, Prolific and EDB EnterpriseDB, that's enterprise Postgres. Guys. This was a lot of fun. And it was nice to go around and hear some real stories, and talk about where this fits and where it may not be the best solution. Any closing comments here? Mine is, let's get let's get connected. So this isn't the last conversation. It's the first, Julian and Gunjan. Any, any quick last comments for the group?

Julian Moffett  36:44  

No, just a big thank you to the group. Really good to hear from folks. And thank you, Greg, for moderating.

Gunjan Goel  36:50  

Thank you everybody for joining in and feel free to connect. I'll be here to help. And my teams will be you know, maybe a little bit smarter than me. Thank you.