 All right, we might be a lot of I think we maybe didn't run our intro which is Parents, you know, we're actually here. Hello everybody So this is a Kubernetes and by example inside and we Do a show where we try to talk to people who are deeply involved with the community SQL system as contributors so that we can find out What's happening, you know Coming soon because unlike, you know, a typical product for example, we try to find When we talk to product managers and it's a little product that's going to happen with the open source world It's often better. They're actually talking to engineers because they Really have some clue of what might really happen. So that's what we're doing today. So I'm Langdon white and I The second member at Boston University now, I used to work for in it and joining me is my co-host today is just Josh Bergus and He will introduce himself Yep, howdy everybody Josh Bergus red hats Kubernetes community manager and sick chair and Kubernetes and a few other things And aficionado of things serverless, which is what we're going to be talking about today So just to kick stuff off for our audience Do you want to explain what the difference is between serverless and micro services and Since we're going to be talking some about Java for that matter the old service oriented architecture Yeah, I can do that a little bit. So but before we get too much further, we should probably choose our guests today we have Daniel of micro services theme and and sorry Clearly far too early for the West Coast So we can introduce you Yeah, so Daniel Daniel. Oh is a contributor to the corkis project More than anything but also K native which which corkis uses and corkis allows you to run I Spring and other Java applications and possibly non-java applications on Kubernetes Right, so Daniel you're you're primarily responsible for kind of outreach to developers, right? with that group and James your I know an old school Java guy, but what's your relationship to service these days? Yeah, so Thanks for having me. So James Faulkner. I run product marketing and technical marketing for Several of red hats application development projects and products many of which are not only compatible with but as you mentioned use and Can have native integrations with serverless capabilities on Kubernetes? things like K native and and other ways of executing code across Container orchestration platforms cloud platforms, etc. Etc. So I'm a former Recovering developer. I worked at Sun Microsystems on Solaris for a number of years and then moved into the Java space in around 2008 and joined red hat in 2016 so since then we've been you know helping to evangelize the goodness of Java and and Capitalized on its popularity along with red hats portfolio Did we go did we go over this where we had said at the same time? It's very likely I was there from 97 till 2010 Oh, that would cover it that would kind of cover it wouldn't it? Yeah. Yeah, I was there from a 608 so Yeah, it's good time. How's it done for 13 years in Oracle for six months? And then I was actually community manager. You mentioned your community manager former community manager for a project product called life ray Oh, yeah, I have a portal before coming to red hat with the portlet for Bible verses installed by default. Yeah, that's right Yeah, that's right so I I'm on the west coast this week and it is very early for me. It is about the same time as for Josh But he's like used to it and Yeah, I'm totally used to it This is completely full of coffee I hear you So the reason we want to invite both of you today was to kind of talk about what you're seeing is kind of future of microservices on You know kind of on the communities platform, why is it interesting? What's you know, kind of what's new and different about microservices versus our traditional service? We can talk a bit about that Sound to call So well, all right, then I will if James didn't leave at the chance I will ask Daniel to say Tell us a little bit about why microservices are interesting weather cool and why you're interested Yes, for sure. So yeah, just once again that Daniel all I'm actually working The James folks on team like the developer advocate and technical marketing is your agency and CPE investor Yeah, so the microservice was a problem like a My seven and eight years ago and then before that we are all working with the monolith application to run multiple module to implement business application But things change that so cloud platform came out and then we're looking for the more Optimized and then more portable and standardized application for example, you want to run single application with a single Independent to business requirement in order to that the microservice architecture actually Help us to make that happen regardless of any Application runtime like a job done that or a Python node. Yes, whatever you need So main purpose of the microservice architecture you're gonna run Individually the application runtime, but also you're gonna serve the single business domain or capabilities and then it really fit into your Container orchestration platform like a Kubernetes You're just a package of one containerized application with a single Microsoft application and the running on top of the Kubernetes or cloud And then you have a huge high scalability and the flexibility and portability as well Yeah, one of the interesting things Josh you mentioned So I think earlier I've common commonly heard the phrase microservices is so a done right Which is kind of funny because like the concepts and and the way you develop microservices that Daniel mentioned It's like well, we had this, you know, 20 years ago with or maybe probably was 20 years ago by now For service-oriented architecture that the problem was so a wasn't the concept of a service-oriented thing it was the way that it was implemented and the the centralization of the the Contracts between the different services into like the central, you know integration team and it kind of proves a big bottleneck and slowdowns in terms of making changes to or developing new and making changes to existing Applications that needs to talk to different services. So microservices in addition to the like the architectural benefits it's also if you if you knows Split the services across Business domains and you also match that to your development teams So that you can have these autonomous teams building these services and then independently publishing them Then you the benefits of microservices start to really shine through It's not like the app the application is getting simpler actually microservices makes things more complex but if you you know adopts the the idea of these Independent services being developed independently by as we've all heard the phrase to pizza teams Then that's where the real benefit comes and that's really the big difference between The microservices of two decades ago, which we called so versus what we're doing to these days And then serverless, you know as we will probably discuss Improves upon that even further And just to clarify what you mean is is so a or yes Oh, yeah, that's right. It's right because I will I will not allow the term so Service oriented architecture. Yeah, right. Yeah, I mean, it's funny right because we've actually been doing that I mean if you think you can kind of trace back, you know, various implementations of how to do services for a long time Corba whatever, you know Clearly the concept of a service and a service Whether it's a you call it architecture or whatever the concept of the services really fundamental to building scalable applications and what I think at least for me What would be differences as well, you know, you kind of mentioned, you know Kind of services done right except I also added is also the approach You know, so a there's a very much a top-down You know, it's like this this ivory tower of architects would come up with this perfect plan And you know, it would take them months if not years to develop that point I remember they would feed it out and get some pieces down to the developers What's so interesting about the microservice model or even the conceptions actually a very similar idea You're actually kind of going bottom up So you would be the only building things that people are actually using or actually And what we found right? This is also some of the transitions Is that If you kind of approach Yeah, one thing we have to be careful about this is Making everything microservices like there are cases where it doesn't make sense Depending on the size of the team and the culture of the organization that that is is building the application You know monolith might be perfectly fine. I think was it the I can't remember his name that the the founder of a base camp Actually just made a conscious decision not to do microservices Because of the the nature of their team and the fact that they are it was a sort of a smaller team They kind of knew what they were doing And they didn't really see a need to have these business domains and split up and they were perfectly happy with that So it's not always the case that microservices is always the answer Yeah, but I mean if there's a shiny toy In this technology, yeah, we have to go absolutely and there's right and there's always resume-driven development So so what is serverless add to this? So yeah, sure, so serverless it's more like a deployment model So the Microsoft set Microsoft is some kind of architecture how to build application how to run Individually in a sub less sub less is kind of deployment model, which means regardless of any application runtime. It makes you have application Just run and scale down to zero with our network trapping So for example the modernist application or some Microsoft application running all the time like a 24-7 Regardless of the container or like a virtual machine even bell metal But in the end a lot of end-of-project company figured it out Oh, our the most our business application don't need to run all the time And then we also need to reduce our cost to run and maintain application in order to Solve that kind of business challenges and technical problem the serverless actually Enable developers as a rise like end-of-project company solve that kind of problem This that's why the sub less we already talk about sub less platform like Amazon lambda or Google function Or as a function, it's all kind of deployment model So when you deploy application as a sub less, it should be running all if you shouldn't be running all the time It should be long very certain period of time and then it will be hyper not The like a scale to down to zero like a 30 second or up a minute Not development stuff is more like a deploy model. That's the fundamental Concept of a server less it can bring you a Microsoft application and a sub less as well Go ahead James. I just wanted to add that when you when you're when the application is quote-unquote running And not scaled to zero. It's also tracking and responding to load So that anyone can scale up to you know multiple instances to handle additional load This is the idea that you want you want your compute resource to track the load on it instead of you know Running all the time as Daniel said but more importantly tracking that load so that you can really optimize your compute usage and your networking usage Saving money and hopefully also reducing, you know, co2 emissions and things like that. Yeah, that's a really good point And so that's really I want to really be talk about so a lot of enterprise company really care about like a climate change like the carbon dioxide that we just seen and then for example Google Cloud They currently co2 neutral cloud platform and they are aiming for co2 free by 2030 and the sub less actually a loss in our project company with the co2 Based on the optimized and compute resources in the end so Those are good so environmental concerns. We've got operations concerns and that sort of thing. What's the benefit of serverless for developers? so for developers it it said We we often present this or actually we started to present this slide Years ago Showing the evolution of software right we have the monolith on the left and then as we move to the right We go from monolith to mini services to micro services to serverless and it's like this architectural progression and the the benefit to developers for serverless is they like I mean the naive way to say it is they don't they no longer have to care about the server But more importantly they no longer have to care about the application Infrastructure needed to run their business logic because that's ultimately what you want your developers to be focusing on is adding value to The organization whether that's for money or for others for other things But you don't want them worrying about how this application is going to be deployed and what? Server info what server API's they have to call to get this one function done there this one task done You want them to be able to write the the logic for their service? and be done with it and you know not have to worry about how to package it up and Run it on like an applique like a traditional application server like a job e-app server. That's really the benefit Well and and similar to kind of the cold Kubernetes idea right is that you know You're just kind of separation of concerns. We actually had somebody remark in the in the chat, right? You know Basically the difference is that while there is still a server in there the Operational control for the server is managed by somebody other than that person who's trying to run the functionality And that's that's really what we mean by service But it's actually the joy of containerization as well, you know and arguably also the goal of virtual machine It's just the separation isn't good enough, right? So, you know as we get further and further away from the virtual do is just separate those concerns Cross different different responsibilities so that we can have an expertise in you know running operational and expertise In building a lot of software that are not necessarily the same people, but but also Yep, that's right, so So Does that mean theoretically so? We've got you know serverless and that sort of thing now theoretically could you have a Serverless function in say cork us and spring call a serverless function written in another language Sure. Yeah, that's all right. So it gave us our sorry service oriented architecture Give us that you know two decades ago The concept that that abstraction, right? It's like the the con the service adheres to its contract Regardless of what language it's written in and serverless is no different in that regard now there are There's certain languages and frameworks that early on had a kind of a Headstart on Java in particular and I'm thinking of things like no JS and go Lang Or and then Python and Languages that were a lot more Shall we say dynamic and easier to kind of write and get running really fast With Java script, right? It's like you write a couple lines of Java script and maybe you get the types, right? Maybe you don't but it's still gonna run so like Framework or sorry platforms like Amazon Lambda had you know kind of first-class support for node And JavaScript for running serverless workloads Java came along a bit later But it's it you know some of the some of the historical Architectural decisions and trade-offs made by the Java platform early on You know built built for big iron built for who cares how long it takes to start up Who cares how much memory takes as long as it can maximize its throughput those kinds of trade-offs made it a little less actually a lot less Friendly to use in a serverless infrastructure environment like AWS Lambda or Knative on on on Kubernetes So yeah, so no JS had a bit of an advantage there, but like I said, you can you can write them in any language that the platform supports Well, and as much hate as J2E has gotten Kind of over the years, right? I mean at the end of the day that whole like that EE part really was service contracts Right, you know like maybe not called that but that was really what was going on So you're doing service contracts between the various components. So in some ways in Java The you know the HGP is the word but the orientation around You know being service model right was was a early early on in Java and did a really nice job of it It was just that It required it was much like so with so out right and there you go. I did it for you What you do it like the overhead to describe the service was so hot That people kind of reacted poorly to it, but you know So now we're kind of getting to maybe a happy medium where you can describe the service and Think a lot of the same code You know for like a better term and you know, no JS brings a lot of that to the table Python So we did actually have a question for the audience, which was So if if you're a developer Should you be preparing your developers to continue to work in months or thinking about service as You know, what do you send them to train for? Do your developers need to know all of those It's one better to focus on Would say Daniel in your opinion Yeah, so developer perspective, so I would say so So here's the thing. So yeah, of course the cork is to provide a lot of stuff like a not just to suffer less But also just in petrified application, but the both general developer perspective They don't need to actually prepare or training all kind of application skill or Technology based on server less because the summer less is a very specific use cases So you don't need to change your own existing Microsoft application or even modernist application to suffer less So for example James already mentioned earlier. So your application sometimes scale down to zero or a very You know Optimize both compute resources of specifically Kubernetes or cloud environment in that case the summer less a really good solution to overcome the challenges, but Some application. Oh, we my application should be running all the time And then the application pre-stable and then not shouldn't be containerized or even not shouldn't be modernized in that case, you don't need to change your application architecture or like a little bit consider about no need to consider about the summer less as well, but So any and a project company already think about okay So some specification like a business requirement that we needed to Evolve using application to suffer less at any time soon In that case, maybe you need to think about so current runtime environment or the application framework should be Changed to suffer less quickly or maybe we need to rewrite using application All kind of stuff. So this is just some kind of challenge for developers even Java developer or no JS developer or like the go-rank developer even application architects Imagine imagine I'm a CS student though looking at graduation and getting on the job market. Yeah, right What should I be learning first? What should I be assuming that if I Develop a greenfield application from scratch, right? I'm working for a startup where I'm writing all new code You know, what should be my sort of default pattern Actually, I got some very similar question in a developer conference specifically the college student They're really looking forward to what is what is the most popular and the valuable like a program language for the seeking new job and then they said like a Python or Like a pH for like a data scientist something like that and if I were to say Java and then there's oh, this is kind of all stuff like a You know, so we all almost the same age We really be talking about cobbles and then oh, it's maybe 20 years ago old school style and actually the college student they said Java is so maybe 30 years ago like some old school thing, but I want to say so Whatever they choose the application or Java like a program language. Yeah, program language could be flexible and then dynamically change it for the adopting new environment not just Cloud but also maybe coming at IoT edge or like a machine learning or artificial intelligence And then if you they needed to Restore was star over running new application runtime or like a programming skill. There'll be good There'll be not good experience So whatever they choose at the program manager that program manager should be keep evolving as a red the huge community and then also Super flexible any runtime any cloud platform they don't have to use James to you, you know, do you want to add that? So if I was graduating today Number one, I would probably learn like the top three languages based on Usage today, which in my opinion, I believe yeah The question was not about languages the question should be learning microservices versus monolith patents, right, right, right? Absolutely, you're 100% right and the reason Yeah, so Like you said, it's not about languages. It's important to know a few languages but they all are kind of they have similar Similar constructs and similar ideas because computer programming computer programming, you know for loops and so forth More importantly the architectural patterns. I think that It's important to learn the value proposition or it's important to learn to the bit the like the main tenants of each of all of the major Kind of buckets of architecture like monolith versus microservices versus serverless Those aren't the only three, but I think that it's good to have a grounding in in several of them Because at the end of the day There's going to be a different right answer for each of the problem that you face, you know post graduation And so if all you know is one then you're going to try and apply that everywhere And that's not always going to work out the best. So I don't think there's any one I think there's a lot of a lot of attention right now on things like microservices and serverless, but The the value proposition of microservices is is you know, it's it's pretty compelling But it's not always like I said the right answer And it's just a special case of distributed computing which we've had for a number of years So if you're looking at a high performance like CPU intensive application microservices probably not the right way to go if you're building of a a Highly can you know a high transaction or high concurrency need web-based application Then microservices is probably going to be a better way to go, but knowing both is better than knowing one and just to kind of add to that like In a sense, I would actually be in a little bit towards service Because it's more complex and so as a result if you understand how to do like a service like architecture pretty well backing into like a monolithic architecture is You should in theory be simpler because you already understand as well as the fact that you if you do Really, I would actually say, you know a service ran to doctor or that's microservices or serverless or you know Even some of the old-school stuff if you're designing even your model in that kind of scenario You know, even if you're doing your services in RAM, you know rather than kind of cross network You'll actually end up generally speaking with a better monolithic app then you Then you would if you were using kind of a service, but you know a service-oriented model in the design of that application and in the future the model of can it has the Kind of like split points that you could break it up into a set of services or as that change happens So that's the but that I would just kind of like add that little bit is that I think you bring up But really a point is that the challenge that a lot of people I think are having right now is that they don't actually understand That there are all these architecture types and they are all different and they all different have different spaces and not every You know not everything that looks like a male needs to be hit with hair Can I actually get off into language theory here a little bit? But just because Java right when you're building a monolithic application in Java Java is much more object-oriented And in its design, right? Yeah, I mean people who are Work on more recent languages will quibble with that But but that is the basic theory of design for Java But then when you move into serverless or at least either of it driven applications or functions of service, right? Which are our two sort of halves of serverless You're actually kind of a necessity foe force to adopt a more functional programming Approach at least I think so. I have not written serverless stuff in Java. My serverless stuff has been in other languages the I So it feels like you actually kind of have to change your programming style, right and how you compose How you compose units of work between serverless and monolithic Yeah, and I think you're starting to touch on event-driven architectures Where it's like, okay, you have these set of serverless functions that you can call But how do you call them like do you call it and wait for response or do you know call it and Then set up a callback so that when the response comes in you can respond to it, right? That's the whole concept of event-driven architectures and event stacks and you know frameworks like Vertex and play and there's there's a few others that That's kind of adopts that mentality that that that It's almost like service oriented event-driven architecture SOE the so Eva So yeah, you're right. You you kind of have to change your mindset a bit when if you're gonna adopt serverless Chances are you're doing so because you want to build a highly efficient and and you know perform an application that's also Tolerant to failures and outages and things like that so the concept of This this event-driven architecture comes into play because it gives you things like this we call temporal Temporal I can't remember the word is basically you're the call that you make You know eventually is gonna either succeed or fail in a good way so that you can respond accordingly It also doesn't have doesn't matter where these other services are running So yeah, I think you definitely have to change your mindset when you're when you're thinking about serverless Driven or serverless centric architecture patterns Speaking as a old-school calm developer so windows calm developer many many years ago Which was an actual event-driven architecture. I Totally miss it, you know, like I I think there's actually a lot of opportunity in a model of the architecture serverless server You know micro service there. There's a lot of opportunity for adventure So, you know, I think they're a little bit orthogonal to kind of the it's a lot easier to do them with the service model But they're so much more scalable. They're so much easier to identify like, you know Microsoft micro services in certain circumstances that it's very hard to debug right and so as a result I think one of the things that the venture of an architecture principle right is that it kind of it localizes where Where the functionality is happening. So it makes it also easier to debug. So so I think, you know, the other day the question for the audience right is like You know, I think I think we're concluding that we need to find the right architecture for the Individual solution, but that there's principles from kind of both micro services serverless even an entry in an architecture that Probably applicable in all those scenarios and we should really be considering them as well Yeah, and one thing to close that chapter on is that when you as we start to move into event-driven Serverless things like you said debugging gets hard right stack traces No longer look like the stack traces of old where you can kind of see from you know From the beginning of the thread all the way through all the calls that that ended up in failure Now you get this super short stack trace that said something failed But you have no idea why and what in What what called that to cause that to fail and that's where things like observability Really become way more important in a non monolithic world So like things like open telemetry, which recently enjoyed their first release Is becoming very very much more important even in the serverless context because even in the serverless context, right? The service lives for a few milliseconds and if there's a problem in there and you You're unable to observe that problem. You're never going to be able to fix it So the ability super super important and that's one of the other things that I think at any college student when they're learning This modular model or modular distributed patterns that they're going to be using Really has to go along with that And there's one thing on the ship on the add one one thing I want to share or something so The eventually when all the scaling specifically like a Kubernetes and the Kubernetes basically using like a HPA Horizontal part of the scalar based on CPU and memory realization. It's really good to enable Your workload all the scaling Dependent use resources realization the problem is so when you build on like an event driven application and architecture on Kubernetes it should be all of scale based on event driven magic rather than CPU and memory It takes a long time to figure it out. Okay, my application like a pause get out based on CPU memory Memory realization. It's a really Latents problem. So that's why you have some kind of new All the scale infrastructure based on events of mastery like a cloud events or a primitive symmetries or Like a AWS monitoring or even Kafka topics. So this is a really one of the reason why the Kata the Kubernetes event driven scaling the one of the CNC a project, which is super popular It's which he allows you all the scale your application like a subless application specifically event driven message of rather than like a long process and CPU memory realization Yeah, that's a really good point. I mean, I think that's you know, one of the things that we're seeing with you know kind of environments like Kubernetes, right is that we're You know, we're talking before right about separation of operational things versus like business logic things Increasingly we're moving more and more of the operational things into automatic engines, right? So, you know, what I I don't know if this is actually like a quote from anything related to like safety liability But it's the way I think of it. Like I explained it is like You know, you want to fix the recipe not the cake, you know So, you know, just put me frosted on the cake. You can fix this individual cake And you know and make it all better But really what you want to do is fix the rest and the more we can do things like auto-scaling for example, especially In scale to zero but more we can you know fix the recipes that we can put these applications and you know some environment that deal with the operation of stuff around it and then kind of just monitor that it's it's working One thing I also want to put up there except James. I think that was a good point Which is that what how do you know you all feel about the kind of future of the observability stuff? Man, you can really see how is that something that people should be paying attention to is important focus Is it a you know, just something people are doing on the side because they look cool grass? You know, I think they're I think it's ridiculously important in a service, you know model Whether that's serverless or not And so, you know, it's kind of wanted to get some more opinions on rather the sort of ability to trace it And also which which tools people should currently be watching or projects I'll put down a mystery I mean, that's one that's that's the one that it's very It's it's very much on the forefront at least from on the red hat side of things in terms of being able to observe because it has sort of that that Quote-unquote native ability for Java applications to use it and it's being integrated in a number of different frameworks like things like Quarkis I know the the the micro profile Specifications, which we can talk about specs later, but they they also have a number of Observability capabilities in that specification feature set, which is fantastic. I think that is that it is sort of It shows you that they observability is important and becoming more increasingly so as we move into this more distributed environment, so the open telemetry is a good one to follow the you know projects for doing distributed tracing things like Jaeger have been around for forever and We have, you know, lots of products at red hat support and use and you can use Jaeger to do that distributed tracing I think the concepts are more important to learn and understand first Before you can, you know pick a particular Toolset, but yeah, those are those are just a couple that are that either are up and coming or have been there for a while now You know forever being relative Right. Well forever in the compute in the cloud computing, you know five years is forever. Absolutely Yeah, I don't know when exactly you're started, but you know, it's it's not, you know, it's not 30 years Yeah, so that's like I said that's a really important space to me, you know, maybe I just write too many bugs But you know, I think you be able to understand what's actually happening Architecture particularly When you talk about things like corpus and no jess and everything else is that when you're having Kind of provided a particular piece of functionality through a whole mess of services that may be written in multiple languages You know, it can be really really helpful to get an idea Across that spectrum without having to know the code inside mouth of you know, six different languages and Communication models and everything else So Josh, did you have a question? Well, there was some of this so so one of the other person right is The I we've got observability on the one hand Another thing is particularly because we're talking about potentially multi-language pro, you know programming via serverless And that makes the interface is super important Are there any emerging standards in this area? Is there anything we should be paying attention to there? Yeah, let me let me try to answer that so, you know, also Everybody has different subless platform like Amazon random Google and Azure and a lot of stuff And then the one interesting part from CNCF. They actually the subless working group Try to standard Standardize the sublass like not just platform. It's more like a Processing model. So for example, they try to give us some specification in How to define like a subless function requirement and life cycle and invocation time and then like a fast controller and even So it's how to handle that and whatever you Implement or standard of your subless platform or subless one time you should fulfill this mandatory requirement for the standard subless platform and then so because so You know, I saw many many enterprise a company looking forward to Like a go-to adopt like a multi cloud or like a hybrid cloud strategy Which means your application could be what should be running on Amazon lambda as well as as a function or Google cloud anytime soon So in order today, we definitely need to standard subless like a model or architecture rather than Tied into specific cloud provider So that's the reason why CNCF working group actually working on that and then we don't have any okay image of lambda Isn't a standard but we're not gonna say that in the open-source community and ecosystem But we can say okay. This is a standard subless processing model With the like some mandatory architectural characteristics and the features Yeah, one thing I'd like to add to the interface or the interface question is like When microservices started to become really popular however many years ago seven or eight the other thing that became really popular was like using HTTP and rest and No one really got the rest thing like they make they call it rest But it was really just you know one simple interface that there was no there was no actual URLs and your eyes and ability to address objects it you just happen to create this Quote-unquote, you know HTTP get interface and you call it rest, but in many cases it was using HTTP completely type You know type unsafe like it was super easy to make bad HTTP calls and so I think what we've seen recently is a resurgence of the old days of RPC with things like gRPC Where you get a little bit you get a lot more Stability around these interface contracts that we're so heavily dependent on in a serverless and in a event driven and in a microservices world So I think those those you know more advanced interface Definition types like gRPC and G son and there's several others Those are good to know and not just rely on okay. I know HTTP and I should be good Yeah, that's a really good point and then also to including the cloud. I mean event driven application with this server less so maybe Cloud event, maybe you might heard about that before because the cloud event provide The standard event driven. I mean messaging formats. For example, you have a react via application based on multiple languages platform Okay, I want to use to Jason format like respo API more. I must use your XML or Binary or a probe up it depends on the what kind of application you're gonna do that But the problem is for the sub less platform or sub less application Maybe you have to interface with the different like a eventually a messaging format, which is a totally Castle not easy. So in the cloud event actually pro solve that problem Okay, whatever you take the application Language will go JavaScript or Java Python the cloud event could stand out for man You can easily communicate The event driven architecture with the sub less application. Yeah, that was kind of funny We were talking about kind of an intro the architecture We're kind of getting some examples of those implementations and I think people don't You know, we realize this because very few people use it this way, but no jazz actually is intrinsically an event driven architecture Like that's exactly what it's supposed to do. But because event driven architectures are so complex We think that people find it so difficult to use. They slap the plug in on top of the complex friends and maybe what Which is like the opposite of the jazz is supposed to be for So I think it's kind of interesting, you know, we see a lot of no jazz implementations that are Literally doing like the opposite It's kind of original of interpretable So Josh, did you have another question you wanted to ask? I do but once you go ahead So I was going to kind of move on a little bit like Where's the where do you feel like the advantage of? Looking at these architectures and thinking about, you know, whether we're talking about Something like porpoise or a certain sort of where is the advantage of open source in those models? Like why why is open source a better solution to that problem? Is there a non open-source solution? I mean the image of lambda Yeah, that's a good point Yeah, so I mean obviously the value Keeps any value proposition that the benefit of open source clearly is that you know get more eyes on it It gets you know, it's more secure. It's more fun to to be a committer on a project or to feel like you're giving back So those are all good things. I think that I think that I Open source one a long time ago in my opinion and so even though we have things like AWS lambda I think that in the long run open source will continue to win There are other, you know Frameworks like things like K-native that run on top of open-source platforms like Kubernetes that will at the end of the day, I think become More widely adopted as as Lambda is sort of a stepping stone to a number of other AWS services, none of which are open-source I think that that as diminishing returns to organizations that are looking to standardize their practices in terms of hiring and training and Purchasing of you know supporting products, I think that that that's going to be decreasingly Value proposition to a company or to an organization Because your things like vendor lock-in and and and other Concepts that are not really technical in nature, but more I don't know what the word right word is but non-technical Considerations, I think open-source is is a better is a better thing for for companies to adopt, but that's just my opinion Yeah, I certainly agree with that. So So just one thing I want to share like opposite of value proposition I mean not just a sub-ass of all kind of like a technology ecosystem. It's so flexible and then whenever you looking forward to like a next feature or More flexible things happening You don't need to wait for the next release like it's like a vendor product So you just pull request and then you can contribute it directly and then there are so many like a individual contributor But also like like a user group or even vendors You know trying to make it better making more flexible not tied into specific product was specific Technology so some less of course is to keep evolving super fast Just not like a monolith. It's a really fast like a IOT edge AI now So any time soon what happened you who knows and then the open source Community so flexible adopted they kind of fast change rather than like a like a more like a Bender right for cycle like a product thing. So there is one of a value proposition I mean open source community and open source of project to keep chasing Fast changing the new technology Yeah, yeah, if you're going all in on serverless For your organization. Do you really want to have that dependency long-term or do you want a platform that you can not Only understand yourself, but also Find other folks who have either contributed or also part of the community to to help out when when you need something It just seems like a better value proposition if you're just doing a one-off thing then yeah, maybe it'll it'll work and Work for you, but longer term, you know a big bet made by an organization is better to be bet on an open source project Because I mean also The business continuity concern right if that vendor suddenly goes out of business Maybe adfs might not do that overnight, but you know having those dependencies on open source means that you can continue to run Yourself if needed Yeah, it's it's it's not all you know roses But yeah, we have open source projects fail as well Yeah, you know and that happens But at least at the end of the day, it's actually like really really old-school Software acquisition right where you know as part of your software acquisition you actually get But basically they would give you a couple of source code, but you couldn't actually see it It was like you're safe held by lawyer escrow You know and so That sounds good in theory. It sounds comparable in theory, you know except that it's not because you have no idea But so it you know, it's not it's not perfect, but it certainly I think you said a certain modicum Defense against Right But I like the other part. I think it's really Models or these architectures whatever is that the innovation is there in the sense that like if I can just go off and like That's chunk of Canadian or whatever I can say. Hey, this is this is what I think should happen with serverless And that's a huge advantage because even if I'm wrong, right at least at least an idea has been tried Right that people have rejected or if I'm right, you know, there's no barrier, right aside from you know My technical ability to just say hey, I think I think we should do That's this way or whatever So I think there's a lot of future images, you know, I think we're all a little biased on the show Right. That's where the innovation is happening. I mean, there's just so much happening to open source Yep That's what I would want to bet on if I was making a big bet so any final thoughts on the the future of serverless and Java programming and microservices and everything else the future's bright I think that you know Additional or like further advancements in the serverless space including ultimately standardization It's going to be an important and an ultimate and I think it's inevitable That we will get to some level of more standards in the space. I think that the advancements in Java Things like project loom, which is going to make that the whole event driven callback kind of thing a little bit easier Projects like Quarkus that we mentioned a few times which is kind of really Focusing on the the optimization of not only the JVM, but also on the frameworks that right on top of that Those are really important advancements in the space and I think those will continue to thrive together and really Hopefully in my opinion make Java sort of a You know bring it back From the dead that it's been dead for the last 20 years But really make it a first-class citizen both in terms of Kubernetes Kubernetes native Java and as well as serverless applications and get rid of the the the old Continent of the outdated idea that Java is big and slow Yeah, and one thing yeah one thing I want to share the future of the serverless space I think the serverless can be Integrated any like a workload not just web application But also you can integrate serverless with the service match or a ML or any Kind of the use cases and workload of pretty easily and the one good thing for the developers Maybe they need to choose the right Program language or runtime environment to make them easily Enable the kind of integration on the just our boss feature rather and are you I need to add some kind of dog party Library or some of the complex configuration Yeah, so that is a one thing so many integration will be happening For the serverless and then a lot of the enterprise use cases and workloads Yeah, I think a lot of people don't really think about the fact that you know like a boss architecture You know internally to the big iron enterprise corporation, right? You know a lot of ways is it a venture of an architecture if not entirely And that serverless solutions can be a great answer for those and in fact like you know Back in the day when I build like trading apps like stock trading apps You know it's kind of like you look back on it and you're like, oh that actually was kind of like a serverless application You know there was a venture and it was fire and forget and that was how the system works was the only way to scale Successfully to that, you know to the workload and so yeah, there's a ton of there's a ton of examples out there where Microsurface is certainly I think a serverless is is really a good solution and as serverless gets Stronger or gets more sophisticated. I think it's even more opportunities for why You know designing your application around a service architecture Might work for 60 70 90% of your application, which I think is really interesting So Josh No, this is I Would one person online had some questions about scaling Which we get into HPA and the like if which would be yeah It'd be very interesting except we're kind of at the end of the show time So Let's follow up on twitch on the well except we're going to lose the restrain The is there a place is there a place where Dwayne can go to ask follow-up questions. They're good a good place Now there is a community Like a forum page For example, so put a cube by example com and then go the community Help essentially and you know the feedback whatever Start community hub and You can go We're wandering around in there You couldn't even know our Twitter ID. I can answer that any All the scaling question. Yeah Yeah, exactly. So so Dwayne or anybody else's watching the show check out keep by example back home Yeah, hello, let me find a link to the forum before we log off I actually have it Okay, yeah, I do not have it so if you want to paste in a link to the forum there we are I Had it and then I managed to switch windows managed to click on a different okay Okay, hold on just a second. I'll paste it into chat before we log off There we are okay, and Now we both All right, so thanks so much to our guests really appreciate it again. I apologize for locations And I thought it'd be kind of cool to do something in kind of a public place but apparently my Mike is not Doing as well as my old Apache helicopter bike where I used to be able to do a meeting from anywhere so the things again Daniel and James and Interlets all right. Thank you so much for having us Thanks everybody. Bye. Bye. Bye. Bye. Bye. Bye