Latest / What the Hoot! / End-to-End Visibility: The Foundation for Modern Middleware and AI

Transcript

End-to-End Visibility: The Foundation for Modern Middleware and AI · What the Hoot!

• 0:10
  SPEAKER_01: We are excited to have Mohan Krishna to our first podcast for the Enterprise Integration Podcast series.
• 0:16
  SPEAKER_01: And we wanted to interview Mohan after seeing his educational YouTube training series.
• 0:20
  SPEAKER_01: And today we are discussing from manual administrators to mission controllers how to manage the digital nervous system.
• 0:28
  SPEAKER_01: So, Mohan, please tell us about yourself, your background, how you got into the middleware world, and what led you to start sharing your knowledge with others on YouTube.
• 0:37
  SPEAKER_00: Hi, Mike.
• 0:38
  SPEAKER_00: I'm really glad to be here with you.
• 0:41
  SPEAKER_00: Well, my name is Mohan, and in the industry, I'm having almost 14 years of experience where I handle really critical solutions for many enterprises.
• 0:54
  SPEAKER_00: And you know, uh I have seen the worlds like uh the insurance world, the retail world, the banking world, financial world, and you know how they are operating their uh messaging streams, what are the loopholes there?
• 1:10
  SPEAKER_00: So these are the areas where I have worked in my experience.
• 1:15
  SPEAKER_00: And in addition, I believe uh one statement from Swami Vivekananda like uh, you know, uh if you share money, it will decrease, but if you share your knowledge, it will increase.
• 1:27
  SPEAKER_00: And I strongly believe in that, and that's where the foundation of my channel also.
• 1:34
  SPEAKER_00: Yeah, that sells something from my side.
• 1:36
  SPEAKER_01: I love it.
• 1:36
  SPEAKER_01: It's one of the best gifts in the world to share knowledge.
• 1:39
  SPEAKER_01: Um, you know, as far as the unified command problem, I'd say that most enterprise MQ admins today aren't just managing MQ, they're jumping between MQ Explorer, cost consoles, cloud monitoring dashboards, and CLI sessions just get you know a complete picture of what's happening.
• 1:59
  SPEAKER_01: So, in your experience, what does that tool fragmentation actually cause an organization, not just in time, but in risk?
• 2:08
  SPEAKER_01: Um, and really, what does a truly unified operational approach look like in practice?
• 2:17
  SPEAKER_00: Well, that's a great question.
• 2:20
  SPEAKER_00: I think you are uh firing me with your first question, right?
• 2:25
  SPEAKER_00: And uh, in my opinion, right, uh, this fragmentation is really very underestimated, unique problem for every organization.
• 2:36
  SPEAKER_00: And uh, you know, whenever a critical issue has been triggered, so these days, MQ Art mains or Kafka Art mains, they are shifting from one dashboard to another dashboard to trace out the entire route of the data.
• 2:55
  SPEAKER_00: Because if the data is lost, it's ultimately business loss, right?
• 2:59
  SPEAKER_00: And uh definitely uh there should be an improvement.
• 3:04
  SPEAKER_00: Like when the issue happened, it should not state, yes, my tool is good, my platform is good, my infra is good.
• 3:12
  SPEAKER_00: So everyone looks in their own perspective, but there should be some place where dots should be connected so to find out the entire trace where something went wrong.
• 3:23
  SPEAKER_00: I think uh I can come up with an example which I faced in my earlier career.
• 3:29
  SPEAKER_00: So I was working for a paper mill company which is based off a different country, which you know uh manufactured the paper and supplied the bio for energy to the entire country.
• 3:42
  SPEAKER_00: I started my career with the company as a middleware administrator, especially with NP.
• 3:49
  SPEAKER_00: Right?
• 3:49
  SPEAKER_00: I think I was in uh shift, I think it was early morning, and all of a sudden there was a critical P1 incident hit my door.
• 3:58
  SPEAKER_00: And you know, the incident, it says like there is a traffic jump in the paper factory, middleware team, please come into picture.
• 4:07
  SPEAKER_00: That's all, no technical details.
• 4:09
  SPEAKER_00: And I was in a bit confusion state.
• 4:12
  SPEAKER_00: I was sitting thousands of miles away from the factory.
• 4:15
  SPEAKER_00: How can I clear the traffic there?
• 4:17
  SPEAKER_00: Right, so there is some missing, missing dot, and um command center accepted as a critical incident, and CIOs are in the call, SVPs are in the call, all the line of business which are impacted, everyone is in the call, and I had no clue how to deal with that.
• 4:33
  SPEAKER_00: Then immediately I picked my phone, I called to my technical leader at that time.
• 4:38
  SPEAKER_00: He was a very nice guy, and you know, he simply told me open service now tool, there is a configuration item, go to the application service, then match that with the inventory, go to the queue manager, find out the depth, and uh there I found the issue.
• 4:54
  SPEAKER_00: It was some configuration uh disabled instead of enabled.
• 5:00
  SPEAKER_00: So, what happened?
• 5:01
  SPEAKER_00: That queue is supplying an information to the mission where that will load the paper, bundle of paper to the truck, and then truck should leave.
• 5:11
  SPEAKER_00: That's the entire business law.
• 5:13
  SPEAKER_00: So, here in MQ, data got stuck, mission stuck, truck stuck, and there is a jump, traffic jump.
• 5:20
  SPEAKER_00: Right?
• 5:21
  SPEAKER_00: This was like a really eye-opener.
• 5:23
  SPEAKER_00: So the thing is when you are in a position to connect the dots, instead of stripping to one tool, right?
• 5:32
  SPEAKER_00: That's where you can solve the business problem.
• 5:35
  SPEAKER_00: So that's what you know, it was uh uh my early learning with uh my first degree one.
• 5:43
  SPEAKER_01: Uh drone to the fire early in that early that day, huh?
• 5:47
  SPEAKER_01: Um, yeah, so it that having that unified view, it would be critical.
• 5:52
  SPEAKER_01: Um it would help then.
• 5:53
  SPEAKER_01: Um, you know, I in your YouTube videos, and you have so much content online, uh, you you've covered a lot of distributed queuing um quite extensively, actually.
• 6:03
  SPEAKER_01: But the reality for a lot of organizations today is that a single transaction might start with IBM Q.
• 6:10
  SPEAKER_01: It'll pass through a file stream and terminate in an autonomous queue.
• 6:15
  SPEAKER_01: How critical is it for modern admins to be able to trace that single message across every hop, regardless of vendor protocol?
• 6:23
  SPEAKER_01: Um, and how far away are most organizations from actually achieving that?
• 6:30
  SPEAKER_00: Well, that's another fantastic question that Hello Transfer.
• 6:34
  SPEAKER_00: And you know, in my opinion, uh, you know, actually uh organizations are in a way that are adopting this kind of transformation.
• 6:44
  SPEAKER_00: Like in earlier days, let's say around uh 10 years ago, you know, the organizations are in a platform-centric uh model, just they used to work like that, but now organizations are adapting in such a way that transaction-centric uh uh operations, so that if one transaction stuck in one hub, right?
• 7:09
  SPEAKER_00: It the the particular admin who is working in that hub, he should have some visibility to Latin to look at the next spot.
• 7:18
  SPEAKER_00: Yes, this is where the problem is.
• 7:21
  SPEAKER_00: So that the entire transaction, the entire transition between the engineers, uh, there would be a flow to find out the issue.
• 7:30
  SPEAKER_00: For example, let's say there is a transaction started from a source database.
• 7:34
  SPEAKER_00: Now let's say that came to MQ, that's came to Kafka, and that's came to some uh sync connector again.
• 7:41
  SPEAKER_00: That went to some uh sync database where the consumer has to connect.
• 7:46
  SPEAKER_00: The publisher says, Hey, I send the data, but the consumer says, No, I have not received the data.
• 7:52
  SPEAKER_00: So here, you know, the NQ team says my queues are good.
• 7:57
  SPEAKER_00: Kafka team says, my platform is good, infra team says my infrastructure is good.
• 8:03
  SPEAKER_00: So now where is the problem?
• 8:06
  SPEAKER_00: And the big gap, in my opinion, I see is the Kafka world can't see the NQ world, NQ world can't see the infra world.
• 8:15
  SPEAKER_00: So there is a big gap among the engineers so that they can't come to one particular strike line to find out the issue.
• 8:23
  SPEAKER_00: When this visibility is there with certain kind of protocols, then you know people can suggest this can go wrong, this can go wrong, this is where the issue is, so that the gap can be fulfilled.
• 8:37
  SPEAKER_00: But you know, I am seeing the organizations are really adapting this approach, and this can give the engineers end to end visibility, especially to decrease the SLA in resolving a particular critical issue that will you know help companies uh to prevent off lossing their revenues.
• 8:56
  SPEAKER_01: Makes a lot of sense to me.
• 8:58
  SPEAKER_01: Um I'd like to move on though, because because you know most monitoring tools in MQ environments are essentially smoke alarms.
• 9:06
  SPEAKER_01: Um, they tell you when something's wrong, but they don't tell you or let you don't really let you do anything about it, right?
• 9:15
  SPEAKER_01: Um, how much does this change the operational dynamic when an admin can not only see the stuck message but act on it directly, moving in it, editing headers, clearing a queue without having to log into a secure terminal?
• 9:30
  SPEAKER_01: Is that a capability most organizations are ready for culturally?
• 9:37
  SPEAKER_00: Well, I think uh the answer would be yes.
• 9:43
  SPEAKER_00: The problem is, you know, when I started my career, right, uh I was having just uh some kind of reading access and particular development environment, but not a full-fledged uh access and the production operations.
• 9:57
  SPEAKER_00: It's because I was very new to the industry and handling production system for a junior resource, yes, definitely some kind of uh uh risk elements to the leadership, right?
• 10:10
  SPEAKER_00: So it's an engineer responsibility, he has to give a confidence to the leadership.
• 10:14
  SPEAKER_00: If you give me this uh end-to-end in my hand, I can handle it in a positive way where there would be no business loss.
• 10:22
  SPEAKER_00: So engineer has to prove uh from uh you know, uh by giving that confidence to the leadership, and leadership has to trust their engineers also.
• 10:32
  SPEAKER_00: Yes, if we can give this instance to this person, this can go smooth.
• 10:37
  SPEAKER_00: So the thing is that whatever the privileged access that's been granted, it should not be misused by the engineers.
• 10:45
  SPEAKER_00: If it's find out that it's a misused and no protocol, no standard, no rule has been followed, definitely there would be a red flag which can cause a portion to the business and a portion to the leadership, right?
• 10:59
  SPEAKER_00: So there should be a governanced approach.
• 11:02
  SPEAKER_00: Like once an engineer started fresh you on one particular instance, he should start with the lawyer environment.
• 11:10
  SPEAKER_00: Once he got the contents, then he should be in a position to adapt the entire portfolio, including production.
• 11:17
  SPEAKER_00: The reason is if uh you are capable of solving the issue, but if our hands are uh linefolded with access issues, there would be again a delay in terms of resolving the issues, right?
• 11:32
  SPEAKER_00: So there should be a proper governance model implemented in every team and every organization.
• 11:39
  SPEAKER_00: This thing should be with this particular team, and he should have this kind of access so that issue can be prevented.
• 11:46
  SPEAKER_00: And again, it's engineer's responsibility that it has to go in a positive way.
• 11:52
  SPEAKER_00: If that's cool, yes.
• 11:54
  SPEAKER_00: So issues can be prevented in a proactive way.
• 11:59
  SPEAKER_01: Yeah, I mean, I couldn't agree more.
• 12:01
  SPEAKER_01: Go on.
• 12:02
  SPEAKER_01: Um, if only things were more that practical.
• 12:05
  SPEAKER_00: Um, so it's a it's a more like a practical problem, right?
• 12:09
  SPEAKER_00: Uh so the leadership has to trust the engineer, and the engineer has to uh give that positive impact because uh every organization runs on the engineer's positive impact how they are reacting.
• 12:21
  SPEAKER_00: Otherwise, you know, uh uh especially for mission critical things, right?
• 12:25
  SPEAKER_00: Uh it has to go in that way.
• 12:28
  SPEAKER_01: I love that you brought up mission critical because I think that one of the most dangerous scenarios in middleware operations is when every infrastructure metric looks healthy, right?
• 12:38
  SPEAKER_01: Channels are up, brokers are running, but that critical B2B transaction is silently stalled.
• 12:45
  SPEAKER_01: Um, how do you help admit administrators make that, you know, the mental shift from monitoring infrastructure uptime to protecting business outcomes and the SLA performances behind them?
• 12:57
  SPEAKER_01: And what does that conversation look like with leadership?
• 13:01
  SPEAKER_00: Uh well, I think that's a great question.
• 13:04
  SPEAKER_00: See, uh, in my opinion, the thing is whenever some critical issue happens, first of all, the leadership will not ask you, is the platform is up, is the infra is up, is my cloud service provider doing good service?
• 13:17
  SPEAKER_00: No, they do not look in that way.
• 13:20
  SPEAKER_00: The leadership always thinks, is my business up?
• 13:22
  SPEAKER_00: Is there a revenue loss?
• 13:24
  SPEAKER_00: Is my customers are uh uh crying about the issue?
• 13:28
  SPEAKER_00: That's what the leadership is going to look, right?
• 13:31
  SPEAKER_00: And all these are directly and indirectly linked with all your platform and infra.
• 13:38
  SPEAKER_00: The thing is, when you are adopting any kind of middleware platform, right?
• 13:43
  SPEAKER_00: Especially that can be EMQ or that can be enterprise Kafka, whatever it is.
• 13:48
  SPEAKER_00: First of all, these kind of vendor products, right?
• 13:52
  SPEAKER_00: They come with certain protocols, like this much infra is needed, like I need this much CPU, I need this much uh RAM, I need this much of uh computing resources, this much of networking, this much of storage, this much of our so they will give certain protocols, and when we are adapting that particular tool, right, that tool has to fit.
• 14:16
  SPEAKER_00: I mean, that infra has to be ready.
• 14:18
  SPEAKER_00: The organization should be in a position to provide that infra.
• 14:22
  SPEAKER_00: Then these kind of critical issues and the conflict between the tool, I mean, between the platform and then the infra can be reduced, right?
• 14:32
  SPEAKER_00: If uh organization infra says, no, we are not we can't provide that kind of resources, then instead of adapting that particular tool for your use case, we have to go what is the tool that can adopt for the infrastructure.
• 14:47
  SPEAKER_00: So when these baselines, before we sign up, if when with these baselines are strictly followed, then uh there would not be infrain and business rate.
• 14:59
  SPEAKER_00: So infra green business rate will go in a situation where there is a conflict between your platform and then the infrayer chosen.
• 15:07
  SPEAKER_00: If that can be avoided, these issues would not occur, in my opinion.
• 15:11
  SPEAKER_01: Makes sense.
• 15:14
  SPEAKER_01: I think there's a uh a real conversation happening right now about AI-driven automation in middleware operations as AI is bleeding into every conversation, but uh natural language queries, automated read and re uh remake uh remediate remediation, excuse me, uh intelligent uh pattern detection, you know.
• 15:33
  SPEAKER_01: Do you believe that level of AI existence will eventually replace the need for junior admins to master those fundamentals?
• 15:42
  SPEAKER_01: You know, MQSC commands, channel configuration, DLQ management, or or will simply that you know, will deep platform knowledge always be the prerequisite for anyone operating in these environments today?
• 15:58
  SPEAKER_00: Well, that's a very common question where every organization is now uh adapting, right?
• 16:05
  SPEAKER_00: Uh but if you take my personal opinion, okay, let me switch the context in this way.
• 16:12
  SPEAKER_00: Before I start about discussing about AI, right?
• 16:15
  SPEAKER_00: Let me take one particular situation.
• 16:17
  SPEAKER_00: Let's assume there are two countries where you know, let's say some war is going on.
• 16:23
  SPEAKER_00: Let's say country one bombed against country two, and let's assume country two defensive system has taken their AI help.
• 16:33
  SPEAKER_00: Hey, uh, we want to take the retaliation against country one.
• 16:36
  SPEAKER_00: How do I do that?
• 16:38
  SPEAKER_00: So, most cases the AI will suggest you can fire an atom bomb against country one so that you will be your retaliation can be done.
• 16:46
  SPEAKER_00: That's what AI can do.
• 16:48
  SPEAKER_00: But it's again human brains that they have to think about the further consequences.
• 16:54
  SPEAKER_00: Let's say if you fire an atom bomb, so what would be the human race in that country for the next 10 years, 20 years, or 50 years?
• 17:03
  SPEAKER_00: And if the Tartum bomb fired due to some mistake, it has fired in your own country, what would be the impact?
• 17:11
  SPEAKER_00: So it's again human brain that it has to think about all the consequences because uh AI can't AI can give you a straight onset for your question, but it can't think about the consequences, right?
• 17:25
  SPEAKER_00: So when we apply the same concept in the NQ platform or any Kafka platform, right?
• 17:33
  SPEAKER_00: AI will tell you AI can give you the direction.
• 17:37
  SPEAKER_00: Uh, you go in this way so that the problem can be sorted out.
• 17:40
  SPEAKER_00: But it's again, uh, you know, uh human's brain has to think is this the right direction as per my organization standard.
• 17:50
  SPEAKER_00: Based on that, the MQ admin or the platform admin, he has to take that issue, right?
• 17:57
  SPEAKER_00: The reason is uh if you know the problem where it exactly lies, it's almost 90% solved.
• 18:03
  SPEAKER_00: You have to go and fix, but whether you have to go or not, that it has to be uh decided by humans only, right?
• 18:10
  SPEAKER_00: So the thing is, uh in my opinion, AI cannot replace the engineers, but it can amplify the engineer's capability to figure out the issue in a quicker manner for a faster resolution.
• 18:25
  SPEAKER_00: That's all, yeah.
• 18:27
  SPEAKER_01: Uh, and they're just having the human element involved, right?
• 18:30
  SPEAKER_01: Is uh it's kind of necessary.
• 18:32
  SPEAKER_01: Um, plus with the contents.
• 18:35
  SPEAKER_01: So when a production out is heads uh you know war room start to spin up.
• 18:42
  SPEAKER_01: Um, what is the single biggest time waster you see over and over again?
• 18:47
  SPEAKER_01: And if you could eliminate just one part of that root cause investigation process, what would it be and why?
• 18:56
  SPEAKER_00: Okay, again, another common issue that uh daily happens in everyone's organization, right?
• 19:03
  SPEAKER_00: So the thing is, in my opinion, let's say one critical issue happened.
• 19:08
  SPEAKER_00: First of all, give the justice.
• 19:10
  SPEAKER_00: I mean, whatever the things that are there, you first give the justice, make the business up so that your leadership will be happy.
• 19:18
  SPEAKER_00: I believe justice delayed is justice denied, right?
• 19:22
  SPEAKER_00: So whatever the struggles you have with the other team, just join with them, find out the solution, give the justification so that your leadership will be happy and command central will be happy.
• 19:34
  SPEAKER_00: Now, later you start the investigation where exactly went wrong, right?
• 19:40
  SPEAKER_00: And let's say uh if you ask me what is that one point that we can eliminate, right?
• 19:45
  SPEAKER_00: I think I already answered before you choose the tool.
• 19:49
  SPEAKER_00: First of all, make sure is that tool fit for your infra or is that infra is a uh fit for your tool, right?
• 19:57
  SPEAKER_00: And second thing is uh when something wrong, uh each and every platform component is highly dependent on the infrastructure, right?
• 20:06
  SPEAKER_00: Whether the tool is running in the on-premise environment or it's a in Kubernetes environment or some cloud platform, so that base underlying infrastructure is very, very crucial, right?
• 20:18
  SPEAKER_00: So when the infrastructure team is giving you the sessions, you follow these rules and regulations while applying your while deploying your tool.
• 20:31
  SPEAKER_00: Make sure you apply that and follow all the rules and protocols so that you will not be questioned back during the real outages.
• 20:41
  SPEAKER_00: And when this has been documented in a proper way, you can have the solid evidence.
• 20:46
  SPEAKER_00: And yes, this is the instructions I have followed, but something wrong.
• 20:51
  SPEAKER_00: So that you can make a corrective action uh in the you know, in the in the next attempt.
• 20:57
  SPEAKER_00: I mean, it's not going to happen in one day because on day one, you can start with all your possible solutions, but on day two, you can notice an incident where you have no idea.
• 21:10
  SPEAKER_00: So it's like a continuous increment from day one to day two, day three, something like that.
• 21:16
  SPEAKER_00: And when you are adopting that in a positive way, these uh issues can be eliminated.
• 21:22
  SPEAKER_01: Gotta love day two operations.
• 21:24
  SPEAKER_01: Uh hindsight is always 2020, but I think that you know that first point is so is so um true.
• 21:29
  SPEAKER_01: You know, it's a two-way street.
• 21:31
  SPEAKER_01: The the tool must match the infra and the infra must match the tool, right?
• 21:34
  SPEAKER_01: Has to be a it has to be a well uh you know good fit, right?
• 21:38
  SPEAKER_01: Um question though uh on de-risking um you know modernizing.
• 21:44
  SPEAKER_01: A lot of organizations are sitting on MQ mainframe cores, they know they need to modernize, um, but they're paralyzed by the fear of a visibility blackout or that migration.
• 21:56
  SPEAKER_01: So, what's your advice for managing?
• 22:00
  SPEAKER_01: legacy and cloud native brokers side by side during a transition and and what separates the organizations that modernize successfully successfully excuse me from the ones that just simply stall out well in my opinion the most successful organization is not that eliminate directly eliminating uh the outdated one and keeping the uh latest ones but the most successful organization in my opinion is you know to have the uh existing applications which are running on legacy platforms and then uh giving the direction to the memorandization for example let's say in a platform I am using a security protocol and let's say tomorrow that's been outdated and in my organization let's say there are thousands of applications or millions of applications within the protocol so on day one itself I can't completely shut down the outdated security protocol it's high risk right the thing is it has to run with the legacy system and then you start planning building the latest security protocol and once that's been successfully deployed into our platform then you have to coordinate with your all application teams hey application team one use the security protocol application two use this one success application thing so it has to go in a sequential way and once it is uh completed i mean once all the applications are migrated to the new security systems right uh then you can shut down your old system by giving one quarter buffer and if you do not notice any issues right then you can put a plan to decommission it completely by putting another quarter buffer so that in this buffer if some application is complaining a new security protocol is not working for me so you can immediately revert back to the old security protocol so that uh there would be no outage uh when you are doing the transition uh between the legacy system and the new systems when organization follows this approach right I think uh that can be more successful uh in terms of uh without any loss in their business I completely agree I completely agree I I think that there is a a a growing push towards giving app developers more visibility and self-service access to their own middleware routes rather than routing every troubleshooting request through a you know central admin team but what are your thoughts on that shift you know what where does it genuinely improve speed and or even accountability and where does that where does that introduce risk if it's not done carefully well see I think again I will take one of my personal experience in this my favorite please share so you know when uh around I think uh 10 12 years back almost a decade back right the platformer means they extensively work on the platform where there is no visibility to the developers area and the developers they are extensively are they working on their own development area where they did not have the visibility on the platform side so here the major gap is if a developer who is generating the business data and who is publishing the data into messaging platform right if they want to see their message or if they want to see their message retention time period or if they want to see any headers of their message every time the developers they have to interact with the platform admin they have to open a ticket to them okay this is my so and so topic this is so and so queue uh can you tell me these details so developer has to sit on his own SL basis he has to give the data so there is definitely a delay right and instead if we give some kind of redo lay access to the developers on their topics where they can browse the information they can see the configuration of their data if such kind of things are there then this uh communication between the developer and the platform has been will be decreased and every time uh the solution I mean uh when you are when a developer is developing a solution right his time will be much much saved and no need to wait with the patience for the admin input right so but this has to be followed with the proper governance proper self-service like the developer for the platform he can see the topics he can see the configurations he can read the message he can browse the data but he should not delete the data he should not delete the configuration so such kind of protocols must be in place and then yes if we queue if we deliver that with a proper protocols with the kind of needed access right then this gap can be easily fulfilled and that is much needed in this uh uh modernization world much much needed bond it you know some of the most damaging outages in middleware environments aren't caused by you know hardware failures or or traffic spikes they're usually caused by an undocumented manual change that no one can trace after the fact how important is configuration governance and and audit trail discipline in preventing what I would like to call ghost outages is it something that the industry takes seriously enough so in my opinion that has to be taken very seriously because ghost outages are quite common you know uh when this git concept was not there so the thing is let's say uh if someone is doing a configuration change let's suppose there is no proper documentation there is no reviewer there is no approval let's assume just one dot which is not understandable by your platform that can lead your entire platform goes down and in order to trace that out you have to set hours and days by stopping all your uh personal life and all the other stuff right because business has to come up but if you have the proper documentation what should it and when you can trace out the document that is easy as a reference that okay this is the mistake that's been committed let's eliminate this mistake so that the system cannot so that's where this git is helping these days in many organizations you know when this git came each and every code is going to store in our repository and once you push your code to git right and someone will approve someone will review and it is going to uh cross certain stages like SIT, UAT preprod and production before it went to the business so that if some problem really happened you can easily prevent before it goes to live so documentation process definitely that should be there but you know uh trust me that's not an easy process but it's not a complex process.
• 29:43
  SPEAKER_00: It's a lengthy process where you have to sit patiently to prevent the outages.
• 29:48
  SPEAKER_00: So instead of wasting the time in the outages you make the changes now so that your life would be very peaceful.
• 29:57
  SPEAKER_00: That's what my take on that gotta get on get so as MQ administrators move into streaming environments they run into what some people call the Kafka tax you know cloud egress cause zombie topics runaway partition growth there's an argument that MQ admins with their disciplined history around message persistence and lifecycle management are actually better equipped to manage middleware fin ops than teams who can you know who came up through the Kafka native world do you do you buy that argument well I think I buy that argument and the reason is see uh this MQ I mean uh this entire messaging world has started with IBM MQ so iBM is the first company who given a solution for the messaging communication right and uh MQ designed in such a way that there is no retention policy in MQ but if a consumer consumed then message will be deleted if you compare to Kafka which is the most emerging and latest streaming platform MQ Kafka both this both target is the same they have to have communication they have to establish the communication right but MQ works on a different protocol and Kafka works on a different protocol but their ultimate goal is same right so the person who already worked on MQ right he his thought process would be if the queue is necessary then only he will create if it is not needed immediately it will be decommissioned Kafka you can create n number of topics on fly let's say if the topic is not needed uh you can't have a proper trace this is for what whether I should keep it or whether I should decommission it there is no such kind of thought process for Kafka I mean who started working directly on Kafka but the person who is uh shifting from MQ to Kafka before he makes the infra changes right he is going to think is this needed and what would be the message size that is going to publish what data that is going to come to whom it is going these kinds of thought process would be there so that the infra would be much stronger and there would be hassle free operations in Kafka so that's my opinion on it.
• 32:33
  SPEAKER_01: I completely agree um it makes sense you know thinking about your YouTube channel and and all the knowledge you've shared and the advice you've shared I I'd love to to as we start to wrap this this podcast up you know I if you can go back and give one piece of advice to an organization at the very beginning of their middleware modernization journey before they've signed any contracts or made any architectural decisions what would that be?
• 33:00
  SPEAKER_01: Well let's say if I am the CAO of the company and you know before I adapt any tool right first what I do is uh as I already said in one of the previous questions when you are adapting any tool that can be messaging platform that can be a Power PI or that can be uh whatever it is first of all you check your organization resources is the tool is going to fit my company and my company can provide the proper infra for that particular tool and let's say uh you are having VM i mean your VM TB saying no we can't provide and your uh cloud service team saying no we can't provide then my session would be that tool must have cloud native feature with the vendor right like you no need to worry about the infra let's say conflict cloud let's say IBM cloud uh uh let's say kubernetes in cloud right so you adapt that so that you no need to worry about infra so that your business uh can run once you adapt it because once you take the tool there is no way you have to move on by solving the challenges instead first you take the proper decision how to run this tool in an efficient way and then uh use that tool for your business that's my session makes sense to me Mohan you know does it fit right does the tool match the info does match the tool uh and then if I if I have to make a rhyme out of it you know I'm gonna think about the git does it fit get on git document on git does it fit um but you know I think that if we're looking ahead right um five years call it do you think IBM Q and open source messaging platforms ultimately converge do they coexist or does one eventually win over the rest um and what does that mean for engineers who are building careers on those platforms today well in my opinion there is no winning of uh any tool in this modern war they're all needed the reason yeah right so the reason is you know when I started my career as a middleware engineer is around 14 years ago right and you know I started uh listening from my seniors that uh MQ can decommission soon but still at this moment right MQ is one of the highly important tools for most of the critical and financial organization let's say you know uh JP Morgan and other investment companies extensively using IBM MQ because IBM MQ has been designed in such a way that it has to go in a batch way in a proper protocol with the vendor supported thing because if your tool is not a vendor supported then organization might think what is the risk if something goes wrong right so if you took in the perspective definitely coexistence would be there I think there is no uh some tool can win some tool can loss because every tool having their own advantages also their own limitations depending on the business to business so if you really adopt your business and if you're in a position to understand your business process then uh tools can coexist forever there's room for all then and there has to be pockets of everything uh that's why I think I see why you know what environments look like today it's it's really a modern environment includes pieces of everything.
• 36:47
  SPEAKER_01: Um but I think we I'd love to end uh today's session by with you telling us more about your YouTube channel you know what you cover who it's for where people can find you i and I'd hope that we come out of this uh with uh with a couple new subscribers to you every week anybody that listens should go and check out Mohan's podcast and YouTube channels um he extensively covers these these topics in depth um but please Mohan tell us you know what you cover who it's for and where people can find you well that's a lovely question to answer well you know my intention is very simple you know my channel starts with the name messaging tech world you know message a very very critical word and uh in this moraniation without data no one can do the business right and uh when you have certain uh information uh that can be useful to others fine let's uh share it with us that's what my motto of uh creating my channel and that's what my inspiration for making the MQ videos right and all mq related concepts are there now uh I am working in the background to have uh MQ with agent TI I am doing a foundation work for that maybe shortly uh six months down the line I will be uploading them and uh it can be useful for most of the engineers who want to understand about the criticality of the data and who want to start the journey in the messaging world and you know I already met a few of the subscribers unintentionally who come to me hey I saw your videos and I got a job in this reputed companies it was giving me more proudness and more inspiration let's work very hard to make the channel more smart that's my baseline for the channel and please keep the content coming I'm not an engineer but I enjoy myself I I know that some of my friends and colleagues have enjoyed it and even gotten jobs with your support and your help so couldn't thank you enough Mohan I'll be looking forward to every new episode um that you put on the YouTube channel but can you just let the see what what is the the YouTube channel called for our listeners it's missing equaral.
• 39:20
  SPEAKER_01: All right so you guys heard it there make sure you go give them a follow give them a like and comment on every video coming but Mohan I can't thank you enough for your time today we've really dug into a lot of cool topics and very interesting takes I really love your personal takes and your personal experiences I think that that is the most beneficial uh perspective to learn from um and I I can't wait to hear more content coming so I hope we get a chance to talk again and uh I'll be sending some questions your way with every new video I appreciate you Mohan and I hope you have a wonderful rest of your day sure Mike thank you thank you very much