PurePerformance - 060 Reactive Spring, Microservices, Serverless and Micrometer with Josh Long

Episode Date: April 23, 2018

Josh Long ( https://twitter.com/starbuxman ), Developer Advocate at Pivotal, Java Champion and author of 5 books, gives us a great tour through the latest that is happening in the Spring Universe. If you are new to Spring check out http://start.spring.io/ and create your first project within minutes. When it comes to Reactive make sure to check out https://projectreactor.io/ and dive into https://micrometer.io/ to learn more about how to extract metrics from Spring applications. As Josh is constantly traveling the world chances are high you can meet him at a local conference.

It's time for Pure Performance. Get your stopwatches ready. It's time of Pure Performance. Andy, did you know that this is episode number 60? Did I know what? That this is episode number 60. 60? Look at that. Yes.

And we got a cool guest on today. And before you go ahead and introduce him, I did want to mention I saw something on our guest's Twitter feed the other day. And it's something I've been thinking about myself. So I'm a fan of Kevin Smith. I don't know if you know him. He's a film director and also… Loves comic books. Loves comic books.

Yep, just like me. And hey, that's our guest. No talking guest. Quiet back there. Don't make me pull the car over. He, um... I went to go see him live recently here in Denver,

and he was talking about the Marvel movies because he's a big comic book fan. And what I... You know, I've seen a few of the Marvel movies. As I got back into comics as an adult, I went more into, like, the image comics, more like the non superhero ones.

But I used to read all those when I was little. Anyway, long story short is he called out the point that these were all leading up to the newer movie, The Infinity Wars, that there's tie ins and lead ins all to the getting to the point of the Infinity Wars, whether it's loose or very strong. And I had no idea that this was like a full on universe all being brought together. So in my back of my head, I was thinking, boy, maybe I should go back and like try to watch them from the beginning or whatever the right order is. And just coincidentally, as you know, I was prepping for the episode today. I saw that our guest today was doing just that. And our own Mike Villager.

Oh, no, no no it wasn't mike villager was it it was uh um no who's from pivotal um our buddy uh oh come on no no the guy from pivotal the guy who spoke at perform two years ago um josh mckinty yes josh mckinty actually of all people was responding to our guest today saying what order do i watch them in so perfect i followed the thread and i now have a a setup there so then andy with all that in mind who is this mystery guest do you want to go ahead and introduce him or you know sure i'm not sure if he needs any more introduction but uh well that's only the comic book nerdy side of the introduction there's a lot more cool stuff that okay so so our guest is not only well known, you know, I think in the spring developer space, because he's a spring developer

advocate. He's also known in the DevOne space. So what is DevOne? DevOne is our conference that's coming up end of April, depending on when this airs. It might be very close to the time. But our guest of honor today is Josh Long. And I think there's a lot of stuff that we can hopefully learn from him today. I'm not only hopefully, I'm pretty sure about this. So Josh, without further ado, I guess we heard you earlier

when you made comments on what Brian said, but I hope you're still with us. Are you there? I'm here. All right, perfect. So Josh, thanks for getting on the show and then we reached out to you because mike villager one of our colleagues actually met you in stormy boston two weeks ago when you were kind of caught up in a blizzard here and then he said hey it would be cool if

josh could get on a podcast with us chatting about what's happening out there in the pivotal space and the spring space and in preparation for this talk talk we actually came up with a lot of other cool things that we want to talk about but i think you want to get started with maybe you can give our audience a quick explainer who you actually are in case people don't know you yet and then we want to jump right into the first topic which you know give us a little background on Reactive. Then let's talk a little bit about microservices and then about something else that just came up, which is the Micrometer project. Okay. Well, where do I start?

My name is Josh Long. Lovely to meet you all. Good morning to everybody. Good afternoon to everybody. I am a Spring Developer Advocate on the Spring team. I'm an open-source engineer and contributor to a number of different projects. I've been working on the Spring ecosystem as

a contributor and general loudmouth and nuisance for 10 plus odd years. And I've had the privilege of, in that time, becoming a Java champion and just being out there in the community. And so, super excited to be speaking at your conference coming up.

That's for sure. Yeah. And you're actually going to present with, let's say, another very well-known figure in the industry when it comes to Java, when it comes to Spring, Jürgen Höller. The most well-known figure in the Spring ecosystem. Jürgen is yeah like

I get goosebumps as we as we talk about him he's he's one of those few people I've ever met you know

there's a there's a few of us now and but he's always been that way as long as I've known him he's always been this way where

he can go to a software conference and just walk around people know who he is which is you know like that's that's almost famous you know that's almost like legit internet famous that guy's amazing He can go to a software conference and just walk around with people who know who he is. That's almost famous. That's almost like legit internet famous. That guy is amazing. Yeah, and it's actually, for me, it's nice.

He's from my hometown, too, from Linz, Austria. That's where DEF 1 is taking place. It's great that you guys are both on stage. So what's the topic you're going to talk about at the conference? Reactive Spring, the thrust of the last release of Spring Framework, which of course he's the lead up, right? So he's the number two engineer

on the Spring projects ever, right? And second co-founder and still to this day, the very active lead of the Spring framework projects uh for which he's won countless awards and recognitions and uh you know including last year did you see jack's uh jack's gave him a um they give him some sort of honorary recognition of the fact that he's been such an amazing engineer and contributor to this project and and it's never had to be rewritten.

The code is of such high quality that the design has never been gutted and then redone. So that framework is now in its fifth incarnation, and the major thrust of that is reactive programming, how to provide a computational metaphor that maps more naturally to the asynchronous sort of IO that we need to if we're going to scale and embrace microservices, move to this world where we start saturating our network buffers, that we need to embrace to be more efficient. Hey, Andy, I was just thinking one thing, Andy. We're going to be talking a lot about Spring and a lot of these other concepts in here today, but should we take a step back and have Josh give us a, you know, cause there's a lot of people obviously using spring, but a lot of people are not right. Josh, can you give us just like a really, really quick, you know, what is spring and why is it, what's the advantage of spring over X? Just so people have that frame of reference of how this all applies.

Well, all right. So spring, when it was first conceived, it's a framework that solves a very simple problem, which is dependency injection. Dependency injection means I have some layer in my code that knows how objects are related to each other. It controls references to those objects and it controls the wiring of those objects. You tell it how you want your objects to be wired and it'll wire the code together for you when the application starts up. The result is that your code is written, and it's written sort of ignorant of how objects that it has have come to be, right? You don't have any

resource locators. You don't have any calls to JNDI. You don't have any factory methods that you have to call. You just have pointers to data sources and, you know, to other collaborating objects. Now, this may seem very simple, and let's be clear, it is, but it was a big deal in 2001 when we first started talking about it. And the result is you have this code that is now, it lends itself to testing. It's code that's been written in terms of just interfaces and objects and clean object-oriented programming. So Spring basically promotes this very clean sort of object-oriented approach to writing software. And the result has been this proliferation of things that we can do

for those objects that build upon Spring. So nobody uses Spring for dependency injection. I mean, they use it because now I can write a regular simple object, annotate it, and get a REST API. Now I can use Spring and annotate it and get a rest api now i can use spring and annotate it and get declarative transactions now i can write spring and annotate it and get a uh you know circuit breakers and i can get uh instrumentation for for tracing and i can you know all these sort of cool things that you want to layer on into your objects without having to write all this twisted code in terms of the underlying infrastructure code that i can still test and write and run independent of a particular application server now that we have we have projects that support things like integration eai batch processing

security uh data access no sql data access uh uh you know all sorts of different ecosystems and we have a whole set of projects around microservices now Now, all of this is kind of confusing at first. So, you know, we appreciate that it can become overwhelming for somebody coming to the Spring ecosystem to sort of assemble all these pieces into a final product. So we have a new project that we released in 2014 called Spring Boot. And Spring Boot is a – it takes an opinionated sort of convention over configuration-centric approach to composing parts of Spring and the larger Java ecosystem to get to something that you can, with a minimal effort, deploy into production and still have to do what you want to do. So it is the configuration that you would have done with Spring and with other third-party libraries but it's done for you

automatically uh so it's just all this stuff that's out there now that we've had over the last almost two decades uh it's now you know automatically and sensibly set up for you by default the result is that uh you know you write very little lines of code and you get a result so spring boot is i think the um the thing with which maybe your your listeners might be familiar it's it's certainly become very popular 20 million plus unique downloads a month on on maven and things like this it's a more than a brand more than a million it's well more than a million but i forget the number now so let's just say at least more than a million uh every month of new projects generated at start.spring.io and um you know there's now a framework on top of that there's a frame called spring cloud which serves

the goals of building microservices so uh there's a lot of pieces there but what you need to know is that spring uh it it it's hard to compare that to other things because as i just explained explained it it it doesn't there's not just one other X. Right, right. There's a lot of verticals strewn together in terms of this dependency injection mechanism at the very core of the framework. I think that gives us a good foundation to work

with then. Okay. Excellent. So Andy, sorry to sidetrack it there for a minute, but we should get that in there. No, no, that is perfect. Actually, I lost my train of thought, but I think that was perfect. track it there for a minute uh but uh so if it felt we we should get that in there oh no that's that that is perfect actually i lost my train of thought uh but i think that was perfect uh to to give everybody kind of like a baseline of what spring is all about now spring framework five uh reactive spring can you give us the highlights there uh so the people are that are not yet aware

of uh what what it entails and what it includes right Right. Well, so, okay, we've got this. We enjoy a wonderful situation where now people are moving to microservices. And the whole thrust behind microservices, as far as we at Pivotal are concerned, is this need for organizational agility, right? You decompose your code in terms of small teams and small teams working on small code bases, small code bases focused on a very small bounded context to borrow from Eric Evans' domain-driven design. And the result is that you have lots of small teams able to release independent of each other at a fast or as fast a cadence as possible. And you get

velocity, you get velocity you get human agility right that's a very important reason to move to this it's why amazon moved to microservices it's why netflix moved to microservices it's why really anybody should move to microservices but the the natural consequence of this of course is that you've now got lots of small services talking to each other communicating with each other over the network and you run into some limitations that you might not have appreciated otherwise, one of which is that you're now saturating your I.O. Your I.O., your input and output, starts to become a bottleneck.

You start saturating both what your software can handle and what your network cards can handle. And it's this, you know, we can't do anything about physics. Obviously, we can only, you know, there's only so many bytes we can send at the speed of light, you know, per second. But before that, we have to deal with the inefficiencies in the way that traditional Java applications have done or scaled out to address input and output. So when you think about a traditional web application, for example, a traditional server-based application, a request comes in. There's a server socket listening for the incoming request. Server socket accepts the request.

It spins up a new thread to then produce the reply. So in this case, the web server, Tomcat or Jetty or whatever, have a thread that will then call into our code, our serverless API, and then Spring MVC and so on. It'll drop down. It'll call our code, and it'll produce a response. And so long as that response only takes a few milliseconds to produce, then no big deal. I can produce replies faster than the rate of incoming requests. But if I have a bounded thread pool, which I very likely will, since I don't have unlimited memory or unlimited threading on my computer these days, and threads are very expensive on the JVM, if I have a bounded thread pool, then there's the risk

that I have more requests coming in than I have threads to be able to respond. And that is a problem, right? You end up blocking requests, you end up rejecting requests. And this doesn't need to be the case. That's the fundamental takeaway here, is that while we are used to this approach, while we're used to having to spin up a thread to be able to address IO, this is not something that is fundamentally a limitation in the operating system or the lower levels of the stack, right? We have asynchronous I-O. We have the ability to say, here's I-O. I'm going to give the operating system a pointer to these file descriptors. I'll ask the operating system to manage the processing of that I-O. And if anything should

happen there, I want it to call me back. So, you know, this asynchronous IO has been in Java since 1.4, right? So that itself is 10, 15 years old, right? It's been around forever today. And yet we have lacked historically, up until about 10 years ago, 8 years ago, 9 years ago, we've lacked historically a good way to describe in our code that we have this data that we're going to produce that isn't here right now, but it might be here in the future, maybe a millisecond, nanosecond, or an hour, right? And we've also lacked this mechanism to support flow control. Our service may deluge a client we don't want we don't want to drop you know terabytes of data on a client that isn't expecting it so the client needs some way

to signal to the producer hold on a minute i can't handle any more data i'm going to stop you right there let me process this and then i'll ask you for another x records right or another x bytes or another x whatever and so both those two things things are missing in the way we traditionally think about IO or programming in general. We don't forget about IO. At this point, we're talking about the computational metaphors at higher levels of the framework, the way we do data access per system, the way we do web services, the way we do security.

All this stuff has to support this asynchronous, potentially unbounded world. And that need led to a number of companies, first of which was, I believe, Microsoft. They had Microsoft extensions for.NET, the Microsoft Research Extensions for.NET. And those extensions led to the – I'm sorry, the Microsoft Reactive Extensions for.NET. And that led to RxJava and a number of other technologies in the Java ecosystem. And we have a project

called Reactor. And Reactor is our approach, our framework that addresses these sort of reactive concerns. It's a programming model that supports asynchronous callback based, or rather it feels like callback, but it's not. I guess it's like the best of promises and the best of callbacks,

in that you get the same benefit, but you don't have to write all that callback code. But anyway, we support this programming model, but that in of itself, however interesting, isn't useful if the rest of the stack doesn't support that. So Spring Framework 5, released September last year, integrates Reactor, and then Spring Data K

in turn supports Spring Framework, and we have reactive data access options for NoSQL stores like Cassandra and Couchbase and Redis and MongoDB. And then we have Spring Security 5, which supports authentication and authorization in a reactive world. And Spring Framework itself has a new reactive web runtime called Spring Web Flux. And then going beyond that, Spring Boot 2.0, which just shipped a few weeks ago, pulls all that in and makes it easy for developers to consume, to build APIs, to build applications, you know, end-to-end from the web server all the way down to the database layer and back again without ever blocking, without ever having this traditional, you know, synchronous blocking code that frustrates our efforts to scale out to be more efficient with the same hardware. Hey, Josh.

Josh, can I – yeah, I have a – wow, that's awesome. I have a couple of questions that immediately pop up in my head. I mean you are a developer advocate. How tough is it to educate developers and actually change their mindset? Because I remember my first Lambda function that I wrote not too long ago. And I was struggling with the new concepts of having to think about asynchronous connectivity, about thinking about more like a state machine where I am able to, you know, to say, you know, I'm ready for processing this right now. And then I need to wait for something. And instead of writing my classical, you know, end-to-end code, my synchronous code, I had to completely change my thinking.

And in the beginning, what I did, I actually implemented my Lambda functions in a very old traditional way. I actually waited for the results and I didn't do it event-driven, which obviously is completely stupid, but I just didn't know better. So my question is, how do you – I mean, you provide the technology, but how can we make developers aware of this and also the change in paradigm?

Okay. So first of all, as to how do I talk to developers, I show them code. I stumbled by accident on the secret to helping developers with software, which is just to show them the software. Instead of showing them slides about the software, I just show them the software. So most of my performances on stage these days are just code end-to-end. I have no slides at all. You know, I was watching that and thinking that's a different way of presenting. I'm not the only one by any stretch.

I think the gold standard for live coding, joking talks is a guy named Dr. Venkat Subramaniam. And if anybody's out there wants to learn and grow as a human and as a technologist, go find one of his talks. He's extraordinary. So that's how I try and help people learn. And one thing that I would teach them if I had an audience and I'm trying to help them with reactive programming is that we have this type called a publisher. And this comes from this reactive stream specification.

And when you work with a publisher, you can create a subscriber, and a subscriber is kind of like a callback. But there are operators. Actually, there's specializations of publisher that are in our reactor project. And if you're using these specialized types that themselves extend from publisher, this interface publisher, you don't really notice that you're doing callbacks. So it feels very much like manipulating a collection that can compose well with other collections. So you can say, here's a Publisher that is going to emit records of type T, where T could be a customer or a byte buffer or a string or date or whatever, right?

And I can filter over it. I can say, you know, filter over these and keep only the records that match this predicate, for example. And I can then, you know, it's like using the Java 8 Streams API kind of, right? So you have this publisher. So you don't really deal with a lot of callbacks. That's the thing so i think really the the important thing for people to to uh keep in mind when they move to this paradigm is um is what's happening behind the scenes what's happening under under the hood in terms of the io why why are we doing this and if you understand that then the rest kind

of flows i think pretty naturally right yeah the and especially once you see that it's not all that difficult to write predictable deterministic code that looks like it's imperative but is in truth actually very asynchronous and being scheduled, it's being managed by a scheduler behind the scenes. That last bit is very interesting. Once people see the power

that I can write this code that looks like it's line one, line two, line three, line four, and it's a fluid API and you just compose line one, line two, line three, they're all connected together through this API. But to look at the code, you think line one will most assuredly finish before line two, but that's not necessarily true. And if you use the API, you can write code that is asynchronous and does all sorts of concurrent asynchronous things. And you don't have to manage that, right? There's no semaphores and countdown latches and all that stuff. So I think it's really, not only is it cognitively less painful than I think, than achieving the same

thing manually with explicit threading code, but it's vastly more productive, right? It's cleaner too. Cool. Thanks for that. The other question that I had, so you mentioned, obviously, all the support that you built into the framework allows us to build smaller pieces of, call them microservices or whatever you want to call it, but we focus on individual smaller teams,

focus on delivering faster value by extending their functionality and we all adhere to the same contract. So I think this is great, obviously, right? That's what we've been promoting for a while. But how do you deal, and now this may come organizationally, how do you deal then with end-to-end features

that spawn multiple services and multiple teams. So let me think about, we have a feature that requires changes in the front end, in five middle tier services, and also somewhere in the backend database. Every service on its own is obviously contributing a part of the functionality, and every team can easily deliver their changes in their own cadence as it fits into their let's say sprint planning what do you teach when you advocate to developers and i'm sure to organizations what do you advocate on how to then make sure that full end-to-end features that spawn multiple teams and multiple now smaller services and many, many kind of dependencies.

How do you control and how do you manage this so that the end-to-end feature is also delivered in a faster way and in the right quality? Is there any best practices around that? Because I've been seeing a lot of companies struggling with that fact. We are breaking everything apart into smaller pieces, but now we have a dependency mess, and not only on a technical layer, but more so in organizationally. So I can't really speak to the organizational aspect there. We recommend agile programming and using sagas and these kinds of practices. That's, I think, fairly standard.

But technologically, what I think most people struggle with is testing, right? This wouldn't be so burdensome if I knew I could just write some unit tests and know that things are working. But if I have to deploy, you know, my Cloud Foundry or Kubernetes cluster just to be able to run my little front end, my little iPhone app, you know, then that's not going to be a very productive experience. Nobody's going to appreciate that feeling, right?

So it's the fast feedback loop that people struggle with. If they have the same feedback loop that they had when they're writing a monolith, then they would feel empowered. They'd feel like I can write this code and make sure that it's working with all the different constituent components that comprise the end user experience. That would be sort of the benefit that they'd want. Now, the feedback loop in a monolith is really quick, obviously, and it's easy to understand where something is going wrong as well. If there's a performance break or a performance regression in the monolith, and you ask the question, where is the performance regression?

Well, it's in the monolith. If there's a no-pointer exception in the monolith, where is the no-pointer? It's in the monolith. It becomes easy to pinpoint where the problem lays. And then when it comes to testing, you having fast feedback without sacrificing the assurance that the components with which we're integrating are actually the components that are going to be deployed in the runtime system. So we want the benefits of an end-to-end exhaustive integration test without having to deploy the whole system. And so for this, we talked to organizations about consumer-driven contracts and consumer-driven contract testing. And we have a technology called Spring Cloud Contract, which gives you that.

It is not schema. It is sort of like PACT. PACT is another framework, another technology in the space that supports the same use cases. And we can, in fact, even work with PACT definitions there. So that's one way to get the feedback loop, to regain the fast feedback loop without actually having to deploy an end-to-end service test, right? So we can keep the testing pyramid the way it's supposed to be with 80% of it being fast feedback loop sort of unit tests and so on. And then the top 20 or 10% maybe being exhaustive end-to-end tests.

That's the testing part, I think, is what people miss about that, right? And then once you've done that, you also need to now expand your definition of, you know, it's hard to debug. You can't put a breakpoint in a distributed system and just follow the stack, the graph from one node to another. So obviously, as you know, tools like Dynatrace are invaluable here. And having a focus, having an absolute zealotrous focus on observability in every layer of the system to get that whole picture. Distributed tracing, we support distributed tracing using Sleuth and our abstraction called Sleuth and Zipkin, for example. And we support metrics accumulation through micrometer.

And all these things have outlets and tools like Dynatrace, right? So that, I I think is valuable. That is more valuable now than it's ever been, you know, at least as far as I'm concerned, to have that whole picture. Cool. So you just mentioned, well, thanks for that. That helps a lot. And I assume when you talked about your contracts and being able to test individual components

without having the full system in place. We then technically talk about mocking away implementations of dependent services, right? I mean, that's technically what happens. Yeah. Yeah. Cool. So the collaborating object, but the collaborating object isn't a type.

It's not a compiled type. It's not an interface in my local class path. It's another REST API. So we have to mock out the REST API, and that's what contracts give you. Yeah, that's cool. Now you just kind of, maybe it was an intended segue over to the next big topic that I wanted to talk about.

You talked about the monitorability, the traceability, the observability. You mentioned a project that we discussed earlier, Micrometer, which is something that you guys are working on. Can you fill us in a little bit about that and kind of also why this came into place? What type of problem you're trying to solve with that? Why it was important to build this system? Yeah, sure. So micrometer is a metrics facade. To borrow the verbiage from the website, think SLFRJ, which is a log abstraction, this logging framework facade, but for metrics. So metrics, accumulation, collection, ingestion, et cetera. And when we talk about metrics,

we're talking about keys and values, but over a continuum, over time. So it's like, imagine if Redis, which stores keys and values, imagine if Redis could also show you every version of that value for the last year that it's ever been. So these time series databases and monitoring tools often have support for capturing metrics. And these metrics you can then dump into a graphing tool like Grafana, for example, or as often as not, these metrics tools will have their own visualization. And these metrics, once you have them in a single place, you can query them, you can look at trends, you can see patterns,

you can use that information to do alerting, right? And so Micrometer supports a number of different registries behind the scenes, one of which I see this morning is also Dynatrace. Dynatrace, there's work being done to support that as well. So this framework publishes metrics out of band behind the scenes as the framework code in your microservice is collecting it, right? So you can register, you know, the framework will emit obvious metrics, things like, you know, HTTP requests and all that kind of stuff, stuff that's perhaps a bit redundant with the support that the agent in Dynatrace already gives you. But you can also register custom metrics, business metrics, things like, you know, how many orders have been added to the shopping cart or how many people have checked out

or, you know, from the shopping cart or how many people have checked out from the shopping cart or how many people have signed in or whatever key performance indicators you want to surface. So these metrics, there's three different types when you talk about them in my commenter. There's a gauge, which is a bounded number. It's the fluctuations between two bounds of a number. Say, for example, the speed of a car, you're not going to ever exceed the upper bound of whatever your car is electronically limited to. A counter is a metric that increases or decreases, plus one, minus one, et cetera,

but that you have to calculate over time. You tabulate it over time as opposed to updating a number, right? So you say, add one to the existing metric, right? That's a counter. And then finally, we have a timer. And timers are, you know, I think where metrics tools like Micrometer really, really shine is they give you the ability to have a histogram

on latency, basically, you know, on request duration. And that histogram, you know, it's why we're here, right? It's what we need is to be able to understand what's happening there and where it got locked up. So micrometer, you can use it independent of Spring, but it also underpins our metric support in Spring Boot 2.0. So it's a very interesting project.

So that means, if I understand this correctly, and you mentioned this, it seems somebody's already working on a micrometer registry for Dynatrace, but there's also all sorts of other registries already available. If you go on GitHub micrometer-metrics, I believe that's the project.

And we can also pull it out. We will add the link to the – Micrometer.io. Micrometer.io. Thank you so much. IO is the new hip ending there. Exactly. Spring.io.

Start.spring.io. Harness.io. Evo.io. Everyone. We'veio. Start.spring.io. Harness.io. Everyone.io. Everyone. We've got to get an IO, Andy. Hey, Andy, let me put you on the spot, Andy. I'm going to ask you a question. So I'm listening to the micrometer conversation and trying to really wrap my head around its uses and how it's being leveraged from, and you know I don't like to go into Dynatrace too much,

but from a kind of comparison, or like what would, if someone had Dynatrace, or let's say any APM tool, right, we'll put it that way, but obviously we know the most about Dynatrace, what would you see the use case of integrating that data into Micrometer? I mean, one thing I can see is doing customized data, displays, multidimensional analysis that might be outside of scope from what we do.

Is it something else that I'm missing from it, or where does it take you? Well, I think where it takes you is if we pull that data into into dynatrace then with our anomaly detection we we automatically detect that a certain application is experiencing a high failure rate or response time problems or availability issues now right now we detect the root cause of it by looking at all the metrics we have and all the entities that we know are depending on that particular application or that application is depending on. Now, with pulling in additional metrics from Spring through Micrometer, our AI actually has additional data points. And it can say, hey, you know what, we see a response time degradation on this particular REST endpoint to the end user.

And the most likely explanation is this particular metric we get from micrometer because at the same time, we also saw an anomaly there. That's a new extension to the AI engine that we have. We do no longer only look at our own metrics, but also baseline and look at anomalies at all the metrics that we're feeding into Dynatrace. And I think that's why having the more data we have into Dynatrace. And I think that's why having, the more data we have in Dynatrace, the better it is. And it's great that there are metrics coming out of Micrometer, even though some

metrics might be duplicates, because we already capture a lot of this information, but certain things, for instance, DBLLopper is put in, right? I mean, that's But also, correlative information in that single pane of glass, that's But also Correlative information in that single pane of glass that's gold But Josh, from a micrometer point of view

there's also, so Andy's kind of describing the use case of a tool like us pulling data from micrometer that we might not have natively or bringing in additional external information for us to analyze but from what I'm also gathering is micrometer can be used to pull data from multiple sources itself as a central data store.

Is that also a use case? No, Micrometer isn't a – it's a framework. It acts as a go-between between your app and downstream registries. You can publish to multiple registries should you feel so inclined. Maybe you have different subsets of data go to different systems but uh and by the way that was the piece that was missing for me yes you mentioned yeah it doesn't compete it's not a registry in of itself it's just an api yeah so we need dynatracks for example well no but you also mentioned grafana and i've seen some really nice things where at least with our older product atmon

where there are certain you know since you're pulling in all this data, multiple sets of data points all independently, once you have them in a tool like Grafana, you could then say, sky's the limit, what can I imagine plotting or associating with each other? So yeah, so it takes other places. But that I think is part of the power of a lot of the new tools, whether or not it's an enterprise tool like us or if it's like the open tools like Spring and Micrometers. All this open endpoints in the API and the data sharing, I think, is quite a wonderful trend. It's not like APIs haven't been there in the past. I mean, going back to my old Lode Runner days, you know, there were some API endpoints into the analysis tool to pull or push data or to pull data, but it wasn't really widely used. It wasn't part of like the nature of,

of the modern world. And I think like that's, it's just coming over and over and over again, seeing almost every tool is having this open API where you want to put data in or get data out. Sure. Take it. You know. I think it's really wonderful. The more the merrier. Now that we can afford to, we should and do. The one thing I wanted to mention was you mentioned, you touched on the word dimensional data, which I think is, that's the, if you're asking why micrometer instead of, say,

drop-positive metrics, which is itself an amazing, really good API, they're slightly different purposes in that it's fundamental to the nature of the data that they collect that they have to be different. Micrometer is focused on what we call multidimensional data. So you can have a metric, but you can have tags or labels, if you will, with values associated with that metric. So think about a hierarchical metric system like DropWizard. In order for you to capture other data, maybe you have a counter, an HTTP request counter, and then you decide you want to also break it down

by how many HTTP requests you have that are.git, that are HTTP verbs of type get or put or post or whatever. So you say requests.count.git, requests.count.whatever, and then you decide you want to break it down for a still by JSON. You say requests.count.git.json. And so now you've got this proliferation of metrics

when you're really just trying to capture, show me all the metrics, show me all the metrics, show me all the requests, and then store extra data for each of those requests to indicate sort of like booleans, if you will, like flags. of data instead of instead of encoding it in this hierarchical thing and resulting in this forest of new metrics just because you're trying to encode all this different information uh break it down in terms of these dimensions you know and that that difference makes it uh you know tools can use that that that distinguishing feature there to good effect in some cases yeah yeah we do this on our side with uh with tagging so we it tags. So we can basically tag data points. We can tag transactions that we trace. And then you can do this multidimensional analysis, as you said. You can say, hey, show me all the requests that were a get request that were putting a JSON on the request where the HTTP response code was between 300 and 400 and where the response time was between that and that range,

and where the requests came in from this particular geolocation. So you can do all of this, and it proved to be very useful for different use cases, right? From a diagnostic use case, from an analytics use case. There's a lot of interesting stuff here. I have another question. So it's great that we have all this technology and the frameworks and we have the monitoring in place. But obviously, when we have a lot of companies out there that have existing software, legacy applications, monolithic applications.

Now, do you see what do you see most? Do you see people are jumping on the latest spring and building new apps just from scratch? Or do you see them either integrating with the existing backend? Or do you see actually people looking at the monolith and starting to breaking individual pieces out and then implementing this with Spring? Well, all right. So big question. That could be a whole week's worth of discussions, right? We see from our perspective as an entrenched enterprise technology spring has been around and certainly ubiquitous in the enterprise.

And so we are lucky, we are fortunate to have an ecosystem, to have a community, a developer base that has lots of applications in production. They have many applications in production. And that means that they cannot, you know, would that they could, they cannot just throw that away and jump to this new greenfield thing. So we see a lot of customers, a lot of users, starting with the existing monolithic applications. And they're trying to get, you know, they're trying to, I think the most important thing these organizations can do is to sort of get themselves in the frame of mind that they have in their code the harness, the feedback harness that they will need to then start tearing at that code base and teasing it into small microservices.

So if you take this journey and you don't have testing in place, then it's not going to work, right? You need that feedback loop to validate that what you just did didn't break everything, right, as you start to extract things from the code base. And you also need visibility into how the system is performing. So again, it's easy for me to sit here and say, oh, well, you should just use Micrometer and Spring Boot and all this stuff. But that may not be an option. So if customers are running on our cloud platform, Pivotal Cloud Foundry or Pivotal Web Services, there they have access to the Dynatrace integration as well. So they can just point it to their existing JVM-based applications and get that visibility, at least to have that to kind of guide their movements, their progression.

Now, when it comes to Spring, Spring is, at the end of the day, still just Spring. Spring Boot is still Spring. So what worked in Spring is also technically a valid Spring Boot application. And in point of fact, the exercise when migrating to Spring Boot is mostly about deleting code. You just delete stuff that Spring Boot is now doing for you. You can leave it in most of the time, but it's nicer to delete it and let the framework do that.

So that's the first journey that people make. And then they have to tease these code bases into small microservices. And that's about, you know, that's about identifying bounded context. That work is an art as much as a science and people undertake

that slowly. So there are patterns like strangling the monolith, for example. The strangler pattern, right? That people embrace to slowly move their code bases without jettisoning all the legacy and valuable work. Yeah. I would love to if we ever get a chance.

I wrote a blog recently on fearless from monolith to serverless, which in the middle, obviously, there's microservices. And one of the things that we built into our product, because we also used our product within our own engineering teams, when we kind of reinvented ourselves and kind of did our code changes and architectural changes. So one of the features within there, we can actually define virtual boundaries or virtual contracts

in a monolithic application. So you can say, here's my monolith, but I think I would like to strangle out this particular component that sits behind that method or behind that interface or behind that class. So you can define that, and then we actually show you how is the monolith internally behaving? How are the individual components of the monolith calling to that now virtual service? How often do components within the monolith call in there? When does it break?

How much CPU is consumed? You can see if there is tight or loosely coupling between different components. And we saw this beneficial in our own journey. But also our customers now are using this to say, instead of investing a lot of time up front in basically doing a lot of code refactoring and trying to figure out where are the right breaking points and the seams. Let's first run a virtual simulation on top of it, meaning we draw the boundaries, we set it on the load, and then we look at the monitoring data. And with that, then we can make better decisions on is this a good extraction point or is this a good seam or a good interface to extract yes or no and i think i want to follow up with you on that blog so because i this could be interesting for

your for your work as well without organizations that's super useful that that be able to be able to the ability to predictably predictably sort of refactor without fear. Exactly. That's amazing. And you mentioned serverless, which is another exciting frontier for developers these days. We have Spring Cloud Function, which is a framework for supporting, in turn, built on Spring Boot.

It's a framework for building functions, and it's function-as-a-service provider platform agnostic. So you can run it on Lambda and Azure and Google Functions. And we even have a new function-as-a-service runtime called Riff, Project Riff. So that's projectriff.io, adding to our IOs. And that is a runtime that supports functions. It's language agnostic. It runs on any number of different languages, including Java, of course.

And it runs on top of Kubernetes. It's open source. You can download it and try the bits out. Kelsey Hightower seems to like it. He talks about it a lot as well. So we see a lot of developers moving to serverless. Not because I think they're not – I don't think a lot of people that we talk to at least, you know, in the same way that the organizations that we talked to weren't moving

to microservices, sorry, they weren't moving to cloud to be able to get rid of their data center. I mean, the data center was just, a lot of it is, sure, they're moving to public cloud where appropriate, but these organizations, they have, they're not hurting for money. They're not trying to save money on the costs of their data center. They're instead trying to get velocity, the ability to move quickly. And so that cloud computing paradigm gives them this sort of self-service thing. is enjoying a lot of success because, particularly because it supports this really, really small, granular deployment paradigm. This tiny little thing.

It's very easy to reason about what's going to happen if you just have one little function out there. Very easy to test. Yeah. And exactly. And compose.

It also fits perfectly into what you said earlier with the reactive programming, the event-driven programming. That's perfect because basically you break it down into the smallest piece possible and then you just chain together these functions through events, through your pub subscriber models, right? I mean, that's basically then, that's perfect. And you can focus on small entities that are self-contained, that you can test independently, and that you can scale up and down independently. That's the, I guess, the ultimate goal. So our project RIF, the design and architecture and development of that,

is being led by Mark Fisher. Mark Fisher worked on the Spring team, and his background is in a messaging technology called Spring Integration. It's an event-driven architecture-centric framework. And then he worked on Spring Cloud Dataflow, which is a way of composing lots of small little bits of functionality in terms of these message brokers, the chief of which, of course, is Kafka and RabbitMQ. So, you know, it's a small wonder. It's no wonder that somebody like that would be the person designing our function

as a service offering. So it is exactly that. It composes into lots of small messaging-centric sort of event-driven components and communication between the functions is done in terms of Kafka or some sort of messaging substrate. And yeah, our functions can accept publishers, reactive publishers, and they can produce reactive publishers.

So I can have a function that takes a trillion records in a stream and I can window over them and say accumulate every 10 records or accumulate every minute's worth of records or whatever and so on. Very cool. Hey, Brian, is there anything else we wanted to cover? I think we learned a lot about Spring, Spring Boot,

the history of Spring, React, anything else that we missed? Or should we summon the Summaryator? I think we should summon the Summer Raider. You have questions. Hold on, Arnold. Just hold the train. Will I get to see you both

in Austria in a few months? Not me. I unfortunately won't be there. I was there last year and I presented this year. I'm unfortunately at a different event at the same time. And I will not be there. I don't get to go to Austria.

This is – talk about ending on a side note. Yeah, I know. I know. It's wrong, right? I know. It's completely wrong. No, but I'm sure there will be other opportunities to meet. I mean, you are obviously uh well traveled

and you are traveling the world and speaking at different conferences i'm sure we bump into each other at some point in time um and uh i think the good news about our technology day of ages we while it's nice to meet physically we can always meet virtually and exchange more of these thoughts and help educate i would love love to. And if you ever come to Denver, we can go take a trip to Mile High Comics.

Yes, I'd love to. I go to Denver quite a bit. There's an amazing Java community there, so I love being there. And Mile High

Comics sounds amazing. So we should talk about this new movie. I'd love to hear what you think in about a month when

we've all gotten to see Infinity Wars. Well, I have to go catch up on all the old ones first, so yeah, I'm love to hear what you think in about a month when we've all gotten to see Infinity Wars. I have to go catch up on all the old ones first. I'm going to need some time. Join me. I just finished Phase 1 yesterday. My partner, Tammy. All right.

Definitely going to check those out. Andy, I think now we shall summon the Summarytor. Let's do it. I'll keep it quick because I think there was so much information. Thanks so much for giving us an overview. I believe the strategy is clear. I think we want to enable development organizations out there

to move away from building monolithic apps where they had to deal a lot and worry about a lot of the boilerplating, about the underlying architecture, about how things call each other into a world where we are breaking things apart into smaller pieces. Spring Boot was a great framework that helped there.

Now we have Reactive Spring and the Last Incarnation that allows developers and forces developers to build more reactive code, meaning reacting to events, which also means we have to, I think, change the thinking of how we develop code. I think that was at least a lesson learned for me

when I started implementing these types of applications. And I think the ultimate goal is that we are moving towards something that is even smaller, something like serverless. And it's great to hear that Spring also has an answer there with the Spring Cloud functions. And on top of that, or kind of underlying and supporting, monitoring obviously plays a big role. While we have then all these monitoring platforms and APM tools or other tools that are already out there, it's great to know that there are projects like Micrometer that you can find

on micrometer.io where the Spring framework itself and the applications that build on top of Spring can expose additional metrics and additional values to do analytics on top or for helping with troubleshooting with analytics. So that's great to know. So Josh, thanks a lot for that. I hope this kind of summarizes the main talking points. I know there's much more to learn and there's also a lot more content online. And we will make sure to link to the key things, the key topics and frameworks we talked about today in the notes of the podcast.

Thank you for having me. And thank you for the summary, Andy. I normally don't have much of a podcast. Thank you for having me. And thank you for the summary, Andy. I normally don't have, I don't have much of a summary. This is one of those ones where I was absorbing a lot more, especially on the whole Reactive. I got, I have, you know,

Josh, my background is more in the testing and performance testing side of the house. So from a development point of view, it's always a learning side for me. And I, buddy. Excellent. Well, I came across Reactive a few years ago when somebody was asking what we do with it.

And it was one of those more abstract concepts with all the asynchronous activity going on behind. And I just really appreciate your description of Reactive Spring because every time I hear more about it, it starts gelling and making more and more sense. It sounds like a pretty really, really cool framework um but that's it liked it that's about that's about the summary i've got andy um josh any any summaries this this is going to be airing towards the end of april around the 23rd or so uh any other any uh appearances maybe in may or june you'd like to promote that you might be appearing at that, you know, aware of or anything else. I know you have your job. Was it job? No native. What's the name of your new book? Cloud native Java cloud native Java. And you wrote that with, um,

my, my buddy Kenny Vistani. It's a book about how to build applications that survive and thrive in the cloud. It's a, it's a good book. I want to encourage all your listeners to go to start.spring.io and spring.io forward slash guides they'll find the ability to generate new projects and get started. They just open it up in their IDE

and then as to appearances what months did you say? Let's say May or very end of April. I'll be at Vox Days Melbourne in the beginning of May. I'll also be at Vox Days Melbourne in the beginning of May. I'll also be at the... I'll be in Melbourne for something else. I'll be in JavaCrow in Croatia

on the 7th of May. I'll be in Manchester on the 9th of May for the Java user group. There I'll be at DevOps London on the 10th of May. I'll be in Spring One Tour in Denver on the 14th of May. I'll be in the Netherlands

on the 17th of May. I'll be in Kiev, Ukraine on the 8th of May, I'll be in the Netherlands for, on the 17th of May, I'll be in Kiev, Ukraine on the 18th of May. I'll be in Dublin on the 22nd of May and 21st. I'll be in Barcelona for Spring IO on the 24th. I'll be in Auckland,

New Zealand on the 25th of May. And then I'll be in St. Louis on the 30th of May. So if you're out there, just come by. I'd love to hang out. I'm on Twitter. I thought I,

yeah, I thought I travel a a lot but i think you just completely uh made me think what i what am i doing hey by the way uh may barcelona 24th i will be in barcelona too because we have our dynatrace perform conference omg that week uh barcelona 24th yeah let's meet i'd love to meet you that'd be great small world yep yep Yep, yep. Sounds good. And the rest of you, if you can't find me there, find me on Twitter. We can meet on Twitter at starbucksmadness, T-A-R-B-U-X in the end. Excellent. All right, well, Josh, thank you very much

for making time to be on the podcast today. We really appreciate it. My pleasure. Truly, thank you for having me. Great discussion. I learned a lot. Thank you. We learned a lot as well, and I hope our listeners did too. Thank you, everybody. Bye-bye.