 So, what I want to talk about today, there is all kinds of really cool stuff happening both with Java and with Cloud Native and all of it is smashing together and it's raising some very interesting questions about what on Earth we are going to do next. As Heather pointed out and I mentioned a little bit earlier, I do not in this deck have information about Scala or Kotlin or other innovations happening on top of the JVM although to some extent they definitely fit in this space. I want to take a second. Everybody should know what Cloud Native is but I still get hilarious comments from people that I wanted to actually talk about. I had someone say that in order to be a Cloud Native application you actually have to use Cloud only backing services like object storage. If you don't use object storage you are doing it wrong. I can't even, really. And I had somebody else say it's not a Cloud Native application unless your team is using agile practices, is using DevOps, is totally your little team is involved, is on the hook for 24-7 operations using pager duty. If all of those things are not true you also do not have a true Cloud Native application. I'm sorry, also wrong. There is very much a culture portion to being active in a Cloud Native environment. DevOps is definitely a thing. There are many different ways to approach managing uptime. Everybody does pager duty for the actual team. There's plenty of other ways to take care of that so I just find that hilarious. If we want to go back to a definition, the Cloud Native Computing Foundation has a definition. Interestingly to me they talk about their applications, the Cloud Native applications being microservice oriented, which certainly leaves room for the microlith, that thing you only have one of because that's what you're starting with and you're not starting with an insane everything, right? You've got room for the microlith there, which is good. The big part is you're loosely coupled, right? All of your dependencies are explicitly declared. Your container packaged, various kinds of containers, right? This is where buildpex come in, Docker comes in. The big point here is that last couple things where the single biggest characteristic of a Cloud Native application is that it can be managed. It can be orchestrated, right? It is stateless. It lives in a box. It fits well so that all of this automation stuff can happen. That has ramifications into how you write your application, but that is the key thing. If you're writing a Cloud Native application, you're writing something that can be dynamically managed by some orchestration mechanism. 12 factor fits right in here. All of those points, right? All of those factors are all about how you write an app that is orchestratable. Now, I'm going to show a couple of things about microservices because this is our shared pain. This is why we're doing this, right? I like to say we all like to badmouth the monoliths right now, the big dinosaurs. We should remember that the big dinosaurs are incredibly capable and they are powering most of the world's internet right now. They are not inherently evil, but they cause us pain, right? They cause us problems. They make it hard to innovate. They make it hard to iterate. They make it hard to experiment. And that pain is why we're starting to move from monoliths to microservices, right? And we're trading off pain to some extent, right? We also came, we took pain and we kind of made pain worse, right? We decided we really wanted an enterprise service bus because we wanted to have service oriented architecture and have all of these pieces, being able to talk to each other. And so we took our monoliths and we wrapped them in soap and Jack's WS and exposed all of our internal details to everything else. Now I should also be clear, like I want us to understand systems that use enterprise service bus are also incredibly capable. They are in places you would not believe doing amazing things. And they're like people who are trying to replace them are like, I have no idea how to replace this capability. It is fundamental to our business. It is awesome. But they can't make any changes because to change one thing, they have to change everything. And that's the pain, right? So I just want to make sure we're all remembering our shared agony here because everything that we're doing next is trying to walk away from this shared history. The ideal when Netflix and Twitter started coming out, this is a tweet that's probably four years old now. I love it because it's Adrienne Cockroft sitting in the audience taking a picture of Twitter's interaction diagram and saying, hey, ours looks kind of the same. And we call it the Death Star diagram. You guys can't see it. I totally have a Star Wars t-shirt underneath this sweatshirt. I'm a big Star Wars fan, so I thought that was just generally hilarious. We know that in order to get to those big environments, that automation is huge. This again gets back to the fundamental concept. These things have to be orchestratable. You have to have automation or you will lose your mind. Zero downtime upgrades, all this stuff, it goes back to our pain. We have to do weekend outages because we have to upgrade the entire system. We have to be able to do automatic scaling. We're not going to bother making all of these little stateless services if we can't scale them automatically. Real-time monitoring is important as is, I'm sure most of you know with Cloud Foundry getting all of your logging and tracing data out of the process because the process will disappear and if you don't have the data out, it all is gone. So some of this, I'm hoping all of this is like, yes, yes, yes, we know, we know, we know. It should be good. So this puts, I'm calling this out explicitly for a couple of reasons, but this puts burden on the developer, at least at first. We'll talk about that. So we are talking about these ephemeral processes that are stateless. Again, we're going to be elastically scaled. When we say stateless, we mean you cannot count on the application that in memory process, process that has session data, for example, in memory, you can't count on that process still being there. You're going to go through the round trip and in the meanwhile, the process got tossed, maybe it was sick, maybe it wasn't needed anymore and there's nobody for you to bring that stateful session back to. It's gone. And so that changes when you start looking at people writing applications that come from the old environment, they're like, but I have stateful sessions. So it's like you have to change your thinking about how you're going to deal with session, that sticky session-ness, because that doesn't necessarily apply here anymore. You have to expect rubbish. Part of why we're doing this, right, with all the pieces everywhere so people can experiment, they can evolve and all of these pieces can evolve independently. And this is the point for everybody that's writing Java, because it's especially, this can happen to us by accident. So we love Jackson, right? We love Jackson. Now the problem is if you use Jackson, you're automatically serializing a JSON object to and from your data stream. How many people are reflexively at this point saying ignore unknown fields because you had better be, right? Like, or you are implicitly fragile, you are not robust. There's another piece to this, which also people, who has tried Jackson views, the JSON views that Jackson has. Have you tried them? Oh, then that means you are very likely exposing all of your internal details to everybody else because you're taking your model and just dumping it. You're giving yourself no room. How many people use DTOs that are separate from their models? That's safer, right? You're giving yourself some padding. If you look at domain-driven design from Eric Evans, they call that an anti-corruption layer, which I think is hilarious. But it's that kind of thing for Java developers. That robustness stuff is really easy to miss because we love ourselves with Jackson. Fault tolerance. We know we have to be fault tolerant. There's stuff we have to do in our application to make sure that errors don't cascade through the system. We have to fail fast. We want to be able to define our callbacks or callbacks and fallbacks and retries and all that stuff that we'll get to why this is important anyway. But here we just have more moving pieces. The application developer has responsible for more things. So far, so good. All this stuff, right, it's not easy. It's not easy to do. It's not easy to get right. So some of this is provided by the orchestration layer. That could be Cloud Foundry. That could be Kubernetes in both cases, consistent with 12 factors. They're saying the infrastructure should handle some of this. But there's a lot of it that the developer still has to do. And that was the beginning of Netflix, right? The Netflix engineers, I think it was Adrian Concroft who quoted it at one time. He's like, not everybody is going to be really good at all of this stuff. So we're going to make a set of libraries so that you have the really smart people who can do this stuff and they can do it once and then everybody can use what they did. Eureka for service discovery. Zool, which is your health-aware API gateway. Ribbon for client-side load balancing, I'll come back to that. Everybody should have heard of those, right? Histrix and Turbine are huge. The good thing about the Histrix and Turbine is the amount of data that they collect from the point of view of the client. There's all kinds of other things you can measure at the network layer. But Histrix is the one that says, I actually tried to make the call and this is how well it behaved, right? So that kind of feedback is incredibly important. Histrix is really, really popular. And they also have a metrics library and our case configuration. So Spring, everybody, who's used Spring? Just a few people have used Spring. So Spring Cloud Netflix combines the Netflix libraries, right, with what Spring Cloud provides. And in some cases, Spring is doing things that Netflix didn't do, right? So Spring Cloud has Sleuth. Who's used Sleuth for distributed tracing, right? Netflix didn't have a library for that. So Spring is filling a gap there. Spring has some security aspects and stuff. Again, Netflix didn't do that. What is interesting here is Spring has made using Netflix really, really easy. I think at this point, based on cursory Googles of the interweb lately, there's absolutely no real useful way to start a Eureka server if you don't use Spring, for example. They have officially like, you know, they've made it so easy there's no other way. I found that really hilarious, by the way. But we know also that Kubernetes is coming on pretty strong right now as an orchestration layer. And there's a whole bunch that Kubernetes already knows. You don't need a service discovery mechanism if Kubernetes already knows all the services that are involved for just the biggest example, right? So has anybody looked at Spring Cloud Kubernetes? So Spring Cloud Kubernetes is taking some of the Spring Cloud concepts, including the discovery client, for example, or the ribbon client, and is making those run on top of native capabilities of Kubernetes. So you don't have to deal with a Eureka server anymore, right? You're relying on the infrastructure that Kubernetes provides and the information that Kubernetes has to be able to do your service discovery, your routing, et cetera. And they also have some adaptations for taking Spring Cloud, or Spring actually, just Spring configuration mechanisms and mapping those down into the configuration capabilities that Kubernetes has. That's pushing more responsibilities down into the infrastructure in all seriousness and is taking some of it out of the application space. I have to be careful. I'm going to go too fast. I do that all the time. What I like about the side and to be fair, some of this applies also to Cloud Foundry. I think one of the interesting things between Kubernetes and Cloud Foundry is how they treat proxies. In Cloud Foundry, you have the go router. Go router sitting in front of your elastically scaled services. In Kubernetes, you have the Kubernetes proxy that's ingress egress to the pod. So how they are used and what linkage you use to get there is different, conceptually, they're the same. Because of where and how these things live, there's ways to configure Zool and possibly, I haven't done this in a while, there's ways to configure Zool, I believe, and also Ribbon or Eureka or somebody, to go through still the go router. So you can still bring the go router back into that, because the go router does, in theory, know who's behind it and what state they're in. And so it's, again, you kind of have a redundant system. If you have Eureka up here, you have to register and de-register with Eureka and maintain your state there when, in theory, the infrastructure already knows. So you're doing a bit of redundant activity. And part of that is because of zone awareness, for example. So one of the things that you can do when you're working with Spring Cloud and Ribbon and stuff is you can be zone aware. Now the problem that I have with this is every application developer is putting that config in their app. Every application developer is defining their load balancing policy. That is way too detailed for what you usually need at an app level. There's no reason to put it there. In addition, retry policies are actually harder to get right than might appear on the surface. Who does the correct exponential back off? And do you actually know when to stop the exponential back off and just stop? Did you do it right? Are you still flogging the dead horse? Yes, a circuit breaker helps, but you can have serious echo problems with everybody trying to retry because there's no way to short circuit everybody doing their exponential back off retry. You still have a lot of noise. And so this is where Envoy comes in, the Envoy sidecar, which is now part of Istio. And the Envoy sidecar is language agnostic. It's out of process. To be fair, Netflix has Prana. Spring has a wrapper around Prana so you could do a JVM-based sidecar. JVMs are not cheap. They're pretty big. So to have a JVM as a sidecar is a bit inefficient. So part of what is good about Envoy is it is, I think it's C and C++, I don't think it's Go, but it's much more compact and small. But it still gives you content-aware, smart routing capabilities that do a lot more at the network level. So it's a lot more intelligent. And because it is aware, and if you think about the way Kubernetes knows how things work and knows where the cluster is, it can short circuit and cut out all retries when it knows somebody's down. Like you actually have the ability to really cut down on your retry traffic because you know way more down at that level than you do inside the app. There's also the interesting thing about Envoy is, and there's some other talks about that later, the motivation behind Envoy is you have lots of people in the company all producing applications. In the case of where Lyft was, they're not all in Java. There's multiple languages going on. And you have different skill levels of developers putting out these apps, which means there's different levels of awareness of whether or not they should add certain kinds of trace or whether or not they should be adding those retry capabilities in a smart way. Or people forget stuff. So part of why the Envoy sidecar came to be is it gives a common base set of capabilities regardless of whether or not the developer remembered to do it. So Envoy always collects distributed trace data for every outbound request. It's always there. If the developer remembers to add additional context to say, okay, this is a follows from kind of transaction or this request is going to follow from this other request so you get your nice nested span diagrams, great. But if they don't, who cares? We can still see something about what's going on in our system because we have that base capability. The other nice thing as a Java developer who really hates trust stores and key stores because nobody wants to deal with that, nobody. But Envoy as the proxy that sits in the case of Kubernetes, it sits right with the egress ingress from the pod in the case of Cloud Foundry, it will sit with the go router. There's a project actively working on that. It will manage secure TLS transport between services for you which means we do not have to do stupid trust stores in our code. We do not have to worry about key rotation in our code. We do not like, you just don't. You just don't. I am so excited when you do not have to do something. It is the best thing ever because if you don't write it, it doesn't break. So it's just goodness, right? You have a much more secure ecosystem and all you did was have a sidecar. It's good stuff. Now, this is where things are going to get really interesting over the next as Envoy grows up. And if you have an opinion about this, by the way, now is a great time to go get involved, right? Envoy and Istio are not baked yet. So if you have an opinion about how this should work, it's a great time to go and get involved because where I think things are interesting is in the intersection of circuit breakers, bulkheads, callbacks, fallbacks, and retries. So if I have hysterics in my app, I can divine certain behaviors like this. But we know some of it is better done at the transport layer because it's just more efficient. There is no way that the sidecar at the infrastructure level is going to know the appropriate fallback to execute if the request fails. Remember where fallbacks came from from the point of view of Netflix? They had some catastrophic outages a long time ago. And they realized, firstly, that their user service was down and they couldn't give you any movies. Well, OK, that was bad. So they figured out how in their cookie processing, for example, they have enough in there that they can remember who you are, even if their user service is down. So that's not in their app. That's like cookie stuff. The next thing they did, and this is stuff they did with hysterics fallbacks in their code is they said, OK, I'm going to try to get the movies for this person. OK, that didn't work. I'm going to try to get movies for people like this person. Oh, that didn't work either. OK, I'm going to get movies for people in the area of this person. OK, that didn't work. Here's the movies. But that is application-specific fallback behavior that they defined so that they can satisfy their requirement, which is you will get movies at the end. You can't put that kind of logic at the network infrastructure layer without heading right down the silvery slope back to ESBs, which we know we don't see. There's a reason I mentioned that. We don't want to go there. We know it hurts. So how that dynamic is going to play out is very interesting to me. Another one is circuit breakers and bulkheads as we see those. Who is in charge of maintaining the sliding window? Circuit breakers are easier. You want to see that traffic shut off. Bulkheads, for me, Java loves threads. We love to manage our thread pools. We love to be able to say, this guy's going to be expensive. I only want this to go. But I don't actually care if the data, like, I can skip a couple. So I'm going to use a semaphore here because I either get the lock and it sends, or I don't. I don't. Life is good. Or I'm going to have a constrained thread pool. And I'm going to queue because we can patch. Envoy cannot do that. So for me, how this relationship involves so that we can get the application behavior we want and yet interact and make best use of Envoy, that relationship I think is going to be fascinating. So if you have opinions, go get involved with the community so that you can get what you want. If you don't say what you want, it's your fault if you don't get it, as far as I'm concerned. Do you have to use Spring? Everybody here, I noticed, just about everybody here uses Spring. Micro-profile is a new standard coming out based on a minimum set, I would say, of existing Java EE specifications, specifically the lightweight ones like Jaxrs, CDI. It's a very small subset. It has all the capabilities that you would expect from Spring Cloud plus Netflix. But it is tiny because it does not drag in an entire stack or the Maven dependency download the universe problem. So as an alternative to Spring, or for people who have a lot of code in traditional Java EE environments, this is definitely something to check out. It has fault tolerance behavior. It supports CDI. It supports, it has a metrics API. It supports open tracing, like all the capabilities are there and they're adding all the time that, again, is a community that you could get involved with also. And then we have serverless. The fun thing about serverless is, do we need any of it? The example from Amazon for Lambda, that's the stack. Like, yeah, there's a lot of stuff we might expect that's just not there at all. And that's going to be kind of fascinating. When you're trying to minimize the size of your JVM or to get it starting fast in that kind of environment, do we need any of the stuff that we think of? Like, no, maybe not. So I think that's going to really change how we do stuff. Rest. We know rest. We love rest. We document rest. We bring it up in swagger APIs. We push buttons to do it. And now we have GRPC, which is binary. Which, by the way, I find hilarious as someone who has been around long enough to work with Corba. Like, we're back to fixed payload. And like, first, it's great. But there's some interesting work going on. I have one blog post here. Envoys doing it. CorOS is doing it. And they've established some end-to-end practices so that they can have GRPC for HTTP2 with the protobuf definitions, that nice thing. And then they can grow up to rest HTTP11 with all the swagger stuff that you know. They're keeping those as a continuum of things that they support, which kind of bridges the two universes in, I think, a rather nice way. So that's when do I finish? Yeah, that's what I thought. Good. All right. I will probably blow through this because, again, I brush. Oh, yeah. And I had somebody recently say they hate GRPC because it's back to binary. And I'm like, yeah, go talk to the guys I used to work with that did a web sphere on ZOS. We know everything about dumping binary payloads. Complete with eye catchers, because for Z, it's also an ebsidic. Reactive is coming. And reactive changes everything. I did not try to go through marble diagrams here. I've had people tell me that the marble diagrams make their head explode. I will tell you, in all seriousness, if you figure out observables and how to do your subscribes and then how to do map and switch map and now everything like I have a hammer, everything. Everything is a nail because you can do synchronous stuff with observables too. And it's quite addictive once you figure that out. But I find this interesting because when microservices and Cloud Native became a thing, there's this, oh, but everything, if it's going to be really, truly decoupled, everything should be an event. We should be going back to messaging. But of course, we all went to rest because that's easier to understand. So how this emerges so that we can understand these systems and reason about them and debug them and let them grow is a big deal. Has anybody ever seen a good way to describe version, test out, be aware of the contents of events? It is the biggest super secret handshake. Everybody is so decoupled with events except the contents are a super secret handshake. I have yet to find a good answer for documenting the contents of these events. Fascinating stuff. Oh, it's the end. See, I told you I would rush. But we can do questions. That's fun. So just for this track, so to get back to the intro track that I didn't really do very well. We do have lunch, by the way. There is a lunch break. Right after the lunch break, Ozzy, he's the other half of my brain, which is scary. But he's going to talk about Istio and Spring and MicroProfile. So if you want to know more, a little more in detail about what I talked about with Istio, you can come to Ozzy's talk. Rick Sarotar is here, and he's going to talk about building responsive systems with serverless and event-driven Java, which is a whole nother pile right out of what I talked about. And that should be a really good session if you're curious about what's going on with that. And then just after them, Ben Hale and Paul Harris are going to talk about reactive APIs, which is also just out of what I talked about. Tomorrow, we also have from Surya at IBM, my colleague. We have a talk about how Cloud Foundry compares with Kubernetes for deployment of cloud native applications. So that is my rundown of all the crazy stuff that's happening in the Java ecosystem. I do hope now you have questions. Wait, wait, no, I'm going to put her on the spot. I don't wear the microphone. I forget where they're like, oh, it's here. Since we have time, can I put you on the spot? Let me know. I want Heather to talk briefly about Kotlin. Because she told me she knows it, so stand up. Yeah, I didn't know it well enough to talk about it. Has anybody played with Kotlin? A couple, yeah. What are your feelings? Exactly, that's what I found. You have to repeat it. So much more. So the comment was that it's very succinct and readable, which has exactly been my experience. So because obviously I had nothing prepared because I just got grabbed and pulled up here. But I would recommend checking it out and checking out some of the language idioms. And once you get used to writing out things some of the ways it does, I think one of my favorite is the when clause instead of an if-else. Once you start writing those, and then you have to go back to something written in Java, it becomes painful, which is my best test for when a new language is worth learning. Cool. Thank you. Does anybody else have a question or a comment? I invite comments, because this was a very opinionated. I love opinions, you can tell. I don't know if this is something you can answer. It's just a general question. Does anyone know where Netflix went? Because all the spring cloud stuff is core to everything that I know that we do. And Netflix just stepped back from the conferences and general support. So what I know from my reading is they did go quiet. Ribbon is in maintenance mode. A lot of I think Eureka is mostly in maintenance mode, aside from the contributions that spring is still making to it. I think they went, I actually should probably not put that down. They went very much into the GRPC space. So they're looking at this point into how you're optimizing binary transports, to really streamline how you're communicating between services. I also think, I believe the last time I looked there and on mesos. So again, you're starting to get into these platforms where the service discovery is happening in the infrastructure, which means you don't need the extra services like Eureka especially because you're relying on that infrastructure, which already knows the information. Does that answer your question? No, I mean, it is a good question. They went really, really quiet. If you look at some of what they're talking about, where they're still investing where I can see is on some of their operational visualization side, because that's something you need either way. Even if you're looking or using a mesos or a Kubernetes, you need to be able to visualize what's going on in your system. And so you still see a lot of contributions in that area specifically. I think I have one more minute. So Istio versus Spring Cloud Gateway. And by Spring Cloud Gateway, you mean Spring Cloud Gateway on Zool. So I think that, from what I know, not being a pivot in fairness, is an interesting space to watch. There's a few places that have gateways. And then it's whether or not the gateway is going to know everything that Envoy or Istio is going to know. And I think part of the question, when you look at how Envoy and Istio are going to fit into an organization that's managing things, is where that data, where the configuration and how the traffic flow or traffic shaping is going to happen and who is going to have that information and who is going to be in control of doing that. When you start looking at how Kubernetes plus Helm charts plus roll-based access controls and how that is shaping, you start to understand where Envoy is sitting with each pot. So it's like distributed behavior, distributed execution of centrally managed information, which is amazingly powerful. When you start looking at Spring Cloud Gateway or other things, you still don't necessarily know who's in charge of configuring any one of those pieces. And I think that's where some of the tension is going to come from. I think, interestingly, as Envoy stabilizes, because Envoy itself is stable, but Istio is very much under development, it will be interesting to see if they adapt to use more capabilities from that, which is possible. Istio itself, Envoy, I think, can work already. I think it can satisfy Eureka APIs. It already has capabilities to fit into existing spaces. And so I would imagine that if you really like Spring Cloud Gateway, there's going to be ways to piece those together. I do know that from the Go Router, like there's active work to get Envoy and the Go Router working better together. And again, once you start getting that, do you still need that Gateway? At what point does it become redundant? We don't know. It's one of those things we actually don't know. You guys get a break, I think, briefly, right? 10 minutes. 10 minutes. I hope that was helpful. Yay, come back.