Thank you all for joining us today. I'm Nate Parsons. I'm the Chief Strategy Officer of Parsons TKO. And I'm excited to talk with you all today. And we're going to be diving in today to talk about why you need a marketing CTO. And what is a marketing CTO? And why is that different from a regular CTO? And part of why I wanted to give this talk today is that we keep running into situations where clients are wondering, why are all these fancy engagement tactics that you see on medium posts and on the web and other things so hard to make part of their day-to-day? Like what's getting in the way of them adopting more sophisticated outreach tactics over time? And why is that challenging? And one of the things that kind of made me think about this, we kept hearing things like this. And I just wonder if any of these sort of sound familiar to folks. The fundraising team might say something like we want to target a very specific set of people that we think are likely to give in a certain scenario. And then the communications team looks into it and they're like, oh man, we're going to have to make an Excel file and do a lot of manual labor to make this happen. Or another thing that we've seen happen is that people are just wondering, their higher ups are wondering why the time and effort they're putting into things isn't creating the value or the benchmarks that they see on the web or other things like that. And they're just wondering why things aren't working. And then the comms team looks and they say, well, there's all this optimization and this improvement that we think is in there that we just don't have time to do. We have the tools to do, we're not set up to do. And from the leadership's perspective, they're just wondering why you haven't already done that. Isn't that your job? There's all these complexities for why that doesn't happen. And part of that is that outreach has become a real team sport. In a lot of organizations, there was a fundraising department, and a communications department, and an events department, and a volunteer management department, and maybe a grassroots organizing group. And all of those were sort of independently operating. And as the tools for outreach have become more sophisticated, the need for coordination and collaboration between these different groups has increased. And the other truth is that as the world has become more digitally sophisticated, the relationships you have with your audience are longer term. They're not three months, they're three years. And to sort of plan for that, you have to have sort of both a long-term view and a sort of collaborative mentality. And that causes things to break down in a number of places. Probably the most obvious is sort of the governance of these shared systems. It's not uncommon for the fundraising team to own the CRM and the communications team to own the email tool and the volunteer management team to own a separate tool and so on and so forth. And that means that even just letting people know in other departments when you're going to make a change, that might impact them, and that change could be how you categorize your audience. It could be how you store demographics. It could be whether or not you pull information back from a system into a shared system. All those things need to be sort of coordinated and announced. And the other piece of that is that sometimes another department needs something that you could provide, but you don't need it. And so you don't provide it. And so that's another place for governance can really help sort of solve those problems. But it breaks down there a lot in organizations. Budgeting and lifecycle is another place where things happen, where a tool can either long outlast its utility because it's serving one department's use case, but it's not serving the organization's use case. Or that the flip side can happen. A system gets replaced that another team was relying on and they didn't know about it and they didn't adjust their business processes and they didn't have a change management plan. Suddenly they're scrambling or the level of service that they're offering to the audience drops because of the systems replacement. And so managing the budgeting and lifecycle planning process is another place that takes just a lot of facilitation and coordination. Then this long-term audience cultivation. We often work with organizations that have sort of like young leaders or new leaders kind of program where they're really helping people get off the ground in their career. And they build a lot of affinity with those folks but they don't keep up with them. And in five or six years when those people are mid-career or starting to break into their late career and have a lot of influence or a lot of ability to direct funding or other sorts of things that organizations might care about, they don't have that connection with them because they didn't plan for a long-term audience cultivation. They're really focused on getting someone from a social media post to a donation but not a long-term relationship with them. And that's just another piece where it takes a lot of people working together to make that happen. And finally just technical expertise. It's very common for different departments to be stronger or weaker in different areas to have better visual design teams, to have better sort of data strategy teams, things like that. And how that expertise is sort of used across the organization often could be improved with a little facilitation coordination and just kind of letting people know like, hey, if you share a little budget here or you sort of fractionally fund this position, suddenly we can all benefit from this. So, why are those things breaking down? I think that's one of the things that people wonder everyone has the best intentions when they start these and everybody thinks they're being a good teammate and collaborator with their other partners in their organization. And one of the reasons that it is hard is that these problems creep up on you slowly. It's sort of like the frog in the pot. Why does it jump out of the pot? And the problem is that when things like non-standardized categories for audiences or different naming conventions for topics of interest are used across different systems, the impacts of those are not realized for a long time. And often they're realized only when you try and do something more sophisticated, all of your basic outreaches are not impacted by those lack of standards. But when you wanna do something a little more fancy, a little bit more data driven or a little bit more personalized, that's where those troubles start to pop up. And usually that's in the late game out of the beginning. Related to that, it's not really anyone's job to manage these holistic things within most organizations. If you have a CTO or CIO, they're typically focused on making sure the organization works effectively. And that includes all sorts of things from information security to make sure laptops work, to making sure the bills get paid on time, picking hosting vendors, managing email security. There's so much on their plate. They're rarely focusing on the outreach or marketing function. And often the people in those roles don't come from a background where they have a lot of exposure to marketing and outreach needs. And so they tend to not be focused on your outreach platform or your audience engagement, even if they have that technical capability. COO's office, the chief operating officer, they're often a great place for this role to live or for this kind of function to live, but they have a million things on their plate too. And just between budgeting, staffing and interdepartmental management, they often can't focus on this effectively. Next sort of group that you might think is the communications department. They often have the most outreach tools that they're kind of the leading edge of your audience engagement. They're out there meeting the new people your organization interacts with, but they're often have these firewalls that prevent them from owning all the systems. Hey, don't get involved in fundraising. Oh, for our own benefit, we're not gonna get involved in the volunteer management system. How can we kind of keep our scope of work reasonable? And so they tend to kind of create breaks where they don't sort of expand and manage the whole organization. The events department, just forget about it. There's so much intensity and so much firefighting on the events department side.  Fundraising is usually typically the most invested and interested in longterm relationships and in holistic relationships. The challenge for them is that they are not as invested in the day-to-day contact and on the early parts of the funnel. And their team is often very sort of results focused. How is this leading to donation? And they can track all of that. And so that creates some data disincentives for them to own a lot of the speculative longterm planning of the outreach stack. Then finally, if you do have folks focused on volunteering or on grassroots organizing, that's another place where there's a lot of interest and expertise on this, but it tends to be seasonal. They tend to have strong areas of volunteering or particular political campaigns they're focusing on. And again, it just kind of shortens the timeline and things they're looking for. So there's not anyone in the organization who's managing these problems or hooks on these problems typically. And the flip side of that is it's really expensive to hire for this role. If you already have a CIO or CTO, hiring another one seems like a real luxury. And most departments don't have the wherewithal to hire somebody like this just within their own department. It tends to be something that needs to be cross-departmental or on the executive team or the steering team or whatnot. And so it's really difficult for there to be a funded position that can handle this. And so that leads to this sort of miasma. How can we get out of this? And you might be wondering, who can save us? Who can save us from this terrible fate? And it's a good question. Like we need somebody who can solve these problems. We think about the long-term interconnections of our platforms managing them and helping improve the situation so you can reach those more sophisticated and more meaningful ways to engage your audience. And that person, whoever that person is, it needs to be thinking about how the outreach systems fit together. They need to be thinking about how that actually feels on the outside. It's really common for somebody who's on the outside to get an email that looks a certain way to go to the website and it's a slightly different field to maybe come to a volunteer event and see and have a different experience. And that all sort of creates friction in your brand. You're not creating a unified brand experience. You're not sort of making them feel like they're part of a cohesive whole. And that's often because you're jumping between departments that aren't coordinated and their systems aren't coordinated and even the visual branding has been always coordinated. And then you need somebody to focus on the long game. A lot of this audience engagement takes, at least a year, if not multiple years to kind of grow because you're having sort of a value arrangement with your audiences. You're trading them information, you're building affinity and trust with them and you're helping them advance their personal brand and their career through your interaction with them. That's just not something that happens overnight. They might give you a donation when they're feeling very motivated or there's a crisis in the world that they want to help support, but that's a little different from having a long-term and high affinity relationship with them. And I think to do that, you need sort of more mature tactics. You shouldn't be sending the same outreach to someone who's been with you for five years as somebody who has just signed up for your mailing list. And that's like instinctually true, but it's actually really difficult to turn into operational truth. And to do that, you need somebody sort of thinking about what are the different stages of engagement with our audiences and how do all these technical platforms and outreach platforms fit into that? And what's the data model we need behind all those things to kind of know when to send somebody the right content, when to segment them into different audience segments that receive different content and how does that all go into work? And how do I sort of train the different teams and get the other teams on board with this sort of segment and plan of attack? And part of that is creating resiliency because every organization suffers turnover and with technical systems that are complex and hard to learn and there might be a steep adoption curve. When somebody who really knows when to grab your systems leaves, that can create a big gap in your audience experience. And you need somebody who's helping to think about that proactively. How can we minimize that gap? How can we fill it in quickly?  It's not something you can avoid. You just need to plan into it. And then the other piece of it is you need somebody who's saying, we've done this for 10 years. We should stop doing it and do this other thing.  How can they go out there and find things that will change the status quo in a positive way in your organization? And do that in a meaningful and change managed way where people accept it and adopt it and find it useful versus just somebody who's lighting fires. So who is this person? Spoiler alert, it's the marketing CTO. You know, really what it takes is a, pardon me, my voice is going a little bit, a commitment to address these issues directly. And you need empathy to do that. You know, if you don't really understand the stress and the anxiety of the other people you're working with, forgive me.  And it doesn't matter how good the plan is if the resistance to it is high. And so there's this acronym FRMP that I like that is sort of facilitating conversations because a lot of it is just getting people to talk, make sure those conversations are factual and balanced and not sort of blame games. Someone who can receive the ideas and kind of enhance them and organize them and share them back out. Somebody who's sort of a trusted partner in that planning process. You need somebody who has a little more time to investigate and sort of understand what the real needs are. You know, often people will complain about something but you have to really dig into it to understand the nuance of what the problem is. You know, it's usually a little tiny, important intricate bit that needs to be changed. And it may not even be that hard to change but somebody needs to investigate and figure that piece of the puzzle out to really move your platform forward. And that's part of the managing process. You know, a lot of this is communication like letting people know what your plans are ahead of time, letting them see what the roadmap is, letting them influence the prioritization and the timing of those things. Just kind of making sure that that's something that everybody can see and engage with. And finally, it's really important to have somebody who can, you know, manage and massage different departmental budgets. Most of these tools are budgeted in one department but they need to be budgeted across the whole organization. And that might not be easy depending on how your organization manages budgeting and manages like how people pay for things and how tools are funded and depreciated. And if you're using capital expenditures for certain kinds of tool replacements and so you need somebody who's kind of thinking about that, talking to everybody and kind of working out all the kinks in that so that when a change is proposed the budgeting for it suddenly doesn't become a huge roadblock. You know, what are the skills that somebody like this needs? You know, and this is something we get asked a lot. We're asked to like help people hire people or to suggest people for this role. And you know, the truth of the matter is they need to be really good at managing up. You know, a lot of the sort of marketing CTO's job in any organization is to sort of say, hey, I'm gonna take away all the technical systems here all of the buzzwords. And I'm just gonna turn this into a business question where there's this challenge there are these pros and cons to different approaches. I recommend this approach but seeing the pros and cons of these different approaches to use a collective leadership team agree. And if you have that skill in your organization managing your technical platform is suddenly gonna become a thousand times easier because people will have trust and will be bought into the solutions and the choices that are made. Even if they don't understand all the technical implications of that they'll understand the business implications which is what's really important. You know, and related to that is having strong communication skills, you know managing up sort of requires you to have some empathy and understand like if people are feeling anxious or if they're feeling tense or you know, if you're feeling excited about things and kind of communicating what you want to this folks often means creating visuals for things that are abstract, you know writing textual descriptions that are maybe a little longer form than you might to another technical person but you know that will really help other people kind of see a challenge and see what you're trying to achieve. So there's strong communication skills that are really key and you know, empathy is important because when you're dealing with technology it's often a black box to people that often directly impacts their business performance they often feel really frustrated and they can't make it do what they want. You have to have a lot of empathy for that if you're gonna be successful in change management. You know, if you just say you're right and you might be right that's not gonna actually help change things as much as if you're understanding anxiety you work with people and you make them feel like they're being brought along on the path in a successful way that's gonna make them personally successful. And you know, that's part of the trust building as well that's really key to this position.  You know, I think that's a, you know hopefully it's actually true but like, you know in a lot of ways the marketing CTI is somebody who builds trust by soliciting a lot of input and feedback. You know, they're asking people what they need how they need it, when they need it and they're saying, hey I brought all that together into a cohesive and useful plan but it's not necessarily my plan it's everyone's plan that I've just self-organized and facilitate. And you know, when you look at this list you might be wondering I thought the CTO, you know needed to be technical and you know, it turns out that's a help. It's really helpful to have a technical background. You know, I was a developer for 10 years before I sort of got into, you know more of the CTO style of leadership but it turns out that many of the technical skills that you might think they need are readily available outside of your organization at an hourly rate. And you know, one of the tricks of the trade is to use all of the expertise that's out there and just not be afraid of the sticker shock. You can get somebody who's a Salesforce expert spend three or four hours with you discussing options for 100 bucks an hour, $125 an hour and that may sound expensive on an hourly rate but the expertise imparted to you as a leader and the experience that you get from that is worth far more than that amount of money. And I think a lot of organizations think of it as a binary problem. We can either have a technical expert or we can't as opposed to we can have an organizational expert a management expert who can learn how to do those things or can bring in experts to help them understand the problems.  You need to know what systems you have how they're connected which vendors and experts you have internally and what they're up to but you don't necessarily have to be a deep expert or domain expert in each of those technologies. I think another piece that happens here is you have to be comfortable discovering and hiring outside help. A lot of people want to go to loan but the truth of the matter is the more experts you bring in the more outside help you bring in the smarter you're going to be the brighter broader your perspective will be and the more likely you are to make a good choice and you know, part of that is the process and governance like even if you get expert advice from somebody they may say you should just do this tomorrow but you have to kind of step back and say oh, I need to do this at the time when the organization will be receptive for it and have I done all the groundwork to make the organization receptive for it and so part of it is always balancing your technical need and expertise of the knowledge of what needs to be done with your business knowledge of what the organization can adopt and absorb and actually achieve with that change. So you might be saying, okay, I'm buying this this all sort of makes sense but we still don't have a marketing CTO and I don't think we have the budget for one so what are we going to do? And the truth is it's possible to get many of the benefits of having a dedicated marketing CTO with just some of your existing staff if you're willing to sacrifice or devote a few hours a month to this management process from your team. You know, and I think one of the challenges here is that the team has to come together and think about how they're going to govern first and the executive team of your organization needs to give them the power to govern. And I think that's one of the challenges for the CTO by committee. You know, each department using or managing our system has to participate, you know, or at least a large percentage of them do. You know, it doesn't help if only half the team that doesn't manage the outreach systems is involved. The governance and decision-making rules that you adopt have to allow for relatively quick decision-making. You know, if a decision takes six months to make that might be okay, but it's probably too long and you're going to need to work with your organization and your leadership to develop a process that lets the decisions to be made a little more quickly. I think another part of that is that the CTO by committee needs to have a lot of sunlight. And this is one of the challenges a lot of organizations, especially if they're not already built out internet that everyone uses or some other place to kind of show this, but you need a very sort of public backlog of changes, enhancements to the systems. And you need all of the participants and all the departments to be able to look at that and plan their own sort of change management processes around that and also sort of impact things to say, hey, I really need this to be a slow period. Can we not have changed during that period? That's the kind of thing that a public roadmap or public backlog of enhancements can help you find and discover. And I think the other piece of this is that CTO by committee only works if the departments agree to sort of jointly fund and license the systems involved. They'll have to have a sort of shared ownership of it and a shared stake in the game. And that also helps when a system replacement comes up. Different departments can weigh in on is the value proposition good or not for them to make that systems change? And then, as I mentioned, the committee really needs to be able to hire expert help. It's really valuable for a committee of folks who are not focused on technology day to day to have somebody come in and just kind of explain like what's happening with the system or this tool? What's the landscape out there of other systems that are coming up and what you're competing against?  All those sorts of things an expert can come in and help you quickly decide without having to be there full times. So that's one way to handle this is to have the CTO by committee. The other way, and this is probably the most common way we see it, the clients we work with is the knighted non-technical CTO, somebody who is sort of blessed by the organization to come forth and manage the technology stack or the engagement platform. You know, maybe this goes without saying but it is worth mentioning that this person should be pretty charismatic and should be well liked by your executive team or at least by your department heads because they're going to have often not a lot of executive clout to make these things happen and that's why this particular approach can be challenging is that these people tend to be the most technically skilled in your organization but not necessarily the highest ranking or the people who have the most pull. And so that means that they have to utilize a lot of soft power to make things happen. You know, they have to have strong communication skills. They need to continue to develop their own technical skills and sometimes their personal interpersonal manage up skills and so they often need a development budget attached when they get knighted. They very much need outside experts and advisors because that helps build credibility with other department heads and other people in the organization if they can say, I've examined this problem myself and then I brought in an outside expert and they've either validated or helped improve the path forward. So that's really important. And then, you know, they may need a new boss like who the knighted CTO reports to is really important. And, you know, typically if they're a thin one department that's kind of, you know, debating and working with other departments and how the outreach platforms work or part of one of the stove pipes you already have in your organization that's not the right place for this person to sit. Often they need to be reporting to the COO or the executive director or somebody higher up who can give them kind of a neutrality between departments but also give them a little bit more gravitas if they need to go and get a decision made or need to like get some people in the room who are avoiding them for some reason. So this is totally a possibility but just know there's some pieces of the puzzle that need to happen to make it successful. So let's go on to the quarterly course correction. This is a lot of organizations default which is that they will say a couple of times a year maybe not even every quarter maybe every half year or a third of a year we're gonna come together and we're gonna try and figure out what we want to do. You know, the struggle with this is that there is a lot of value in this at least you're addressing these problems and moving forward and looking at them but a lot of the day-to-day nuance and a lot of the day-to-day feedback about frustrations, wants, ideas things that can be improved aren't captured in a quarterly way, right? They're captured in a day-to-day way or a weekly way. So you need to really focus if you wanna do sort of just a quarterly course correction where there's no one really managing it day-to-day on mechanisms that let people have an inbox or other ways to just kind of put their complaints in the box and whatnot and you can like look through those and have a process to review those before this meeting comes together. The quarterly course correction tends to take a lot of time it needs to be planned almost like a major event. Somebody needs to do a lot of prep work for this. They need to come together, hear everybody's complaints and needs, sift through that, organize it, try and categorize it. They need to brief each of the departmental champions and people who are coming to the workshops. Agendas need to be set. Often there need to be different discussion times figured out and it usually is pretty time consuming for everybody involved. It's like a half day or a full day of planning every quarter, every time you have one of these meetings to kind of go through all that information. So it's definitely possible, but it's not necessarily the best. And so this is kind of a little bit of an option of last resort or maybe a starting point for sort of adding on to your sophistication over time. And it's also important you have a spill facilitator. I should just mention that that these meetings tend to be a little contentious or people can easily have strong opinions in them. And it's really important to have a clear facilitator figured out beforehand. And often it's good if they're sort of a neutral party. So this takes us to our last one. So maybe my favorite one, there's a little picture of me on there, which is the fractional CTO. So this is our little sort of personal plug, but we do a lot of this for organizations where we will offload a lot of that platform management and engagement planning from your organization. And we're a neutral party, so it often helps. And we've often done stakeholder interviews when we come in, but even if it's not us, there are lots of fractional marketing CTOs out there, people who have deep technical skills and are kind of doing this on a consulting basis. And that consulting experience gives you a lot of the manage up skills and communication skills you need for this. And you can often find marketing CTOs or fractional support with people who are expert in at least one, if not multiple parts of your outreach platform. So that's another nice thing is you can kind of fit people who have that already built in expertise and breadth of expertise at other organizations to come in and help your organization. And they can range from being there an hour a week to being there a half a day or a day a week, but you can kind of figure out a way that works for you. And the nice thing about this is that often these folks are engaged on a weekly basis, if not a daily basis. And so they hear a lot more, they know a lot more about what's going on and they're able to kind of bring that plan together in a little bit smoother and easier way because they're capturing a lot of information right from the get go rather than having to kind of deep dive with people every quarter or whatnot to find that stuff out. And the truth of the matter is you might be a little to be this person. If you're in this meeting and you're thinking maybe I could be a marketing CTO, you might be right. And I think there's a couple of things you can do to get started on this. There's a ways to assess your engagement platforms current health, like where are you starting from? Where are the challenges? And sometimes that's the best way to start a conversation inside your organization is just kind of say like, hey, we're here. I think we could be here. These are the benefits that we would receive from that. And I think it would really help our bottom line or would help us engage your audience in these ways. So starting the conversation there is part of starting an assessment of what needs to happen. It's really easy to run a workshop internally if you can get people to, you know commit a little time to it where you can kind of think about the cross dependable challenges and needs things you might need like a shared taxonomy between departments that sort of stuff, you know sometimes there's just a conversation and a facilitated conversation in a workshop can uncover a lot of it and build a lot of shared momentum and that's sort of shared support for it. So once you kind of know where the challenges are having a little workshop like that is a good way to kind of get started and dive in a little bit. Then, you know, begin planning your technology roadmap. You know, once you have people bought into like what they want to change and how things can be improved sort of starting to put those on paper is really a good way. It might not be funded yet.  If you give them something and they say Oh, that's not right. They're going to adjust it and make it better and they're going to start to feel some ownership and some investment in it versus if you say, hey, give me a roadmap and it's a blank piece of paper they're going to probably come back with a blank piece of paper. So it's really valuable to kind of start putting all of those things after you have sort of workshop like that together on that roadmap and sort of figure out your path forward. Then, you know, as you do that it's not uncommon to find there's missing pieces of engagement architecture. And, you know, we have a lot of thoughts on that. One of the things I like to hear was a contact model. So how do you actually track and manage each audience member? What's the data on there? Which systems have that data? Can you put all that data in one place? Like, is there processing you need to do on that data? Like, hey, if they've come to like three events and open three emails in the last month do we put them in the likely donor bucket? And can we put that as like a processed like tag or signal on their contact record? So it's easy to find those folks without having to remember all those rules all the time. There's things like that that you can start to bring together. And, you know, if you do this over time suddenly you start to find that you're unlocking a lot of those more sophisticated and powerful outreach possibilities, things like personalization or optimization or automation. I mean, all those things require, you know the systems and the platformers to be working well together and the contact model and the data model buying these things to kind of support that kind of interaction in a way that feels positive. So yeah, I think it's like I said it's a conversation is all I need to start, you know bring these people together, you know like get people thinking about these problems but, you know, don't let them languish, you know I think a lot of organizations are saying our department's working great but, you know, it's really about your organization working well and it's about your audience experience, you know, building and being more sophisticated and more meaningful to your audiences over time. You know, you want somebody who's been consuming and being involved with the organization for two or three years to have really high affinity to be a brand supporter and to really help your organization enhance and move its mission forward. And that can only happen if you, you know really focus on them and have empathy for them and figure out how you need to build your system and your tools to support them. So yeah, thank you all for your time. Yeah, this has been great. If you want to continue the conversation or if you have any questions I'll let an artist or anybody pop up here and let me know if there's been any questions during the conversation, but my Calendly link is up here you can schedule a meeting with me anytime and we'll chat about stuff and my LinkedIn and our company LinkedIn is on here and we do have a little project thing there if you're already like, oh my gosh I have a project in mind you can go to our little project planner and pop in there and we'd love it if you just fill out our survey from this link as well and let us know what you thought and if there were any things we didn't cover that you wished we had or any insights you have that you'd like to just kind of share with the group we'd love to hear those too. So thank you. Awesome, thank you, Nate. We did have a couple of questions in regards to advocating for the position are there any suggestions that you can make for getting prepared to start those conversations to get ahead of the politics at all? Yeah, so the first thing I think is to start the conversation like not with, we need to hire this person but more so we have these organizational challenges that we need to overcome, you know and I think that the thing you wanna do and build consensus around is this idea that there are these things in the organization that are holding you back from the best value organization could have and in a lot of ways, the thing that is holding you back is creating a lack of return on investment from the effort you're already spending, right? Like most teams are already spending tons of effort conducting outreach, you know it's not that people aren't putting their backs into having great audience experiences it's that the efforts they're doing are limited because they're using, you know like simple hand tools instead of like electric driven machine tools and things like that. And, you know, if you can kind of get the challenge to be the focal point of the solution and then you can say, I think one of the solutions if not the best solution to solving these challenges that we all agree are important and would, you know, derive the organizational value from is to hire somebody to manage these pieces and here are the concrete things they're gonna do that really helps you can say like they're gonna help organize this taxonomy and implement it in all our systems they're gonna help build a data model that helps us, you know capture and manage context of the longterm they're going to work with each of the departments to help coordinate their budgets and as you list those things out the time commitments required for each of those are gonna become really apparent. And, you know, then the question is we have these things we wanna accomplish we have these concrete actions need to be done how are we gonna fund those with staff time? And now you're in a really good place I think to start talking about that hire so that's kind of the approach I would take. Great, thank you so much. Another question about recruitment strategy if you are working in an organization that has not had a position similar to this or with these technological skill sets how do you educate yourself as an organization on where to look for the best talent for the position? Yeah, I think there's a number of ways probably the simplest way is just to go to one of the big like freelancer recruiter sites look for a freelancer who seems a little more senior and uses one of the tools you use and hire them for an hour and just ask them those questions. You know, I think there's a lot of industry expertise and the people who freelance and interknowledge about these tools because they probably learned those tools working in another organization working with the group of people just even knowing how they onboarded it to those tools. So there's a lot of ways to bootstrap your way into finding the right experts by already investigating people who claim to be experts and it's not necessarily the first freelancer you find is gonna be great but it's a really quick and cheap way and I think a lot of times that especially in mission-driven organizations the idea of spending like 150 bucks to have like an hour conversation feels like really anxiety producing but the actual cost to value ratio is immense there you're saving yourself hours if not weeks of time and you're really getting quickly to people who are experts. So I'd say please try and leverage the community of experts that are out there to find the right experts but don't assume the first person you pick will be that just that they're kind of an entryway into the great community of people to like ask and become knowledgeable out who can advise you. Great suggestion, thank you. Now, when you talked about being the person who could potentially step into this role that's I guess the other side of recruitment is kind of recruiting yourself almost. So how do you prepare yourself outside of the organizational and product management side of the change for your own role? How do you prepare yourself for this position? Yeah, that's a really good question. I think the first thing is to think about how you're gonna sort of split up your week and to give yourself some different pie wedges of time that you're gonna focus on. And I think those are things that are really good to be intentional about even though they sound sort of like basic at the beginning but how much time are you setting aside to do sort of stakeholder interviews with the different departments each week? Where are you gonna document and capture these things in a way that you can share them back with people and sort of demonstrate value by just writing down what they told you. I mean, it's amazing at so many organizations how there's this kind of like cottage industry knowledge or like folk wisdom about how they do their outreach but they would love to have that stuff written down and often it just takes somebody interviewing them spending a little time writing it up maybe making a few diagrams and if you hand that back to them you're suddenly building a lot of affinity and support. And part of your week and your planning for taking on this role needs to be thinking through what's my value proposition back to the people I'm servicing? And that's usually different from somebody's previous role where they're, I need to make my boss happy, right? Like, so there's a mindset change in these that happen where you're thinking about how you can build value with the new organization and affinity with the new organization through your work in that role because all of the good grace and all of the good energy that you build as you learn about what people need can be spent and will need to be spent actually getting them to change what they're doing in the future and adopt and get on board with change management to things you want to improve. And so the big change here is probably a little bit of a value exchange mindset. That's a really key one. I think from a just like practical perspective like doing things like toastmasters and whatnot is really valuable. I think if you don't feel comfortable being a public speaker or you don't feel comfortable being a convincing speaker I think that's a really important area to focus on. And there are a lot of good skills trainings for salespeople. I hate to say that but I still hate salespeople but around the skill called active listening. And, you know, active listening is what it sounds like. You just, you're really paying attention to what people say and instead of waiting for your turn to speak you're processing and thinking about what they say and then you're reacting to it and trying to really respond to what was said to you in a really empathetic way. And having that sort of skill set is extremely valuable. And so there's a lot of sort of the soft skill side I'd say people should work on. And the other piece of it is just you need to kind of think about how you're going to organize all this data. Like it's really easy for there to be mounds of data and it for not to be useful or lots of documentation and not be useful. You really need to think through your sort of your own content strategy for how you're going to manage all of these things. Then, you know, that's really valuable. So when somebody asks you a question and you can quickly share with them the answer share with them where they can discover the answer and you can make it additive. Because at the beginning often you're going to be the person managing all of this documentation and all these systems diagrams and the red map and all that. But if you're successful over time you're going to democratize that and there can be more people involved.  If you have like a thought out system that you feel comfortable and proud of sharing with other people you're going to be able to enroll them into your process more easily. And so that's the really key part of these successful here is that you're a facilitator. You're not somebody who owns these things. Great. Thank you so much. That was really great information. If anyone else has any questions to add please do so now. But otherwise I think we're going to get ready to wrap up. Oh, Liza Hogan had a question. What tool or software do you use for organizing this type of data? Yeah, it's a great question. So we have evolved many way, many times in different systems for this. You know, we started out using Confluence which is a wiki software for this and we actually still use it. So it's actually been pretty foundational for us. But over time we've moved more and more of this kind of information to Miro which is a real time kind of dashboarding system where you can kind of like drag and drop things and most people can get in there and collaborate with things and it's really useful because it kind of lets us both have static documentation and visual diagrams next to each other and it lets us collaborate really easily on it. So we're doing a lot in Miro right now to kind of manage and sort of create this and it kind of has a low barrier to entry and lets people feel like it's a little more fun. So those are all really positive things. I would say though that for us a lot of it is about where our team spends their time. You know, we try and make sure that these things are accessible and you know, not another thing that's a barrier to entry to learn. So if your organization already has a place that they are sort of like centered on and focused on for knowledge management, even if it's not ideal sometimes that's the best place. So I just kind of caveat to saying that our tool set was also based on our cultural history about how we've picked tools and worked together and collaborated remotely. Great, did anyone else have any questions before we wrap up here? Hating that kind of wiki or you know, record of that knowledge on behalf of your clients or just to have insight about them or no agency operations in the same way? Yeah, it's a great question. So we do both. We have a wiki for every single client or we have a wiki space for every single client where we document our technical approach, everything we've discovered about them. We also use another product called Teamwork which is kind of like a project portal software and it has a like much crappier but still useful wiki functionality in it and we actually put a lot of our evergreen client facing documentation in there so they can be involved in it. And then I will say for some clients we actually go into their knowledge management systems and either build or transport our stuff in there. Yes, so like one of our clients is super duper into Microsoft and so they have SharePoint and even though I don't really love SharePoint we have built documentation and SharePoint so that it is like, you know, accessible and everybody's cool with it and knows where to find it. And you know, in a lot of ways the collaboration is so much more important than the quality of the documentation. I hate to say that because documentation is very important but you know, people looking at it and consuming it is the key and feeling a part of it. So yeah, we will both manage it for ourselves and for our clients. That's another nice thing about Miro is that it's not internal for us. Like we can easily add clients to it and then they can own it and yeah. I mean, we've also used Lucidcharts. There's a lot of different systems that are valuable for this and one thing that's interesting just slightly side pandemic related technology changes is that everybody who made some form of online collaboration is now adding documentation to it, you know, like the ability to keep and manage documentation to it and like Lucidcharts example, like they just launched their like real-time board competitor to Miro just like last week or something. So I think there's a bunch of tools that are starting to get really good at this and Microsoft Teams has actually improved a ton in the last two years. So it's actually pretty competitive now too, I'd say. All right guys, do you wanna have any other questions? Let's go around. All right, I think we're good to wrap up. We will be sending out further communication with the recording of this webinar. Nate, if you have any closing remarks, feel free to take the mic. Oh, thank you guys, this has been great. I just think it's really valuable for a lot of organizations to start diving into this and taking this full by the horns. And if there's anything we can do to help you, let us know. Like I grabbed my event on my Calendly thing, little chat. So thank you, I appreciate it.


Everybody forced here ripping a box at 2022 dynasty baseball for William L Here we go, buddy Come on. Flatty jr. Nice five out of ten on the three or the two-color patch auto Vladimir Guerrero jr Gray young player game one of course in dynasty Appreciated William Get this one out to you in a bit


My definition friends, I hope you are doing well. It's a pleasure to be here for a new Tech Talk. So I'm your host today. Two weeks ago it was Natali, I think. This week it's me. So I'm Sebastien Blanc. Maybe you know me from the definitions, the show or from the deep dive. And today we have a really exciting topic with an awesome speaker. So without waiting anymore, let me bring to the stage Danielle. Hey Danielle, how are you? Hi Sebby, it's good to have you. I mean, thanks for having me. It's really good to see you again after Devon Nexus. Yeah, exactly. I'm doing pretty good. Okay, and where are you based again? I don't know. Yeah, sure. So I'm based in Boston in East Coast. Yeah, so today's a little bit chill. Okay. Then last week, so last week, so almost 75, almost 80. It's a pretty much a summer weather, but today's a 55, a little bit chill, like just in the weather. Yeah, yeah. Well, I'm live from South of France and I can tell you here it's summer already since two weeks, it's really hot. I have my small airco here. I turned it off because it makes a lot of sounds so it's getting really warm here. And you are going to present us a really exciting topic. Even driven autoscading using CADA and creative integration. So I'm really excited about it. Daniel, the stage is yours. I give you the screen share. I will move myself and see you at the end for the questions. Good luck. Yeah, that'd be great. Thanks for the great introduction and hello everybody and good morning, good afternoon. It depends on where you are. So today I'm going to talk a little bit about event driven autoscaling using CADA and the CADA integration. Maybe some people already heard about what CADA is, Kubernetes event driven autoscaling. And the CADA is allows you to have some less function capability. So let's get started right now. So just who am I? Just a little bit real quick. So my name is Daniel Oh, I'm working for Red Hat as a technical marketing major slash developer advocate, specialized in cloud-native runtime, for example, Quarkus, Spring Boot and Node.js. And I spend a lot of time to put cloud-native runtime application into sub-less and sub-summit with Kubernetes and slash your function. I'm also responsible CNC for investor. Tried to help a lot of people how to build the cloud-native application and architecture in one of the DevOps platform with the GitOps practice and then sub-less and sub-summit practice, et cetera. Here's a few contact information if you want to reach out to me on my Twitter and then my Vinny URL, Daniel TV, YouTube channel and then my Twitter, just feel free to reach out to me if you have any question around this technology but also CNC projects. Okay, so let's try to take one step back, understand what auto-scaling architecture looks like in Kubernetes. For example, you can have multiple Microsoft applications as a running on part on Kubernetes. For example, inventory application and catalog application. Just imagine that you're in a business application like online shopping or something like that and the order card payment. Each Microsoft application deployed on Kubernetes as a pod with the deployment manufacturer on Kubernetes. And then if you want to scale that application automatically you just define horizon to pod auto-scaler aka HPA. And each HPA resources decide when your application pod will be scaled out and in based on the resources, the CPU memory. But this is really good architecture for auto-scaling on the Kubernetes. But what if you could have external services which impact your existing running application on Kubernetes? For example, you have a prometheus put together the metric data or a Kafka source to process event-driven messaging from external system or the Azure monitor or the AWS SD monitoring or the event-driven system. So this is a bunch of stuff is a common practice and use cases that you could integrate the external services with inside the Kubernetes application. In that case, somebody auto-scaling should be what must be designed based on event-driven messaging or event-driven metrics rather than CPU memory because it takes some time to measure the metrics based on CPU and memory. So, but in order to redesign and handle their external services with your agency Microsoft's application, you could have the custom metric, custom auto-scaling infrastructure layer on top of this box. You can see you can add Amazon cloud watch metric adapter or you can have promising metric adapter or Azure monitor metric adapter. You could have multiple custom metric adapter but the problem is here, you can have only one metric at once. So some of the application, for example, inventory needed to aggregate or communicate with the symmetric data with the Amazon cloud watch rather than the Prometheus or Azure. But in that case, you can just auto-scaling the other application part, for example, order for a card related to Prometheus metric adapter which he consumed the event messaging from Kafka server. But you cannot auto-scale it immensely because you cannot enable Amazon cloud watch metric adapter at the same time. So this is just some potential problem. If you wanted to auto-scale your application based on event-driven metric rather than just standard auto-scaling based on CPU memory resources. So this is the reason why Kader was designed. So once again, the Kader is the Kubernetes event-driven auto-scaling, it's a principle and then it invented by Red Hat and Microsoft a couple of years ago and then he actually donated the CNC ever project. It is now incubated project in the last October. The current version is 2.6 and then you can go to diskkader.sh, you already combined all detail. A little bit detail about this Kader. So Kader actually allows developer to scale standard Kubernetes manifest, for example, deployment or job or existing custom resources. And there are more than almost 50 built-in scaler to handle external services, for example, Kafka from Mythos or RabbitMQ and Amazon services or Azure services like a monitor, et cetera. And then all resources will be scaled based on events message rather than just a CPU. For example, you got a bunch of the messaging from Kafka topic, the application needs to consume that messaging from Kafka topic. So you have to one criteria to scale your application based on that maturing message rather than actual the CPU memory realization on the part. But one good thing is Kader does not manipulate the data itself. And then you can also install Kader using operator or a ham chart. So with the Kader, you can improve your own scaling infrastructure. For example here, you can have a multiple scaler controller. And then the behind the scenes, the Kader scale controller actually trigger introducing horizontal part or a scalar HPA. And then you don't need to HPA resources for each application part. You can see here the middle of a side, you can define scaled object. And then each scale object just call scale controller and scale controller code to your backend HPA to scale from maybe 10 or 100 part based on event metrics. And also scale controller only handle from zero to one and one to zero. And if you need to more scale more than one part I mean the replication number HPA or intervene and then scale your application. So now you could have multiple resources and multiple external services whenever you define scaled object. So inventory application, you can have a scale object to get metrics data from AWS cloud watch. And then Kader could be integrated with the Apache Kafka for all the scaling. And then current application enable the metrics data based on the scaling with the edge or monitor. So here's a little bit detail how Kader works here. So of course Kader absolutely based on Kubernetes and then you can define scale object or scale jobs. Scale object just manage your standard object for example deployment and the job is sort of more Apache the job, something like that. And then the message workload from scale to one and zero to one. And then so behind the CRO dimension here so HPA you can use the Kader or the scalar actually called to horizontal or scale to scale your application like a zero to one one to zero. Okay, so here's a quick example. How to define scaled object. And for example, here is the one importing here such as the minimum replication count and the maximum replication count. And then what is the trigger? So for example here, so I want to all scale my application based on the Kafka source. So that's why I set it at the example as a Kafka type and then you can specify the Kafka servers detail. For example, bootstrap server you are like a service name and the full name in the consumer group and the topic name. And this is all I need for Kafka source to all scale my application based on the metric which comes from the Kafka server. So what about the server less or scaling? So why we need to talk about server less in this moment? So a lot of people saying event driven application really feelable in the server less because the server less application just scale up, scale and down depends on the network traffic. And then which means all about event driven application just like a server less. So if you want to scaling server less application as a part of an event driven application, how do we do that? So one of the interesting project maybe you already know that K native. So K native is built on Kubernetes and then K native allows developer to manage and deploy your application as K native service which he provide exactly same capability almost similar capability like a server less just like a lambda. But here the two some of the differentiated between Kater and K native. So for example here, the Kater only scale standard Kubernetes resources like a deployment or part or something like that. But K native it deploy different resources like a K native services. It's not standard services, it's not standard deployment. And then the Kater just keep monitoring your application status and then just scale out. But the K native they have own order scalar not HEPA their own K native scalar. And then that scalar trigger the application scaling like a from zero to one or one to zero. That's why we have we could say put and push model. And there are a few more things I'm gonna really explain in a next second demo here. So I'm gonna showcase four different demo today but my Kubernetes like open to the cluster just like some issue. So let me try to read log in in a minute but if you I cannot log in my open to the cluster but don't worry about that I actually create the related video. So maybe I can play the video and showcase how the demo works it. So the first is case. So we're gonna do try to order scale the standard application based on HEPA using CPU or our memory utilization but this is not event-driven order scaling. And with the reason why I wanna try to showcase it's really helpful to understand what difference thing between event-driven order scaling versus just the standard order scaling even if the application consume the mass event messaging from Kafka topic. Okay, so let's go into the demo and here to my open to the cluster. Okay, here we go. Oh, thank God.  And then here's a cater as I mentioned earlier you can install cater as operator just like I did it or you can install cater using ham chart. So I use operator and this is up to the serverless based on Knative. So with that you can deploy application as a serverless. So I already installed three operator and then go to developer console. Developer console. I already create the Kafka topic in my project, the first project here. So Kafka dash HPA. And then let me try to log in this open to the cluster from my local environment. Okay, luckily open to provide the login token. And then, okay, here we go. I just log in my local host and then here is my current project Kafka HPA, which is good. Okay, so I just, I already installed to save my demo time my Kafka topic here. The topic name is my topic. The cluster here you can see the jukey per and then here's my Kafka topic with the three, the high availability pause. Okay, so go to my terminal and then I'm gonna open my application here. So here's my first, I'm gonna make it bigger. It'll be better for you hopefully. So here's my Quarkus application. So the Quarkus application just in case you never ever heard about the Quarkus workforce Quarkus Kubernetes native Java framework is really fitting the cloud every application development but also serverless application because Quarkus provide a lot of developer experience feature, for example, live coding and the continued testing and demo services which are also used being up your container image automatically, for example, database in single sign on and then a key clock single sign on database and then the messaging broker and a lot of the integration container automatically stand up. And also the Quarkus provide two different build strategy one board just in compile like creating job file you can running on job file on top of the JPM and the other one is to provide the native compilation which allows developer to packaging application and running without JPM because this is based on ahead of time strategy and the running on some train VM actually grow VM which is make a super fast response and start of time as well as tiny memory footprint. So this is my sample application to consume the event messaging from Kafka topic the topic name is my topic. It's a pretty simple, if you have some experience to develop reactive application based on like a spring boot there are some bunch of different methods and API you have to implement on spring react with totally different architecture or development practice compared to spring boot application. But the Quarkus are one of the great and the beauty of the Quarkus you can develop imperative application as well as a reactive application at same method and then you just need to write in a proper annotation which he make your method in the class for imperative application or reactive application. So for example, you can see income annotation it allows this method, a reasonable method just consume the event-driven messaging from my topic the topic name from my Kafka. It's really simple and the other application pretty simple I just print out the messaging from the record and then here's my resources and then there are a bunch of resources here. So first of all, I'm gonna deploy this application to my OpenShift cluster. To do that, you can use a Maven command line like a Maven or Gradle but today I'm gonna use a Quarkus CLI. Quarkus CLI is a pretty simple for developer you don't need to remember all Maven command line on parameters and in arguments the Quarkus CLI give you all the complete functions as a range that are pretty much easy and good developer experience for you. So I'm gonna build the Quarkus application I'm gonna skill unit test for this time and then it automatically packaging oh yeah, I need to go to write directory. Okay, so I'm gonna Quarkus build it will build my application like a Java app first and then in order to containerize the application using Docker or PubMed and then lastly, it will push the containerized image into containerized. In this case, we're gonna push the image into integrate containerized inside of the cluster but you can also push that image into external container registry, registry for example, Docker Hub or Query.io or Google container registry, et cetera. So, and then in last step the open-shift try to pull the container image and then just running on one of the available worker just like a Kubernetes feature. So, and then you can see there are multiple steps how to containerize this application. When you go back to here and then there are already generated Docker file which is one of the good feature of the Quarkus framework when you generate the Quarkus project your Quarkus CLI will download from the code that Quarkus IO and these Docker file automatically generated to build your application as a container just in case for the JVM or native, et cetera. Okay, let's go back to here. I just view success and then here we go. My application Quarkus is running and then go to view logs. You can see, so my topic is inelible. Here's the Quarkus race version 292 and there are a bunch of extension like a Kafka client and then like deploy to Kubernetes and then in the reactive application to reactive messaging stuff. So now one thing I need to do is to just you can see that I can manually scale and scale down. So you know the auto scaling I need to set it up the auto scaling here the Quarkus and then like a minimum one and then make sure on 10 and CPU realize a percent like a 75% which is a pretty normal use case. I just set it up and go back to console you can now see the arrow is gone which means this part will be auto scale by Kubernetes and not me like a human. Okay, so back to the ID tool. I just created a few of the job YAML file. This is the actually run the Kafka produce performance test batch screw which already if it is inside the Kafka servers I just use that and then here's a bunch of the parallelism and then it will run five job to keep generating the dummy message over the 10,000 record size and then it's maybe a million messaging generated every single second. I just copy this YAML file and then go back to my official console I can just the input YAML file and back to the top of the view and then the application here is the job will be create the five and then click on one of the job file you can see the record just generate in the sense to Kafka copy and then back to the top of the view and then here to corpus and the view logs and now you can see there are so many messaging just consuming from your Kafka copy and then this application and observe here and observe here and you can metrics okay or go to resources here we go HPA now the target 75% but the current naturally it takes some time to aggregate out the utilization of a CPU it takes some time but in the meantime your corpus application actually keep consuming and processing the message maybe sometimes it will end up with like a latency for the end user it's speeders so it takes some time to all the scale this application and then just give us a moment and then it will scale out so meantime let's go back to slide there and adjust to remove on the next use cases here the second use case we're gonna redesign this auto scaling based on Kater as you can see now we have a Kater here and Kater just pull the metric and from a Kafka copy and then in the end Kater trigger the application auto scaling specifically Kubernetes deployment so this is based on event driven we're not gonna scale based on CPU or memory realization so let's go to that demo as well so here is the application still just one part which means it takes some time to scale out based on CPU memory realization let's switch another project Kater the Kafka Kater I also create the same Kafka topic here and then when you go to the application and here's the same application but I'm gonna use this YAML file to set it up the Kafka topic and then the same application so because I will say the Kater only impact the standard Kubernetes resources for example, deployment so I just create a new deployment here back to here and then needed to create a new scale object and the same name is the EDA our deployment name, Quarkus EDA demo just like here and then you can actually change this part just to represent the Quarkus of which.io and on time equal Quarkus okay now we can see that and then I'm gonna create that auto scaling scale object and then once I create it, automatically scale down to zero because there's no network traffic at this moment so that's why there's no event driven messaging so just scale down to zero just like happening and then I'm gonna use the same load job YAML file based on the Kafka project performance testing here and just create that and then back to the topology and it will start and then pull deeper on the application start and then click on the messaging just starting generate and send it to Kafka topic and then back to the topology view and it will scale up soon in the meantime, let's go back to our Kafka HPA project as you can see, the job is done and then our Quarkus is scale to 10 so but it's already done already done all the load testing but it's still in scale out to 10 and you go to logs file and then it will still processing application because it takes some time to scale out and it also takes some time to scale in as well so go to auto scalar HPA now you can see the current is only 2% which means it's already done to scale out and now it takes some time to scale in after some time period okay, so try to back to the Kafka Cater and now you can see it's already scale out to 10 it's pretty much faster than just using HPA so this is the actual event driven or scaling on Kubernetes plus Cater and now we go back to and in the end one more thing in the end, when the job is done and the application will be scaled down to zero based on Cater but when you go back to this namespace based on HPA it will be scaled down to one, not zero that's the one of a big different thing and also the how much time we needed to scale out and constantly scale down that's another big different thing between only HPA and Cater okay, move on to the next use case and back to the slide where so next case is a sublass and the sublass as I already mentioned here so Cater, so when you go to the right-hand side this is a new designed architecture so we have a Kafka topic here and then here is that we need to create the Kafka source which is one of the integrated feature KNEM eventing with the Kafka so when you create the Kafka source so Kafka message just sync into Kafka source and then we send it to actual application which is your KNEM services and then the KNEM auto scaler can manually our KNEM service and then it will decide when these services will be scaled up and down and then so one of the good thing is you can handle cloud event messaging so for example, you got a lot of different types of the messaging format for example, I want to use JSON format I want to use the binary format I want to use like a protocol type format to manage my evangelism messaging but you sometimes need to put together the old application which you need to use different messaging format it's a pretty complicated to handle all kinds of stuff at the same time so cloud event was designed for handling and they provide a standard messaging format regardless of your application runtime or your messaging server so cloud event really good specifically cloud network district environment to manage multiple types of event to deliver architecture or tools but the problem is you have to change your application code to consume cloud event messaging so this is the one of the caveat when you use KNEM eventing to manage a cloud event and then let's go get back to the demo and then how it works this kind of stuff okay, so I'm going to switch to another project here so and you go to the one simple Java application you can see just the cloud event but just simple event stream and then the same thing the just pre-down resources and then go to application and here is the, we're going to deploy to KNEM of the above that in the previous project you can see we're going to deploy to OpenShift but now just a new property here we're going to deploy to not this one here we go so we're going to deploy KNEM which means this application deployed to as KNEM service with the Quarkus this is really pretty good feature for developer to deploy using application to as KNEM services okay, so there's a whole bunch of the application property here to deploy this application to OpenShift so I'm going to switch it to another project like a K.NETIF, a Kafka K.NETIF as the same I already installed the Kafka topic here and then I needed to change my project to Apka-KNETIF and then also change it to project here and then I'm going to build and deploy this application here we go and then it's almost the same process so we're going to build this application as a job file I'm not going to try to use the name of the compilation at this moment but if you need a more high performance result to deploy application, specifically serverless I would pre-suggest to use the name of the compilation but it really will take some time longer because once we packaging application we need to create the executable file natively and then packaging container so it really will take some time so in the reality practice you might need to add the name of the compilation process as a part of your GitOps pipeline or DevOps pipeline rather than every single time you do whenever you change the code on your local environment and then once you redeploy this application to OpenShift-Kubernetes you combine a little bit different icon on OpenShift-DevConsole which you'll represent this is the not normal application but it's more like K-Nav serverless application okay I just deployed that and back to the here so now we have a new application a little bit different and then you can see here is K-Nav services and here's a revision maybe you can change a little bit revision to showcase this is a Quarkus application not Node.js or not a Python all right, so now with Quarkus then you go to a view logs and then now we can see the same here is just the same 292 version and then running on JVM same maybe dependency we have okay so the one interesting part we need to do a three second to start off when you have an average compilation it may be a maybe 30 millisecond start off something like that okay so back to topology view now I gotta go back to my ID tool and then here is the one thing I have to do here I need to add a Kafka source as I mentioned earlier and then back to the here and in the meantime your application all automatically terminated which is you can check the same behavior of serverless like Amazon Render the default time period scale down to zero is 30 seconds you can change that like a one minute or even 15 seconds I never ever tried invoke the application in the meantime that's why this application terminating and it will be a scale down to zero just like here and then I'm gonna add the Kafka source which he consumed events messaging from Kafka topic and it will link to K-nav services here so Quarkus EDA K-nav demo which is the same service name as my serverless here and back to topology view now you can see the Kafka source is the link to your application and then I'm gonna to back to the my ID tool I'm gonna use the same performance load script and then I just create that and then it automatically start up but you already saw that the automatically start up because I just tested a couple I just tested a couple minutes ago but I just started this definition talk which means my Kafka topic actually still a bunch of the advantage of dummy message it's automatically just send it to Kafka source and then Kafka source just send it back to the my serverless function in Quarkus that's why the application automatically start up when I added the Kafka source here and then go back to here and then click on the view logs and you can find a bunch of the event message keep consuming from Kafka topic Okay, so the one interesting part here you can see just only one part so whatever you send the messaging how much message you wanna send it to but it already scale zero to one and then it's sometimes overflowing your part or show like a little latency to process like some web rendering or so return your RESTful API or something like that So let's go back to quick chat to HPA just if we scale down as you can see now it's scaled down to one, just one part here and then go to Kafka with the Kata and now you can see there's no running part so two different things based on HPA and Kata and now we have go back to Kafka with the Kata it's still one part and then still the job is running it will generate a five million event messaging every single second it will send it to Kafka topic and then it will consume through Kafka source into our Kata service application based on Quarkus it takes some time to consume a five million message and it will eventually scale down to zero so now I'm gonna back to my slide deck and then go to the last use case which really I wanna showcase today so what about event-driven serverless auto scaling so previously it's not technically event-driven because even though it's consuming but not like scaling the multiple serverless application so here is our design box project integrate Kata and KNATIVE some people say oh KNATIVE a little bit competitive thing with the Kata because Kata auto scaling application KNATIVE auto scaling application but KNATIVE a little bit more focused on serverless and Kata just focused on the normal application but the auto scaling perspective the two project provide the same capability even behind the scene you use different auto scaler and different algorithm and mechanism but what if we could integrate the Kata and KNATIVE and then provide a more great feature for example Kata can be used auto scale KNATIVE event infrastructure here is KNATIVE eventing source or a channel and in the end it will auto scale the infrastructure itself and then the application as well and then we gotta still working on this project by Red Hat and then Microsoft and then a lot of the vendors and individual contributor and then one of the goal of the Kata and KNATIVE integration to Kata in the end scale KNATIVE service itself just like with auto scaling normal deployment part so here to finally redesign an ultimate goal auto scaling event driven application on top of the Kubernetes with Kata and KNATIVE really complicated maybe you feel but there's just a point is you can have a two compound here KNATIVE Kata so Kata are responsible for the scraps of event the metric from Kafka and then just scale the Kafka source I mean this is the eventing metric infrastructure and then it based on that increasing the Kafka source is automatically scale your KNATIVE service based on KNATIVE auto scale so this is really good so previously version we actually the K Kafka source deploy as part but the latest version of KNATIVE and then the KNATIVE source not going to deploy as part is just interior in the Kafka infrastructure but in the future of it in a future roadmap it will be come back to deploy as part once again so let's try go back to our demo environment and then try to deploy Kata and KNATIVE at the same time okay I'm going to switch my last name space Kafka dash Kata dash KNATIVE here and we will so three Kafka infrastructure here and then back to my IDE and the one thing I need to change in my application here so I'm going to change my image group which is a name space Kafka Kata KNATIVE in the huge of bunch of the my KNATIVE configuration which is actually related to Kata stuff so this is the actual how to scaling and how to the scale up and the target and the min max, et cetera and then back to my terminal I'm going to change my project Kafka KNATIVE Kata first and KNATIVE okay now here we go and then I'm going to just run Kata's bill unit test here and then just remember that the previously and back to the here so previously into Kata and Kafka project we actually create the scale scale object manually when you just open import YAML editor and then we just paste the Kafka scale object manually and it will end up with increasing your application based on Kata controller but we did the Quarkus annotation I want to show that here it's automatically scaled up set up the scaled object automatically when you deploy this application into Kafka Kata KNATIVE project back to here then take a look back to our terminal window so this is the the same process just packaging application and then now we're going to you can see multiple spare which is based on Docker file to packaging application as a container and then we're going to push that image into integral containerized to here and then just done and then we just deploy the application as KNATIVE services or less okay and now we have an application and now we also create the Kafka source for the KNATIVE and then the one different thing is here let's go back to here and then I'm going to make it bigger and then there's the service name here and then here is the Kata or a scaling annotation so this is your make this Kafka source will be scaled based on Kata now with that annotation I just create that back to here and now the application here and then application automatically already starting and then go to log4j and drop file in the meantime once again I already testing just a couple of minutes ago so that's why the application automatically scale so try to once again to create the job and then it's super fast or scaling even this is just some less but when you go to here it's three parts scale and then we have a new job in the file and back to here to keep sending messaging to the Kafka topic and then it automatically and it's really flexibly scale out and in based on evangelism messaging so I'm going to really be changing the label once again showcase the quarter thing one time all right and you can see the part is now four but here so now you can see the part is nine and this is a really bit super fast but in the meantime to scale down to five and scale up to scale out and it's a really bit flexibly that depends on how much event messaging comes from your Kafka topic not just scale out just once really be differently handling by HPA so this is the how to redesign our order scaling for evangelism application on the Kubernetes all right so I'm going to just summarize today topic and then go back to my demo environment how do we scale down to zero and I'm going to more than happy to address any question so here's Dean K-Nav and K-DAR Sandbox to integration effort you can also use the Kafka source so today I will show that because Kafka one of the popular common event driven architecture event driven infrastructure and then you can use the AWS SQS and then Redis Stream and then RevitMK broker and then just to there are so many related technical video and the topics I already push it into my YouTube channel here to be in URL DanieloTV you can scan the QR code feel free to watch it and keep running and also don't hesitate add some comment or suggestion on my YouTube channel and feel free to subscribe to it as well it really helpful for me to keep creating valuable and technical tutorial and demos so here's your full take away from today so K-DAR is Kubernetes event driven autoscaling it's super simple and then K-DAR just pull model and K-Nav pushing model and then so K-DAR only influence standard Kubernetes resources but K-Native only deploy K-Nav services unique resources rather than deployment or a job that's like that and then K-DAR autoscaling K-Nav eventing infrastructure which is integration with the K-Native and based on event autoscaling K-DAR annotation okay so that's what I have today now we gotta go back to demo and then you can see the pod scale down to five and the one last thing go back to Kafka K-Native then is still colony one which means it will eventually scale down to zero okay so I'm gonna give us a moment ask us some questions and then the question here Hey, thank you Daniel that was awesome and there was one question not directly related to what you showed but was more question about Quarkus regarding Springboard so I gave some answers and especially especially if you want to if you're doing scale to zero autoscaling to zero and you want a really fast startup time when your first event comes in then you really want a fast startup time and that's another use case where you really want to use Quarkus in combination with K-Native of K-DAR so that's Yeah, absolutely so as long as you wanna use a neighbor cooperation with this new architecture for example K-DAR plus K-Native with a native cooperation with Quarkus it's much faster than a startup time when the new message comes first yeah, that's really a really good point and that's what we want to showcase today but it takes some time to have a neighbor cooperation arrive at that and well I have a question about K-DAR and it comes with a whole set of scalers that are already available but you can also write your own custom specific trigger scaler I don't know what the correct name is Yeah, you can actually made that but so the one thing is as I mentioned earlier you can create the custom scalar metric for the K-DAR itself but you cannot use that custom thing for K-Native and K-DAR in a moment Yeah, okay, that makes sense I really like the four different use cases I guess you have GitHub repo with all those examples Sure, yeah Maybe you can put it in the private chat here in the ReStream and I share it and then we will have to give the channel back but if you have a last question now is the moment in the audience so don't be shy and ask your question now of course the replay will be available the URL that you see in YouTube is also the URL of the replay I will put down the GitHub repo in the beginning I also put Daniel's Twitter channel so if you have any other question that pops up later don't bother, just send in a tweet and you will be more than happy to reply to you Let me see, no other questions? No, okay, we are a bit over time so I have to give the channel back but again, it was really awesome really four different really comprehensive use cases that really give the complete panel of how we can modern autoscaling with events stuff and with awesome projects like K-DAR that I didn't knew really well that I will play with and K-Native which is one of my preferred technology out there in the Kubernetes ecosystem Hey, Daniel, thank you so, so much we will meet in a few weeks in Rio in Poland for Demax Poland, that will be awesome I'm really looking forward to that in the meantime, everyone, thank you everyone for attending, see you again and I think next week will be the show not with Mia's host but with Anna I think awesome guest and the week after we will be back or end of the month we will be back for another tech talk so until then, please stay safe enjoy the rest of your day and see you later bye bye everyone bye