 All right, we might be a lot of I think we maybe didn't run our intro which is parents No, we're actually here. Hello everybody so this is a Kubernetes 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 I'm like, you know a typical product for example. We try to find When we talk to product managers and it's a little product that With the open source world So that's what we're doing today. So I'm like the white and I Fact number at Boston University now I used to work for it and joining me is my co-host today is Josh Josh Berkus and He will introduce himself Yep, howdy everybody Josh Berkus 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 thing and and sorry Clearly far too early for the West Coast And 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 you're 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 Some 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 former. I'm a 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 Hat's portfolio Did we go over this were we excited at the same time? It's very likely I was there from 97 till 10 That would cover it that would kind of cover it wouldn't it yeah, yeah, I was there from 0608 so okay 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 An open source. Oh, yeah, I have a portal Before coming to Russia with the court writ for Bible verses installed by default. Yeah, that's right Yep, that's right Yeah, I'm totally used to it This is completely full of coffee So the reason we wanted to invite both of you today was to kind of talk about your scene is kind of future of micro services 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 micro services versus our traditional service or in this architecture We can talk a bit about that Sound to call So all right, then I will if James didn't leave at the chance I will ask Daniel to play Little bit about why micro services are interesting whether cool and why you're interested Yes, for sure. So yeah, just once again that Daniel all I'm actually working to James folks on team Like the developer advocate and technical marketing is your agency and see panbestar. Yeah, so the microservices was a problem like a Like my seven and eight years ago and then before that we are all working with the modernist 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 micro service architecture actually Help us to make that happen Regardless, regardless of any application runtime like a job done that or a python. No, yes, whatever you need So main purpose of the micro service architecture, you're going to run Individually the application runtime, but also you're going to serve the single business domain or capabilities And then it really fit into your container Orchestration platform like a Kubernetes You're just a packaging 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 whether 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 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 micro services in addition to the like the architectural benefits, it's also if you if you You know 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 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, sorry. Yeah, that's right Because I will I will not allow the term so I Service oriented architecture. Yeah, right. Yeah, except for 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, you know, if we would get things like Corba or whatever, but you know, the Literally the concept of the service and a service Whether it's a you call it an architecture or whatever the concept of the services really fundamental to building a scalable Applications and what I think at least for me one of the 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 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 take them months if not years to develop that point Feed down it gets in pieces down to the development teams. What's so interesting about the Microservice model or even the conceptually is actually a very similar idea You're actually kind of bottom-up. So you would be the only building things that people are actually using And what we found right this is also some of the transitions What are called the agile is that many if you kind of approach software development Building over what you need when you need it Better any product Yeah, one thing we have to be careful about is 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 and it's technology we have to go And there's right and there's always resume driven development So so what is serverless add to this So yeah, sure so sublas is more like a deployment model So the Microsoft set Microsoft is some kind of architecture how to build application How to run independently in a sublas sublas is kind of deployment model, which means regardless of any application on time 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 seven regardless of the container or like a virtual machine even bell metal But in the end a lot of enterprise a company figured it out Oh Our the most our business application don't need to run all the time And we also need to reduce our cost to run and maintain application in order to solve their kind of business challenges and technical problem So sublas actually Enable developers as well as like enterprise a company solve their kind of problem This that's why the sublas we already talk about sublas 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 sublas, it should be running all if it 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 scales down to zero like a 30 second or up a minute Not development stuff is more like a deployment model That's the fundamental concept of a sublas It can bring your Microsoft's application and the sublas as well Go ahead James. I just wanted to add that when you when you're when the application is quote unquote running Um and not scaled to zero. It's also tracking And responding to load Um 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 um, 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. So That's really I want to really be talking about so a lot of enterprise company really care about Like the climate change like the carbon dioxide reducing and then for example google cloud they Currently co2 neutral cloud platform and they are aiming for co2 free by 2030 And the sublas actually, uh, allows the enterprise company reduce co2 Uh 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 it We we often present this or actually we started to present this slide Years ago, um 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 microservices 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 those applications going to be deployed and what server What server apis they have to call to get this one function done or this one? task done you want them to be able to write the the logic for their service And and be done with it and you know not have to worry about how to package it up and and run it on like an Applicate like a traditional application server like a job EE app server. That's really the benefit Well and and similar to kind of the coal Kubernetes idea right is that you know, you're just kind of separation of concerns We actually had some of the remark in the in the chat, right, you know the Basically the difference is that while there is still a server 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 servers, but it's actually kind of the joy of containerization as well You know and arguably also the goal of virtual machine is just the separation isn't good enough, right? So, um, you know as we get further and further away from the virtual do is just separate those concerns um across you know different different responsibilities so that we can kind of have an expertise in You know running an operational and an expertise in Building a run software that are not necessarily some people But but also can operate 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 corkis and spring call a serverless function written in another language Sure. Yeah, that's all right. So it gave us or sorry service oriented architecture gave 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 um now there are There's certain languages and frameworks that early on had a kind of a A head start on java in particular And i'm thinking of things like no j s and golang Or and and python and languages that were a lot more Shall we say dynamic? and easier to kind of write and get running really fast With javascript, right? It's like you write a couple lines of javascript and maybe you get the types, right? Maybe you don't but it's still going to run so like Framework or sorry platforms like amazon lambda had you know kind of first-class support for node uh and javascript uh 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 two cares how long it takes to start up Who cares how much memory it 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 node.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 there's much hate as j2 has gotten Kind of over the years, right? I mean at the end of the day that that whole like that ee part really was service contracts Right, but you know like maybe not called that but that was really what was going on Because you were doing service contracts between the various components. So in some ways in java The you know the h3 is the word but the orientation around You know being service model right was was a early early on in the java And did a really nice job of it. It was just that It required it was much like so with sell out, right and there you go. I did it for you What you do it like the overhead to describe the service was so high That people kind of reacted poorly to it But you know, so now we're kind of getting to maybe a happy medium You can describe the service and A lot of the same code And you know node.js brings a lot of that to the table python So we did actually have a question from 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 serverless As you know, like, you know, what do you send them to train for? Not there's a lot of training you see as per monolith, but You know, do your developers need to know all of those deployment models or it's one better to focus on Uh, I would say january in your opinion Oh, 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 a serverless but also Just in petabyte application, but the both general developer perspective They don't need to actually prepare or training or kind of application skill or technology based on serverless because the serverless is a very specific use cases So you don't need to change your old existing market service application or even modernized application to serverless So for example, james already mentioned earlier. So your application sometimes scaled down to zero or a very uh You know optimized for compute resources, specifically Kubernetes or cloud environment in that case the serverless is 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 Little bit consider about no need to consider about the serverless as well but So any And a project company always think about okay, so some specification like a business requirement We needed to evolve existing application to serverless at any time soon In that case, maybe you need to think about So current runtime environment or the application framework should be Change it to serverless quickly or maybe we need to rewrite existing application or Kind of stop So this is just some kind of challenge for developers even Java developer or no jes developer or like we go rank developer Even application architects Imagine imagine i'm a cs student though Looking at 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 or i'm working for a startup where i'm writing all new code um You know what should be my sort of default pattern Uh, actually, I got a 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 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 they said oh, this is kind of old stuff like You know, so we all almost the same age We really talk 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 That program language could be flexible and then dynamically change For the adopting new environment not just Cloud but also maybe coming iot edge or like a machine learning or artificial intelligence And then if you they needed to Restore or start over running new application runtime or like a programming skill That'll be good. That'll be not good experience So whatever they choose at the program language that program language Should be keep evolving as a large the huge community and then also Super flexible any runtime any cloud platform they don't know to use James to you, you know, do you want to add to that? Yeah, so if I was graduating today, um, 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 patterns. 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 Um, 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 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 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 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 lean 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 oriented architecture 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 than 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 monolith can it has the You know kind of like split points that you could Break it up into kind of a set of services or whatever 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 your 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 a hammer Can can can I actually get off into language theory here? A little bit Well just because java right when you're building a monolithic application in java java is much more object oriented In 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 for 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 um 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 you know call it and and 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 um, you know frameworks like uh vertex and play and There's there's a few others that um, uh, that kind of adopts that mentality that that It's almost like service oriented event driven architecture SOE the so eva Um, so yeah, you're right You you kind of have to change your mindset a bit when if you're going to adopt serverless Chances are you're doing so because you want to build a highly efficient and and you know performant application. That's also Tolerant to failures and outages and things like that um, 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 you're the call that you make, you know, eventually it's gonna either succeed or fail in a good way So that you can respond accordingly. Um, 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 Uh speaking as a old school Calm developer so windows calm developer many many years ago, which was an actual event driven architecture Um, I totally miss it, you know, like I I think there's actually a lot of opportunity You know model with an architecture serverless or you know microservice There's a lot of opportunity for adventure in architecture. So, you know, I think you're a little bit orthogonal To kind of the either it's a lot of the action easier to do that with a service model But they're so much more scalable. They're so much easier to identify like, you know, one of the products of like microservices in certain architectures is that Um, it's very hard to debug, right? Um, and so as a result I think one of the things that the adventure of an architecture plans the table right is that they 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 from the audience right is like I you know, I think or I think we're concluding that we need to find the right architecture for the for the individual solution But that there's principles from kind of both microservices serverless even adventure in architectures that Are probably applicable in all those scenarios. Um, and we should really be considering them as well Yeah, and one thing to 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 The 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 uh, 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 a serverless context because even in the serverless context, right a service Lives for a few milliseconds and if there's a problem in there and you You're it's you're unable to observe that problem. You're never going to be able to fix it So observability 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 The observability has to go along with that And there's one thing I want to add one One thing I want to share or something so The event driven auto 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 auto scaling Depending on your resources realization The problem is when you build on like an event driven application and architecture on Kubernetes it should be Auto scale based on event driven matching 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 Auto scale infrastructure based on event management like a cloud events or prom materials metrics or Like a aws monitoring or even Kafka topics So this is one of the reasons why the Kata the kubernetes event driven auto scaling the one of the cnc fp project, which is super popular Uh, it's which allows you auto scale your application like a subless application specifically event driven message 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 were talking before right about separation of operational things versus like, you know business logic things Increasingly we're moving more and more of the operational things into automatic engines, right? So, you know, uh, what I I don't know if this is actually like a quote from anything really to like safety my ability But it's the way I think of it like I explain 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 recipe and the more we can do things like auto scaling for example, especially when we can scale to zero The more we can you know fix the recipe so that we can put these applications in some environment that will Deal with the operation of stuff around it and then kind of just monitor that it's it's working. Okay Um, one thing I also want to put up there except james. I think that was a good point Which is that, you know, what how do you you know, you all feel about the kind of future of the observability stuff Um, the ending could be going to see though. Is that something that people shouldn't pay attention to is an important focus Is it a you know, just something people are doing on the side because they look cool grass Um, you know, I think they're I think it's ridiculously important in a service, you know model Whether that's service or not And so, you know, it's kind of wanted to get some more opinions on kind of the sort of ability to trace anything And and also which which tools people should currently be watching or projects I'll put that in a mystery I mean, that's one that that's the one that uh, it's very It's it's very much under 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 Um, and it's being integrated in a number of different frameworks like things like quarkis Um, I know the the the micro profile specifications, which we can talk about specs later, but they um, they also have a number of Observability capabilities in that specification feature set, which is fantastic. I think that is um, that is sort of It shows you that the 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. Um, the you know projects for doing distributed tracing things like yager have been around for forever And uh, we have you know, lots of products at red hat Support and and use and you can use yager to uh to do that distributed tracing I think the concepts are more important to learn and and understand first Before you can you know pick a particular Toolset, um, but yeah, those are those are just a couple that are that have that either are up and coming or have been there for a while now You know forever being relative Right. Oh forever in the compute in the cloud computing, you know, five years is forever. Absolutely. Yeah I actually don't know when exactly the yager started, but you know, it's it's not, you know, it's not 30 years I'll tell you right So Yeah, so that's Like I said, that's a really important space to me. Um, you know, I don't maybe I just write too many bugs But uh, you know, I think being able to understand what's actually happening. I don't kind of through your architecture particularly When you talk about things like corpus and no jazz and everything else is that when you're having, you know Kind of you're provided a particular piece of functionality through a whole mess of services That may be written in multiple languages. Um, you know, it can be really really helpful to get an idea of You know, what's happened across that spectrum without having to know the code inside now for, you know, six different languages and different communication models and everything else Um, so josh, did you have a question you want to follow up on? Um, well, there was some of this so someone the other person right is um The uh, we've got observability on the one hand Another thing is particularly because we're talking about potentially multi-language pro, you know, um programming via serverless And that makes the interfaces super important Are there any emerging standards in this area? Is there anything we should be paying attention to there? Uh, yeah, let me let me let me try to answer that. So, you know, also Everybody has different serverless platform like Amazon, random google and azure and a lot of stuff And then the one interesting part from cncf. They actually the serverless working group Try to standard Standardize the serverless 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 serverless function requirement and life cycle and implication type and then Like a fast controller and event sources how to handle that and whatever you Implement or standard of your serverless platform or serverless one time You should fulfill this mandatory requirement for the the standard serverless platform and then so because so You know, also many many enterprise company looking forward to Like 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 Any time soon So in order to do that We definitely need to standard serverless like a model or architecture rather than Tied into specific cloud provider. So that's the reason why cncf a working group actually working on that And then we don't have any okay image of lambda isn't a standard We're not going to say that in the in the open source community and the ecosystem But we can say okay, this is a standard serverless processing model With the like some mandatory architectural characteristics and the features Yeah, and one thing I'd like to add to the interface or the interface question is like When microservices started to become really popular over 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 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 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 g rpc, uh, where you get a little bit you get a lot more Uh 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 g rpc and gson 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 maybe cloud event Maybe you might have heard about that before because the cloud event provide The standard event driven. I mean messaging formats. So for example, you have a react via application based on multiple language platform, okay I want to use json format like respo api more i will see you do xml or Binary or a probe of it depends on the what kind of application you're going to do that But the problem is for the serverless platform or serverless application Maybe you have to interface with the different like a eventually a messaging format, which is a totally Like a hassle not easy. So in the cloud event actually solve that problem Okay, whatever you take the application Language or go javascript or java python the cloud event the standard format you can easily communicate The event driven architecture with the serverless application Yeah, I thought it was kind of funny. We were talking about kind of event driven architecture We're kind of getting some examples of those implementations and I think people don't You know really realize this because very few people can 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 of that driven architectures are so complex So people find it so difficult to use they slap the plug in on top of the complex press 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 So josh, did you have another question you wanted to ask? I do but why don't 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? Probably I mean the amazon lambda Yeah, that's a good point Um, yeah, so I mean obviously the the value I keep saying 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. Um, I think that I think that Open source won 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 it's diminishing returns to 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 A value proposition to a company or to an organization Because you have things like vendor lock in and and and other Concepts that are not really technical in nature, but more um I don't know what the word right word is, but non-technical Considerations, I think open source is um, is a better There's a better thing for uh for companies to adopt, but that's just my opinion Yeah, I I I certainly agree with that. So So just one thing I want to share like up on source 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 for the 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 a like a user group or even vendors You know trying to make it better make it more flexible not tied into specific product or 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 h a i m l 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 Like a more like a Bender rifle cycle like a product thing. So there is one of a value proposition I mean open source community and open source 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 or also are in 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 adbs 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, I mean it's it's it's not all you know roses and Yeah, but yeah, I mean 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 a 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 know safe held by lawyer escrow. That's right. That's it. Um, you know and and so That sounds good in theory. It sounds comparable in theory You know except that it's not because you have no idea what that code looks like you have no idea how it works But so it you know, like I said, it's not it's not perfect, but it certainly I think is a certain modicum of Defense against you know You know and then they're This is this is also huge But I like the other part I think is really interesting about the open source A lot of these models or these architectures Is that the innovation is there in the sense that like If I can just go off and like build the last chunk of k-nade air or whatever I can say hey, this is this is what I think should happen with serverless And that's a huge advantage because like 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 This that's this way or whatever So I think there's a lot of huge changes. 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 Yeah 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 uh, you know additional or like further advancements in the serverless space including Ultimately standardization Uh, 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 As well as serverless applications and get rid of the the the old You know the outdated idea that java is big and slow Yeah, and one thing yeah one thing I want to share the future of the sub-last space I think the sub-last Can be integrated any like a workload not just web application But also you can integrate sub-last with the service match or a ml or any Kind of the use cases and workload very easily and the one good thing for the developers. Maybe they need to choose a right Program language or runtime environment to make them easily enable that kind of integration on the Just out of both feature relevant I needed to add some kind of dog party library or some of the complex configuration Yeah, so that is one thing so many integration will be happening For the sub-last and then a lot of 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 um, and you know it was fire and forget and that was how The system works because it was the only way I could scale Uh successfully to the you know to the workload. Um, and so yeah, there's a ton of uh, there's a ton of examples out there where You know microservice is certainly I think a serverless Is is really a good solution and as serverless gets Stronger or gets more sophisticated. I think we'll see even more opportunities for why You know designing your application around a serverless architecture Might work for 60 70 even 90 percent of your application, which I think is really interesting to move forward So josh, I see we had a question I No, this is I Would one person online had some questions about scaling Which we get into hba 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, um, let's follow up on twitch on the well except we're going to lose the restrain Um The um, is there a place is there a place where duane can go to ask follow-up questions? Is there a good a good place? Now there is a community Like a forum page on the Kubernetes by example, so go to cube by example.com and then go to community Help essentially and you know the feedback or whatever it may be kind of perks or community hub Um, and uh, 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 So so, you know Duane, um, or anybody else who's watching the show, uh, check out keep by example back home and uh Yeah, hold on 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, uh, there we are I had it and then I managed to switch the 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, uh, thanks so much to our guests. I really appreciate it again. I apologize for my location And I thought it'd be kind of cool to do something in kind of a public place But apparently my mic is not Doing as well as my old Apache helicopter bike where I used to be able to like do a meeting from anywhere So the thanks again Daniel and James and We hope you will see you around on the interwebs All right. Thanks for having us Have a good rest. Thanks everybody. Bye. Bye. Bye. Bye. Bye. Bye