 Anyway, thank you for surviving throughout the day. Looks like there's more than I was expecting. I was expecting like two people here. That's cool. Anyway, first thing I wanted to say is I want to thank my co-presenter who's actually not here. She ended up being somewhere else in another continent. So that was interesting. So this was actually her idea and her brainchild. But I'll try to keep it in her spirit. So anyway, to myself, I'm actually a bilingual person. I look around and I actually see a lot of bilingual people or trilingual or omnilingual people where I tend to do work. And I think that that's a really big valuable asset that we have because it changes your perspective, right? I also know a lot of computer languages from Ada to XML, like really everything in between. And I think that's valuable for any developer to have. And I actually did invent a language which I would say that everyone should try to do but it's really a tough thing. And if you're gonna do it, good on you but it's a very challenging effort. All right, so what is a polyglot? A polyglot is somebody who can master multiple languages. And it's really somebody who can kind of dive in from one language and one perspective into another perspective. And it doesn't really just mean programming languages. It really also means things like backend services, right? So if you have a SQL server or a Redis cache or something, you know what that means. And you actually have a perspective of why is this important or not important? The other thing is that's weird about programming languages is if anyone of you have taken any comp side courses when it comes to language theory, you know that one language is actually equivalent to any other languages as long as it has some sort of constraints. And in general, the programming languages that we deal with really do follow these rules. So it's kind of strange that we kind of intuitively know that this is a possibility but we don't utilize it. We don't go out there and actually try to make it so that people, you know, we don't force Java developers to do .NET things. And why is that? It's pretty interesting, but I think that there's definitely power in that. So why do we do polyglot? Or why is it important? Again, it's the different perspectives, the different systems that are involved. I find that it's a better use of our intellectual capacity when we can actually find, hey, maybe this is better done in one language versus another. And it's a good way to actually communicate between your own teams, right? So if you have a Java developer or .NET developer, you might have different perspectives on how to talk to them if you are an AngularJS developer. And having at least a glancing understanding of what those people are trying to do and what they're capable or their systems are capable of doing is pretty valuable. All right, different perspectives. So this is kind of the interesting thing. I've seen so many organizations that have leadership at the top that say, you know what, we need Java developers. And that's kind of an interesting topic to me because I don't think I look at a developer and say, you know what, you're better at a Java, being a Java developer than a .NET developer. It's kind of an arbitrary conversation. And I don't think that the business leadership should necessarily be driving, hey, I just want this platform or just want this because it means that you can't really adapt to change from that top level. If you're a developer, I don't even think that you can be a non-polyglot, especially now. Maybe if you're a cobalt developer doing mainframe stuff, but that's kind of a dying breed right now. And architects, I see it all the time, these really beautiful drawings. I actually saw it from our room sponsor yesterday in their keynote, this beautiful drawing of all these nice little boxes of how everything's supposed to interact. And it's really strange because I never see software that's that beautiful. I see software that's kind of cobbled together and kind of, you know, it works. We want to make it better. And I think that the architects really are, you know, kind of fooling us when they go out there and say, this is how the system's going to work because it never comes out that way. It's never a recipe. We're not making cakes here. We don't take a recipe and just make the same thing over and over again. We have to change and adapt depending on our business needs. The last thing is the operators seem to be a forgotten entity within polyglot, right? These are the people that run this application day to day. If you're not going up to them and saying, hey, by the way, I'm writing this Java application and I would like it to do X, Y, Z, you know, maybe the operators don't know what that means or maybe, you know, it's exotic to them and you should bring them in. So, you know, when you're thinking about a language to use, think about those guys too. So who here is a polyglot already, right? Who thinks they are? Well, congratulations, right? We're all done here. What are we doing here? The point is that we are. We should realize that. We are polyglots. We always have SQL databases or some other exotic database that has a different language or a CSS style sheet or something that's in a different language and that's good. And once you start realizing that these are different things, that's good. But let's break it down. So we got this application, right? This is a simple application. Has an angular front end, maybe a spring boot for the business layer and to facilitate all this, we've got bash, something to facilitate that. But, you know, we're actually not done. We can't go out there and say, hey, we got a polyglot system here because we also have other services underneath, right? We've got our data services with SQL. Maybe it's got a JSON store or something like that and then infrastructure. You know, we're a cloud foundry so let's talk about bash a little bit. So we might have other infrastructure needs. And then we also have these things like CICD pipelines and maybe it's got a build system there so it's using Maven. So we actually have really a whole diverse set of languages that we are using every day. And they're all different. They all do different weird things and we wanna make sure that we're enabling our developers to have the freedom to do that. So again, here we have multiple layers. It can get messy pretty quickly. So why do we use different languages? Well, we use them for obvious reasons, right? They're different. They do different things. So it's better to use things that are in certain domains versus other domains, right? We wanna do a machine learning algorithm in R versus in JavaScript. It seems intuitive, right? Well, I don't wanna go out there and make an octave website that just seems arbitrary and wrong. These languages were developed for very specific use cases. And if we use them correctly, they're incredibly powerful. If we don't use them correctly, well then we get this spaghetti mess of stuff that we're not really satisfied with and we kind of go around in circles. But we can also make any language better than another one, right? So the classic example here is C++. If anyone uses C++, who uses Boost? Probably anyone who does anything in production, right? But this whole thing of programming is actually fairly new to humanity. It's only like a 50 year, 100 year endeavor for us. So we're still as humans, still pretty new at this. And the future is unknown at this point in time. We have machine learning coming up. Maybe we'll create a machine learning language coming up there. And as a developer, you'd be like excited but then fearful of it. But we have to make sure that we're prepared for that. And that's gonna be interesting. So let's talk a little bit about how do different languages interact, right? And it's kind of obvious. We all kind of realize this. We use REST services and whatnot. And we use those interfaces as the conduits to change. These are those contracts that we negotiate between ourselves that go out there and say, this is how my system is going to interact with the world. And it's really important and it's so trivial at the same time, right? We go out there and we say, hey, this is how my services act. But we don't talk about how the client is going to, or we might talk about how the client is going to interact with it, but we don't understand necessarily all the clients that are going to interact with the system. We just say, okay, here's one, here's another. And then we force people to go through that one channel. And that's okay, but it's not always the answer, right? So let's talk about when you wanna change something, right? So imagine you have a bug with your interface itself, right? We wanna do this thing called an anti-corruption layer, right? So an anti-corruption layer is just basically a layer to help you change, right? So the first thing we do within anti-corruption layers, we go out there and we put something in between this, right? And both sides can understand how this thing works. So it's, you know, your interface is going in the same and it's coming out the same just like it was before, but you put that layer in there. This is where interfaces really can help you out. Because the next thing you can do is start routing your calls into another place, right? Into maybe an upgraded version of your application. And it seems, again, so intuitive, but people don't use the power of, you know, Cloud Foundry or these other applications to actually create that shim. And then we can go out there and get rid of that anti-corruption layer and just connect to the other services. So this allows us to actually go out there and do massive changes to something that we used to say is steadfast, unmoving, unchanging. We can actually go out there and change it, which is something that a lot of companies feel are paralyzing them. So, you know, that's one pattern that's really been effective and I think it's been underutilized a lot of places. The other thing is, is breaking up a monolith. This is probably, everybody's done this a billion times, right? But okay, we're in a polyglot talk here. How do we break up a monolith and why does polyglot even matter in this conversation, right? And the thing is, is what we can do is we can find the actual heart of this application. And I've done this at a client site where I've figured out, okay, this is the central piece. This is the thing that connects everything together. And you really rip out the heart of this thing and change the language. It sounds weird but it's very empowering to do because what that does is it basically takes this core feature, changes the languages and now everybody has to figure out what to do, right? And it seems weird but it's a very big catalyst for change. So what we have is we eventually go out there and we take that heart out and then we can start fragmenting out those little pieces in whatever language we choose, right? So in my particular case, I took a .NET application and changed that heart into Golang, right? Very exotic thing for that company. And it was the catalyst to change. In fact, I talked to them today and they said, yeah, you know what? This thing is actually moving forward a lot faster than we were expecting. So being a polyglot, all it is is it gives you more tools in your toolbox and make sure that you're understanding and conveying your point a little bit better because you have a perspective of maybe somebody else's understanding of the world. And quite honestly with the pace of change and pace of technology, it can allow you to pick and choose the things that make sense for you that enable you to move faster. And with that, because I'm blowing through these pretty quick quickly, that's it, that's all I got. So if there's any questions, feel free, I have a microphone. So, oh, thanks Mark. Any questions, you have one? You gave an example whereby when the program you try to convert into Golang and that sort of thing. Do you suggest that a big legacy monolithic application, it should be translated into multiple type of languages, means the part of it in Golang, part of it in Node.js, part of it in Java, is it pragmatic and means really giving values, that sort of thing? Okay, so the question really comes down to is, would I suggest doing this, right? Like this, and the answer is for me in this particular case, yes. The team was first of all energized because they were learning something new. So that's really like the human aspect of it, right? The second aspect of it is we were converting something from IBM BPM, which is a very massive application and we took out the actual workflow engine part of that and made just our own custom thing to do that. So that's the background of what we did and we used Golang because we could actually get that up and running into Cloud Foundry within two weeks. We could get that core done. That said, do I think that we should always just change languages? No, I think you, we have to be pragmatic there, right? We have to go out there and say, does the team have both the energy and the discipline to do it, right? Is it a fit? Is this a Node.js application doing machine learning? Probably not a good fit, but in general, I would say, yeah, like shake it up a little bit, if you can get the team to do it, yeah. Asynchronous, say some portion, which we are from the asynchronous city of the code and then some other portion, which has a very complicated logic, so retain it in Java and the other portion which might benefit from asynchronous call, convert it to Node.js and that sort of thing, break it down and that sort of thing. Absolutely, use the right tool for the right job, right? So, you know, when you only have a hammer, everything looks like a nail. So I'm telling you, yeah, if you have something that fits more of a front end aspect of it, definitely consider Node. That's a perfect example. But that requires a very high level of maturity of the architects and sort of hands-on architect who knows the different languages and their actual benefits and that sort of thing. Absolutely, you can't do this with people like novices right out of school. Like you have to go out there and have some competence in it. That said, when you, even if you don't have competence, at least have the discipline to do it, right? The biggest problem I have is that we try to adapt too quickly sometimes and that's great, but if you kind of lose your way about you, that's a problem. In the back. So I understand the concept of polyglot, but in an enterprise, having too many people who know different languages, it didn't become sort of a management nightmare. Why not, you just put APIs over what we have so that we have a standardized way to access the systems that enterprise already has. Okay, so if I understand the question is, becomes a management nightmare just to have the various different languages. I actually would disagree, right? We have a lot of different reports that we generate for various applications or various parts of the company. It really comes down to using the right tool for the right job. If you're a very crud-oriented organization where you have just database transactions doing that, you might not have a very diverse background in various different languages. It might not make sense, but to go out there and not enable you to have tools and lock you into one platform versus the other, I think you're putting the organization at risk, right? Because there's two aspects of it. There's the human aspect of it, which is can I find Java developers to do this, right? And if you go in the marketplace, you might not be able to find those people, right? Finding a COBOL developer is a pretty hard task nowadays. But that said, all right, you wanna somewhat standardize, but let the developers be free to choose whatever they, in their professional opinion, they believe is the right way to go. But if you look at it in a different way, companies can have multiple projects happening at the same time. And there may be multiple projects who need the same resources who know a certain tool that would create a bottleneck within an enterprise. So, and that would actually slow down the enterprise considerably than doing the benefits. So what my point was that maybe having an API over what we have, at least gives a standardized way to interact with the system. And even say two years down the line, if the system goes away, that API needn't change. Does it provides you with a technical model to access a certain system? Yeah, so all of the rules for doing microservices and doing specific things, they still apply, right? It's just what is the language that that API is built in, that's really what we're kind of talking about. We're not talking about that having the resources to build something is a much different conversation than going out there and saying, what is it built in? If you don't have the resources to build applications or maintain them the way they are, then that's a risk. Having it so that your developers can jump into this code line or this code line or this code line is how to mitigate that risk. So as a developer, I would say, or a company, I would say I would want all of my developers to be a little bit more polyglot versus going out there and saying, hey, you know what? I've got this API that's Java based. Sure, it might be screaming fast and perfect for the application, but polyglot isn't just about the one application, it's about the entire ecosystem. And can you get those resources and shift them and move those humans to fulfill those tasks? I have a question on how DevOps should be handling this situation because I can give an example, like we were breaking down a monolith and we were trying to do one of the components in Go and DevOps came back and said, hey, you cannot do Go, we cannot maintain Go programs or Go applications. We can only do Spring Boot and Node. So how do we handle this kind of a situation in the enterprise? I'm actually, if I could speak to that one. One of the things that as we've seen from Cloud Foundry now for the last three and a half years or so is a powerful agent of both freedom for the developers but also governance for the organization or the language build packs inside of Cloud Foundry. And so what several of my large enterprise customers have done have said, hey, we're gonna support both from DevOps all the way up through release management and production. This subset of languages, so long as they have a build pack that's got governance around that. And then because of the standardized behavior both in from the developer experience and from the operations side, then that gives organizations both the enterprise architects as well as the operations folks a comfort level that this is a build pack is just a governance set of dependencies for a particular language framework. And so rather than kind of throwing the door open and saying, well, you can do anything anytime, what we're really doing is using the constructs of the Cloud Foundry platform to be an instrument of governance. Now we typically discourage clients from tinkering with the build packs other than using configuration parameters to inject enterprise-y kinds of things in there. But at the same time, as long as they're using that then you get a lot of value on the governance side that you were talking about, which is important. But from a developer experience side, you've given them a broader toolbox but a very consistent experience in terms of how they interact. So I don't know if that's helpful or not, but that's how I've seen several of my large customers. So they don't say, well, you can do anything. If you can go find some language that no one's ever heard of, you can do that too. That's not realistic and that's not what we see. However, in a Cloud Foundry environment at least, we have seen, hey, we're gonna do these three, four, five kind of enterprise languages that are all supported in the foundation and we're gonna pay attention to the build pack itself and what goes in there so that we understand how to vendor dependencies and how to manage what's under there. So what was that? Yeah, and the other thing to tack on to that is, I did bring up the fact that operators are stakeholders, right? So that's a big problem with a lot of organizations right now. They don't necessarily think, they think the developer is king and that the operations people are just another wing of the organization. And that's not the point, right? Like the thing is, is like you said, DevOps is about the operation side of the house too. So there's a negotiation that has to happen, right? If the operations people aren't competent or they're not willing to do something in a different language, well, that's a different set of opportunities to either learn or to, you know, maybe that's not the right tool for them. The whole point is, is operations as part of this as well, right? We can't just go out there and say, okay, you know, we're only doing .NET. It's the only thing to do and go forward. Because I think you're gonna have problems, again, with operations, with personnel in general, finding those people, making sure that they're competent. But if they can swing in and out of one language versus the other, nobody's really scared. It's just the way it's gonna be. And I think that's powerful. Good, we have time for a couple more questions. Anyone else? Sure. So just my perspective to kind of add to yours, I think with DevOps, one of the challenges is a lot of companies think that DevOps is a team and not a mindset. Yeah. And I think in a cloud native world, the development team actually would own the operational responsibility for that application, cradle to grave, which means you're getting the pages at night, not the ops team. So I think that solves part of the problem. However, if you're structuring your company is set up where you do have a DevOps team, then it would be the responsibility of that product owner or development team to actually either train or embed an individual with that language skill set into the DevOps team. So that's kind of how I would tackle it and how we tackle it at our company, but it is a concern. In terms of your statement about the polygop programmer, from a systems background, I know having somebody with multiple disciplines and multiple sets is extremely powerful. It allows you to see things differently in different ways. And I think from a programming perspective, if you know three to five programming languages, you're just amazing. So you would wanna keep pushing that boundary of learning and pushing new languages because not one language rules them all, right? Well, and it can't, right? Like if we think about it, it's like we could mathematically prove that you can't, yeah, you can't possibly create the perfect language. It's just not gonna happen because what my definition of perfection is in that language can easily be changed by your definition. So it's powerful to learn how these different perspectives. Thanks, some great questions. Anyone else? All right, well, thanks a lot for coming and have a great evening. Thanks.