 So I'm not going to talk as fast same material I'll probably add a couple things at the end may extend it out a little bit if you guys are all right with that So like people have mentioned this very clickbaity title Will microservices die First of all, I'm Rich Hagerty. I work for IBM a developer advocate looking at new technologies. I'm more Java runtime focused This is about microservices, but at the end I'll Deviate a little bit into Java So the agenda we're going to talk about let's see I can read better up here Myth and facts about microservices thing you should know the future and a little bit about Java performance So first thing we need to define microservices And we can start by saying what it's not Which is the monolith right that's where most people or that's that's the standard and it's old news monoliths They're old-fashioned. They're problematic. They're evil but they work and Half the country so it's like Java 8 right no one admits they're using Java 8, but half the country is using it Monoliths around we have clients that are running the same application never taking it down for years That's how solid they are But it's not new and shiny we all want to go to the cloud we want to take advantage of cloud Technologies, so we're talking about microservices So these are the microservices over here. They're all maintainable and testable as single units Independently deployable loosely coupled. That's the key microservice should not count on other microservices of being up for their livelihood Organize around business capabilities. You want the like-minded people working on things that they understand And owned by a small team Submits about microservices the smaller the better the more the merrier Not true It depends on the function right they could be very small they could be very they could be huge I've seen some very large microservices Microservices are the destiny Monolith will have to be migrated all monoliths are gonna have to eventually be migrated. So here's an interesting poll Taken last year. So this is the amount of people actually doing microservices only about 17% 54 are content with their monoliths and This is really interesting 12% have started and they decided to go back Some more myths microservices make developers job easier Increases productivity boosts performance Microservices are fast. That's the selling points. But once you get into it, it's just like any other development, right? It all depends on communication and And working good as a team This is a job influencer. He's he brought up a good idea He goes why don't we take these microservices combine them into one big application and call something new and everyone will jump on that bandwagon because he's tired of microservices, but When implemented correctly like a couple of you folks have mentioned you've done it so microservice facts Independent deployment need continuous development pipeline. That's the key right the whole point of microservices One big point is maintainability, right? So you have the accounting microservice over here You want to make updates? You can do those independent of everything else You don't have to roll the whole application to get those updates Owned by a small team we talked about that Shouldn't have any code sharing no beta big no database sharing. So these are independent loosely coupled Very little integration between microservice other than through their APIs And they are agnostic to language. You can implement them in any language So things you should know if you're gonna do microservices Is it the default answer for your all your problems? I think we all know the answer know it isn't Microservice still need a good architecture So some of the more common architectures used for this right now are Domain driven design Event driven design. This is pretty funny Don't go down there resume resume driven design, right? I haven't done that. I need that. That's my resume day two operations Real important is anyone heard that term before day two operation is basically here's our new Application with microservices all in containers second day comes it's been running now what? How do you determine if it's working right? Right? You have to have a standard programming model to interact with other microservices So open API is a good good way to go with that set those APIs up front set up contracts Know that you affect others when you change those Be mindful of refactoring monoliths to microservice. So The people I asked earlier have implemented microservices. Did you come from a monolith you said sort of Anyone else did you come from Kina? So there if there are tools out there you should take advantage of one of them is I work for IBM anyone heard of WebSphere It's been around for 25 years. It's a Java runtime. We have a new version of that that runs containers. It's more Cloud native. It's called open Liberty. We have a tool called mono to micro That actually uses AI to look at your monolith and breaks it down and says this is where you need to split it up So I know other tools like that exist take advantage You don't have to reinvent the wheel We don't need to get into these So monoliths and microservices will coexist and going into the future But what the important thing that you should take away from this is you have to change your mindset Whether you stick with monolith moving to cloud or you're gonna go to microservices you need to embrace this cloud native application concept Cloud native application. There's so many tools on the cloud to support your application but if you don't Provide your application in a way that it can understand that you're really gonna defeat you're defeating the purpose of it What are cloud native applications? Here's a really good starting point. This was developed about 12 years ago It's called the 12 point 12 factor Application methodology and this was developed by heroku was one of the early cloud platform providers They took a look at what was working. What wasn't as teams try to bring force their their development their applications And they came up with guidelines best practices and these are the 12 factors. I'm not gonna go into each one of them But basically some of the things are kind of obvious right code base It's all gonna be driven from the same code base in get hub or some Repository like that your dependencies are gonna be really explicit Down to version number so you can reproduce your builds configuration is always external to your source code Have these well-defined build release run Processes in your in your pipeline Concurrency that's taken care of with your orchestrator like Kubernetes Disposability so your microservices need to be able to start clean and and clean up when they're done This is one of the key ones the dev prod parody what we're saying there is Whatever you're using to develop Should be as close to as possible what you're produced you're gonna put out in production right? So we don't have different folks working with different source code We get the same code base We say I want to build a test Version it's gonna be the same code. It's gonna be talking to the same databases whether stubbed out or whatever You're gonna test the same code. You see it's in containers. You're gonna test in containers So you want those as close to as the same as possible logging becomes ultra ultra important in a microservice world You can have thousands of instances of your microservice you have an error How do you see that how does it tie to that instance running in another location on another another site? Logging is huge And of course your admin processes should be a part of the code, but they should be called externally as one-offs Over time I said I was developed about 12 years ago Since that time we've they've added some more API first we kind of talked about that Define your API is up first what your microservice is gonna provide Set up contracts saying this is what all your clients are gonna say I understand that contract I will live with that. So if anything changes your build will find that not when you run Telemetry is is basically logging extended so Kubernetes has hooks in it that it will ping your microservice and can determine its health and its Metrics, but you have to supply that going through these so Like I said, there's a lot of companies a lot of standards a lot of folks out there trying to make your life easier So there's a lot of API standards out there. These are the micro profile and jacardi with Java Right. These are open specs That define how you should define your applications a lot of these run times implement those specs Like I work for IBM. That's open Liberty. You got cork is from red hat All the big players Jakarta's got oh This slide is pretty interesting. So different versions of the spec depending on what you want to build I'm going through these kind of fast and of course Everything has to be containerized You know the tools pod man or Docker and When you have those you can deploy them anywhere any type of cloud private public or hybrid So the other thing is anyone implemented serverless So this comes up a lot. So it's called cloud native applications obsolete with serverless. So the concept is serverless It's either on or off So you have an application out there when it servicing a request it starts up service the request and goes away You as a consumer only get charged for what the time that it's Servicing the request. So a lot of folks are jumping on that because it sounds pretty good As far as using resources Some myths about serverless it actually does have a server obviously But it's always in an idle state when not being used. It's a pay as you go Occasionally running and fast operations scaling to zero So basically serverless is for short-lived applications. That was the intent people are kind of abusing it But that's what it was for Now here are some of the implementers of serverless IBM code engine Amazon Lambda. You probably have heard that one Google function is your function There's also Kubernetes extension called K native if you're aware of that. That's that's scaled to zero basically the same thing Now in the Java world It's pretty interesting. So any Java developers are working Java shops No one one Okay, so the biggest problem with Java is it has Biggest problem is its strength. It was written 25 years ago It runs monoliths and it like I said it can run for years because it has great garbage collection It has internal compilers. So the code is so optimized as it's running the longer it runs the better it gets Profilers go out and check the code see what's actually the parameters that are being passed Optimize the code that way. That's called dynamic compiling that happens as it runs So that's a benefit people like that the problem is Let's make that into a microservice. Well, it takes now 10 seconds to start up because it has to do all that Right. So instantaneous startup is is not a thing with Java. So Whenever there's a opening people jump in so Here are some options that have come up lately to try to solve this issue growl VM and Growl VM basically does static compilations of Java code. So it treats your code like see The problem with that is you lose the garbage collector. You lose the JVM and There's some dynamic features of Java you lose not the best solution a better solution is taking The Lennox CryU technology has anyone heard of that? CryU has been around for a long time. It stands for checkpoint restore and user space Basically, you can take a process in Lennox and you can say I'm running stop it take a checkpoint kill it Come back the next day start it. You'll start exactly the same spot So that that technology has been pushed up into the JVM's now So there's actually open J9, which is an open source JVM Has this feature called instant on so you basically start up a container run your job application It'll take a snapshot as soon as the application loads It'll shut down and it'll keep that image and that's what you load in your docker file And now when you start that container again, it starts up instantaneously I'm gonna show I'll show a demo of that real quick So the key point there is microservices are not the same as serverless if you hear that Microservices are supposed to be they last a while. They're not not up or down So when you're talking about scaling of microservices, we're talking about scaling from one instance to and instances Scaled to zero or serverless is talking about scaling from zero or one zero or one Before I leave I want to give a plug so at 455 I'm doing a talk couple rooms down that I'm gonna talk about microservices in Java if there's not a lot of Java folks here So you may not be that interested But basically the the concept there is we're gonna pull the jit that does the compiles out of the JVM and make it a remote service Now all your JVM clients will talk to this jit and the results are fascinating So key takeaways, I do want to do a demo if you want to stick around for a minute on that instant on So key takeaways do not use microservices as a goal Define your problems first monolith is not evil use best practices cloud native applications Definitely go down that road So if there's one little nugget you could take if you want to go to cloud You want to develop applications embrace cloud native technologies? All right, let me do a little demo real quick By the way that took well, I don't know I started my clock timer late. All right So I have this Java application it basically it's a simple app comes up and it shows system metrics and Some system properties for the underlying host now If I run let me do this. Where is it? I have a so this is The normal application this how long it takes to start up a job application Simple application still running. Here we go. Can you see that? five seconds right and Here's the application There you go return system properties and some some metrics and health So that's five seconds normally This is a solution for serverless by the way so now I'm going to start it with So I created an instant on or a cry you image With the same application I started it and stopped it took a snapshot of that and put it into a container So now let's see how long it takes So there you go it took 358 milliseconds Pretty impressive now. I also set up a aws cluster With kubernetes and the extension Knative so I have both of those images sitting in Knative and It's got a 30 second time out. So if it doesn't get a request it goes idle and Sit there for a while So let me do this Let me kill that application. I Think I have the pods command. I could type it but there it is so Right now it finds there is nothing running in the pods It's dead That means it's been over 30 seconds since I accessed this So here is the first so I have this loaded already the page But if I go to refresh it or I asked for system properties, it's going to send another request So I'm gonna click on this link. So this is a normal version So if you wrote a job application you want to take advantage of serverless. This is how long it takes We'll go ahead and start click One two three Took ten seconds So now here comes the instant-on version Destiny demo gods. Let's see how it works So three little over three seconds and what happens is Knative itself takes three seconds to fire up It's gonna get better But that just tells you the difference so this is Is acceptable Three seconds three point, you know through 300 milliseconds is acceptable. The other one really isn't so That is a instant-on Solution to serverless for Java applications. I know you guys aren't into Java, which is gonna what do you guys develop your Microsoft what what language oh? Okay, so goes real popular with serverless to is anyone implemented any serverless functions Okay, no JS. Okay, and what does it do? Okay, so it's a it's a it's an administrative function you do once in a while just a Okay Yeah, so that's perfect example of what the serverless is intended to be right it's a function that isn't very It doesn't isn't used very often, but it's there your code is probably in the code base, right? It's probably an API that isn't probably called by the any any other part of your application But you can create this little function start up get the information and die. That's what it's for But folks are looking at that model going hey that that sounds cheap It only gets it'll only get charged when it's being accessed. What if I put my whole model? It's on serverless Right no one's using it at night. I Don't know so one of the big the big problems with Microservice is what you're gonna find is as people are the intentions are correct, right? We want to take this monolith we want to put it into microservice so we can take advantage of all this cloud technology They're moving at the cloud thinking they're gonna save money and they don't Initially it takes it takes work your containers are gonna be too big Your scaling is not gonna work right because it's not gonna be efficient scaling So you have to have more instances running than you want You're gonna wind up and then you get that Amazon bill and you're gonna say hey, are we really saving that much? So it's that second day part where you figure out what's actually needed Streamlining all that application code making your containers smaller all those things But anyway, thank you very much. That's the end of my talk any thanks Any questions Yes Yeah, those are all features that you had to build into your application so they can determine metrics Microfile has a good API's for that. So metrics on health and Logging all that stuff to see what you're really doing. Where is it spending all of its time? That's a hard That's hard. There's no to hit button make efficient. All right, it doesn't work like that. You have to dig deeper Anything else? Well, hopefully in 10 years. We're all talking about converting our microservices back to these monoliths But anyway, thank you very much