A java developer walks into a serverless bar

Key Takeaways

[Music] hello everyone wow that's loud uh hello I hope you still have some energy for this bit of last sessions I know this has been an intense couple of days a lot of news a lot of uh Innovative stuff happening in Cloud next so today in the next 40 45 minutes or so we're going to discuss Java and ser lless when you think about Java you don't necessarily think about serverless particularly mainly because of the Inception that Java is a little bit slow Java is a little bit beefy but we're going to try to uh solve all these misconceptions before that I'm Muhammad I work for Spotify and also I'm a Google developer expert for Google Cloud so what we're going to discuss today we're going to start by having or having a quick look into software architecture and how it evolved in the last 20 years or so we're going to discuss what we mean by serverless because I feel like it's an overloaded term that can mean basically everything and nothing we're going to discuss some of the best practices constraints misconceptions around Java in serverless we're going to discuss what some are the best practices that we can have while deploying Java applications in uh serverless and specific specifically Cloud run and then we're going to end up with some conclusions and things to uh be aware of while going back to your daily day-to-day job and when I asked uh a ji to generate an image of a Java developer into a serverless bar this is what actually the output was and the idea here is basically to highlight a story of a Java developer who had a very intense day of discussions trying to convince their team that Java could be a good class citizen in the cilus world however his team and colleagues keeps pushing back saying that Java is probably not the ideal scenario do I agree but let's first look into the evolution of software architecture and we'll get get back into all those Mis misconceptions and check if they are true so in the 8S uh it was a simple flow of communication the majority of architecture look at monolith simp flow of simple flow of deployment all the components will tightly packaged into one single unitive deployment and we take this unitive deployment and deploy it to the server single flow of communication between the client and the server however scaling was a problem here so if you want to scale it's going to probably hit you hard so in order to scale we started to break that monolith down into smaller components and in the '90s uh s SOA or service oriented objects appeared and and the promise was it's going to help you to scale and focus on business value and uh scale better uh and we needed for that smart pipes and smart pipes in the form of USBS and mqs however it was the software and the engineering that was required and the solution that was provided back then were hard to operate and from an from an organizational point of view they were also challenging and then in we needed another approach and microservices came in in 2010 with Netflix uh Spotify as well and those companies that had managed to build hundreds of microservices and scaled pretty much and help even from an organizational point of view help it to orchestrate and organize our team into what we call feature teams and then microservices uh hyped even more with the appearance of cont my I'm losing my English I need more caffeine with the appearance of containerization and orchestration tools such as kubernetes and that helped it basically to introduce a new layer of obstructions package everything including your dependencies and your system dependencies into an unit unit of deployment Docker images or container images and deploy that into an orchestration and the orchestra will basically uh take care of uh everything and that help it to separate what we call platform teams and uh feature teams and offered the new layer of obstructions that um and a new contract to uh scale even better and Serv lless because of that because we we introduced this new layer of abstraction and the separation of concerns between the Afra team and the operations and the service team was possible and this is how basically we ended up with serverless and all of that was because we faced trade-offs uh when it comes to architecture when I heard the word best practice I feel like it's a joke because like there is no best practice when it comes to architecture if you have read uh fundamentals of software architecture book which is a great book by Mark Richards and Neil Ford they suggest that everything in software engineering is a trade-off there is no single thing that's going to be that's work for every scenario for every use case each company each use case each feature uh it's has its own challenges and Throwbacks and tradeoffs that we uh behind uh thinking of software architecture trying to solve some of these trade-offs and challenges for example is performance we need to think about how fast we want our application to start is latency important is are we building a latency sensitive applications uh efficiency how much resources do we need our application to take of course if you have infinite amount of resources you can build the one of the greatest application in in the world but we have limited amount of resources that we want to optimize for and optimizing and having efficient resource utilization of course make our application even more cost effective because at the end of the day be it if you are using it on the cloud or having your own servers you are paying for that resource consumptions scalability and resiliency how much you want your appli to scale do you want it to be multi- region or in one region uh how many instances you want to have all of those questions all the tradeoffs uh are important questions that we need to ask also sustainability and maintainability we know that we when we build software now we need it to run for years to come so maintainability is an important topic not only for the code but also for uh the architecture as well so surus architect oh um for that we started what we call 12 actor app 12 Factor apps and basically those are best practices in maintaining the code and running it from the moment you start writing the code till it ends up in your production so basically we're trying to introduce best practices s uh standard uh like worldwide standard on how you can basically manage your life cycle of your application from the moment you start uh pushing the changes into your repository until uh deploying them into your application so in the beginning there were 12 Factor apps but we noticed that some other factors are missing and if you check all those 15 factors you can see security right it's like kind of a hint of it which is authentication and authorization but it's still missing and security is pretty important topic when it comes to production so 12 Factor apps or 15 Factor apps nowadays are still work in progress we are trying to introduce bits and improve them here and there but they are wildly known and uh cized and best practices that we can do to manage the life cycle of our uh applications and then it comes surus and as I mentioned in the beginning surus is kind of an overloaded term which means a lot of things and I want to clarify that before diving into it from two models first the operation model and then the programming model so from an infrastructure model there is no infr management and that's one of the good things and one of the important things of Serv list you are basically delegating order infrastructure management to the cloud provider or the platform that you are running your serverless your application on security is also managed as part of that but uh that's only only the infrastructure security bit that is managed your code security there is something that you still need to take care of and one of the important uh features is pay as you go and pay only for the consumption how much CPU how much memory how much nodes your application need and can scale up and scale down depending on your traffic so we are paying only for uh as you go and we'll came back to that into a minute from our programming model if you are a developer um server list are event driven and service based everything in the servus world is an event be it a request coming in Saving something in your database Sav in a file can be audio can be an image can be everything everything you know Serv word is an event which is a kind of a um programming model that is uh most of you must be familiar with and the last bit is it's stateless we don't have a well we do but stateless from a programming model is a best practice when it comes to that uh Cloud run I will hint you that support having a state uh if you want to but it's kind of considered of a bad practice uh having having a stateless uh service and externalizing the state into some form of State Management be it a database or something else is what you need to do when it comes to uh move to a serverless uh architecture and I'm I hinted into that uh but it comes with a lot of promises and a lot of good things uh Simplicity because basically you delegated all the infrastructure management and the runtime is managed by the the platform and the cloud provider uh in this case uh Google Cloud platform it is cost efficient because they are only paying as you go only using the resources or only paying for the resources that you used and if there is no request your your application is Idle your your uh your service is Idle there's no cost that you need to pay for it speed basically you delegated everything that is infrastructure management to the cloud provider and you have you take you you take back that time and put it into uh new features it's flexible uh the the platform will handle uh scaling up scaling down um managing the traffic for you and then it's simple because the product team the developers are focusing on adding value managing the business rather than focusing on uh new things so I managed saving costs and these diagrams try to uh detail in uh some way that so as your application scale uh in a traditional server basically you are paying for The Upfront cost if your the resources of your service is Idle you are still paying for that and the surus is another uh way of uh paying ex uh or billing it's you are only paying for doses that you use that will shift at some point in the future because as as your application is is growing and getting a lot of requests and a lot of using a lot of resources the traditional server and the serverless platform will basically be the same but if you scale uh if you scale more to handle those resources or add additional resources for additional server you gain that back so that's another this diagram tries to answer that and cl clarifies the best the bet when it comes to cost saving um serverless platform from a Google Cloud point of vi from from the Google Cloud platform we have two things uh go Cloud run and Cloud functions Cloud run very easy to use basically take a container and deploy it and everything else the magic taken care of by the Google by the cloud runchy cloud functions it's kind of limiting uh in terms of the things that you can do the runtime is basically taken care of by uh the team and all the introducing uh uh only deploying the code that you use only deploying your faction and your bet and it depends on again on the trade-offs that you have a cloud run is much more flexible so you have you deploy your code and you deploy the run time behind it and that's why you are taking you can basically move from container orchestration tool to Cloud run pretty easily take your container and deploy it there and um in a few days back we did um a full day workshop deployment in a Java application in Liberty uh in op Liberty which is kind of a application server for Java applications and we deploy it pretty successfully in Cloud run with minimal changes to uh to the cloud run configuration compared to uh cuberes Cloud functions is much more managed so we only have control only about your uh code and everything it's it's managed for you there are some use cases for cloud functions uh basically if you have if you have uploaded an image and you want to generate thumbnail the code for that should be pretty minimal so you want to add that and delegate the management for everything to the cloud provider and servantless is a whole ecosystem uh right uh there's a lot of bits and pieces that uh can be collaborate together in order to have a application and serve all the needs all the things that you might need to for your applications we have from a compute point of view we have Cloud functions that cloud run if you need storing data be it's in a SQL mode have alloy DB manage post gra if you want to use a no SQL thing you we have big table from a passing data around around your multiple Services pops up can be used uh and events will be generated from all your services and you have control if you want to listen or just ignore those Services then if you want to save some file be it audio video image those also can be storage within stored within Google Cloud Storage so it's a whole ecosystem that can help you basically to build all the use cases that you application might need and now come the interesting part Java and Serv word um starting with the good part uh we all know this about Java Java has a good and robust ecosystem it's been running for 20ish years now uh so with the system is pretty mature there a lot of Technologies and a lot of tools that enable you to do whatever you want with your Java applications um there are a lot of java Java is used to build Miss Mission critical applications that is running for years and years and it helped us to reach the moon right uh mature tooling and develop development support there's a lot of options probably more than we should have in the Java world but yeah having an option is always good to have a lot of options uh based on the build tool based on uh everything that you might need it continuous Evolution uh so we switch it from from all Java developers we switch it from uh years like five three four years uh when it comes to releasing versions of java to now having the six month monthly release so now we're in Java 21 well few years back we were in Java H which is mind-blowing but Java is continued to evolve and it's evolving rapidly and security is one of the big aspects when it come to Java because it's kind of built in and that's why it's pretty popular in the Enterprise world because uh it has security built in the tricky part though is the cold startup Java has an Heritage uh from 20 each years it's Backward Compatible from uh old versions mostly uh and that that eres basically is constraining in some ways uh and in the servus words can be tricky to deal with the cold startup Java can be slow sometimes depending on your application sorry and then we have resource constraints because how do gvm is actually work and then we'll uh dive more into that in a minute and then I alluded to the startup time and someone would ask what startup time M startup would startup time matters and the short answer is yes long answer is also yes uh and that's because if you think about with resiliency uh you would need basically if you're aut scaling you would need your application to start as fast as possible and starting as fast as possible meaning that you can handle the traffic shift or the shift into traffic faster uh if your application is slow meaning that the nodes are under stress and that can basically affect the performance of your application you might start dropping requests or that can lead to what we call cascading failures with one application starts failing and then the whole thing uh start falling as the Domino effects so startup time does matter if in for Java applications especially for the case of serverless and the rest of the presentation we're going to dive into some mitigations in how to uh make Java and uh leviate the resource constraint uh constraint part and also the startup time and the speed uh for the Java applications starting with the optimization that we can adopt from the uh runtime which is in Google Cloud uh we have what we call CPU allocations and having options is I mentioned that having options is always good and Cloud run offers options so allocation to CPU can be done in both ways the most ther way is throttled CPU which is basically where allocation CPU for the requests for handling your application once you finish will B basically that's a CPU so paying only for the amount that your application used CPU always allocated can be used for some sort of application and basically you are allocating this CPU from the moment you start your application and in most of cases we're basically using uh throttled CPU uh but in some use cases you would need to use always allocated CPU if you are running threats multiple threats and you would need to do a concur programming CPU always allocated can be important for you if you are dealing with lot of lot of a lot of GDB uh connections managing that pool connection can be tricky uh especially if you are allocating CPU back and forth so you want to have all that's always uh CPU and so on and so forth so we have the options and having the option is always good so that's one part of it second part is concurrency uh I talked about having a stateless application is good when it comes to uh serverless but if imagine for example you're having a stateful application where you can't have multiple requests concurrently then you can uh disable concurrency in Cloud run and specify concurrency to only one meaning that each node will handle one request of course it has the drawback that you are you would need more node to handle the same traffic compared if you enable concurrency but you have the options and having options is always good so that depends on uh you the maximum the maximum uh concurrency request that you can have is 100 uh last time I checked I might be wrong uh given that there's a lot of uh new features introduced in uh Cloud run but concurrency if it's enabled then the amount of nodes that you need to handle the same traffic is definitely less as shown in the graphs build Autos scaling Autos scaling it's my favorite feature in or whatever platform is available for it especially if you're un cool but it will help you to sleep better it help you to pursue other things uh be it Music guitar whatever uh but it's really important it saves uh a lot of time to pursue other things especially if uh you are un call um Autos scaling enabled by default for Sil pass from uh one of the greatest features and it's also available in uh Cloud run and in Cloud run it's you have two modes either CPU usage by default 60% again last time you checked you will kick Autos scaling or request concurrency if you hit the maximum uh Max concurrency then the uh Auto scaling will K can and especially it helps in the middle of the day if you are having uh a good day you poit something on R it and that blow up you're receiving suddenly a lot of traffic having Auto scaling is always good rather than getting page in the middle of the night and waking up Autos scaling is good but also uh don't be too optimistic Always setting the maximum amount of nose that you would need uh if for example if you go hacked and someone is buying in uh Bitcoin on your service you don't you don't want to have that so setting the maximum amount of uh sizes is always uh uh recommended heeld checks another important topic when it comes to deploying Cloud native applications and especially serverless and we have two things uh startup probes really important to tell the platform or the infrastructure that you're application is ready to start serving traffic uh especially if your application is slow uh I mentioned that we did the demo with uh uh an a liberty which is relatively slow it takes some seconds to start up but we managed to deploy it on cloud run um and we managed to do that by setting up a startup probe because we said oh wait until Hit This Server that hit this endpoint that until the server is actually ready to serving traffic it's really important both for starting up your application because you don't want your platform Cloud run in this case to kill your application before it's actually disable to serve traffic and we also have liveness problem livess prob is when your application is running and you are you reted at deadlock your application is no longer service traffic just like Bing to get that uh lock back uh so the live the platform will basically send in pinks it's like her bits and then checken after application is healthy if not it will kill it and start it up again again and that can help you and help you increase the resiliency of your applications startup prob and livess probe increase the resiliency of your application and help in serverless environments and last but not least I think CPU boost um and CPU boost also when you have applications that are that having trouble to start fast uh Cloud run it's enabled by default now uh so Cloud run will add additional CPU boost for your application in in actually to start faster it's enabled by default for your uh for your uh applications be it Java or anything but it's really beneficial when it comes to Java applications and it will basically uh uh bill you for the additional CPU imagine you have one CPU and you enable CPU boost uh the total amount of uh CPU you're going to be built for is two during the startup time and then it will scale back to one CPU during the lifetime of your application uh the choice is yours again you have options that depends on your applications it's a question of tradeoff so uh you are in control here uh and you you are in the driving SE basically Java specific optimizations now we finished with the cloud run time uh Cloud run and we uh are going to dive into what we can do from a Java uh Java point of view starting with using the latest version of java I can't stress enough how simply switching from old version of zva of java to a new version is actually beneficial and here opop planner did a benchmarking uh comparing startup time of java 11 and Java 17 uh and all the versions in between and you notice that startup time is much more faster to Java 17 uh compared to Java 11 so switching can help you to increase the uh the decrease the startup time for applications and here another example um just by switching from java 1 to Java 21 with no modification whatsoever just changing the runtime or the DVM basically help it to reduce the latency of of your applications so from a resiliency point of view the easiest way to benefit from all the improvements uh in the Java ecosystem is by switching to a new uh new version of java and you will gain a lot uh of course don't take my word for it uh uh migration to can be tricky but there is definitely some improvement in there that you can uh take knowing your gvm ergonomics uh and GV gvm ergonomics basically is a very clever way from the gvm basically to reach big performance the gvm thinks that it owns the environment that is running on and it thinks that it's the beefy process the most important process that is running in a uh in a machine and it gathers it gathers infrastructure environments amount of CPU amount of memory and it makes uh un un decisions uned decisions it makes unformed decisions and those decisions are basically based on the infrastructure information it collects and when it get those informations it basically decide on the amount of uh memory it's going to use for the Heap it's going to decide how much CPU or cores is going to use to run your application and it's going to also decide on which garbage collector to use now this can be tricky in Cloud native and specially cous environment starting with G garbage collector um so imagine you having application running under one gig of memory you may assume that the gvm will basically run or g1gc which is the default uh the default garbage collector now it is right well it's not because someone made the decision while back that if the memory is less than that number 1791 it will default to serial GC otherwise it will be G1 GC if that's memory and there are two uh C two CPUs or two processors or more so it makes those decisions and your decision might affect also your garbage collection so be aware of that another thing is the hip size so someone decided that if the the available memory for applications is to to 256 it will be 50% of the available memory if not if it's between 256 and 512 it's not a percentage it's a fixed number otherwise if it's more than 512 it's another percentage and it's only 25% so all those things might affect the performance of your application especially in serverless and uh and uh container environment so be aware of that and how to overcome the those things is basically to tune your gvm uh there are multiple options multiple flags that you can use to do that starting with using container supports that's available by default memory management basically Ram percentage and uh Max meain initial that helped to uh make uh informed decision to your gvm sitting the CPU core as well picking your own garbage collector if in doubt and want to debug how the gvm is behaving what flags it's actually picked you can always print flx final and that will print all the information that your gvm is using during startup time and that will help you to understand why the gvm is behaving the way it is um this is a very good table comparison from the micro Java team in Microsoft that did uh different uh infrastructure settings and compared what garbage collection is better is best for different uh settings and basically tells which one to pick in the different uh in different configurations uh greater Source check it out um the second thing is tiered tiered compilation T compilation was introduced in Java 8 and made by default prior to that we have two level of compilation or two types of compilation C1 and C2 so C1 was the client mode for those who remembers it client mode if you have less than one core in your machine uh basically developer machines we default it to C1 and that is f focusing mainly on improving uh startup time and reaching native uh Native compilation fast C2 is the server mode uh that's that that or that's how it was called back in the days and it's basically it could take some time but it's more focusing on reaching Peak perform reaching Peak Performance slowly um since Java AG we are basically mixing those two modes so we have a bit of C1 and a bit of C2 and that's what we call cheered compilations in servance environment since we are uh interested in reaching startup time faster uh setting up the tier compilation to C1 might be beneficial and can improve the startup time of your applications and we will get into that in a minute class data sharing um and the idea here is uh take all the archive that was generated from the DVM and share it between all the ens uh so when you want to execute a class file the gvm basically needs to look for a class name in the jar load the class load the bite code ver verifies it compile it and then put it into an internal data structure that takes some time and it's most noticeable when you have hundred or even couple of thousands in a typical Java application nowadays right the the problem is this data structure this data is actually the same if the the jar doesn't change so whenever you run your application the gvm needs to do all those steps and come to the same conclusion each and every time the idea behind class data sharing is basically take this data dump it into an archive and reuse it in every run which can save uh startup time in some scenarios and there are two types of archives static and dynamic uh since Java 13 the dynamic one uh basically you generate the archive and then you specify share uh shared archive file uh in your runtime and they basically util gvm to use it and it's consistent so you would need to use the same gvm each and every time you run it and it's compatibility it's something you need to be aware of you need this the default GDK is not generated you would need it by default in static damps crack uh or coordinated restore at checkpoint crack is a new project in the open GDK and the idea basically is to improve startup time and reach Peak Performance uh so to run a Java applications what we have is we compile our bite compile our classes when generate the bite code and then we archive them or dump them into an and then we deploy that and then the jet kicks in uh optimize our uh bite code and then compile it into native code and that's how when we reach Peak Performance crack hello yeah crack uh basically benefits from reaching the Peak Performance of the gvm and it's basically taking a snapshot think of it as taking a snapshot of your gvm or taking a snapshot of your container so we take a snapshot of the gvm and then in uh subsequent runs we basically run that snapshot which improve the startup time of your application and also improve pick performance and it can be available from the first request once the snapshot is generated and it's easy developer on boarding because because we are using the same gvm environment the same uh Java without changing uh anything there are some trade-offs as anything in software engineering uh checkpointing needs to take take a checkpoint of your applications and where you take that checkpoint might affect the performance of your application so you want to delay taking the checkpoint as as late as possible so the gvm and the jit compiler did its work and then generated the uh all the native code needed to reach big performance and the performance might vary depending on what where you took basically snapshot of course we take a snapshot so all the resources need to be closed Pool connections file streams all of that need closed and that's something you need to handle on your own o dependency since it's based on cryo and it's only available on Linux machines and there are some security concerns around it because we are taking a snap snot and that's still a work in progess progress and finally uh we have grvm and it's basically ahead of time compilation uh so in normal Java applications we generate an archive and deploy that archive and gvm checks of optimizing it uh and ahead of time compilation with grvm we're basically having this close uh word view and deploying in everything into a native executable as everything you would generate with C go rust and we deploy that executable into production it's no longer a Java application when it's generated no gvm a lightweight VM it's called substr VM but it's no longer jav uh a Java application so you also have a startup time lower uh con lower memor lower uh resources usage uh especially CPU and memory lower Footprints smaller attack surface you get rid of all uh the things that you might that you don't need in your application and you reach the pig performance from the get go however there are some trade-offs um since we have this closed view word we need to do everything during compilation time eacha take some time uh gr VM folks are working on uh what we call um uh layers basically uh similar to what we have in containers and Docker so that might speed up the compilation uh Clos word assumptions I already hinted into that you need uh Reflections and the dynamism of the gvm is no longer available so that's something you would need take to take care of uh metadata for third party libraries some libraries are still not supported within grow you need to specify some uh Li uh some metadata for it to be uh compatible and finally project Laden and here to hint that even in the open GDK we are doing some work uh in order to speed up the startup time of our Java applications and the early uh early numbers are relatively uh promising when it comes to proom project Laden this is just to be aware that is uh Community is working to improve the startup time of your application can I get [Music] my laptop um up uh just to show a quick demo of an application hello can we switch it's basically a Java applications and since the we're in Cloud next and everything about Ai and we're talking about AI every now and in so I thought we can have a Java application uh that is basically Bas use gini so what we have here is we're basically reading uh the div. Java repository so that's basically a website that has a lot of resources around Java so we're reading that and then we embid in uh okay what's wrong with my machine my machine stopped working interesting hello can r on the video and said uh NJ decided to stop interesting can you R the video and set sorry can I okay quit production can we have the video otherwise I can for squitch yes enj enj starting please demots still have five minutes that should be enough so yes I'm back okay so we have a Java application yes still there Java application that reads A webbsite uh and it's basically use Gemini and we're doing rag uh application so we're taking the knowledge that is in that website adding it to Gemini and then asking some questions and here I'm an prompt that's saying answer the following question as best as you can and provide as much uh information from the website as possible and having a list so let's start with a demo first uh so that's the service and I'm having basically a simple controller that is called chat and also my application is running here and sorry here so what is GFR what is Java flight recorder application is running locally first uh and it will basically come up with a it Che sometimes you know uh I would have a database with that but just for the sake of the demo I'm having it locally what is gell so it goes it loads all the information in the website and bid it into the gini and then return ask your questions order learnings about Java that's available in that website that's not the interesting part what I'm trying to show here is this thing so I have multiple Docker files and each Docker file is um uh an optimization that we can do to improve the startup time starting with this rist this rist is basically a Multistate support so I'm taking my Java application compiling it and here I am deploying it uh using this stess container image very secure uh I advise you to use it and then deploy more applications the startup time for this one sorry for the headache is I'm deploying it I deploy it already in Cloud run so it's Java 21 and the startup time for this one is 10 seconds so I'm using basically spring boot application and I'm using the startup time that could be indicative for the usage of it the the second optimization is sheared compilation and as I mentioned before it's the same exact Docker file my in is doing weirdness today hello so it's the same Docker file but I'm specifying cheer compilation and stopping at level one using C1 as I mentioned before and the startup time for this one is relatively improved and it's 8 seconds so we gained some seconds back uh the third one is um CDs class data sharing it's a little bit longer since I needed to uh download the archive and then uh generate the archive so I'm generating the archive here uh this one and then I'm using it in the last one so I'm generating the archive here uh and I'm hitting my application so I can have some uh traffic so uh traffic to the gvm and allow it to do D optimizations and then I'm using it here so uh I'm using this app G GSA which was generated somewhere in here uh here so this one for Generation to Archive and this one is for using it and then if I run that I my application starts only in 4 seconds now okay 4 seconds is good but let's do more optimization using crack crack is a little bit more complex to do taking a snapshot so I first have a this Docker image and all the magic happens in this entry point and the entry point is using is calling uh uh is running my application and uh generating the snapshot and generating taking hitting it with some traffic and generating uh taking a snapshot of that image while loading so once I generated that take took that container image and deployed to Cloud run my application actually start in 1 second is good can we do more yes we can we can use native image and here we are using grvm so we're taking application and deoy natively so we have a standalone native application and uh the application start now in less than one second so the application that was starting in 10 seconds with in Cloud run same environment now it start in less than uh SEC one second which is really great uh can I go back to my slides please awesome thank you very much I'm going to go a little bit slowly but just talk a little bit about security I know it needs a session on its own but just to mention that your code is your your responsibility we took s list infrastructure is managed by uh by the platform Cloud run uh Google Cloud but still the security of your code is your responsibility um dealing with secret is also an important uh topic secret manager works with Cloud run it enables you to Mount Your Secrets either as volumes or as environment Vari variables but it's a secure way to share secrets databases API Keys s Keys uh you name it but it's take of uh uh managing secrets in a secure way before they land in uh GitHub for example service accounts use specific service account for whatever you need uh by default we use uh default service account and that has access basically to everything so if someone attack got access to your Cloud run service it may basically good access to everything ident identity aware proxy works with Cloud r as well and manage authentication and authorization for you uh and can be uh uh added to your Cloud run or uh configuration and it can be managed authentication and authorization for you uh Engish policy uh so if someone manag to get access to the node URL uh by default the Engish policy is allow aut traffic we have the load balancer before Cloud run but if someone managed to get access to node he can access your cloud cloud run uh node directly and gain access to it uh so I advise to switch that to load balancer so uh all traffic needs to come from the load balancer basically cicd Cloud run works with everything as well as Java so pick your favorite stack and then uh run with it key takeaways have 20 seconds to finish that so Java has uh a great EOS system and so is Google Cloud especially Google Cloud run as we seen in the past two days uh so combin finding them is best of two words your code is your responsibility you still need to take care of it uh and then know your tools and know your gvm uh this one is uh don't forget to scan the QR code and please provide feedback I'm right on time thank you very [Music] much