 Welcome. My name is Peter Humphrey and I'm a Principal Product Manager at Pivotal. I've been working at places like BEA, Oracle, VMware since about 2012, and then we then we all joined Pivotal. So I've been working pretty steadily to bring Java and Spring together with Cloud Foundry since the get-go. I am lucky enough to be joined by an actual engineer on stage. Hi, everyone. My name is Madhura Bhave and I also work at Pivotal. I am a developer on the Spring Boot team and before the Spring Boot team, I used to work on Cloud Foundry. I worked on the UAE for a couple of years, which is the user authentication and authorization component of Cloud Foundry. Coincidentally, it's one of the few components of Cloud Foundry that's also written in Java and Spring. So I'm really excited to be here and talk about the Java microservices on Cloud Foundry. Yeah, so just a little bit about you folks before we get started. Who's a JVM developer? Spring, Java, Scala, whatever, something of the JVM. Okay, c++.net. Wow, okay. Python. All right, you get to come talk to me afterwards. JavaScript note. Hey, all right. Okay, cool. And then architecture. Who's like still classic three-term monolith or that's what they work with all day long? Okay, sure. Modular monolith. Getting there kind of a little bit here and there. Okay, okay, cool. Who's jumping into the deep end of the pool and going cloud native? A few people. Great. All right, thanks. That really helps just to give us an idea. So we're going to talk about Java microservices at scale. And before we talk about that, we're going to talk very briefly about something called an economy of scope. The economy of scope is the lesser known cousin to a phrase we all know really well, the economy of scale. Right? This is super basic concept in business. We all know it. The bigger your operation, the lower your unit cost is going to be, right? Right. Simple, easy, straight out of wealth of nations, you know, from 100 years ago, whenever Adam wore that book. This is the slightly less known cousin. The idea is that these are the efficiencies you get in business based on variety, not based on scale. Okay, wait a minute. What does that mean? Well, turns out that's actually pretty straightforward too. Here's some examples. The idea of an economy of scope is when you have maybe a shared function. So we all know that there's only one finance and HR and accounting department at your company. Right? I mean, it'd be stupid to have a separate finance and HR and accounting for every separate department. That would be kind of weird. So that's your shared function, right? You get an efficiency because you're leveraging it. Another example would be cross-selling. Hey, I make hairbrushes. I'm a hairbrush manufacturer. Well, it turns out that if I wanted to manufacture toothbrushes, I've already got most of the stuff I need. Right? All I have to do is tweak things a little bit. Or hey, I'm a 3D printer. I can make anything, right? From the same physical, indivisible asset, right? So this is economy of scope. Maybe one other example would be attaching the output of one business to be the input of another so that that second business is sourcing materials for free, right? So hopefully this is pretty straightforward. Economy of scope. Little different from economy of scale, but not that much. Still pretty easy to get your head around. This was a concept from two economists from like the mid-80s, by the way. So this is not exactly like a new thing. So this has been around for a long time. So why the heck am I talking about economics when this is a session about Java microservices at scale? Well, if you're thinking about doing Java microservices at scale, are you... And you look at what's on your team, if you're in management, or even if you're on the team, and you decide, well, what kind of talent do I have in-house right now, today? What kind of talent can I acquire easily for who I am, where I'm geographically located, what business I am in, and all the kind of other factors that play into hiring decisions? Who finds that hiring is a real challenge? Hiring good people, yeah. Okay, finding good people for your team is a challenge, right? So if you're thinking of microservices, remember that there is a pretty hefty tax that you're going to pay every time you introduce another programming language into this equation. Now, like I said, if you can't hire Java programmers or your staff is already very polyglot, then that makes a lot of sense for you. Otherwise, you have a lot of taxes to pay. Every different language you add adds at least all of this stuff on the slide. You switch from Java to C++, you may have a slightly different database ecosystem. You certainly got the ins and outs of all the client drivers that you have to learn, et cetera, et cetera, et cetera, et cetera, et cetera. Different tool chains, different IDEs, you name it. I think we all understand this instinctively, but it's kind of like how we understand the wage gap in the United States, which is not at all. Okay, well, maybe we understand it. We know that there is a wage gap, but we don't really know how bad it is. And in fact, even when we tell people how bad we think it is, we don't really get it. So that's my thought, is before you make your decisions, just think that bit of it through. And if you do decide to go with Java as your microservice stack of choice, you do have a couple options with boot. You can certainly go with Kotlin, Groovy, Spring, and Java, of course. But as you move up the value chain, there's a lot in Java to offer. In fact, you could argue that Spring has led the way in Java in a lot of instances with microservice infrastructure. And when you pair it with Cloud Foundry, you can start getting rid of boilerplate ceremonial code and have implementations of real best practices at lots of different levels. So you've probably all heard of Spring and that it does a great job with application boilerplate and patterns. Spring Boot, great. That helps with configuration. Spring Cloud, great. That helps with distributed computing patterns. Cloud Foundry, that helps with the infrastructure automation. Microservice infrastructure, microservice specific infrastructure automation even. So there's a lot to offer in Java. So what we're going to do, Madra and I, are going to take you through a quick 30 minute whirlwind tour of what that looks like with Pivotal Cloud Foundry. So let's talk about, start by talking about boot. Okay, thanks, Peter. So I love Spring Boot and I love Cloud Foundry. But that's not what I want to talk about. I'm going to talk about why Spring Boot loves Cloud Foundry and why Pivotal Cloud Foundry is a great place to run Spring Boot applications. Whenever we talk about cloud native microservices, we usually talk about 12 factor application patterns in the same vein. And a lot of the building blocks for these 12 factor applications are some of the core features that Spring Boot was actually built upon. The most important, or I can say the most relevant one that I want to talk about is configuration. And by configuration, I mean the kind of configuration that you would want to separate out for different environments that your application runs in. So say your application has a welcome page, which displays a message. And you want a different message on a test environment versus the prod environment. You don't really want to hard code these constants into your code. Or even if you do, you shouldn't. So Spring Boot lets you easily separate out your configuration from your code by using properties files. You can also use profile specific properties files. So say you're running on the cloud platform. You would define those properties in a file called application-cloud.properties. And Spring Boot would automatically pick up that configuration. So it's a great way to separate your configuration from your code, which is one of the factors of 12 factor application. Portbinding, that's actually an interesting one. What that means basically is the application should be entirely self-contained. And it shouldn't rely on an external web server to run. And it should just be able to run standalone. So with a Spring Boot application, you can actually embed Tomcat or Jetty web server inside your application and build this factor or executable jar file, which you can just run standalone. If you want to push it to Cloud Foundry, you can just do a CF push. And the platform will take care of it for you. And you have a running application within seconds. When it comes to connecting to backing services, backing services are basically services that your app consumes remotely, such as a database. What we provide is something called Spring Cloud Connectors. And Spring Cloud Connectors give your Spring application an ability to connect to the services available on your cloud platform. So in fact, they even create beans for those services that it has discovered. So it can create a Spring Bean for a data source, if it finds that your application is connected to a database service. And finally, logging. So the Spring Boot application by default, it logs to Standard Out. When the application is pushed to Cloud Foundry, a log aggregation component such as LogGator can aggregate these logs. And you can send them off to an external log analysis tool such as Splunk. So these are just some of the factors of a 12 factor application, which are really easy to build in with a Spring Boot application. And that's why I think it's really great if you use Spring Boot. I mean, we're going to talk about why Spring is great for building cloud-native Java apps, Peter's going to talk about that. But let's shift the focus a little bit and talk about why Cloud Foundry is, once you've built the Spring Boot app, why would you want to run it on Cloud Foundry? So the Java build pack, which Ben Hale spoke about in great detail this afternoon if you went to his talk, it's really cool because all you need to do is write your Java application as an application developer. You do not need to worry about how that app is going to run on Cloud Foundry. You just do a CF push. The build pack works with JVM-based applications, not just Spring applications. So you can see the list of applications that it works with down on the screen there. And the cool thing is it works with self-executable jars. And as we spoke about just a few minutes before with Spring Boot, you can build this fact jar which can just run by embedding your web server into the jar file. Java applications typically, developers might find it a little tricky to manage memory, especially in containers with limited or enforced memory requirements. And the build pack has this cool feature where it does advanced memory calculation. I'm not going to go into the details of that. But all you need to know is that you can just push your application and the build pack will ensure that the application is able to use the available memory without exceeding the memory limit. Who's seen Docker users complain about out-of-memory management online, Stack Overflow, that sort of thing? Okay, just curious. Thanks. Well, and even if your application does happen to crash, you don't always have access to the heap dump because the container gets recycled and the heap dump is basically lost. So another cool feature that the Java build pack added recently, I think it was recently, right Ben? So it logs a histogram of the heap dump and you can access this even once the container is lost. You can use sophisticated tools to look at why there was a memory leak. So that's a cool feature. Oh. So for spring applications, the Java build pack provides automatic enablement of the cloud profile. What does that mean? Has anybody heard of spring profiles before? They've been around since 3-1. Yeah. Okay. Yeah. So spring profiles lets you segregate your configuration for different environments. So you can turn on certain features in one environment, turn off certain configuration in another environment. So say for example, you have an application which wants to talk to a cloud controller and you're developing the application locally, but you don't have access to a running cloud controller. So you might want to mock the configuration for a cloud controller and you put that in a dev profile. But when the application is pushed to Cloud Foundry, you actually have access to a running cloud controller and you put that under the cloud profile because you know that I want this on my cloud platform. And the cool thing is that when you push your Java application to Cloud Foundry, the build pack will automatically enable the cloud profile, which means it adds the cloud profile to the list of active profile for spring, and you get the configuration under the cloud profile without any recompilation. Yes. So the final thing that I'm going to talk about why Spring Boot loves Pivotal Cloud Foundry is the most recent integration of the Spring Boot actuators into the Apps Manager UI. Apps Manager is the user interface for Pivotal Cloud Foundry, which lets you look at your applications, manage them, start and stop them, scale them up and down, et cetera. And Spring Boot actuators, they are end points that let you monitor and manage your application. So if you have a Spring Boot application to which you add an actuator dependency, you can actually get a number of built in end points, such as health, which tells you the health information about the application, or the end end point will expose the Spring environment, so the properties that you've configured in your Spring environment, et cetera. So the actuators are useful for getting arbitrary information about your application, or even diagnosing problems that your application might have. And the cool thing about this Apps Manager and Spring Boot integration is that now when you open the Apps Manager UI for a Spring Boot application, you get an enhanced dashboard. And I'm actually going to walk you through the Apps Manager UI that is running on PWS, or Pivotal Web Services. Has everyone heard of Pivotal Web Services? It's Pivotal's hosted version of Cloud Foundry. And this is the Apps Manager UI for a Spring Boot application. Got the mouse there if you want. Oh, thank you. Yeah, sure. So as you can see, this UI has been enhanced with some info from the actuator end points. Typically, you wouldn't really know whether this is a boot app, or a Ruby app, or what is it. But with this nice little eye-catcher here, this Spring Boot icon, next to the application name, you can easily tell that it's a Spring Boot application. The health information for each instance is actually augmented with health information from the health actuator. So if you can see here, I've added a custom health indicator, and that also shows up in the health information. Another cool thing about the actuator integration is the info that's returned from the info actuator. You can see that there is a link to the Git commit that the application was last built and pushed with. So I can actually go to the source code and find out what the heck is this app, or which commit actually caused this breakage that I'm seeing right now. Otherwise, a little hard to kind of figure out what's going on in our Spring Azure. Yeah, otherwise, sometimes it's a little hard to know which commit was this built from, or track it down. One of my favorite features is this new actuator that was added recently as part of Spring Boot 1.0.5. And it's the runtime configuration of loggers. So you can actually configure the logging levels for any logger in your application. And without having to restart your application, the logger will log output in that mode. So I have this, just a demo over here. I have this class called the Schedule Logger. And it's currently set to the info logging level. I'm going to change it to debug and see what happens. So as you can see, no restart required. I'm going to tail the logs. I'm going to tail the logs. It'll work. OK. And I should see debug output from the Schedule Logger. Yeah, I usually see it. It'll show up. Maybe you missed the click. Click on the demo code. Pause and tail again. Actually, let me just quickly make sure my configuration is yeah, it's on debug. OK, this was working a minute ago. OK, it might show up. But the point is that I can change my logging configuration at runtime and have that take place without restarting my application. I swear this worked before. Like 30 minutes ago. Yeah. OK, and the latest additions, I believe, as part of PCF 111 that have been added are some useful troubleshooting tools for troubleshooting your Spring Boot application on PCF. So if you can see here, you can get a heap dump or a thread dump. And you can also view HTTP trace information for all the requests that were made to your application. So I can show it to you a little bit in detail over here. You can click on any request and see the request headers, the response headers. And I think that's pretty useful for troubleshooting what sort of request response your application is getting or making. And one thing before I forget, all this is secured by none other than Cloud Foundry's own OAuth component, the UAA. So the actuator endpoints, as you can see, can reveal potentially sensitive information, especially something like the end endpoint exposes your application's environment. And you can probably think that what if you put some credentials in your environment? What if they get leaked? But as an application developer, you don't need to worry about any of that because it's all protected based on existing CF roles. So only authenticated users with the right roles, like a space developer or maybe the space auditor can view certain actuators. And it's all protected by OAuth scopes. So you just need to push your app, and the platform will take care of securing it for you. Cool. GVM Dumb? What? GVM Heaps. I did that. You did that? Cool. OK. Awesome. Thanks. Great. All right, so let's talk a little bit more about moving up the value chain, up the stack, just a teeny little bit. Let's talk more about why Spring Cloud likes Pivotal Cloud Foundry so much, and move into more microservice-specific infrastructure automation. Before I even talk about Spring Cloud Services, I have to mention container-to-container networking. That is a Cloud Foundry feature, but it is so important as a substrate that we have to talk about it for a second. I mean, this is basically your firewall rules at a container level. So if you don't have application, if you don't have container-to-container networking, how are you going to communicate sideways across containers? How are Eureka replicants in running when they're in AHA mode? How are they going to talk to each other? How are you going to have to go all the way through the front-go router and come back? Yikes. That's network traffic that you don't need. So we've engineered this in beta in the last release, and I believe it's actually going to go GA in a matter of weeks with the PCF 111 release. And in addition to just doing more than HTTP, because go router knows how to route what? HTTP. So if you want to do something like, hey, I'd like to use RabbitMQ as a transport for my rest JSON payloads, or maybe I have an IoT use case, and I need to do some funky MQTT protocols or something that just isn't HTTP, then you can. The other interesting thing is, of course, you can lock things down a little bit more. So container security within the container is all built on that Linux kernel, various Linux utilities that can help you do that. But this is the front door. This is the network to the container. So you can configure containers to pop right into existence with a zero trust policy. Deny all incoming traffic except for. So this becomes very useful. Comma, side note for any operators in the room, this also opens up the door for things like VMWare's NSX and other software defined networking protocols or suites products. So that makes things very interesting when you start talking to the ops folks about what they can do. Now with that in mind, what Spring Cloud services? Well, I saw a lot of Java developers raise their hands, so you might have heard of Spring Cloud. That's the open source bits that you use on your desktop. Yes, and you can, just like Josh Long showed you earlier today, you can say at Eureka, at enable Eureka server in your code, and ta-da, you have a Eureka server running in your desktop. Are you going to put that into production? Right, who said no? Thank you, yes, exactly, NFW even, right? So that's where Spring Cloud services kicks in, right? The scope of Spring Cloud open source that you use in your desktop is much wider as well. It does a lot more than just the circuit breaker, the service discovery, the service registry, and the configuration server, which is what Spring Cloud services does. Okay, so I think I've said the word Spring Cloud like 20 times in the past two minutes. So if anyone's keeping track playing bingo, you can cross it off. We've got, I just want to make sure you understand what the difference is between these two things before I go on, okay? So the Spring Cloud services is the server side bits that are run in production on Cloud Foundry. So what are they? So the configuration server, this is basically version control as a service for your APIs, right? You, the developer, you push configuration to a repo. Maybe it's a HashiCorp vault. Maybe it's a Git repo. Maybe it's several different Git repos. Maybe it's a mix of the HashiCorp and the Git. That doesn't matter, we support all the scenarios. You push those to a config server running on Pivotal Cloud Foundry and that is managed by Pivotal Cloud Foundry. And then your client applications that need to refresh themselves with the latest configuration, no reboot, no re-stage, no recompile, right? You're just pushing it at runtime over an API call. So, and we'll even provision some of the infrastructure to help you do that with things like Spring Cloud Bus and we're looking even in future iterations to figure out how to make it even more automatic. I think today there's like a rest end point that you can call to force your application to refresh or something like that. So we're even working on making that more automatic but very foundational part of a microservice infrastructure, right? Because you have containers winking in and out of existence very quickly, unpredictably. So being able to do things without a recompile is really helpful. So another, probably the most foundational component is the service registry. This is what, hey, I don't have to specify things with a hard-coded DNS name or IP name. You don't have to worry about that in the sort of DMZ demilitarized area where you're gonna implement your business logic behind a firewall, not exposed to a public by something like a Zool endpoint where there's a DNS name and an IP address. This is all dynamic. The producers and the consumers just register themselves with the registry. Hey, when I need to make a REST API call, where am I? And am I up or am I down? Pretty simple, right? But boy, isn't that a little more intelligent than the dumb round robin algorithms we've been using for the past 10 years? I mean, even just am I up or down is a big improvement, right? So again, when you put this in context on a system where containers are winking in and out of existence, new services have to be able to register themselves dynamically. This creates the foundation for things like intelligent routing, et cetera, et cetera. And given our focus on day two operations here in the Cloud Foundry business, this is fully integrated with the PCF UAA service, the security service, as well as you can deploy Eureka itself in high availability clustered mode. So we're kind of going beyond just, hey, we got a VM stood up or a container stood up that has the server process in it, like we're working on making those highly available. Again, real production scenarios. The last one would be the circuit breaker based on the Netflix open source Histrix library. When you have a failure or even a slowdown in a microservice system, it can potentially cascade and take out all the others. So even if it's not dead, right? Even if it's just slow, which in some cases is worse, harder to figure out, it's not dead, right? It doesn't show up on an alert panel that it's actually gone. It's just slowed down enough to become a problem. So that's gonna stop routing traffic, right? It's gonna break the circuit. It's gonna say, hey, after I exceed a certain number of failure indicators, that's it. Hey, I'm done. Don't route any more traffic to me. I'm dead, right? And then you can take some sort of complicating action or maybe that's to call another service that's actually working or maybe display some sort of fallback behavior, something like that. That's up to the developer to write. You can basically do anything that Java can do at that point. But the system will help you manage that and PCF will set up all the visualization for you and the dashboards. I'll show that to you in a demo right now. So I have a very simple app that, yeah, here we go, in my apps manager. And it's basically two boot apps. This is the data access layer. So this is just my service, right? This is the user interface layer. And this depends on four services. Config server, circuit breaker, service registry, the things we just talked about. And good old MySQL, right? Nothing too fancy here, just very basics. And push this application, gave it a route. And so I can come here and not look at that window. Let's look at this window, not even that window. How about I click on the UI portion? There we go. Okay, so this is a very simple app that just vends Chinese fortune cookie fortunes. Very simple. Every time I hit refresh, gives me a new one. Okay, so I'm gonna go to the command line here and say, let's find out what's in here. So I'm just doing a CF apps that tells me what I've got. Okay, great. I'm gonna stop the fortune service, which is that first service there. That's your data access layer, effectively. So if I kill that, what's gonna happen? Anybody? Anybody? Think I heard, yeah, I think I heard the correct answer in there. So this is gonna give some error fallback. In this case, we hard coded it to say, your future is unclear. And it will continue to do so until such time that I bring the service back up. Now, Cloud Foundry does that for you auto-magically. You don't need to do that yourself. I'm doing it to show you the demo. So that will take a second for the container to start, for the services to re-register with Eureka, and for then the timeouts to hit on the circuit breaker to say, oh, okay, I'm back to health. You can start routing traffic to me again. So at that point, you'll see those other messages that you'll see the Chinese fortunes come back again and not your future is unclear. While we're waiting for that to come back up, I just wanna mention, talk to you about one other distinct capability of PCF, which I think people are really gonna appreciate. This is the tracing with Zipkin, Dapper, HTrace type stuff that Adrian Cole has been doing in Spring Cloud. That project is called Spring Cloud Sleuth. We have instrumented that in PCF, something we call PCF metrics, which is an add-on module to Pivotal Cloud Foundry. And basically, it gives you a view of correlated logs. So when you're doing microservices, you don't benefit as much from pre-compile runtime checking. You don't benefit as much from a debugger. A lot of your errors are happening at runtime, which are a lot harder to find. So if you can't see the call graph, it's gonna be really hard for you to figure out where the problem is, right? So this at least gives you a sense of what REST service called what REST service called what REST service and how long did it take? So you can start to see where the problems are. Also, we've fine-tuned it a little bit so you can even visualize and filter the metrics out down to the application instance level. And again, sorry to hit you over the head with this theme, but it's fully integrated into the PCF security, right? So it's not in the sense of it just prompts you for a logon, but this works with the concepts of the spaces and orgs. As well as a little cake topper and a bonus for any of the Spring Boot developers, if you've bothered to define any custom metrics, we will display and graph them for you automatically without you having to do a damn thing. So that's kind of nice if you're doing your own metrics. Let me go back to my demo page here and see if this is recovered. Yep, there we go. It's actually not showing like that. Oh, yeah, there it is, yeah. Okay, cool, so I'm back to Chinese fortunes again. And just as a point of minor interest, if I go over here to the circuit breaker and I click on manage and I log in, apparently. Right, I guess security's the thing. So let's see, let me just hit a little bit of traffic on this endpoint again. Great, and now I can look at it. Oh, there's my spike of traffic. It should probably fall off pretty dramatically in a second or two here, but this is the Histrix dashboard and it was just nicely integrated into the thing. I didn't have to go to some strange URL or look up the documentation or any of that CRAP. It's just there. It just works, right? So I didn't have to set up Histrix. I didn't have to set up RabbitMQ to bring the metrics. I didn't have to do any of that stuff. Just works, which is great. So with that, I think let's wrap up this section. And... How are we doing on time? I think we're doing pretty well. You wanna check the timer? Yeah, I think we're actually a little over. Does anyone know what time? Okay, no, I think we got a few more seconds. Last thing, almost at the end, just some basics for the operators and the DevOps folks. Try and do that first order of magnitude. Where did something catch on fire? What component is at fault? PCF metrics will also give you network stats, container metrics like CPU disk memory, that kind of stuff, and app events. Just to give you that first order, like where's the problem so I can go zero and figure out what the remediation is. So again, lots of stuff to try to help you troubleshoot because we're very painfully aware that microservices makes things a little harder to troubleshoot. Now, everything I just said is what we are delivering today right now. You can use all this stuff right now. You can just go to run.pivotal.io, sign up for an account, you get $87 of trial credit, and you can kick the tires and test out your own microservices all day long. So that's available on our public cloud right now. You can certainly use it with PCF, of course, as well. In the future, what are we gonna be doing? Quick safe harbor statement. Yes, this is roadmap stuff. It's not committed delivery folks, so FYI. We're gonna be working on a similar PCF managed experience for Spring Cloud Dataflow. Anybody heard of Spring Cloud Dataflow? Okay, it's great. Think integration for those that haven't heard of it. This is a way for doing integration with microservices, messaging, Spring integration adapters, that kind of stuff, analytics. And so we're gonna be working on that as a PCF managed service as well, often to the future. And last but not least, the next release of Spring Cloud Services. We're just working on, this is actually input we got from some of our customers. The application instances or containers that get created when you want to make like a new CF org in space and provision a bunch of Spring Cloud Services, the Histrix, the Config Server, et cetera. And you want to provision that for a set of CF orgs and spaces. As you duplicate that and scale that up multiple times, that some customers were saying, wow, we would really love to lower our AI count and licensing costs and reuse the Spring Cloud Services app instances across multiple orgs and spaces. So put another way, as you scale up your business logic, the supporting infrastructure can now, with this upcoming release, can be reused a little bit more so you get some cost efficiencies. But most importantly, we wanna talk to you. We wanna hear about what you want to see in the future. We've come up with crazy ideas. We're talking about things like Zool API Gateway as a service managed by PCF. We're talking about, hey, what's a unified laptop to cloud type of developer experience look like for Spring Cloud Services? We wanna hear from you what matters and where the problems are. So please come to the Pivotal booth and talk to us. If you're into this stuff, we wanna work with you and our customers are very actively influencing this roadmap. So thanks for that. And I think with that. Yeah, thank you all for coming. We're good. Thank you very much. Appreciate your time and attention. Thank you.