 Oh wrong intro. Good morning. Good afternoon. Good evening and Welcome to another episode of in the clouds. I'm sorry the level up hour I am totally out of whack this morning for a poor night's sleep. So confused. Yes This is in the clouds with myself Chris short executive producer of open shift TV Technical marketing manager here at Red Hat as well as the illustrious Langdon white Langdon How are you this morning? I'm pretty good. I'm pretty good, you know, doing doing well in the coffee I think this is my second cup. So we good for you on my second cup as well. Awesome. Yeah, yeah We are Excited to invite some also illustrious guests. Yes today so we have I'm gonna I'm gonna ask y'all to indicate the group you're with because Red Hat has been Renaming a bunch of the teams that we have quite a bit lately and so so I'm getting very confused But first up James Faulkner. You want to tell us a little bit about who you are and and what you do? Sure. Yeah, so thanks for having me on. So James Faulkner. I work in The make it easy for you formally known as the middleware business unit now the application services business unit I do product marketing for our suite of Cloud native runtimes for running, you know, a very horizontal set of use cases for applications So, you know, the traditional ones no JS spring boot Java EE Jakarta EE and now some of the more modern stuff with the things like carcass So, yeah, I've been at Red Hat for about four almost five years. Actually five years in February. It'll be five years prior to that I spent a bunch of time in Sun Microsystems and Oracle and I was also at life Ray for a few years as well. So I've been in the Java space for I don't know 12 years now. I think something like that life Ray the portal that you know Bible quote Portlet by default. Yes. I actually worked on life Ray for a long for a little bit Nice, I'm glad to hear it. I apologize if you had any trouble. It's all my fault So I actually it was my trouble one of the better ones Yeah, it was one of the better ones. My trouble was with our devs that just insisted upon having for control of fraud and that was not good Yeah, that's a challenge no matter which portal you're using exactly Daniel Thank you for coming. Do you want to tell us a little bit about who you are and what you're doing at Red Hat? Yeah, thanks, and I'm good. Yeah, my name is Daniel. Oh, and actually I'm working with the James Faulkner It's same team and the runtimes team So, yeah, I'm technical marketing major a little more focused on technical stuff like a creative workshop demo and a technical some enabler month for many Developers in the IT operation team really about the cloud and runtimes. Yeah, Park is spring good and no Yes, and course tables EAP that is our still be cash cow Yeah, so that's what I'm doing What I think it's funny about Daniel and I is I think we live like 40 miles away from each other, but have never met in person It's kind of like there's a there's a woman who lives in Cambridge so I live in downtown Boston and a Cambridge is like right next door and She is I see her all the time around the world at conferences I have seen her once in the Boston area, which I think is also So, yeah, when you when you travel a bunch it can be it can lead to some entertainment. Yeah Sorry, Lane. Yeah, one story on that There's like there's a guy that works at Red Hat that I I've only seen at conferences And so and we seem in almost every single conference. His name is George. He'll know He works at Red Hat and it's just hilarious every time we see each other like hey, buddy Again, see you next week at the next conference and we never ever meet up outside of that So it's kind of fun, right, right. Yeah, it's it's a conference friends and yeah There's something we said about that like circuit, you know I I often wonder if that's if it's similar for and much longer lasting in a sense for like actors and actresses or like people who work in You know TV shows or movies or whatever you only see them kind of on the circuit You know or like comedians or whatever like I suspect it's a similar experience. Yeah But you know, obviously I You know being Me and a nerd. I only have experience with the software conference circuit. Nothing Nice So what was I gonna say, okay, so Why don't we start? Oh awesome. I just got signed out of Google. Oh good. So, you know, that'll make things faster It's an easy right now Like literally it popped up when I was about to switch Perfect. Yes. All right, let's see if we can find the right window But I'm gonna share my my awesome awesome slides that I do for every show and I think I even corrected all of the bugs in them this time, which is even better But what I like to do is to quickly start off I like to say, you know in case you're lost. This is the level up our on this show we talk about why Containers might be interesting for you and maybe a little bit of an introduction to containers and in particular how containers are Kind of like an easy convenient way of doing things kind of all the time rather than just this special technology or whatever that you use when you need to You know go to production or something and so in particular we want to show use cases a lot of the time where Non-developers might be interested in containers, but we also cover a lot of development stuff And I think we're gonna cover a little bit more on the developer side of the house today But this is the level up our Your host Chris short and I myself. I'm Langdon with a one on Twitter and Chris is Chris short And if you want to chat with us you can chat in the in the whatever a streaming platform chat You're on and we will see it on twitch and and respond either on the show or on twitch But you can also join us in discord and we're there all the time. Maybe not all the time sometimes we sleep But you can join you sleep. Well, yeah occasionally Yeah, it's a surprise to most people who know me. What's that like? But you can definitely join us there and we we sometimes get into interesting discussions We've been trying to flesh out the discord to kind of cover all the shows as well So any of the shows that we do on open gif TV, you can kind of come and chat with us there off line and Yeah, so Do you have the oh you've dropped it already so I'm just looking for the link and I'm gonna stop sharing here because as we all Know the next part is the sweet sweet internet points and we don't want to give those away too early And Daniel and James if you are unfamiliar You will you will learn the awesomeness that is internet points very soon So I Asked the two of you here today because we have through the show so oh wait, you know what I did miss a slide I thought I did and here I was doing so well So and the reason I want to make sure I go back to it is because It's somewhat important to my point So what I want to point out is this is episode 22 of Our episode so we've actually been doing this a while now mr. Short It's been quite a journey though. I love it. It has been it has been I think I taught you something new yesterday too, and it's been a while So I was hoping to hit something Yeah, you did so The show notes from last time are at the link below and I will throw that in the chat I forgot to pull them up in advance like I I actually did this one and The reason I want to point it out is because we have been doing the show for a whole bunch of episodes now and We have been recently covering or been using NextCloud as kind of our example application and NextCloud is cool and does it stuff well and that's a little bit the problem in that you We can't break it I want to do this brand new thing off to the side and change things around and you know and use canary deployments and that kind of stuff because NextCloud just kind of does it thing well So what I wanted so what I was I was asking around about and came across James, I think that you answered me. I can't remember where I how I got there, but You have a tool or an application that you've built that is for demo So you get to break it but is also more complicated than hello world And so what I wanted to invite you on the show about was to talk about that application But then the part that I think you also did which I'd also like to talk about Was I think it was actually a migration originally from a monolith application. Yeah, that's right. Okay, so so that's an even better story So why don't you tell us a little bit about the app and what it does or maybe a pointer to where it lives and that kind of stuff sure So the cool store is It's the retail shopping. It's a fake retail shopping experience It was I did not write the original one the written by Eric Chabelle and a few others Really intending to showcase not necessarily the retail experience but showcase our business rules management system How business analysts can you know edit a spreadsheet so that they can alter the the shipping or promotion costs or promotional Details without having to go in code. So it's kind of separates, you know, the business guy from the from the coder And so that was originally a monolith a Java EE, you know, essentially a war file that gets deployed Had the BRMS or business rules management system technology in it. It also had a front-end written in a Web toolkit called Vodin And it had a few products you select the products you click the purchase button It calculates the shipping costs and any promotional details based on the BRMS rules And then you get, you know, your result and when I joined Red Hat in 2016 microservices were all the rage and Also all the rage was for container orchestration with OpenShift and the OpenShift two to three kind of transition that was in that time period So we really I thought it would be a great example because you're like everybody knows retail everybody Uses some kind of online shopping So it's a very familiar use case And so it's it's easy to add features and demonstrate various technologies using those features So adding things like an inventory system or adding a payment gateway or something like that and all fake, of course but we really used it as a as a I guess a way to showcase containers and OpenShift as well as the The microservices capabilities that people like Berserter were talking about very heavily at the time So it is it was a monolith and we Basically converted it into a set of microservices and then built some demos and workshops around that To showcase and use some of the tooling to do that migration from a monolith to a microservice and then along the way adding features from OpenShift like, you know, blue-green deployments and Build pipelines and things like that. So that's sort of the the genesis of that application and so In more modern times, we've we've continued to add new features like We've added an API gateway poor man's API gateway if you will with camel. We added a single sign-on. We added Infinispan for for in-memory data grids for storing the shopping cart details for each user things like that we also rewrote the UI because Although that Vodin is great It it wasn't what people were looking at when they're looking at microservices A lot of people do things like single-page apps and front-ends and things like angular and react So we wrote the front-end and angular turned out of no microservice as well with no JS and so we had all these different technologies kind of sitting in this one demo and so a lot of the Field folks at Red Hat started to take that and use it for demos and workshops and whatnot So yeah, so I mean What's cool about that? We've actually within our group We've been talking about actually moving all of our demos over to the same platform So basically we can kind of have like the the one demo that rules them all you know in particular what I also enjoy is and The kind of thing I like to show off is in a in a real-world application the likelihood it is just one programming language is very low and So what I particularly like is that you kind of have kind of a no JS component as well as a bunch of Java components You know even going back as horrific as it is to say, you know You know using Java front-ends against the mainframe, right? It's another common scenario Even even today, which is scary and one of the things that Narendra brought up in the chat actually which I'd point out too is it it also allows for Kind of and this is one of the things that's true about kind of a service-oriented model in general Whether you call the micro services or macro services or services or small chickens or whatever you want It allows for change over time Around the feature set that you want to offer right? So he brought up AI for example You know an AI for analysis, you know, so that's a very good example It's like, you know, how well are your you know, widget selling when you're you know If if you have the price point at X versus if you have the price point at Y And we talked a little bit about this last episode. We were talking about service mesh and kind of red black Or I keep doing this, you know, it's oh, no, it is red black red black Deployment of applications so that you can kind of say, okay I'm going to try this UI and see how it performs or try this price point and see how it performs and try this price point Presented in the same application, but to different sets of users so you can get some feedback Yeah, some people call it a B testing as well. Yeah A B testing I find though in the industry language tends to be really limited only to UX tests. Yeah Yeah, actually I was I meant to bring this up at the last episode is Someone's Presidential campaign. I want to say it was Hillary Clinton, but it could have been somebody else There was a story about how they did an AB test with two different size donate buttons And it made like an astronomical like difference like orders of magnitude difference Wow on a donations when now, of course I can't remember whether the button was bigger or whether it was like where it was placed or whatever But they actually did an AB test with their donate button, you know kind of layout and it made a huge difference Yeah, it's kind of interesting how you how you know the user experience and UI can really affect your decisions like even in the in the cool Store one of the things that I I found really early on when I first joined red hat and I looked at some of the existing demos They were like the the big money shot was like the log file scrolling by and you're like look it works I see the value changed from one to three isn't the fantastic mr. Customer It's like not all that impressive stuff. Like I know there's some masses like super computing going on underneath But you know seeing that line change is not that exciting. So I That's a developer log files are the bomb, right? I mean like right like you want to you know See in your own log file scroll by without errors is like an amazing experience But you know, I don't I get the impression that nobody else cares You know, for example, I don't want to see Amazon's log file I want to see a transaction But yeah, I totally I totally get you What I'm really curious about that and you know kind of I think relevant to kind of the audience in the show is like So what was the experience or how did you go about taking kind of the monolith to the microservice side? what You know, what complexities were there? What what were the things that you didn't expect to be a pain in the butt? That you know turned out to be or or that kind of you know, what are the what are the gotchas? So yeah, that's good question one of the things that I used when I started this process was I mentioned Bursutter He had this presentation where he kind of showed a very crude if you will Depiction like an illustration of a retail site showing the different microservices And how you can like do API chaining where one calls, you know a calls B calls C calls D If D fails and they can cascade back, you know all the way back to the end user and they get that stack trace or an error message and so one of the things that one of the other options is to do Either client side or server side API gateway I mentioned API gateway where you have, you know a single entry point and then that gateway makes decisions and calls different microservices and pieces things back together That turned out to be kind of hard to code myself because of all of the different HTTP verb rules and I also was learning camel at the time and Trying to sort all that out and set up the the different rules for you know the different routes essentially For the different microservices and aggregating those pieces back together turned out to be Relatively challenging even though they we kind of made the microservices return kind of simple JSON objects aggregating that together and D duping and and Returning a sane result turned out to be not that not that easy There's lots of gotchas with HTTP especially if you're doing HTTPS, which we were also doing with you know having like cores headers and Trying to get the certificates Deployed correctly and things like that in the JVM that was running the API gateway So that turned out to be challenging but at the end of the day it was I think the right way to do it because You kind of want in a microservices and containerized world You kind of want to hide the implementation detail of your back ends So that if you want to make a change You don't have to go update the client because if your client is a mobile app on the app store For example the Apple app store it is a massive pain in the butt to update an app quickly It's like you got to do all kinds of crazy stuff to be there So hiding that stuff is was kind of a pain but also worth at the same time Yeah, I mean, you know have a conversation with someone at Red Hat who works in rel and talk about updating say rel 4 You know the yeah, it ain't just mobile apps So one of the things I wanted to comment on was can you expand a little bit on what? camel is Because you know, I'm not sure our audience has a lot of familiarity with it And and you keep talking about it and I personally very cool So, you know, I think it's an important thing to talk about a little bit. Sure. Yeah. So first of all I'm not a camel expert. I didn't know about camel until I joined Red Hat. So I probably won't do it the justice that it deserves But it is a an integration technology So if you want to glue one thing to another thing and not have to write all the logic yourself They have a ready-made set of connectors and they also implement a number of patterns that have emerged Throughout the years of doing distributed programming or distributed computing where you can have like if you need to make a call to Three microservices or three other services and aggregate the result they can do that It can do filtering you can do chaining you can do all kinds of interesting architectural Patterns and then it also has the connector. So if you want to hook up your super modern like react front-end to a FTP server or some other kind of Server that you may not familiar with there's probably a connector for it in camel. I think they have 300 or more Yeah, so it's really an integration technology and it made it seemed to make a lot of sense as an API gateway because that's exactly what I was doing I was calling different services and then filtering and aggregating the results So yeah, so that's what camel does it to kind of glue things together So is camel different than camel K or is there is that the same thing it is they're related camel K is the is the Essentially a way to run. So when you when you're when you're building an application with camel You create what's known as a camel route and it's basically a snippet of code that says, you know If this call comes in on this address or this end point do this other thing and then return the result So that can be expressed as a Java application Using camel it can run in a in an app server can run as a you know, it's a runnable jar file or whatever camel K takes it kind of the next step further where instead of you building a container and and and And you know deploying a container Starting up a pod and there you have it you simply take your snippet of code and you submit it to the camel K run time And it then chooses a run time to actually execute that kind of like in a serverless or function as a service Okay, so it's but it is you can basically use you know the same camel that you know and love in sort of that serverless Context so that's actually one of the things we're looking to do in the cool store amongst many other ideas that we have no time for Delaying than you might be interested in that Stuff like that. We're looking you mentioned AI There is you know, you could imagine a feature where it's like if you bought this thing You might be interested in these other or maybe that's a machine learning I don't know that I'm not a strong different. I don't understand the difference that much between a we covered that in a show This is a personal pet peeve of mine. So yeah, so Modern modern thinking right now is that machine learning is a subset of AI so Basically is that it's a it's a subcategory. Yeah, but if you go back to my AI work in college You would disagree But but we covered that in a show and it entertained me at least and we will definitely cover it more In the future is my goal. Nice So Narendra one of our regulars ask is came as camel camel K mainly Java oriented That is a good that's a good question. It's obviously does do Java you can also write routes with XML And they also have a DSL that you can use I believe is also Java. I think they do have other bindings I'm not entirely sure on that. Yeah So so I was gonna answer as being kind of a wider like I've done a lot of stuff besides Java as well as Java It's it's a very Java world thing But it is definitely used elsewhere as well and this kind of goes back to that service oriented kind of model, right? Is that you know camel is like it's more it's more like a service platform than it is like a language binding per se you know or if you think of like What do you call it Communication like a message bus, right? It's like many message buses are Java world But or even the written in C for example for performance, but their experience to a Java user is very Java ask So you have so it's similar to that in that, you know In the Java world you see camel a lot in the Java world You also see message buses a lot, but that doesn't mean they're not in other worlds. I would say it's more application domain So if you're doing true, you know kind of in-house IT or even public-facing, but like true business software You know or you know B2B type software that kind of stuff you'll see camel a lot as well It's like message buses You know, I did a lot of work with message buses for example because I did a lot of stock trading or stock Company work, you know, which is a lot of stock trading And camel camel is also a big integration layer as well and one of the things I was going to bring up is to your earlier point about Kind of the business logic stuff is that's actually one of the reasons Like the mainframe stuff is often still there is not just because the mainframe functions Can perform so well, which they really really do right? They just you know, they're so much faster than almost anything else, but also because no one is quite sure what the business logic is anymore And so as a result It's actually safer and better to front-end the existing transaction Sometimes even through regulation, right? You might have to go and get re-re-approved If you're an insurance company or something like that and If you can't replicate the results exactly you won't get re-approved without a full-on audit in that kind of process. So You know, so you you use things like these integration frameworks of various sorts message busing camel you know, even like It wasn't JBoss, but IBM's IBM's app server, which I'm blanking on the name of What's fear? Yeah, web sphere was always really well known for its integration with mainframes shocking, right? but you know if and so you use those integration layers basically so that you could Hide that complexity and it would still be there But at least you could worry about it another day. I think ESBs also grew up in that time. Oh, yeah, yeah, right. Yeah, of course So Yeah, so it camel is not like Nats in the sense. It's just a message cue I mean and Nats is obviously a lot more than a message cue now with the 2.0 release, but Think of it as kind of like a glue layer between all the things that you want to like tie together that might be disparate different like The services written in this language the services are written in this language and we need to wait to talk to each other And this is it right like yeah a good description James It's yeah, exactly kind of enables distributed integration where like in the past you had sort of the integration competency center And when you needed a new Integration you would go to this team and they would take six weeks to build it and it might not be exactly right now You can kind of essentially do a client side right with camel You can kind of build in that integration into the individual pieces and kind of distribute the load of building Integrations from a single centralized team out to a distributed team Also lines out well with microservices well and and almost almost as importantly if not more importantly your vendor can deliver them Right, so right so your camel vendor, you know red hat for example can say Here is a slack integration for example, you know or whatever and and give you those pipes You know or like a camel and maybe I'm mixing my groups but camel and Kafka for example are big like coupling these days and You know kind of like with open shift for example, you actually have a bunch of this stuff just integrated So you just can kind of consume it rather than having to build the bridge as well Which is you know because it's a standardized way of doing these things all that stuff then you can only you only have to build that you know slack I the reason I'm thinking of slack is just because I was in a like future of open shift kind of meeting the other day and Slack was one of the things that is in the pipe So and as Chris often says we live in the future on this show and yes the future may or may not happen So you know take it with a grain of salt, but we did I did hear that slack integration was one of the things they want to see coming through to open shift and Yeah, so I know I think I like these integration tools are Like hugely useful, you know even in your personal life if you just think of something like if this then that That's the same concept. You know, they aren't using or maybe they are underneath. We don't know But you know, they they're not presenting it as kind of the same standardized model But it's the same concept. It's like I have a message You know, I have a message or a packet of this format over here Be it slack or Twitter or you know, whatever and I needed to cause some event over there and so there's some sort of Manipulation or translation or whatever that kind of happens along the way and the more we can standardize that the less often We have to build it. Yeah, and there's there's actually some work going on in in the Knative space around this So Knative we have Knative the serverless framework, which is really good at scaling You know pods up from from zero or down to zero then on the top of that we have events and then functions and so this whole notion of Kind of like if this and that like throwing off events from a producer and then responding to those with a consumer serverless function We're starting to see that as well as as a as also way to integrate things. So more and more vendors are producing these cloud events and there's a standard being developed in the in the in this Knative projects For representing those events for an event-driven architecture And that's one of the things that we've we're still we've started to incorporate into the cool store as well actually, so, you know, I don't really mean this to be turning into a camel show, but Somebody asked in the chat about camel versus red hat fuse and I think that's an important thing to answer And I don't know if I could do a justice. So You're gonna try no Okay Yeah, so I mean it's it's so is the short answer is fuse is the red hat product eyes and supported version of camel Yep, that's that's kind of red hats. That's our bag, baby. That's what we do product eyes and support open source Yeah, I remember that. Yeah, I did I did a bit of that with this other product. We have it's called Linux So I did that for a while But all right, so I don't know. Were you able to prepare some demos? Do you want to show us the app or yeah? I can show you I can show you some of the app Let me I'll go to share my screen and see what I got for you here Let's see. Okay. So let me switch to my desktop here So I had to just couple I have a screenshot and then I have the actual running app on OpenShift that Daniel Also help and Daniel, feel free to chime in if you want on the on running on OpenShift So this is the original cool store. This is the the the genesis of What's the what we considered to be the modern course cool store demo from Red Hat today? You can see it's a retail app. You can choose some some products on the left. You click add to cart Then you click and you see your shopping cart totals get summed up over there The promotion and shipping gets calculated through that business rules thing I was talking about And then you can check out and so that's sort of the that was the basic demo. It's a it's a monolithic demo. You you build a War file web archive file, which has the VRMS guts in it And then you deploy it to an app server like Jboss EAP Wildfly and so that was the original monolith. So that's just a screenshot. It is still available You can still run it on the I can I can I can throw a link I'm not sure where I would throw a link if I wanted to throw a link in the zoom chat. I'll pass it over. Yeah Yeah, so I'll throw a link to that in a second, but this is the original cool store and then So we took that and one of the one of the ideas was as you mentioned earlier Langdon the mono to micro the migration This is we red hat has tons of customers I'm sure there's many others out there that have you know existing apps that they have no idea what to do with them But they just know they're old and slow and they want to make them fast and awesome and compete in their whatever Industry they're in so digital transformation is the name of the game and that what that boils down to in in reality is You know taking applications and either kind of lifting and shifting them over to a different platform that has some features like OpenShift or Refactoring or rewriting, you know going from a monolith to a microservice So we have some tooling a red hat that we threw it. We so we took that tooling. We took the monolith We took the rewritten microservices and turned that into a workshop And so the end result is and this is all running on OpenShift And so we use a lot of the features for container orchestration that you find on OpenShift for doing advanced deployments for doing CICD pipelines And and other aspects of the platform and more modern times things like OpenShift serverless and service mesh with this deal So this is the let me switch to the other one first. So this is the This is the monolith lifted and shifted over to OpenShift and on to JBoss EAP Part of that part of this is is a competitive thing where we show an existing app written in Oracle WebLogic And then we use the tooling to migrate it over to a much faster and lighter weight product Sorry, this shouldn't sound like a sales pitch, but that's the point of the workshop So would you like faster and lighter weight on this channel? Don't worry I was a big fan of BEA WebLogic Yeah, okay with Oracle you don't do just out of Kerasi is this is this source code for the lift and shifted Version available somewhere. Yes, it is. It's it's I mean, it's it's part of the source code for the workshop and demo So okay available and we can we can throw some links in there to Daniel if you want if you're able to throw a link into for the the monolith source code That might be useful because yeah, just throw it out there for anybody, you know kind of for the audience, right? It's like You know, I I have a talk about or I have a lab. I do it summit about this. It's that like do not try to Magically convert your monolithic application to services instead Something like a lift and shift get that whole janky mess into containers just any which way you can Then start pulling out pieces and making nice services out of it. Yeah Pattern is what it's called. Yeah Bangler pattern is it's good in in theory, but there's and language we talked about this earlier like The you know from next cloud is is from what I understand an actual production app This is never should ever be used in production And because we take a lot of shortcuts when we're doing this right and so like For example, when we move to micros so this is the monolith running here I have a single postgres database backing this thing I'll just go ahead and click on it and it's the store right now It's a modern version of the store with new images and a front and that's a little more Dynamic so you can add to your cart and you can check out your shopping cart And you can check out and buy things and it's all good Notice I never logged in, you know, so there's no single sign on there's single sign on support We haven't added in this particular demo but we also took a lot of shortcuts as far as migrating a monolith to a microservices because You have in this case a single database in the other case we're gonna have like eight databases, you know They're the challenge of of migrations is not necessarily in the code It's in the data because that's where the that's where the value is for companies And that's what they really care about and if you blow that up you're in deep trouble So taking a monolithic database and converting it to a microservices number one You no longer can do joins right like database joins like sequel joins And number two you can have potential for corruption if you don't time things correctly You could have two microservices trying to change their state and then they get out of whack And then there's no way to reconcile that because you don't have the the protections that you would have in a monolithic database So we sort of hand wave over all of that in the in the workshop and say, you know a true monitor micro You're going to be hiring, you know or doing their in-house or some expensive consultants to come in and do things like event Storming and domain-driven design and yeah exactly and do it right instead of just what we do in the workshop Which is we go from monolith to microservice like magically So I will say though if you if you want a good example of where it is done with a production application even if that application is not terribly complex although I think Data storage is always a challenge the next cloud actually does have both So they have a monolithic version and they have a service-based or or service-ish based version and seeing all the changes between those two because they they ship both these days Is really really interesting So yeah, I would definitely recommend that for anybody who wants to kind of learn how to do it as a kind of another Example, but I think the nice thing about a demo version is that is that you do skip over some of the complexities because they the complexities are Like kind of unique to the application that you're working with usually Anyway, so if you can kind of get the broad strokes, you know from something like a demo application I think it is a good start on how you might need to do it You know or how you might deal with your own application Yeah, and I will say the the original monolith even though it was a monolith It wasn't just a you know Flat set of code. I mean it was still kind of structured Service that ugly. Yeah, it wasn't that ugly I mean it had like you know Java packages with you know model and service and impulse and you know kind of a standard way to do a Monolithic app with with multiple different functionality So there was some level of kind of one-to-one mapping if you look at the source code of the original monolith versus the source code to some of The services and the microservices one They're not drastically different because the logic is more or less the same So it wasn't that much of lift and so the tooling that we have to do this sort of I won't say automated but assisted migrations Kind of looks at the source code. This is a migration toolkit for applications. It's an open source products from Red Hat It looks at the source code and it kind of makes recommendations The easy stuff is like yeah, you're using this proprietary API from Oracle You really probably should be using the standard one from the Java EE world Those are easy, but the harder ones are like doing you know refactoring of large chunks of code And so we kind of walked the user through doing that in the workshop So yeah, but we do take shortcuts and we call them out. We're not trying to say that it's magic But yeah, it's definitely something that you have to take and take into account when you're doing an actual migration of a production app So so this is the monolith and then in the workshop we kind of walked through creating the different services So we have an inventory service. You can see there's a little number here It says like 500 and something left or 734 left There's a little icon for a location and then there's the products themselves like the descriptions and the and the images and then we have And you promise that if I if I add to the Kubernetes shirt to the cart and then buy it it'll show up in my house Oh, yeah, absolutely. Yeah Yeah, we totally do the whole payment gate, you know PCI compliance and everything Yeah, no Yeah, so so that's that that's the monolith and then over time We we take them through the microservices journey and we not only do the transformation of the business logic but we introduced some of the some of the concepts in the illities of a microservice like, you know reliability and fault tolerance and Scalability and so forth and then we end up with them. I'll switch over to the other namespace in this In this open shift cluster called user one dash cloud native apps And this is the the sort of the the end all be all microservices version There's a lot of stuff. There's lots of stuff going on here But you can see the individual services like we have a cart service which is backed by an infinis band date or JBoss red hat data grid Which is an in-memory data grid There's the order service which handles ordering and it's backed by a Mongo database. There's the payment gateway, which is Using serverless technologies with Kafka to respond to orders that hat when an order is placed Something is pushed into the Kafka stream and then that's responded to by this serverless component here the payment service and then we have our Our our Kafka cluster and we have an inventory service which a lot of these have little mini UIs on them Which we use throughout the workshop to kind of give, you know, it's it's it's hard to Get it your head around all this at one time. So we kind of build up slowly So we say okay build the inventory service and go make sure the info the fake inventory UI is okay And you're seeing the the locations and you're seeing the quantity in the item ID And then we also do things like we'll kill off the the pod and this thing will go dead and then come back to life Automatically through you know, self-healing of pods which we kind of demonstrate some of the health probes and Kubernetes So that's kind of a simple example. We have some others. We also have a spring boot Catalog service which shows you the different Things available in the catalog and click properly and show you the catalog Which is kind of like basically the UI but boiled down to a table name description price inventory or a quantity So, yeah, so we use these services and this then and this is it This is the kind of the end state of the end of the workshop after you get through all this This is like a full-day workshop to kind of build all this up And you kind of you kind of put all the the pieces they kind of start to show up as you kind of go through the workshop Yeah, exactly. Yeah, yeah, that's cool. Yeah, and that's that's what you linked to early, right Daniel that's what you linked to earlier is that workshop like the the path for that or The monolith one right there is a monitor. I'm gonna bring a dead this cloud neighbor repatriate as well Okay, cool. So here's the front end. So that so the big the big finale here is you go to in your cart You you add something to your cart you head over to your cart you check out and then we ask you for payment information. So My don't copy this down or buy anything Right exploration I'm just making stuff up here 1940 nice Just put in junk you check out and then when you check out that kind of fires everything off And you'll soon see this payment starts to come alive because the order was posted to Kafka the Kafka Our serverless payment gateway responded to that notice that got an event from Kafka And it came alive and processed that payment and then with some built-in delays to simulate sort of real-life Delays and so then if I head over to my orders, you can see my order here is now in completed I think I can't see because the the zoom so window Really tiny Yes, I can make all this stuff bigger just yeah, I should have known that I should know Anyway, so actually just because you know, we keep mentioning it or whatever and I have this weird history, but Can you explain a little bit about Kafka is because what's funny at least for me is that when Kafka came out It was essentially real-time Hadoop and almost nobody talks about its ability to do that anymore which was You know basically a map reduce functionality But that's what it kind of originally launched as so so in your mind two people who kind of use Kafka all the time Versus somebody who kind of just watches the trade press about it. What is it for or what does it do? So hey Daniel, do you want to take that one? Yeah, so sure so Kafka is based on address your district messaging so you can actually use the Just a simple message broker to handle your Topping message of a payload from your application or some client to specific side But sometimes you got a lot of tons of the payload or a messaging from Thousand of your Microsoft application. So Kafka cluster Definitely can handle there are district metrics and district payload on your cluster like a Kubernetes Spare a lot of thousands of Microsoft's application. So we're going to showcase the Kafka cluster in this Microsoft's architecture How to use that and then even though this is simple retail application. We don't need to handle the Tons of the traffic, but we can showcase how to use that thing with the Kafka cluster with the Serverless technology with some bingo both of technology at the same time Well, and we know it's like super scalable, right? Because it came out of Twitter, right originally And it's how they used to do exactly what's referred to is the Twitter fire hose Which is actually a very hard license to get where you can kind of get all of Twitter's feed Which you know, I think it's limited to like six companies in the world. There's something one of them oddly enough I don't know if they're still around but they there's a Boston company called Crimson hexagon Which tells you about basically they do social media monitoring for your company or whatever and so they had a Twitter fire hose But it's like could we have a more like dr. Evil sort of company name because I was just like Crimson hexagon It's a little weird. I mean, it's a little bit more explainable because I think it's a it's a Harvard Like incubated company and hexagon and sorry and crimson is Harvard's colors So the you see crimson in the Boston area a lot more often. I think then you see it kind of elsewhere in the world just because of Harvard But yeah, so I used to have some friends who worked over there And I was just like that is the best company name if you are super evil But So all right, cool. Thank you for that kind of little kind of sojourn around Kafka You know and yeah, so this is this is kind of what I wanted to show is that you know Here we have kind of a put-together fully kind of microservicesized app right that we can Do experiments with right so we can talk about how can we you know? Hey, we want to do our payment gateway We want to switch from you know payment gateway a to b I actually used to know the list of four, but I can't think of them right now But maybe it's just like striped to you know to somebody else and You can do that with something like a canary migration for example You know and you can have kind of in parallel Accounts with them while you're running and then you know and just basically farm your traffic across Yeah, so what else actually is somebody in the chat there's a bunch of questions in chat I wanted to oh, yeah follow up on why don't you tell us what they were cuz yeah, yeah, so I'll just go in order here So Islam I'll screw up your last name L the military. Yeah, are these solutions? Available yes, that's in the links, but he also asked what are the most challenging obstacles when promoting the solution? Objects across environments slash pipelines That's a good question. I mean It's a generic challenge. I mean without with or without open shift It's it's challenging to do that like safely in a production environment to replace one service with another or move it from You know a developer's desktop to a test environment to production obviously Kubernetes and open shift make that easier with things like namespaces and You know the the the container image storage and the way that Sort of containers are quote-unquote promoted across different Environments, which I assume that's what the question was about like going from the developer You know dev to test of production and if you can then incorporate pipelines into that It makes it even easier for the developer just because they all have to do is push code so I guess the challenge in that case is just kind of setting it up, but it's it's not that Difficult I think the hardest thing is is For the workshop is Creating all the sort of yamls that we need to deploy these things and I know that that's getting easier over time I know it as our developer tools Get easier to use and more powerful that that will be reduced over time But it's still you gotta kind of have some some yaml descriptions of these things to get them deployed very quickly To do things like setting up a workshop so that they can then so the developer doesn't have to do that So all the pain we we experience and setting up this workshop is something that you would have to experience in a production environment in terms of getting an application defined and deployed and Flexible enough to be able to migrate pieces across different environments And then on top of that there's the challenge of what we talked about earlier like a B testing or blue-green deployments or dark launches or whatever you want to call it to where you can kind of You know distribute traffic and across different implementations based on Safety, so if you if you want to you know bring in a new version of the payment gateway You maybe you want to only expose it to 10% of your users and see if that thing blows up Instead of exposing it to all 100% and it blows up and you're you know, you're out of business So those kinds of features I mean they're great features, but you know still there's some challenges in setting that up So the next question is oh, it's just gonna ask a comment on developer tools One of the things that you see over time is developer tools get better as the people developing developer tools Start to understand the problem better And kind of by way of example one of the things that I read that was really really interesting about Why IDs are useful versus text editors is basically if you have a highly dynamic changing language like a language that is Kind of changing how its constructs happen in a sense all the time People who can use that language tend to be text editor people Because an IDE won't help you much But if you change if you're using a language that is not changing as much for example, you know, Java or you know Or even your C sharp or whatever The the languages are a little kind of slower to drift And so the tooling that you get inside an IDE is actually much more useful than it would be in say a language like Python and So I thought that was a really interesting kind of comment So basically it's like as a language matures you get IDEs, you know And so as I think we see these microservice oriented applications Mature or exist for a long time essentially. I think you're gonna see more and more tools and you've seen this already, right? That make the migration to them or the creation of them Faster and simpler and easier and reducing the complexity because basically we just have to we have to understand the problem before we can write fixes for them And I think that's been really an interesting journey. Yeah, there's so you're absolutely right about the language stability Leading to you know more feature rich IDEs But that also can apply to the intersection between the developers IDE and like the deployment target So, you know, once you're done writing the code then what like normal in a in a very efficient production environment You would push code to git or github or wherever and then that That was set off some pipeline that would go off and do it But for a developer who is who is wants to kind of do that Ahead of time they want to be able to deploy on their own desktop, right? The the tooling for getting an app Define its dependencies defined and deployed and then running the app in sort of a production like environment I think that tooling is still in its infant stages, and I think it's getting better with some of the work in the Eclipse project Eclipse J and Which is a web-based IDE, but they're also working on defining how a Production like environment can be instantiated by a developer so they can run this code after they After they're done writing it in what would look like a production virus So you have a fake database. I mean, it's a real database with fake data But it's using the same schemas as production You have the same services as production and you can kind of test your code So those are that's a really important Advancement that we're seeing that I'm seeing personally the other one I found really interesting is Istio We didn't talk about service mesh much today. We do use service mesh in this application But it was of interesting article someone posted on one of the internal Istio boards about the title of the blog posts was Essentially the paraphrasing it is like Istio should fade into Obscure not obscurity, but fade into the background. It should not be something developers have to care about today And so I think that as technology sediment into the underlying platform I think they should you know be essentially Transparent when they're intended to be transparent and not have to have a developer write some crazy YAML or understand even what a service mesh is It just kind of becomes part of the the operating system of the of the container platform if you will So yeah, so next question No worries, let's talk about just cock of Kafka for a second because it is very very powerful and the questions from Michelle Orlandy MQ is a subset of Kafka, right? And yeah, like there's a lot to Kafka so I will let y'all explain that Yeah, I don't think and so MQ is like a message queue in general like the durable messaging Concept, I think they share some things in common right Kafka has you know topics and Subscribers and pub sub and that kind of stuff it doesn't Aim to solve the same set of problems that a message queue would solve Kafka is very good at storing large amounts of data very quickly and sort of a time series You can then go back and replay it and things like that. You can cluster. It's very highly scalable and message queues are more About like if you if you take money from one account you better it better land in another account or that operation should fail altogether It shouldn't be where you take the money from one account and then maybe the other one happens at some point in the future But nobody really knows so message queues have these kind of guarantees about you know delivery Mechanisms that that Kafka really doesn't have as a as a as a design goal if you will so I'm just gonna add like I mean so message queuing is often referred to as reliable. Yeah, the capital are And it's a reliable messaging so it's guaranteed to go through often item potent So you can actually rerun the same message multiple times and it will not trigger the same event again Whereas Kafka is way more like pipeline And so it's like, you know, we're talking about the Twitter fire hose, right? It's like If you drop a couple messages on the floor, it's not that big a deal, right? You know, whereas like a message queue will never drop one on the floor It's much more like a database so it's in some ways similar to like storing something in you know Like a database versus, you know, kind of storing things on a file on disk or something It's it's kind of hard to compare but Kafka is generally much more about speed of pipe Rather than guaranteeing every message gets through whereas message queue is more about the safety and security and Like reliability of the of the pipe or of the message is getting through exactly So they're similar by different cases similar concepts Yeah, that's why Kafka we can call out streaming platform Messaging and disarray storage and then processing that are continuously Rather than traditional make the messaging technology Yeah, I would also say Kafka also does some transfer can do transformation on the content as well And whereas a message queue generally won't for reliability reasons. So like as in or like auditability reasons So not that's not always true, but mostly true Yeah, they also do things like flow control or back pressure as some of the concepts from the integration world that you find in message queues like native support for Yeah, whereas, you know with Kafka, you just buy more hardware. Yeah, um So all right, so let's let's pause there. I'm not sure how many more questions we have but we should try to hit the I think we're good on the questions. Uh, let's go ahead and shout out to our build team Oh, right. Yes. Sorry. Yeah So, uh, yeah, we wanted to bring it up, you know in our chit chat at the beginning of the show We tend to you know, kind of talk about stuff that's going on and as Many of you are aware, uh, it was martin luther king jr. Day on monday And uh, and we wanted to kind of shout out to one of the Practices that red hat does for a bunch of years now. Uh, and run by an organization called build is uh, which we we figured out what is Uh, blacks united in leadership leadership diversity. Yes. Um, I I have of course blanking well under the gun. Um, but uh One of the things that red hat does is like this day of service during mlk day and so Where we basically organize a bunch of different activities that people can participate in And you know, if you participate in these you you can kind of take the day off from work without actually Kind of treating it as a vacation day and work on the service stuff And there was a hackathon in particular, uh, that that took place That maybe we'll cover the results of in a couple weeks. I'm not sure I know I know it was a 24 hour hackathon I just don't know whether they were doing like when they did the judging in a sense Right, you know around, uh, basically some, uh, trying to Model if I recall correctly, um safety stops, uh in Basically in various precincts so that uh, you can kind of categorize, uh, whether those are taking place In a good way, uh, so Yeah So maybe we can cover that in a future show, uh, but yeah, so we wanted to give a quick shout out They do a great job. There are a bunch of good speakers that you could also kind of listen in on They did a kids program as well. Uh, so shout out to the build team for putting that together for the build team Seriously and making it virtual Yeah, like this was this was the hardest year to do it and they pulled it off with great success So that's a huge shout out some big props to you all on the build team. Thank you very much. Yeah Um, all right, and then points, uh, let's see even find the window. All right. So, uh, for our guests, um One of the things we like to do in the level of our is we give out what we refer to as, uh, sweet sweet internet points Uh, and sweet sweet internet points are, uh, think back to slash dot old school what they used to call karma uh, same kind of idea is, uh, you know, if you participate in the show, uh, we like to reward you for doing it. Um, and so we Uh, give out these points basically coming for the the episodes or submitting some issues or submitting a pr against the episode, uh Reco like the content, uh for the show. Um, and so Here are the current standings Um, I'm just gonna find the window. Sorry. Wait for it. Wait for it. There we go. There we go. Um, Let me, uh Fix that. All right. And so as I explained last episode, we have been messing with the numbers a little bit Except, uh, this should make most people happy. The numbers largely went up versus last week They largely went down. Um, but I think I think I'm done futzing with the numbers And this is all in support of making the sweet sweet internet points having a value beyond intrinsic Yes And having a real value Yes, what had intrinsic value is real value True So I will throw, uh, this week's code into the chat And, uh, hopefully I don't have any stupid errors, you know, whatever. Um, but Netherland's hack them, uh, with 3,900 points, uh, which is awesome. That's awesome. And, uh, Narenda with 3,400 points. Um, I didn't see Netherland's hack them today, but I did see Narenda Uh, no affriction 2,900 and then Joe Fuzz still holding strong at 2,200 And then, um, I'm not sure how to say is it Detective, I don't know what debt is supposed to be but yeah, Conan Conan could be debt nation. Who knows? Yeah, yeah, uh, with 500 points and then another newcomer, uh, Thomas Mota with Tomas Mota probably, uh, with 400 points and, uh, yeah, so Thanks so much for, uh, participating. I I think this is a hilarious part of the show. I really like doing it I really like giving out that's one of my favorite things on the channel. Yeah, so, uh, You know, when we really appreciate y'all, uh, participating, uh, you know James and Daniel if you want to all you have to do is go to the link there and you can get your own internet points. Um Debt is short for detective. I thought so, but then I wasn't sure. Um, I think it's a it's a, uh A pop culture reference that because I'm too much of a nerd. I don't get Yeah, so yeah, I'm gonna look it up now So, uh Yes, so thanks again for everybody for participating. We really appreciate it and we would like to, um See more internet points in the future and uh, you know, and I will I I continue to try to, uh Convince other people on the channel to give out internet points as well. Um, and maybe we'll we'll get there someday. Uh, and, uh But yeah, that's uh, that's what I got Do we have any kind of closing questions or comments or thoughts or anything else that you'd want to kind of add? I'm looking back through nurendev as always wants us to make crc speedier and more lightweight I We're working on it. It's work in progress. I don't see any other, uh questions. We haven't answered either via chat or talking, but yeah Till more thought that could have stand for detroit and that would have made me happy obviously, but It is apparently a I don't want to get it wrong. Uh, not anime. What's the other one called manga manga? Yeah Apparently a character from that so So, yeah, I looked it up real quick. I'm not in that genre, so I don't you know, I have no, uh Yeah, everybody wants a better crc apparently Um What's funny is I'm also not that like into anime manga, you know, I've seen some of it or whatever But two of my children are like crazy into it and I don't know where they got them on man You should just yell over your shoulder. Hey, what is? Yeah, exactly Yeah, they probably would have uh, they probably do a better job hosting the show to be honest It is anime. Okay. Cool. Awesome. Uh, so yeah, all right. Well, thank you so much for coming Uh, we really appreciate it. Uh, hopefully we'll have you back sometime soon Did you have any uh, kind of closing remarks or anything you wanted to kind of Oh my god, I forgot to say No, I don't think so I I'm looking forward to my sweet sweet internet points my starter points, right, right I found that pretty fun. Um, I was I was kind of worried it was going to be some kind of a quiz at the end That is that is not a terrible idea We we did joke around about doing um doing a kahoot, uh at one point And giving out extra points, uh, if you if you like one in the kahoot But we have not executed on that craziness yet. So we'll see maybe Yeah, okay. That's cool. Yeah, thanks a lot for having us on Very fun to to kind of reminisce a bit about where where where it came from and where we're going with it So hopefully we'll we'll find some additional new features to add and uh more compelling tech to add to it to kind of showcase that stuff Lots of interesting things happening to add to that awesome well, thanks again, and uh Islam, uh, there was a quick question and here about you know, open shift cluster sizing and everything Reach, I would say potentially, uh, it depends on the size and your ha needs of that production cluster But it's always nice to have a backup cluster just in case you need like to upgrade and an upgrade goes bad, right? So, um It it really depends on your scenario work with your redhead account team to figure out what's best for you is what I would tell you um, because there's no perfect answer for any, you know Car, you know, kind of organization That it's the general that's the general answer to that kind of question, especially, I mean like, you know How big is a cluster? Right? How you know how small is a cluster? Um, but uh, I would say in you're on the right track Um, you know, it's you don't have to have 40 No, no, you don't need 40 clusters. Um But yes, we appreciate everybody coming on uh tune in later in about an hour. We'll have uh, the open shift administrator office hours So bring your questions and everything else But we will be talking about Open shift on top of redhead virtualization. So tune in and learn some vert and some open shift all at the same time It'll be awesome Well, is it virtual learning? No without vert Technically, I guess Maybe yes, you're welcome for the bad jokes. That's that that will be it for the day. All right. All right. Thank you, Daniel Thank you, james and always thank you, lingdon. Uh, we will see y'all next time. Good luck out there Except right. Bye. Bye