Next-Generation Cloud Native Apps with Spring Cloud and Kubernetes

all right welcome back to the architecture track um we're gonna have ryan baxter up next talking about cloud native applications next generation cloud native applications with spring clouds so take it away ryan thanks craig i appreciate the introduction um welcome everyone welcome to my home office here in the lovely state of new hampshire i hope everyone is doing well um and staying safe i hope someday we can all be in person together but this is a great opportunity to learn a lot virtually and take advantage of all the benefits of doing virtually like the great uh chats and the many different rooms that you can interact with us at and be a slack so i encourage everyone to do that as well so um i know spencer and olga just gave a great talk um and i'm going to follow that up with a little bit more spring cloud talk uh and this time we're going to be talking a little bit about spring cloud and kubernetes and if you uh were just attending either spencer or oldest talk or you're attending dave syre had another talk um right before me as well and he's uh he also is talking about kubernetes so either one of those talks would be great follow-ups to those sessions so um get ready and i'll start sharing my screen here [Music] let's so make sure i share the right screen [Music] all right let's see that um all right so let's get started so first i have the uh usual legal statement that uh we have to we have to show to everyone so um you know uh i'll give you a minute to read that uh and if you really want to read it further i'll happy to send to you afterwards as well um just a little bit about me uh before we get started so uh like i said my name is ryan baxter um i've um husband and father two small kids that um actually just started school today so they should not be running into my office and interrupting our session today which is a good thing so they're all back to school so we should have this time to ourselves um i'm a long time job developer uh i've been writing java since i was uh in in college and university um and uh spent a while at ibm before uh joining uh pivotal and now vmware uh and joining the spring team i've been working on the spring team uh for a while now around five or six years i can't really remember i have to double check on when i started but it's been a while uh the whole time i've been on the spring cloud team um doing a lot of work with uh like i said with uh spencer and olga um and the rest of the spring cloud team um and obviously closely working with the the spring team as a whole as well super grateful and lucky to be part of such an amazing team and organization and be surrounded by very smart people and constantly learning in awe of what they do every day so encourage everyone to take advantage of of joining the sessions given by everyone on the spring team because you're sure to be wowed by what they all present um when i'm not doing my uh follow fatherly duties or working on spring cloud um i spend my time exercising and training for obstacle course racing so i you can usually find me downstairs in the basement in my home gym that i built or running on the trails here in new hampshire so a little bit about me um so to get started uh kind of talking about what it means to build spring cloud applications that are run on top of kubernetes um we should really start by talking about where spring cloud was and where it's come from and and where it might be going and uh so we'll take a little step back and um and talk about that first [Music] so uh years back uh this term started to appear called uh microservices and later cloud native applications and it was a new way of of of building and running applications right um uh traditionally we had uh monolith applications huge applications lots of code they you know it was a single app it encompasses everything right the whole application uh lived uh inside this monolith and we found that it was hard to maintain and didn't really work very well when you started to move these types of applications over to the cloud so the term uh an idea of building an application that's cloud native uh uh came around right and we started to take these monoliths and break them apart into uh things we called microservices which are small um you know very focused pieces applications that did very specific things and they're much more maintainable they're easier to deploy and manage and run in the cloud but as we did this we ran into a new set of problems right we needed to be able to um uh talk to all these applications right one application need to make a request to several different other applications so how did it um you know do that and uh you know the cloud was very um uh dynamic so you know an application might be running at this ip address today but tomorrow i'd be running a completely different ip address it might there might be multiple instances of that application running um sometimes uh configuring those applications involved was it was not possible to do things like pull configuration or right configuration to the file system so we need to figure out a different way of doing configuration you know when you had multiple instances of an application running you had load balancing and uh you had to think about load balancing across all those different instances and then of course while the cloud is great there's there's also room for failure right so we had to prepare for failure and be more resilient so a lot of these uh concepts started to emerge as we started to break apart our applications and move them to microservices and then eventually move them to the cloud and spring cloud did a great job uh trying to solve a lot of these problems right we saw the need for things like service discovery uh with with services like netflix eureka and zookeeper and console and we externalized configuration via sprint cloud config server and we provided circuit breakers to prepare for failure with with um spring cloud um uh circuit breaker and and and before that uh netflix's um hysterex library we had load balancing with with uh netflix's uh ribbon and now uh spring cloud load balancer right so we solved a lot of these problems using um you know other technologies and we made it in typical spring fashion very easy to use consume and integrate into your application and uh there is much rejoicing uh and then um so we we had lots of cloud platforms start to emerge right um you know we have uh you know all the popular big name cloud platforms like um aws and google cloud and and microsoft azure and we had open source projects emerge like cloud foundry and you could even run your own cloud in your own uh infrastructure right and we had spring boot evolve and spring cloud come along to then make it very easy to deploy these applications to these clouds right and as that started to happen um you know these platforms recognize that everyone building these cloud-native applications they they all ran into these same problems right they needed service discovery they needed load balancing they needed routing they needed externalized configuration um in some cases they needed you know you know circuit breakers and provide resiliency in some way right and they and they started to introduce all these different types of services into their platform they integrated these things into the platform um so that because they're just common use cases across the board uh that uh that people started having right uh you know i can remember the days back and the only thing that aws used to offer was ec2 right and now you go to the aws services menu and you see an endless list of services and just trying to find the one that you're looking for seems like a monumental task so um you know the platforms have done a lot a great job of providing uh features and functionality that are part of the platform uh to make building cloud native applications much easier so if you think about your typical spring cloud application it kind of looks a lot like this right and um you know this is just very basic right but this is kind of the basic the basic thing that we see a lot a lot of applications right in this case we have two boot apps um you know um that are running um we have configuration externalized in a config server here in this case it's backed by a git database or a git repo but this could be anything else that the config server supports you know such as a vault or subversion or the file system or whatever your choice is right in this case i just put kit here that seems to be the popular choice we also um the config server can optionally take advantage of uh spring cloud bus and use something like rabbitmq to notify applications when configuration that they might be using has changed so that they can update their configuration in real time without having to restart the application right which is that's a feature that is key and very popular in of the config server you know and then we also have a service discovery server right this could be eureka zookeeper console whatever your choice is down here and the applications use spring cloud to register with that that discovery server and also uh fetch data of the other services where they're located how many instances there are etc from the discovery server and when you have this set up we also have libraries for things like circuit breaker and load balancing and tracing that we've mentioned that then the applications can then use to take advantage of this data right so the boot app will pull in this configuration data from the config server it can use the discovery server to fetch data about you know for example um uh boot up b and how many instances are and what the ip addresses or host names are and then it can use like spring cloud load balancer to load balance requests to call just the multiple instances of boot at b and maybe put a circuit breaker around that so if that boot at b starts behaving badly it can trip that circuit breaker and at least you know not bring down the entire application and then we have tracing to trace requests back and forth between all the different applications right so this is just something that that i think a lot of people who use sprint cloud today are quite familiar with so as i mentioned as as these platforms have started to recognize various different use cases of building cloud native applications they've um taken some of uh the pain points that uh every app developer experiences and they push it down into the platform so that the platform provides support for these things as opposed to having the application developer or the app having to worry about it right so kubernetes is no different in that case right kubernetes is um an amazing platform it's one that i think um a lot of people are excited about including myself and i think it it provides a lot of advantages uh but it also recognized that we have a lot of different use cases and we're running all different types of apps on top of kubernetes and it tried to or does solve a lot of these common uh cloud native concerns um at the platform level right so if we were to take the same um application that i was just showing the previous slide that was using spring cloud and said i want to you know re-implement this application or write this application to run on kubernetes uh it might look something like this instead right um and um here i have instead of spring boot app a and b i have pod a and b but you can imagine these being the same thing pod is a is a resource inside of kubernetes which is running the application uh inside a container um so just in case anyone's unfamiliar with that um but for configuration in in kubernetes you have uh two different resources called config maps and one i don't have pictured here called secrets so config maps are just general configuration data it could be a properties file could be just key value pairs it could be a yaml file etc a secret is for more sensitive data you know usernames and passwords right things that you don't necessarily want people to be you know viewing in in the open um and either one it doesn't matter they both work in the same manner but how the application then uses that data is by uh you know configuring uh the pods so that that that data gets mounted as a volume in the file system inside the container or as environment variables inside the container and then it's up to the application to then either read that file or or you know look for those environment variables which is quite easy to do with spring boot today you know if you have a yaml file and a config map you can mount it as a volume and and point to that that file in your spring boot configuration and it will read that file and you know contribute those those properties as a property source in in the application and same with environment variables right and then for service discovery and load balancing and routing in those types of things they're all a side effect of creating what's called a service in kubernetes so just this just a little background the service is a way of exposing um a pod or a set of pods um to the outside world so that it can be um you know you can make requests to it for example so um the fact that you create a service for a pod then acts as a form of registering that service that's equivalent to registering that service in a service discovery server if that's what you're familiar with and we'll have another example this in the next slide to explain a little bit more about this but basically what that does is it configures a set of dns entries as well as environment variables which contain uh the ip address um the the the protocol and the port number um that then get used can be used by any other pod so right if i have service a here the ip address the the protocol and the port number for service a gets um there are environ variables created inside this pod or registered or i guess created inside this pod that pod b can then look for and use to figure out what's the i p address of service a what port is it running exposing what what's the protocol it's using in addition kubernetes also configures dns entries so that pod b can say i'm going to make a a rest i'm going to make an http request to http service a and it knows how to route that request over to service a um so it does both those environment variables as well as creates dns entries inside the pod so that these these things actually work in addition the act of registering a service uh also acts as a load balancer in kubernetes so when pod b calls service a you know via it's it's hp request uh service this service acts as a load balancer and we'll load balance requests over across multiple instances so we have multiple instances of pod b here uh you know service a makes requests to pot service uh sorry pod a makes a request to service b uh it will then load balance the um uh the request across all the different instances of pod b running right um as far as circuit breaker and tracing those things would work the same as they were today there's no difference you know when using those types of things in front of uh when running on kubernetes you still would wrap the http request for example on a circuit breaker and still add your normal tracing configuration etc now there are some differences uh and maybe potential downsides uh in in this this when doing things in this way from a configuration point of view uh if this config map changes you can go in there and change the config map values dynamically the the file in the volume uh will actually change as well with it but there's nothing telling the application that that configuration changes up to the configuration to actually figure out whether it changed or not there's obviously ways to do that but one may also make the argument that um you could do what's called a rolling update here where if you change the configuration for pod a or pod b you know you might have multiple instances of that application running and then you just one by one restart each instance so there's always an instance running to serve traffic but you restart them one by one to [Music] restart them with the new configuration data essentially which is a perfectly valid way to do it but i know that as a long time spring cloud developer that people also love the automatic uh refresh functionality that the config server provides in addition if your application is using the config server today um you know that know you're gonna have to make some changes here so that when you deploy the application onto kubernetes um that you no longer you know look for a config server instead look for a file and a given volume or some environment variables so some additional work you would have to do here um the other thing here is if this was using a discovery client implementation like say pod a was a spring spring cloud gateway uh and it was using load balancer in the discovery client to uh to uh route requests uh that would be a bit of an issue right because there would be no discovery client implementation then running in in uh kubernetes because you don't have one here right it's all taken care of by the platform um the other thing is this load balancer that's happening here at the platform level uh you really don't have much control over what algorithms are happening here so um you know uh however the the platform operator has configured the load balancer algorithms and kubernetes is what you get uh you don't have any control over it you know whereas if you had client-side load balancing you'd be able to pick an algorithm uh maybe depending on the service or the application so you have a little bit more control over as a developer right so those are some some issues that you might run into when we're comparing the two you know a spring cloud approach to maybe just a kubernetes quote-unquote native approach so just uh just to review here uh in case you're looking for equivalence here we have um to what spring cloud provides we have a config server the sprinkler fixed server will be equivalent to using things like config maximum secrets you have load balancing which is done at the kubernetes service level um again the act of registering a a service in kubernetes basically exposes it to other um uh pods uh running in kubernetes so that's kind of your discovery server as far as the discovery client end of the piece so figuring out where a service is located or or how to make a request to a service you have a hostname resolution so you could say http my service name right whatever the service name is that you created for that service or you can look at the environment variables inside the container and figure out what the ip address import and protocol is uh and they kind of you know this is an example if you had a redis service for example running this is what this might look like as far as environment variables inside the container [Music] so a few years ago i guess it's been a few years now we had a community project startup called spring cloud kubernetes so they realize that there is this kind of gap between what kubernetes provides as a platform and what spring cloud offers has traditionally offered as far as apis and interfaces etc right and they the community started a project called spring cloud kubernetes which the spring cloud team eventually adopted and brought under um the spring cloud organization in github and has since been maintaining um as part of uh the work that we do on the spring cloud team um and so they provided implementations uh for a lot of these things uh like configuration and load balancing and service discovery um uh out of the box um with spring cloud kubernetes and uh to our kind of naive detriment i guess on the spring cloud team we weren't really that versed in kubernetes at the time we were like oh this works really well but eventually we found that one of the major barriers that the initial implementation had was that it leveraged the kubernetes api server a fair amount so all the pods that were using spring cloud kubernetes basically had to have access to kubernetes api server to do a lot of these things to reconfiguration to basically use a to have a load balancer to you know basically fetch information about other services using a discovery client um in some organizations that's okay um but in some organizations it's not you know really the right approach they don't want the individual applications being able to talk to kubernetes api server and by default when you deploy a pod or an application to kubernetes that you're not allowed to um you have to give it special permissions um so there are some easy solutions to this problem and maybe some not so easy solutions to this right so the first thing we did was tackle kind of the configuration problem because it was somewhat easy right um because you could already take a config map or a secret and mount it as a volume or surface as environment variables inside the pod uh and that was fine and the boot app could read that that volume or those environment variables in in and you know use that that configuration in the application um and it also you know you could change these values and it would actually update the the data inside the pod which is great but you didn't have that refresh capability right and the way that spring cloud kubernetes out of the box would do this refresh functionality was it would create what's called a a watch which is a kubernetes concept again needed access to the kubernetes api server to do this to watch the config map to see if it would change and then you know refresh the application context if it did so to break that that tie to the kubernetes api server to do this we introduced an application in spring cloud kubernetes that you can deploy kind of like an infrastructure level application or a kubernetes controller you might want to call it it doesn't really matter but you can deploy this config watcher from spring cloud kubernetes to your kubernetes environment and it's the thing that talks to the kubernetes api server and watches the config maps and then use a spring cloud bus to or it can actually do this over http as well but you know whatever method you choose it then notifies the application that is configuration has changed and refreshes it so the only thing instead of each pod having to watch um you know use the kubernetes api server in order to watch it for configuration changes it's just a config watcher that talks to kubernetes api server and then we use you know spring cloud bus and http to notify the pod so that breaks that that dependency to the kubernetes api server for that piece of functionality um and but still inside of spring cloud kubernetes today the discovery client implementation as well as the load balancer implementation they all still uh require you to talk to the kubernetes api server in order to do that right so if you need a discovery client implementation you're still going to have to talk to the kubernetes api server to to get the list of services and and all that stuff uh so it's not in the ideal state yeah but what i want to talk to you about today is where we're going to be heading and this is much more about where we're going to be going and this is what this looks like so the first thing you're going to notice here is that none of the pods are talking to the group in any type of api server anymore hooray right we've broken we've made sure that that's that's still within case right we don't want to have that as a dependency for the applications the other thing you're going to notice here is that we also have um in addition to this config watcher we now have two new things right well not new things right we have a spring cloud config server this is a config server that you're all loving familiar with you've used forever from spring cloud but it in addition to the existing environment repositories that can talk to get subversion file system svn vault whatever uh we can also pull in data from config maps and secrets into the config server so if your application is currently using a config server and has data from git that it wants to pull in but you also want to maybe provide some kubernetes specific configuration and keep that on config maps and secrets uh the config server would allow you to do that and then we also have this new thing called a spring cloud kubernetes discovery server and this is you can you know for all you just basic uh conceptual purposes you can think of this kind of like eureka it's not eureka but it it behaves a lot like eureka and that is just a set of rest endpoints uh that allow you to fetch uh uh service information from um the various different services that are registered in spring cloud in kubernetes right so um the the one difference is that in something like eureka you the pod or the the application would actually register with the discovery server they would send a request and say hey i'm a service and here's where i'm discoverable at uh the in with this implementation that doesn't happen um again the act of creating a service here in kubernetes uh is the same is is is basically how you register the service right um so spring the kubernetes discovery server uh it talks to the kubernetes api much in the way that config watcher does to figure out the services their endpoints their ip addresses their ports etc and that's how it gets the data um that then can feed back to the applications right same with the config server right the the way it's it's monitoring and or the way it's it's getting data for the config maps uh to surface into or to serve alongside other environment repositories and fix over to the pods is by talking to kubernetes api server so we're trying to keep this model where you have a couple of maybe sprint cloud infrastructure-like components that you might deploy they're the ones that need access to the kubernetes api server they're the ones that have special permissions but outside of that every other application that you're going to deploy here that might use spring cloud does not need that right um but now this opens you up to again having a discovery client implementation um that you can use you can use client-side load balancing at that point uh again circuit breakers and tracing still work the same way um you can you can choose to use these services you can then mix and match components like if you don't want the config server you just want config maps and you want to mount them as volumes and do all that stuff uh you can you can do that you can not include the kubernetes discovery server and just leverage um you know the environment variables and dns routing if you want right so then you can start to mix and match things but this model here and in these services then make it much easier to basically choose the approach that fits you right so the one when people ask me you know should i use a config server or config maps should i how should i do service discovery how should i refresh configuration right there is no right answer here um it really depends on what you're building where you're coming from and and and how you're trying to you know you're a specific situation like i can't i can't give you one answer there is no one size fits all right so basically what i'm saying is you can choose to use the platform as is and not use any spring cloud components at all that's a completely fine approach to building a cloud native application that runs on top of kubernetes i fully support it i think it's great i you know i have no problem with you taking that approach right if you're building a green field application uh something that you know is just gonna run on kubernetes go for it like there's nothing stopping you from do that it might make your life even simpler right it might even be a better approach but if you're taking applications that might be running somewhere else that are already using spring cloud and you're trying to move them to kubernetes instead of having to rewrite them and change them and recompile them and do all this crazy configuration to get them to work in both places or whatever um you know i feel like these new components in spring cloud kubernetes could make that that transition a lot simpler or if you're planning on keeping them running in both environments maybe you have a cloud foundry deployment over here and you have a kubernetes deployment over here and you're going to apply some applications for race some applications in cloud foundry or both in both environments you know this makes moving them back and forth and running them in both places a lot easier so it really all depends on uh what you're doing in your use cases right so what i want to do do next is demonstrate this to you to show everyone right so i'm a big fan of demos i think that's much more impactful so um let's leave that up for later okay so what i have here i'll show everyone i don't think we're gonna need that window but we will need this ied window here so i have a very basic application here um i'll try to make text bigger so everyone see it as well so i'm gonna describe it as first this is just a basic spring cloud application um we have a config server that's pointing to a git git repo it's using git as back end inside that github repo is really just one single file you can see here this is the repo it's going to it's just an application yaml it has some basic configuration which is uh stuff around actuator and and some other things eureka that we'll we'll explain a little bit later on but that's that's what that's doing again nothing fancy happening here it's just has a at enable config server uh annotation on it um we also have a discovery server and this is again very basic just eureka nothing fancy going on we have at enable eureka server that's the only thing that's going on here then we have a couple of different quote unquote micro services so we have a fashion application we have a hot deals application we have a toys application there this is kind of just a very basic like shopping example it just services data about you know maybe toys and hot deals that might be happening and some fashion items right and in front of those microservices we have a gateway which is a just a spring cloud gateway again this this has is nothing terribly unique or fancy about this application at all has a couple routes configured which for each different [Music] microservice that you can reach so you can see here they also have a circuit breaker here wrapped around them that goes to a fallback method which just returns an empty list so nothing incredibly fancy again uh there is a rest controller here and i'll save you from trying to read all the code but basically all it does is aggregate it calls all three different microservices and aggregates all the data together into a single response that's it nothing again nothing terribly exciting so i'm going to start this up and while all the applications actually the server server's already running the server is running and so i just need to start the other ones um so we should start very quickly i'm just going to wait for them the microservices to start and register get that away oj um they're all started okay and then i'll start the gateway um the one thing i'll mention that is a little bit fancy about the toys application is that it's using a library called um chaos monkey which is a really cool library for doing chaos engineering um and one of the things it does is introduce random latency into rest controllers so that you can randomly have it say take five seconds to send a response back uh and that's a good way to test whether upstream applications can deal with you know the slow delay response uh from downstream applications so that's why the gateway has everything wrapped in the circuit breaker so when the toys best seller has this this random latency uh pop up that it will fall back to the the fallback in the circuit breaker will be tripped etc uh as a demonstration of that uh by default it's it's disabled so chaos monkey is not running when i start this application uh off the bat here so um i'm to pull up my terminal window here i'll close some of these other ones so i don't get distracted and i will close here so we'll just demonstrate how some of these work so um h oh i just need to remember the ports of everything that's running uh 8083 is the hot deals slash hot deals see [Music] we get some i'll make this window a bit bigger for everyone as well [Music] there we go and i'll make a size just a little bit bigger in case that's a problem so we just get some json back um from that end point right um fashion application running on 8082 so if we do http colon 8082 try this all right 8082 slash fashion slash seller here we get you know some fashion items that are best sellers and then we can do uh i believe the toys services on 808.1 [Music] um so 808.1 is going to be still yes there's still text being cut off somewhere [Music] there we go so there's toys all right um now uh with the gateway application we can do like i said there's that we can route uh to each individual service um [Music] but we can also hit this start page which then uh aggregates all the data from all the services into a single response so we can see that all here as well all right so i mentioned that the uh the gateway here uh sorry the toy service has a chaos monkey enabled um or has a library there it's not enabled so uh this might be easier to look at in the browser so if we do http slash 8081 slash actuator chaos monkey we see that it's currently disabled uh we can enable it by using the making a post request to actuator cast monkey enable and that will enable chaos movies so we can see here that's not true um and let's do this here just for the sake of it you can see that you get some random latency here the toys response was triggered that that took a little bit to come back so we got the fallback getting the fallback and here this next one we got the remote service so if i keep on refreshing the page randomly we get you know the late random latency and we get the circuit breaker trigger and then sometimes we can actually get the actual response to come back so that's how the application works now what i want to do is bring that application including all of its spring cloud components over to kubernetes right so i have a cluster deployed to aws or setup in aws here it is completely empty if you're in case you're wondering it should be completely empty there's nothing running uh if you're wondering what this is i'm using it's a cool little tool called lens um i just found out about it the other day i really liked it um as far as the gui is concerned the other tool i really like if in case you're wondering i'll just throw out some random advice unsolicited uh if you're more of a cli guy uh k9s is a really cool cli tool which i've been using in the past uh to see you know what's going on inside your cluster instead of kubernetes anyways random piece of advice we're going to stick with lens for right now um it's empty there's nothing going on there's no fig maps there's no deployments there's no pods there's no services really running there's some default config maps and secrets that are part of the cluster but other than that there's something here so we're going to go ahead and deploy things right so i mentioned we have that discovery server that config server in the config watcher as far as like infrastructure type components that we want to run um to support us running on kubernetes so i'm gonna deploy those um i have all the deployments and and all the lovely kubernetes ammo that everyone loves uh from kubernetes already written out so we're not going to have to go through and do that so i have these yaml files here the one thing i will point out uh that's special in these that really you're really only concerned about is for the config server i have its configuration set to include uh the git profile right and it's pointing at that same github repo that our local host config server is pointing at um so it's this looks exactly the same right so we're going to go ahead and deploy those and then while that's getting started up um we'll we'll talk about something else while we wait for it to happen so i'm going to do ctl apply f and we want all the stuff in the infra directory here so that's going to go ahead and create all that stuff we should see you know various things happening here in our deployments and pods now spinning up which is good but while that's happening i just want to go ahead and take a look at some of the configuration inside the applications that we're going to be running now these are really these this toys bestseller the hot deals the fashion application they're really just kind of basic um boot applications there's nothing crazy going on if we look at their application yaml here they really like i said they're they just they're really just a boot application with a rest controller there's nothing really fancy in any of these they all look pretty much exactly the same um the configuration as you might imagine is just using you know spring config import pointing at the config server in the local host and then in the local case here we'll try to remember to make the text bigger and in on kubernetes we have it pointing at the um the kubernetes config server right where does this dns name come from sorry this host name come from again this is the name of the service in kubernetes so you can make hdb requests to that service right so if we look back here [Music] configuration server and i'll make this a little bigger and find service here we see the name is this right and that matches um what we have here and the port number 88 right that also matches um the port that we're exposing in the service right so that's basically what that that how that works um this um spring config activate on cloud platform kubernetes a nice little um configuration enhancement that boot has um added i believe it was in boot 2.3 but it might just be in 2.4 i can't exactly remember what was added but definitely in 2.4 but it basically allows you to activate this this yaml document on a specific platform so they have you know various different cloud platform options here one of them being kubernetes um so this this spring cloud uh config import statement is only gonna be activated when we're running on kubernetes and this configuration looks exactly the same across the hot deals and the toys best seller application as well so i'm not gonna bother showing you them um the gateway um it's uh only different in that it also uses discovery client so in addition to the discovery server i've written a discovery client starter in spring cloud kubernetes here again this is something new that isn't in the open source yet that i've written for the you know as a demonstration purpose here and hopefully will be in open source fairly soon um it's in my github repo my fork so you can check it out but um that's the only difference here um for its uh as far as differing from the other the other apps in any way uh configuration wise it looks you know this application configuration for the gateway looks exactly the same so all these are up and running here i'll just quickly demonstrate some things to you if we go to the services for these i have them they should be exposed and sometimes start off in a discovery server here sometimes these external ip addresses don't resolve as quickly as i'd like but let's see if we gave it enough time so this is discovery server okay great um so this should look pretty much exactly like if you're familiar with the response you would get from eureka it look should look pretty much the same right you see you have the config server you have the config watcher right these are the only things that are running right now as far as services but it has the host port uri all the same stuff that you're normally used to here and then for the config server let's try that out here [Music] application right now you're only going to see data from the github rego right but this is basically the config server you know you can see that this is the data coming from the confixer or i don't think it helped people when it comes okay uh all right so let's deploy our apps uh so i'm gonna say [Music] apply apps and just i'll point out real quickly here again we have all the services and everything here i do have um a a can feedback and secret for the toys best seller application that i've specifically created here um to demonstrate the fact that we can fetch data from config maps as well as the github repo and this is how we're going to enable chaos monkey right now you can see it's disabled by default and we're going to show enabling that the secret is not used for anything it's just demonstration of you can pull data from the secrets as we'll see in a second there's also an application config map which gets to apply gets applied to all applications uh that pulling data from the config server um just to demonstrate that as well but again it's not particularly important or useful um all right so those should be all up and running great uh i'll start out with the discovery server again i'm just going to quickly show you that we have all the services running i'm going to scale up oh actually i'll show you the services first so now if i refresh this discovery server here we have the gateway we have hot deal service we have the toys best seller service and the all the other ones the fashion service right all here now great so that seems to work um i'm going to scale up one of the instances just to show that that we can have multiple instances running so we're gonna wait for that to finish in a second uh i mentioned we also have the config map here for the toys best seller you see that here uh that's been created um look at the look at the config server here so we're going to change the configure request to be the toys best seller [Music] somewhere all right so if we look at the property sources that get returned here we see we have the application.yaml config map um which again is just gets gets applied to every application that would make a request to the config server we have uh the config map for the toys best seller here right with our chaos monkey enabled set defaults uh we also have the secret that's not used for anything here but it's just a demonstration of that and then again we still have our configuration coming from the github repo as well now um just jumping back to the discovery server if we look and make sure that the hot deals application scaled correctly it did so if i go back to my discovery server here refresh that i'm going to see it should have three instances of the hot deal service sorry one two three um i can also for example you know narrow down my request here to just show me um details about the hot deal service and that then just shows three instances if i want to see a specific instance there's also an endpoint for that right and this is all just really adapted from the api from eureka looks perhaps the same idea so if i change this and oops i also [Music] on the instance id we'll just see the specific data for that [Music] i think it's just [Music] true i can't remember the api endpoint at this point i might have messed up the id too anyways you can drill down to a specific instance i think it's instant slash [Music] try instance one more time there we go so this is the the specific instance i just remember the end point um so yep that's the discovery server all right so as i mentioned before we have our um toys bestseller it has chaos monkey set in it so if we look at this so 8081 slash actual weight or slash envy we look at scroll down here lots of stuff going on [Music] but we should be able to see oh my goodness so much so many properties we see uh the config server config map property source here uh for the application we see the toys best seller config map property source and this is fetching all information from the config server running on kubernetes uh backed by the github repo as well as the config maps and secrets we see all that stuff surfacing here inside the actuator endpoint the environment actually endpoint if we look at the chaos monkey here it's at the faults i'm going to go ahead and look at the deployment for the config watcher i'm going to look at this i'm sorry look at the pod big watcher here i'm gonna go ahead and change this to be true save see we have about a minute left so hopefully i can get this in this should send a refresh event to the toys best seller service eventually maybe come on come on uh there we go there sent the refresh event uh if i go back here and see it's enabled now true so if i go to my gateway sources gateway real quickly here seven oh slash start page here we get our gateway data we see the remote service remote service from upstairs and then the fallback so um that's it that's about all the time i have i hope everyone joins me in the in the slack room uh in the zoom session for more questions uh here are links to demo apps i placed that all the links in the slack room as well so thank you all right thanks ryan that was that was great loved hearing about all the uh the spring cloud and kubernetes uh synergy going on um next up we're gonna have a small break but after we come back from the break we're gonna have stephen van beelin talking to us about event sourcing with our socket so see you in a few minutes you

Channel: SpringDeveloper

Views: 1,051

Rating: 4.8571429 out of 5

Keywords: Event-Driven, Kubernetes, Serverless/Microservices

Id: UDg7y9TheI4

Length: 56min 8sec (3368 seconds)

Published: Wed Sep 22 2021