Latest / What the Hoot! / The Hidden Cost of Hybrid: Modernizing IBM MQ® and Open Source Messaging

Transcript

The Hidden Cost of Hybrid: Modernizing IBM MQ® and Open Source Messaging · What the Hoot!

• 0:10
  SPEAKER_01: Hello everyone and welcome to What the Hood, the podcast where we explore trends, technologies, and ideas shaping the future of enterprise messaging, streaming, middleware, AI, and data management.
• 0:23
  SPEAKER_01: I'm your host, Mike Jocay, and in today's podcast, we're talking about what the hidden cost of hybrid is.
• 0:30
  SPEAKER_01: Um, I'm joined by Vijay Gondla, the director of technology for one of the world's largest retailers to discuss navigating IBM Q, open source messaging, and the reality of enterprise middleware modernization.
• 0:42
  SPEAKER_01: So I, you know, without any further ado, welcome, Vijay.
• 0:45
  SPEAKER_01: Thank you so much for joining us.
• 0:46
  SPEAKER_01: But I'm really excited to dive in with you.
• 0:49
  SPEAKER_03: Yeah, thanks, Mike.
• 0:50
  SPEAKER_03: Thanks for the opportunity.
• 0:51
  SPEAKER_03: I'm very happy to be part of this discussion and sharing my thoughts and my experiences probably will help someone somewhere, somewhere.
• 1:01
  SPEAKER_01: I know it.
• 1:02
  SPEAKER_01: I know it.
• 1:02
  SPEAKER_01: I'm glad I'm really excited.
• 1:04
  SPEAKER_01: Perfect.
• 1:05
  SPEAKER_01: So, you know what?
• 1:06
  SPEAKER_01: I just want to you know, set the scene for us.
• 1:08
  SPEAKER_01: When you look at middleware states you work with today, what does hybrid actually look like in practice?
• 1:15
  SPEAKER_01: You know, how many organizations have truly blended IBM MQ with open source solutions like like Kafka or ActiveMQ?
• 1:22
  SPEAKER_01: And how intentional was that journey?
• 1:26
  SPEAKER_03: Yes, I love the word hybrid, okay?
• 1:29
  SPEAKER_03: That hybrid will talk about the diversity and the technology.
• 1:35
  SPEAKER_03: And it it talks about, right?
• 1:38
  SPEAKER_03: When you talk about hybrid, uh, you talks about the technologies which we are using in a multiple multi-verse.
• 1:46
  SPEAKER_03: So MQ in MQ world in a middleware, whatever the observability that you talk about, one dish can't serve many.
• 1:56
  SPEAKER_03: So likewise, we have multiple technologies, so we have to use the best out of every technology and every available options.
• 2:06
  SPEAKER_03: So yeah, hybrid is inevitable in a larger complex environment.
• 2:12
  SPEAKER_03: So every large, I don't even say call it out large, medium to large organizations, especially the where the transactions and the events are more and more important.
• 2:27
  SPEAKER_03: Uh there the hybrid is inevitable.
• 2:29
  SPEAKER_03: You talk about any financial organization, any retail, it's inevitable.
• 2:36
  SPEAKER_03: So you we can't call it a count it out one or two or three, but yes, I say ten out, I mean nine out of ten organizations will be using this hybrid.
• 2:50
  SPEAKER_03: If they're not using, I would call them they should step up for it.
• 2:55
  SPEAKER_01: I love that you called it a multiverse too, as a big Marvel fan.
• 2:58
  SPEAKER_01: Um, you know, that maybe there's a bit of a middleware adventure somewhere, somewhere uh, you know, helping out the world there.
• 3:05
  SPEAKER_01: Um, but I really appreciate the answer.
• 3:09
  SPEAKER_01: I and uh I I think that right, that it's nine out of ten at minimum, are are using it, and they're and it'll soon be 10 out of 10.
• 3:16
  SPEAKER_01: Um, I'd say there's a narrative in the industry though that IBM MQ is legacy at this point, uh, and open source solutions are the future.
• 3:24
  SPEAKER_01: How do you respond to that framing?
• 3:26
  SPEAKER_01: You know, what does it you know what does it get wrong about how enterprises actually operate?
• 3:34
  SPEAKER_03: Yes, um, this is maybe the legacy would come from the people who is really active on YouTube, but but but if you look at the organization's architecture or the any retail, financial where you see the real-time solutions are implemented, there is no one talks about this legacy of the word word legacy because uh mq is rock stable.
• 4:05
  SPEAKER_03: How much No SQL comes in?
• 4:08
  SPEAKER_03: How many of you really think that RDBMS goes away?
• 4:11
  SPEAKER_03: So, in a similar way, in a message queuing environment, mq is a rock stable as RDBMS, like uh table-based and very reliable, very consistent.
• 4:22
  SPEAKER_03: And when you go for a reliability, you can't beat MQ till today.
• 4:27
  SPEAKER_03: Yes, in the open source, we have a very dynamic solutions where you go research an RD and the Kafka kind of a things which were really fantastic in the event management and all, but messaging reliability, I still rely back on MQ.
• 4:45
  SPEAKER_03: Yes, open source, many tools are coming up as I mentioned in the previous as well, right?
• 4:52
  SPEAKER_03: So one dish can serve everybody.
• 4:55
  SPEAKER_03: So MQ has its own, it's still a main course, and we are going with a lot of other dishes like Kafka, other fulfillments where the where you where you have to make your test buds happy in in terms of technology.
• 5:14
  SPEAKER_03: So whatever the open source technologies are coming, they are really, really helpful where MQ is not really solving the problems or where the places MQ is not at the best, because MQ is more or more focusing on the reliability.
• 5:32
  SPEAKER_03: So I feel where you look for agility and dynamics and scaling, such kind of a things, we might rely back on a few open source tools.
• 5:43
  SPEAKER_03: So the legacy word, I uh I'm not going to use it in our real-time scenarios.
• 5:49
  SPEAKER_03: This is all about the need and the requirement and what needs to be done.
• 5:55
  SPEAKER_03: But yes, on the MQ side, I'm really, really confident that nobody can beat it in the near future, at least.
• 6:02
  SPEAKER_03: At least.
• 6:03
  SPEAKER_01: I couldn't agree more.
• 6:04
  SPEAKER_01: I I think that it's because it's so rock steady and rock stable, it's it's it's not going anywhere and anytime soon.
• 6:10
  SPEAKER_01: Uh, it's just like people like to talk about the shiny new toy, you know, that's uh open source.
• 6:14
  SPEAKER_01: Uh, you know, they want they want people to be using it.
• 6:16
  SPEAKER_01: Uh, but I think I'd be IMQ is is like you said, rock stable, um, and and and very scalable and and uh steady.
• 6:26
  SPEAKER_01: So moving on though, when an organization does decide to introduce open source alongside existing MQ environment, what are the first three things that could go wrong that nobody warned them about?
• 6:41
  SPEAKER_03: The first thing is uh business need.
• 6:45
  SPEAKER_03: First and foremost thing.
• 6:47
  SPEAKER_03: So, what problem statement we are going to solve that is more important, and how?
• 6:53
  SPEAKER_03: So instead of going to the solution, I go with the problem statement and the solution which we are going to implement.
• 7:01
  SPEAKER_03: So when we are going for it, first thing you should talk about is uh what the complexity it's bringing in with this coexistence.
• 7:11
  SPEAKER_03: So the complexity in the architecture is the most painful part in a today's real-time environment because of the search in the technology innovation we we are adopting, the complexity becomes the biggest, biggest pain point.
• 7:31
  SPEAKER_03: So that is the one thing which I clearly call it out.
• 7:35
  SPEAKER_03: And the second thing is a coexistence, right?
• 7:41
  SPEAKER_03: Where uh we are having a multiple technologies in parallel, we should have the clarity which is used for what and in what way, and how we make the integrations work as smooth as possible.
• 7:58
  SPEAKER_03: If we didn't think about the proper integration, then it will be another message we are going to face it on.
• 8:08
  SPEAKER_03: And another thing is like how I make my team, the same team, who is doing the current MQ environment, and they should they are they able to cope up with this coexistence and they could be able to understand why it is coming, how best we can get out of this technology as well.
• 8:32
  SPEAKER_03: Because, see, uh we can't build the teams for every kind of a tool or technology, right?
• 8:39
  SPEAKER_03: So our intent for the teams is to deliver a solution, not for the tooling, I mean, not to handle a tool.
• 8:47
  SPEAKER_03: So, ideally, uh the people's mindset shift is very much needed here before we adapt, because they should be ready to adopt it and they should be ready with the knowledge, how and what it brings value to the business, and they should be comfortable with the technology as well.
• 9:09
  SPEAKER_03: So that is more much more important because as we discussed in the previous questions as well, we are going with a more of an open source ones.
• 9:19
  SPEAKER_03: So when you go for open source, the support we more rely on our own team because we don't have anybody, or I don't say anybody, not having enterprise support is always a pain point, right?
• 9:34
  SPEAKER_03: So that's where I feel those three pain, three or four pain points I talked about.
• 9:38
  SPEAKER_03: One is a coexistence, architectural complexity, and the engineer's mindset shift.
• 9:46
  SPEAKER_03: It's all should be binded to business value or the problem statement, else it will be become more and more complex, and nobody has no idea why we had two or uh technologies in the same space.
• 10:02
  SPEAKER_01: Love the answer, right?
• 10:03
  SPEAKER_01: Understand the complexity, understand the coexistence, um, brings clarity, and then the ability for your team to comprehend uh and and and be able to mold this and and bring them together.
• 10:14
  SPEAKER_01: Um, thank you, Bajay.
• 10:16
  SPEAKER_01: That's that's uh very helpful.
• 10:18
  SPEAKER_01: Um for observability across hybrid messaging states, you know, it's a well-known pain point.
• 10:25
  SPEAKER_01: Um but where specifically does the visibility break down?
• 10:30
  SPEAKER_01: Is it is it a tooling problem?
• 10:32
  SPEAKER_01: Is it uh is it a pro a process problem, or is it something deeper?
• 10:37
  SPEAKER_03: Observability, very, very big topic you're touching best upon.
• 10:41
  SPEAKER_03: But yes.
• 10:44
  SPEAKER_03: Observability have a multiple folds, right?
• 10:46
  SPEAKER_03: We are talking about uh proactive identification of the problem.
• 10:53
  SPEAKER_03: So to identify the problem, the observability tooling should have the functional functional understanding.
• 11:00
  SPEAKER_03: The entire observability tooling itself needs a functional understanding.
• 11:05
  SPEAKER_03: What does it mean?
• 11:06
  SPEAKER_03: Means if a database transaction is happening or any transaction is happening, are you looking at a particular complete transaction?
• 11:17
  SPEAKER_03: Are you looking at uh half of the transaction while payment system is happening?
• 11:23
  SPEAKER_03: When the transaction is traveling from an uh endpoint to the database, what you are really looking at it?
• 11:32
  SPEAKER_03: Are you looking at the reliability?
• 11:34
  SPEAKER_03: I mean it's is the transaction is atomic uh as well as its swift.
• 11:41
  SPEAKER_03: So the observability should think about first atomicity should be supported because uh either the transaction should be fully successful or fully failure, and then the time it should take usually to make the experience better, and everything should have these, these are all the functionalities we defined before, right?
• 12:04
  SPEAKER_03: Observability should actually complement this or actually look at these things.
• 12:10
  SPEAKER_03: Is the functionality is being delivered or not?
• 12:13
  SPEAKER_03: The first that is the first thing, and is the functionality has the reliable and it's a timely happening or not?
• 12:22
  SPEAKER_03: All these things should be taken into consideration.
• 12:25
  SPEAKER_03: So, your question about the observability in a hybrid messaging is it pain points or the engineer's mindset and the understanding of this observability need.
• 12:37
  SPEAKER_03: That is the biggest pain point I'll see.
• 12:39
  SPEAKER_03: Because my experience, I build observability stack for a couple of organizations.
• 12:46
  SPEAKER_03: One is a SaaS-based product company, another is a uh healthcare organization.
• 12:52
  SPEAKER_03: So the majority of the thing is uh the engineers understand the architects come up with saying that this is my functionality, these are the things, metrics and all.
• 13:03
  SPEAKER_03: Either the observability is over provisioned or the less provision because they are looking at the uh metrics only instead of looking at the functionality as I mentioned.
• 13:16
  SPEAKER_03: So there are gaps are happening.
• 13:19
  SPEAKER_03: Which metrics will bring this complete functionality monitoring is breaking, and engineering teams work in silos and they don't know real pain of this, and we see the gaps in observability where the areas are being not been added to the observability, and we will come to know only after that incident hits back to us, right?
• 13:44
  SPEAKER_03: So that is the biggest challenge I have.
• 13:46
  SPEAKER_03: That's where no company in any organization having zero percent reactive incidence.
• 13:55
  SPEAKER_03: What I mean to say is uh everybody having a reactive incidence, there is no one having a zero percent reactive incidence because of these gaps.
• 14:05
  SPEAKER_03: Observability is all about proactively acting for uh incident manager incidents that are happening, so because of these gaps, understanding, and as I mentioned, the architectural level, understanding of every component in the flow should be part of observability.
• 14:24
  SPEAKER_03: While observability also we need to do a lot of brainstorming on the architectural design, how the data is flowing, how the logs are flowing, how these logs are being uh tracked or traced, and the tracing is another thing which we talk about when we are coming to observability part.
• 14:44
  SPEAKER_03: So these are all things need to be taken care of.
• 14:47
  SPEAKER_03: So the biggest pain point is the understanding of end-to-end functionality of the product to the engineer who actually enabling the observability.
• 14:57
  SPEAKER_01: It reminds me, uh, you know, of the comprehension piece, uh, right?
• 15:01
  SPEAKER_01: It really comes down to you the different teams and different teammates being able to comprehend the value of observability or the value of hybrid estate.
• 15:09
  SPEAKER_01: Um, or you know, so it really does come down to the human element there and being able to work more cohesively, um, whether it's it's the coexistence of MQ and and active or um you know engineering teams working in silos and needing to understand the the full business impact of not having this you know uh visibility and observability into the functions.
• 15:31
  SPEAKER_01: Um, but let's let's talk about that human side, right?
• 15:34
  SPEAKER_01: Um when you when you're working with a team that has deep IBM MQ experience and expertise, but is being asked to operate Kafka at the same time.
• 15:44
  SPEAKER_01: Well, you know, what does that skill gap look like and how do organizations bridge it without you know burning people out?
• 15:51
  SPEAKER_03: We already touched upon this topic, right, earlier.
• 15:54
  SPEAKER_03: Like we are adopting uh coexistence of uh new tools, right?
• 15:59
  SPEAKER_03: So that we need to make our engineers' mindset should be ready to adopt this.
• 16:04
  SPEAKER_03: That is the biggest thing, I mean the best thing which we can do.
• 16:09
  SPEAKER_03: Means our engineers are not bounded to the tools or the technology, instead, that they should be bounded to the functionality or the need of this technology.
• 16:24
  SPEAKER_03: So when they are bounded to that need, they are easily shipped between the tools to get that done, that need.
• 16:34
  SPEAKER_03: So we need to prepare our engineers to think beyond one tool, beyond one technology to address the same thing, because every technology comes up with a very unique features which will create a lot of value to our business.
• 16:51
  SPEAKER_03: So if the people are working with MQ, it's uh it's uh what do you say?
• 16:57
  SPEAKER_03: The fundamentals are similar.
• 16:59
  SPEAKER_03: The only thing is how you are playing with the message Qs and how you are making it a best use of it, subjective to the that particular situation.
• 17:10
  SPEAKER_03: As we talked about um scale and high availability, we go for a Kafka and uh reliability, we go for an MQ.
• 17:19
  SPEAKER_03: So when our engineers understood this, they are ready to adapt it.
• 17:24
  SPEAKER_03: I mean, I believe in uh instead of architect suggesting these kind of solutions, we need to build a kind of a mindset.
• 17:32
  SPEAKER_03: Engineers should come up with hey, why we are bonding to MQ only?
• 17:36
  SPEAKER_03: We will go with the other technologies also.
• 17:38
  SPEAKER_03: So that kind of um mindset we should inject to our engineers.
• 17:43
  SPEAKER_03: That is the human side of it.
• 17:45
  SPEAKER_03: If if that is not happening, it's very difficult for us to run the business with this hybrid and high-based open source era, right?
• 17:56
  SPEAKER_01: So it it it I think it truly is a mindset shift, right?
• 18:00
  SPEAKER_01: Like to understand that uh to not be complacent, right?
• 18:04
  SPEAKER_01: That you you get kind of bored if you're just working with one thing, but you have to understand the the the the needs and functionalities of the the other tools, um, and and be able to you know kind of go with the flow.
• 18:15
  SPEAKER_01: Um, but I I I do understand that there could be burnout, but um, I think that it's there is um a great value in being able to understand how and when and why to work with different technologies.
• 18:27
  SPEAKER_01: Um let's talk about AI now being injected into every conversation.
• 18:33
  SPEAKER_01: So I hate to just inject it here, but what does AI actually mean for Moodleware ops uh in in practice?
• 18:40
  SPEAKER_01: Where is it genuinely useful?
• 18:43
  SPEAKER_00: Uh, and where is it still mostly just hype?
• 18:47
  SPEAKER_03: Um everybody coming there, everybody is thinking about AA, everybody is thinking about AA.
• 18:56
  SPEAKER_03: So, how I mean what it changes, I really don't know.
• 19:01
  SPEAKER_03: I admit that, but what I think I'll say this is what my recent conversation with my CAO also mentioned.
• 19:08
  SPEAKER_03: Uh, he also mentioned, I don't know, but he what he thinks he mentioned, so I'm using the same methodology here.
• 19:14
  SPEAKER_03: Beautiful.
• 19:15
  SPEAKER_03: So so but uh yeah, as you mentioned, AI is like uh I will treat it as a weapon.
• 19:25
  SPEAKER_03: I'll treat it as a weapon which is available for all our engineers or the techno technocrats, everybody, to best use of it and get the best solution.
• 19:36
  SPEAKER_03: So in a MQ medalware, as we talked about the complexity, coexistence and the observability, whatever it's the problems to do the analysis, to do the what do you say, more and more in detail uh experiments, A will give you A will make it easy.
• 19:58
  SPEAKER_03: For example, if I want to look at the entire login observability stack, I'll look at what are all alerts are coming and what are all actually logs has been there and what logs has been not been configured as alerts, and what are the traces or the they are missing while we are capturing these logs after an incident happened?
• 20:18
  SPEAKER_03: I just want to go and check what are what is happening in the logs.
• 20:22
  SPEAKER_03: If I go humanly, it takes a lot of time.
• 20:25
  SPEAKER_03: If I give it to AI, pull it out.
• 20:27
  SPEAKER_03: This is what I need, because we know it what what log, what kind of logs we need to identify this problem.
• 20:35
  SPEAKER_03: Go and find it out what logs I have.
• 20:37
  SPEAKER_03: So AI can pull it out, sort it out, and give it to you.
• 20:40
  SPEAKER_03: Hey, buddy, this is what we are having.
• 20:42
  SPEAKER_03: That is the first level of AI.
• 20:44
  SPEAKER_03: I mean, we we can add more intelligence to AI to find it out from the logs, what could be the problem, all these things.
• 20:52
  SPEAKER_03: So you can use it as a weapon, or you can use it as your colleague, you can use it as your executive assistant, or however you want to use it, use it, but add your human side and your human intelligence to it and get the best results out of it.
• 21:08
  SPEAKER_03: That's what we can do.
• 21:09
  SPEAKER_03: It is simplifying my job, whatever I'm doing, as far as AA to me, it is there for me to make my job easy.
• 21:18
  SPEAKER_03: It it is there to help me out on where I can't put our effort my time.
• 21:25
  SPEAKER_03: So that's where the yay is there.
• 21:27
  SPEAKER_03: Yes, we can best use of it, that it makes me reckon.
• 21:32
  SPEAKER_01: I really like that metaphor that it's a weapon.
• 21:34
  SPEAKER_01: Really, it's it's only as useful as the human using it, right?
• 21:38
  SPEAKER_01: It's uh the how you're operating it, right?
• 21:40
  SPEAKER_01: How you're holding the weapon, how you're pulling the trigger, right?
• 21:43
  SPEAKER_01: You have to put that human element in to make it more powerful.
• 21:46
  SPEAKER_01: A weapon is is no good by itself.
• 21:48
  SPEAKER_01: Um, yeah.
• 21:49
  SPEAKER_01: So that's a really good thing to think about it.
• 21:51
  SPEAKER_03: To add on it, right?
• 21:53
  SPEAKER_03: For that, we need to make our logging systems, especially to observability, right?
• 21:58
  SPEAKER_03: Yeah, we need to make sure.
• 22:00
  SPEAKER_03: Or logging and configuring the logs and capturing the logs should be top notch.
• 22:05
  SPEAKER_03: Else, what happens is garbage in garbage out.
• 22:08
  SPEAKER_03: If you're not loading the logs, it doesn't do much.
• 22:12
  SPEAKER_03: It is not useful.
• 22:14
  SPEAKER_03: So make your data is accurate and highly quality data, then only you find the best out of it.
• 22:21
  SPEAKER_03: Else, as I mentioned, gigo, garbage in, garbage out.
• 22:24
  SPEAKER_03: I call it as a giggle.
• 22:27
  SPEAKER_01: I love it, bud.
• 22:29
  SPEAKER_01: Um, let's take it as SLA management because I think SLA management across hybrid environments is is is um also fundamental to this impact.
• 22:38
  SPEAKER_01: But is it even possible to hold a meaningful SLA when when the transaction touches IBM Q, open source solutions, and a cloud service before it completes?
• 22:48
  SPEAKER_01: You know, what does what does good look like there?
• 22:51
  SPEAKER_03: So SLA is a humanly defined thing, it's not a mission, mission defined, right?
• 22:57
  SPEAKER_03: Whenever we architect a solution, we know that what is a realistic value.
• 23:03
  SPEAKER_03: When you are using MQ, we are using Kafka, so everything has its own transactional time.
• 23:10
  SPEAKER_03: And we have the defined and accepted time when we are architecting this much of time it will take in in general.
• 23:18
  SPEAKER_03: That is what we keep it as SLA.
• 23:20
  SPEAKER_03: I don't think SLA really having issues if you configure an architect in the right way of a right architecture in the system to flow the messages.
• 23:32
  SPEAKER_03: Um I didn't really understand your question.
• 23:35
  SPEAKER_03: What is SLA in hybrid environments?
• 23:38
  SPEAKER_03: It's SLA is SLA for entire infrastructure or the architecture.
• 23:43
  SPEAKER_03: It's not looking different for a hybrid environment or a it's about the transaction time, right?
• 23:50
  SPEAKER_03: How much time it takes and how much time it should take it.
• 23:53
  SPEAKER_03: So that's what I look at as SLA.
• 23:56
  SPEAKER_03: I don't uh break it down.
• 23:58
  SPEAKER_03: MQ is taking this much time, Active MQ is taking this much time, Kafka is taking this much time.
• 24:04
  SPEAKER_03: It doesn't matter, right?
• 24:06
  SPEAKER_03: It's all discussed during our design.
• 24:11
  SPEAKER_03: And then SLAs we have in mind when we are architecting itself, if we architect in such a way and define SLA, so it should be complementing each other, it's not a one-way.
• 24:27
  SPEAKER_03: So whenever we are doing this SLA definition, that that's the time we look at the design and architecture and we define the SLA.
• 24:36
  SPEAKER_03: So I don't think SLA is really a big problem here in the MQ environments.
• 24:44
  SPEAKER_00: I love it.
• 24:45
  SPEAKER_01: I love it.
• 24:47
  SPEAKER_01: Makes me think though, open source, right?
• 24:49
  SPEAKER_01: Back to open source, it carries this perception uh of it being free, right?
• 24:53
  SPEAKER_01: In quotations.
• 24:55
  SPEAKER_01: Um, but what what's the real total cost of running open source solutions in production enterprise environments?
• 25:01
  SPEAKER_01: And where do organizations consist consistently underestimate that?
• 25:07
  SPEAKER_03: Open source.
• 25:08
  SPEAKER_03: Uh it's I see open source as being brutally used in our startups.
• 25:14
  SPEAKER_03: I'm using this word because that is my experience with a misperception that it's free.
• 25:20
  SPEAKER_03: At least in this world, nothing is free.
• 25:23
  SPEAKER_03: If it is if it is free in the starting while you download a solution, it costs you when you are using.
• 25:33
  SPEAKER_03: So there are different costs involved, right?
• 25:37
  SPEAKER_03: One of the first things is the support when you are doing uh when you are using open source, it's really, really tough to get the enterprise support level of confidence, enterprise level of confidence.
• 25:52
  SPEAKER_03: So you need to invest in the people to operate it first, and the second one is like a risk, right?
• 26:01
  SPEAKER_03: It's not true when there is no proper optics, and the second part is the integration flexibility or the clear definition of the available integration will definitely tie our hands while we are customizing the solution.
• 26:23
  SPEAKER_03: And um, governance and compliance is a one thing which is always the biggest, biggest pain points with open source.
• 26:31
  SPEAKER_03: You can't go for a compliance, all these things get succeeded.
• 26:36
  SPEAKER_03: So I feel open source is good, and the RD stages, dev environments to prove or to test our solutions, to give the full freedom for our engineers to open their wings and put their ideas and define solutions.
• 26:57
  SPEAKER_03: But coming to production, I can't risk my business for the sake of open source software.
• 27:04
  SPEAKER_03: So I'll always go with the enterprise.
• 27:07
  SPEAKER_03: It everything, I mean, either enterprise or the open source have its own advantages, use it uh day diligently and use it uh in such a way that it won't hit you back in a wrong way, right?
• 27:24
  SPEAKER_01: You should use it in a way that minimizes risk no matter what.
• 27:26
  SPEAKER_03: Yeah, that's what I'm saying, right?
• 27:29
  SPEAKER_03: You should be paying somewhere.
• 27:30
  SPEAKER_01: You don't think that open source is free, otherwise, you'll be paying later in a way in a way worth it?
• 27:36
  SPEAKER_01: You have to pay.
• 27:37
  SPEAKER_01: Oh man, oh man.
• 27:39
  SPEAKER_01: Um, so you know what?
• 27:40
  SPEAKER_01: I'd love to talk about the past and then talk about the future if that's okay.
• 27:44
  SPEAKER_01: But if you could go back and give one piece of advice to an organization at the very beginning of a middleware modernization journey before they've made any decisions, what piece of advice would you give to them?
• 27:56
  SPEAKER_03: Take time to conclude the solution.
• 28:01
  SPEAKER_03: Don't conclude the solution in hurry.
• 28:03
  SPEAKER_03: Please be very cautious, please be very clear on your problem statement, what you're trying to solve.
• 28:10
  SPEAKER_03: Sit back and look at every risk we are going to face it and define a solution in such a way as we discuss a lot of things, SLA, observable D, everything to be pre-measured and pre-defined while we are going for any modernization.
• 28:27
  SPEAKER_03: And one of the best things is how loosely coupled it is.
• 28:32
  SPEAKER_03: If I get a better technology tomorrow, how easily I can migrate.
• 28:37
  SPEAKER_03: That is the one thing which will which I uh which we always should keep in mind because the technology becomes very, very volatile, and day in and day out, you are seeing the drastical changes.
• 28:51
  SPEAKER_03: So our solution should be very much ready for the migrating if I get a new technology.
• 28:58
  SPEAKER_03: Yeah, my design, my should be.
• 29:01
  SPEAKER_03: Yeah, don't be tightly coupled with any tooling or any technology, so try to make it as a plug-and play.
• 29:09
  SPEAKER_03: So design should complement that.
• 29:12
  SPEAKER_01: That's such good advice, Vijay.
• 29:14
  SPEAKER_01: I I I couldn't agree more, right?
• 29:16
  SPEAKER_01: Just truly understand what the what the migration is gonna look like, right?
• 29:21
  SPEAKER_01: But be ready to you know decouple and pivot when needed, right?
• 29:25
  SPEAKER_01: That's great advice.
• 29:26
  SPEAKER_01: Um, but let's look ahead.
• 29:27
  SPEAKER_01: Three, five years.
• 29:29
  SPEAKER_01: Um, do you think that IBM MQ and open source messaging platforms do they converge?
• 29:34
  SPEAKER_01: Do they coexist, or does one eventually win out over the other?
• 29:39
  SPEAKER_01: And and what does that mean for the engineers building on these platforms today?
• 29:45
  SPEAKER_03: Huh?
• 29:46
  SPEAKER_03: You are talking about the same thing again, right?
• 29:49
  SPEAKER_01: I but I think it's gonna keep coming up.
• 29:52
  SPEAKER_03: Yeah.
• 29:53
  SPEAKER_03: It's it's see, it's not about right, the future is not about MQ versus Kafka or MQ versus something else.
• 30:01
  SPEAKER_03: It's uh it's always about the business problem to solution.
• 30:05
  SPEAKER_03: I'm not really, as I mentioned, I really don't want to think too much about the tooling.
• 30:11
  SPEAKER_03: I just want to think about the solution or the problem I'm addressing.
• 30:17
  SPEAKER_03: So if MQ is going away, that means the business statement is defined or delivered by some other technology.
• 30:26
  SPEAKER_03: That's where I'm saying, right, when you are working on a modernization plan, please type try to make it very loosely coupled with the tooling.
• 30:37
  SPEAKER_03: You have the tooling that is very much right.
• 30:42
  SPEAKER_03: I mean, uh the technology or solution, whatever you're defining, should be ready to migrate to new technology, but but in the reality, I don't think MQ MQ are going anywhere because MQ is there for quite a long time.
• 30:58
  SPEAKER_03: You see, you still see, right?
• 31:00
  SPEAKER_03: There are a lot of mainframes that still exist.
• 31:03
  SPEAKER_03: Right.
• 31:04
  SPEAKER_03: I mean, I see a lot of AX machines still exist.
• 31:07
  SPEAKER_03: I can see few Solaris machines still exist.
• 31:11
  SPEAKER_03: Uh, I can see HP UX service also exists in few organizations.
• 31:17
  SPEAKER_03: So, how and why, even the AA is in picture, these things are still exist.
• 31:25
  SPEAKER_03: So, every technology has its own advantage and it has its own business value.
• 31:32
  SPEAKER_03: To deliver a business value, that is the best technology.
• 31:35
  SPEAKER_03: So, no technology is going away, no technology is going to stay as it is today.
• 31:40
  SPEAKER_03: So, technology will evolve and business cases will evolve.
• 31:44
  SPEAKER_03: We will we have to run and run along with them, and we have to evolve with them.
• 31:52
  SPEAKER_03: Yeah, we have to co-live with them.
• 31:54
  SPEAKER_03: I I could say that we have to co-like with them, and but one thing will change definitely.
• 32:00
  SPEAKER_03: The way you are using MQ today will definitely change by tomorrow because the people's mindset is evolving than the technology.
• 32:09
  SPEAKER_03: How ideally I can use this technology?
• 32:13
  SPEAKER_03: That is what changes.
• 32:17
  SPEAKER_03: But uh, the mindsets of the people who are using these technologies and defining solutions will definitely going to take a real swift shift from one mindset to other.
• 32:29
  SPEAKER_03: That's what you are looking at.
• 32:31
  SPEAKER_03: The way we are using servers, right?
• 32:34
  SPEAKER_03: Earlier it's a physical server, one server, then we went for virtualization, then we are going for a containerized.
• 32:41
  SPEAKER_03: So I did we are trying to best use of the available technology.
• 32:46
  SPEAKER_03: That's how we change it.
• 32:48
  SPEAKER_03: The underlying voice is there from the physical server to containers, but how you are tuning this operating system matters.
• 32:56
  SPEAKER_03: That's how the messaging queues are whatever the technology you're talking about, that will people are not putting great efforts in changing the or inventing the new technology, but people are putting a lot, lot of efforts how efficiently I can use this technology.
• 33:14
  SPEAKER_03: That's where the things are changing.
• 33:16
  SPEAKER_03: The stateless systems are the virtualization, containers, everything talks about how ideally how effectively I can use the resources.
• 33:27
  SPEAKER_03: That is what's changing, not the technology.
• 33:29
  SPEAKER_03: Technology stays, I think, I don't know how how long ago a full-fledged language has been developed after Java.
• 33:38
  SPEAKER_03: It's all uh all babies are thus the features have been extracted and made it easy.
• 33:44
  SPEAKER_01: Still, the whoops concepts is underlying, so that's how so I really I think it comes back to that that mindset shift, right?
• 33:53
  SPEAKER_01: Is is how effectively we use the tools.
• 33:55
  SPEAKER_01: The tools aren't changing, they're not going anywhere.
• 33:57
  SPEAKER_01: Um, but how effectively we use them in different use cases in different ways.
• 34:01
  SPEAKER_01: So again, it comes down to the human element of us trying out new ways to use these technologies and tools.
• 34:07
  SPEAKER_01: Um Vijay, thank you so much for today.
• 34:10
  SPEAKER_01: Uh, you know, I that's that's the last question I had, and that's all for today's episode of What's the Hoot, but I wanted to give you the biggest thank you and shout out.
• 34:19
  SPEAKER_01: Vijay, thank you so much for joining us today, sharing your insights, very valuable.
• 34:23
  SPEAKER_01: Uh, if if anybody listening has enjoyed this conversation, be sure to check out more episodes of What's the Hoot and explore additional resources on enterprise messaging, streaming, middleware, AI, and data modernization at meshik.com.
• 34:37
  SPEAKER_01: Thank you again for listening.
• 34:38
  SPEAKER_01: I'm Mike Joe Kay.
• 34:40
  SPEAKER_01: We'll see you next time on What's the Hoot.