The Microservices Substrate - NetflixOSS, Spring Cloud Services, and Pivotal Cloud Foundry (Ep. 32)

Episode 19 · 45:19 · SRT · archive.org · all Tanzu Talk

So I was thinking earlier today, I was just walking up here. I was trying to get my daughter out of my home office. She's about, well, she's going to be free next month. In a few weeks, we better get started planning her birthday. Just that's a pro tip right there. But I was thinking, you know, she's at that stage where almost everything she does, she announces. Like, I'm going to go get my book, watching Frozen. You know, like, I've got poop. And I was thinking, you know, there's a lot of computer services like that. I mean, that's basically how, like, UDP and multicast works, right? Is you've got all these things in your big distributed system, and they just tell you every time they have poop in their diaper and everything that's going on. And there must be some name for that, like, broadcast everything style. More interestingly, there must be a name for the, I guess it would be a pull mechanism. It only tells you something if you want to know. I guess that would be SNMP. You've got the traps in SNMP, which broadcast everything out. But you do have to explicitly subscribe to them. Whereas with my daughter, there was no message sent about subscribing to her diaper notification service. I guess that's implicit in being a parent. It's kind of defaults that are set in your configuration. But there must be some name for the situation where broadcasting is not done. The mum broadcast paradox or something. That's right. It's like big kid data. You're just a lot of volume. That's right. And a variety coming in there. I know there's no filtering out this, you know, we ask our systems now to tell us more and more. And unless you have systems on the other end reading it, you just get, you know, dumped this way too much data. It's like, not now, Slack. Stop telling me so many things. Just relax. So I know our systems are very chatty, just like our children. Slack has this one thing that drives me crazy, which is like, there's no way to turn off the at here, at channel thing. And like any system where it's – I think there's probably some rule that also has some principle law or theory behind it that if there is a mechanism in a group listening situation by which you can get everyone's attention, it will be abused.

It's just like, that'll happen. So it almost seems like that channel in here thing is a – it's a misguided feature to have. It's the opposite of what you want. I saw you mentioning on Twitter this morning that if – boy, maybe you could just do one thing at a time versus 50, maybe you'd be more productive. But I think we just accept the fact that continuous partial attention is our reality. That's right. You've got to learn how to cope with it. That's right. You know, this reminds me of another highly related thing. I remember I was reading that – how do you say it? Nassim Taleb guy. And he said two paradoxical things, which I'm sure delighted to him. He likes to be in a quad paradox situation constantly. But he's essentially saying, you know, hey, I made a lot of money with arbitrage, so the following I am lucky enough to be able to experience. Just like, you know, you should just wander around and like eat really good meals and only like work about an hour a day, and that'll work out better. And yet, paradoxically, he said he reads like 10 or 15 books at a time because he gets bored with them and he's got to bounce between them. So there's silos of focus, I guess. You just got to figure out your situation. So, you know, I was thinking of all this distributed stuff, and we'll get to this after our brief news thing. But our topic today was another part in our Circle of Code exhibition, going over the Spring Cloud services, which are based on the Netflix OSS stuff. But it seems like what's becoming the industry-leading way to do microservices and all of the, as we would say, sort of day two operational stuff, or even day one. But all of the operation stuff around it as well, which we'll get to in the second half. At your suggestion, you're doing a good job driving our Circle of Code agenda here. I'm just behind the scenes. You know, you're the face of us. On the audio-only podcast. Yes. So with that, you know, I think the VM world is actually going on at the moment, like, as we speak.

I think it's the first day as we're recording. I really haven't caught up on it. It's not, you know, some people think that we're all in this federation, and we have some sort of conspiratorial, like, Richard Ailes memo that's sent out every day. But it's not the case. So we'll have to, I'll have to catch up on the news that's coming out of there. But, you know, that's kind of interesting that it's happening. And then I was reminded of this because of another item we have in here is, I think it was last week, the second half of last week, or something, that Microsoft is getting PowerShell to run on Linux, which is a, speaking of circles, that's a fascinating full circle. Yeah. Yeah, it's wild stuff. It's good. And, you know, Amazon, I think, gave some PowerShell modules, kind of their plug-in components and, you know, donating that. And putting that in, so it's open sourcing, it's widely available. And you could ask, if I'm a Linux developer, why would I pick this up? And the answer may be, you won't. It may be, you know, live with your Bash shell, and, you know, you're scripting, and you're fine, and you wouldn't use PowerShell, if anything. I was reading something else where Microsoft got asked to change the name of a couple packages, because back when it was only Microsoft World, they used things like WGET and other terms that were Linux-based, but who cares? Because this was never going to overlap. Now it does, and now you have these packages with the same name that shouldn't be using that name. So it's just very funny now when you build systems and never expecting worlds to collide and probably joke about it. Now when they do, you actually have a little bit of a mess on your hands. So amusing, but it's a good trend. I forget what year it was that, I guess it was called Monad a long time ago that that came out. But I remember this was back when I was at RedMonk, and I think I even did a video here and there, which has probably, like, disappeared into the nothingness of the Internet. But it was Jeffrey Snover who was architecting that, and he had been working at Tivoli for a long time. And I remember the story that he had is he basically, you know, among other things, well, I think he's kind of like the head architect of their server business or something now, or some highfalutin position.

But, you know, it was basically, like, part of what he was hired over is to, like, do this, sort of like, hey, we should make Windows more Linux and Unix-like. And I remember him telling me that the first thing that he spent a lot of time saying is that in the Linux world, people use the command line. There we go. Which, you know, speaking of, like, a Zen presentation, that would have been a good single-slide presentation for, like, a multi-day meeting, right? Like, you know, like, what does it mean to use the command line? And naturally, I think what, if you think about, at least the way that I think about PowerShell is sort of, like, the implementation of that in Windows land. And I remember some of the first things were, like, you know, you could basically do batch changes over multiple machines with PowerShell things and configure everything that you were sort of used to bucking around in a GUI for. And before that, like, right around that time, thankfully, I'd just been, well, I mean, for this story at least, and I guess also for myself, but I'd been working at BMC on their, like, some of their Windows monitoring stuff. So I had this weird passing understanding of, like, WMI and Windows internals, and it was basically exposing all those Windows internals to a command line interface, which is pretty interesting. And I think, I mean, you probably know better than I do at this point, being more in Microsoft land and stack stuff. But, like, yeah, I mean, it seems like PowerShell is, like, a full-on, like, shell and scripting language. Like, way beyond even what, I mean, if you were to think about what the command line in the shell in Unix and Linux are, and how, like, anything that's successful in decades old, they're kind of bound to the past. Like, PowerShell is probably one of the newer, like, complete reinventing of what that idea is and what you would want to do. Yeah, they've done a nice job with it, a super powerful platform. That's where, again, I think the benefit you'll see is if I'm a Windows admin who now has these sort of Linux boxes in my purview, I don't have to necessarily completely shift my thinking.

I can actually start pointing this at Linux boxes and doing things in my entire environment. So, you know, PowerShell is a first-class citizen by Microsoft, but as you say, you're also dealing with an OS on a platform that traditionally has not been very CLI-centric. It's been more point-and-click. So, a new way of thinking, I guess I'll also promote the blog post that we put out last week around Bosch for Windows and treating Windows as immutable servers. This is novel stuff, treating a Windows box as something that you stand up, you tear down, and everything's cool, versus stand it up, apply all these group policies, do all these other things. That's a very new way of thinking. It was actually a really good blog post and goes into our thinking about what does it mean to do immutable Windows, which most people have thought was pretty tough to do. Hmm, immutable Windows. That sounds like those Windows we used to have in the co-op I lived in college that you could never open. And you might have to be careful that you paid the extra for the AC if you were in one of those rooms. Can you imagine, like in the 90s, you could actually rent a college room in Austin, Texas without AC? I was thinking about that the other day. That's just insanity. No, I try to think of how my parents had jobs with cars with no air conditioning and how did they possibly not get to work as a sopping mess. And it's just a different world back then. Yeah. Clearly, clearly, you know, aside from the last 30 years, humanity was suffering for the eons before that. I have no idea how it worked out. Just all dumb luck. It proves that UFOs must have exist because they had to come down and help us. So, you know, related nothing to that, I guess. What's this item about Salesforce having an AI called Einstein? Yeah, I mean, they're apparently going to announce something coming up at their upcoming conference. I think, you know, this jumped out at me. It's an AI product called Einstein. You can imagine, you know, it was light on details in terms of the stories. But you can think about it as you're doing complex CRM and sales managing campaigns, that there could be some value in doing machine learning or AI or bots or something as you're interacting with customers.

But this just seems to be this constant drumbeat that AI is starting to hit the masses among tech companies. You're seeing some of these things come in real life. Microsoft just bought some natural language and AI-type company last week that they might try to mix into office-based stuff. And, again, if I'll plug something that I've enjoyed reading, Jack Clark, former journalist for Bloomberg and Register, has an AI newsletter, which is really good. It has some really good stories in there every week. And even if you're not in that space, I can understand if you're deep in the bowels of an insurance company, you might not think about AI. But these are areas where it's probably good to just know what things are going on because this might be one of these things that bum rushes us. And all of a sudden it's embedded into a lot of tech and a lot of libraries are available that all of a sudden you might want to know what's going on. So it's a fun thing to keep an eye on. Watch out for the cyber bums. That's what you got. Yeah. You know, I'm always, I don't know, I guess a skeptic on AI stuff, mostly just not that it's not possible, but I'm always just curious what the applications are. And it's like a lot of stuff that I'm skeptical on the tech world. It's like I'm more skeptical as a forcing function for like, why don't you talk about the practical things? And like, I can think of one thing. I remember there's, I think it's like AI.x and it's some service you can sign up for, for like scheduling meetings. And you just like CC them and they've got cutesy names. You can either get like Jane or John or something. And you can, if we were to have a meeting, right? Someone's like, hey, Coté, we should have lunch. And, and then I, I would, I would reply back to them and CC Jane or John and be like, Jane, can you schedule us lunch? And then it would like the AI thing or it would sort of figure out like emailing back and forth to figure out where to go and when and everything. And like that, that would be kind of nice. And so, you know, I tried it a little bit and it's, it's, uh, it might be my problem, but it's the equivalent of like, I never want to use like a travel agent to book my travel. Right. Like, it's just like, I have too many opinions and I want to tweak it too much. So maybe that's the issue, but just like, yeah.

And we have one of those, uh, those Amazon echo things. So every now and then we're telling Alexa stuff, but Alexa is not too bright. That's more like speech recognition. No, I know. That's the thing is I don't think we all, I finished a good book recently was talking about the complexity of technology. And one of these things that you can either fall into multiple camps, either you are just in awe of technology, which is a dangerous place to be. You need to understand what things are, or you can fear it. Like you have to be Skynet and that's not good. You need to have this sort of like healthy respect for tech. And even with AI, I think a lot of people just don't trust algorithms yet. I mean, I drove to Vancouver, British Columbia this last weekend from Seattle and, you know, I used my mapping technology and there still be times where you take some ridiculous looking route. And it's just like a stupid algorithm, you know, you just yell at it. I just don't think we have a lot of faith yet. If we really had to put our entire trust in these things, that it's making all the right decisions. And maybe we're getting there when we have self-driving cars and planes with no pilots. But right now, you know, I still can't trust, you know, my hand going under the sink that it'll actually turn the water on. I'm not ready to have a driverless car. Yeah, maybe like mapping stuff. I'm sure some highly nerded out AI person would say that's not AI. But like that feels like AI. Like I was, to fill more anecdotes in here, I was using Waze the other day. And, you know, I was going from one highway to the other that I drive all the time. And it told me to go on the frontage road instead of the flyover. And I was like, well, that's stupid. So I went on the flyover. And sure enough, there was a wreck on the flyover. So I just sat there for a long time. Right? And it was, it's, again, like that's, that's not really like complicated AI that's going to go and like, you know, read about enlightenment and go sequester themselves off somewhere to talk with each other. But like, like it's, it's, it's, it's pretty nice. Right? Like that, even that level of, of, of AI, we could call it artificial compute conclusions, just like helping me make conclusions would be nice that. Yeah, we'll, we'll keep seeing more machine learning. I think if you're any enterprise, this just drives an importance on making sure you're collecting good data, you're having figuring out ways to ask questions of it.

And at some point, maybe you can have things that make decisions based on it. But, you know, step one is if you don't have data, you can't train a model. AI is meaningless to you. Same with machine learning, those sorts of things. Yeah, you got to edumacate them. Right. Get them learned up. Well, also this week, to close out our new stuff a little bit, or this is last week, actually, the, there was finally an announcement that Rackspace was going to be acquired. That, which is to say, go private. I don't know much about the Apollo Global Management LLC. In some article I read, they said that they also had bought the security company ADT, which, you know, not, not, not to be all, you know, a scan side. But that sounds like the kind of thing that you write when you search in a database and you just plop that in a paragraph, like, of all the coverage. So I think it's like, was it 4.3 billion that they're being sold for? And of course, it's got to close and all that stuff. But, you know, that was the thing I was most curious about is like, who are these Apollo people? Like, I know they can play a liar really good, but other than that, and they get really upset if you try to, like, you know, try to compete against them, they might skin you and hang you upside down on a tree. You got to watch out for that. But other than that, what's their deal? Yeah. I don't know if it is a shadowy finance group or they've all just have tons of good finance stuff. I think it was, you know, 4.3 billion is not selling for spare parts. So you are clearly identifying this as a very good asset that you plan on doing something with. I think that's going to be the interesting part is when it's great they're private, they can probably be more focused on certain things now, but they've already shed some parts of the business. And the question is, how much of a leash do you have? You know, I think you and I have been through acquisitions. You know, many things sound great until certain things start to hit the fan. So hopefully things go fantastic for them as they double down on being a managed service provider across clouds and things like that. So from my experience, you don't typically get a long leash or a lot of time to show value when you have an impatient parent. Yeah. Yeah. Well, we on my other podcast, Software Defined Talk podcast, we talked about this at length last week.

And I also wrote up some little highlights over on my blog that I'll put in the show notes over at Coté.io. But I think, you know, the only other notable thing I would say is, well, there's two things. One, you know, we talked about the IaaS magic quadrant a while ago, where Rackspace is in the, they're high up in it, but they're kind of in the dreaded lower left-hand quadrant. Now, that said, there's a managed cloud magic quadrant that they're the leader in. So I think that's the way they've been repositioning themselves. So it depends what glasses you look at them through. And also, I mean, it's, I think, I think pursuing that strategy seems to be interesting. And I think if you look at our, our customer base, like the idea of having a managed cloud seems to be very appealing, right? Like, like having someone take care of that for them. Like, I think most of the customers we have, or at least that I talk with, would be quite interested in that in the preceding years. Yeah, the hard part is, yeah, you like when it's managed, but then you don't like the lack of agility of, I just want to do stuff. I don't want to open a ticket with a managed provider. So there's always this weird place of, look, I'm trying to be more agile, but I'm still giving the keys to the kingdom, to someone who has great processes to operate lots of different customers. So, yeah, I don't know. The jury will be out there. Clearly, they make good money there, as do other managed providers. But is that the future in this sort of self-service, automation-driven world? I don't know. Yeah. It'll be interesting to see. Yeah. You've got to have a really fast ticket desk. That's the innovation that needs to happen. So just as a pointer, so I, last week I also point, I've been working on trying to, we get asked about return on investment a lot, as you can imagine, being an enterprise software vendor. And I took a first drafty kind of rambly pass at writing up something there. I'll put a link to it, but I have it over on my Medium blog, and hopefully sometime I'll write some, what you might call, professional versions of that, instead of me kind of ranting about it. But I would be curious for listeners for this. Like, when it comes to, and as I define it in that piece, ROI basically usually means a lot of different things, not just a straight-up return on investment.

And it's usually when someone asks for ROI to do Agile or DevOps or Cloud Native or use a platform, what they're saying is, help me justify spending money on this. Right? Like, and one way of doing that is to show that if I spend this amount of money in time, I will get a return on that investment and we will make profit from it. Which, for something like Agile, is kind of weird to think about how you would do that. It's sort of like, you know, what's the ROI on brushing my teeth every day? It's sort of a long-term, there's no pivot table for that, that has a short time horizon. And that's, let me take a note, pivot table for brushing teeth. Anyways, I'm always curious to have people's realistic input on how they, in their own business justifications, have done ROI and things like that. Because despite the fact that people are always asking for a spreadsheet to do it, my theory is that every single time it's something slightly different for something like for Agile and higher-level stuff up the stack. Fair enough. So, with that, what's the topic we have this week, like I was saying at the beginning, is to go over, basically, Spring Cloud services and Netflix OSS and all those things. So, why don't you tee that up? Yeah, I mean, this is, to some extent, self-serving. Since I've signed up to write a white paper on Spring Cloud and Netflix OSS for Pivotal, I thought I'm going to road test some ideas with Coté and our illustrious audience. So, but it also fits, clearly, into our circle of code discussion. We talked, what, last week, two weeks ago, about, last week, about project management or, you know, using Pivotal Tracker. And this idea of how do you start to collect stories that drive your Agile work. And, you know, the next part of this circle, and if you get a chance to view Ansi, he's our VP of engineering. This video on YouTube from the Pivotal kickoff earlier this year or the one from SpringOne, which was great. This idea of saying software development happens in a rhythm. It's not a one-and-done exercise. It's often about the idea through development, through testing and deployment, to collecting feedback, to incorporating that feedback.

And you're constantly iterating in, like, a circle, as we love circle shapes. So, one of the pieces of development is, you know, how am I accelerating what I'm building here? And so, the Netflix OSS group, if, you know, I don't know if anybody on this podcast does not know who Netflix is. But when you're talking about 80-plus million customers, many of those international, 30-plus million now, you know, at peak times, representing over 30% of network bandwidth in the country with people streaming. So, they solve problems at scale that probably few companies see. And so, when they've been an Amazon customer for years, but, you know, as the platform was still growing and as their use cases were so edge in terms of their volume and their processing, they've built a ton of services and tools to help them operate at scale. And so, they've open-sourced nearly all of it, obviously, the stuff they talk about. And so, they define Netflix OSS as this kind of layer for reliability, for processing, that helps them do the things they need to do at high availability. Anytime you read stories about, you know, Amazon US East 1 going down, Netflix is rarely ever impacted because they have simply built for a level of resilience that, frankly, I don't think many do. But, what's interesting about all of this is, and Adrian Cockroft mentioned this at his SpringOne keynote, is these are now solved problems. And so, you have these questions or these decisions of, do I reinvent the wheel from things that, you know, Netflix processes billions of requests per day through Zool and some of their edge stuff? Am I going to do better than that? Do I need to? And so, they have some really cool tech that says, look, this has now been done. How do I use it? And then, with Spring Cloud, we partnered with them, Pivotal, what, a year or so ago, and said, let's make this stuff more consumable. Because I can go to the open-source repo, download bits, and run Eureka myself. I absolutely can do those things. We'll talk through some of these services. But should I be doing that? Is that the best thing to be fiddling with this for a few days?

Or would it be great if I just add some annotations in my Spring Boot app, and all of a sudden, I've got, you know, circuit breakers, or I've got things like that? So, the idea of how do I operationalize and productize these libraries to make them just brain-dead simple to consume, while still not losing any of the power, we've baked it into Spring Cloud. And then, with Spring Cloud services, those are the ones that run cleanly, natively on Pivotal Cloud Foundry, just with a button click, deploy out the config server, deploy out things like that. That's kind of the history of where some of this comes from. So, then, kind of starting from the top and then getting down to the components, there's basically, I don't know what top is. It's more like a chronology. But there's, so Netflix writes all this stuff to basically handle their big distributed microservices-based application that allows us to watch videos. All in the cloud, though. Yeah, and, you know, does a bunch of other stuff as well. And, you know, no one's going to get more upset than someone who just started to try to watch, like, what's that strange thing show? And episode six doesn't come up. So, they need some resiliency. Or people are going to get really pissed, as it were. And so, they write all this stuff to be able to be a resilient distributed system. And then, they decide they want to open source it, whenever that is. And then, along comes, so you've got Netflix OSS, and they have a bunch of their own separate stuff. And then, so we have Spring Cloud, which takes a lot of that stuff, and probably some other things as well, and bundles it in a Spring way that makes it, on its own, just easier to consume by Spring's opinion. Like, that's always, that seems to be a lot of what Spring Frameworks people's ethos, I guess, is always. It's like, let's focus on getting maximum usability for this API and layer it around there. And then, the next thing is that, if you have Pivotal Cloud Foundry, the use of Spring Cloud services, and therefore, much of Netflix OSS, is basically baked into and pre-configured and wired up in Pivotal Cloud Foundry,

so that you don't really have to spend much time at all, especially as a developer, setting it up or configuring it to work with each other. It just sort of works out of the box, if you will. Yeah, I mean, if the job is to bootstrap devs so that they're writing the stuff that matters, right? Business logic, experience with customers, getting to do that faster, this sort of stuff, which is scaffolding, which is plumbing, super powerful plumbing, but it's plumbing nonetheless, you know, your customers should just see a resilient app. They're not going to ever see these services. These are something that help you stay online at all times or be durable, whatever. So, I think it's that mix of saying, look, as a dev, if my job is to get into building awesome stuff first, then I don't want to necessarily have all this other bootstrapping of getting projects stood up, figuring out these libraries, standing them up somewhere. If I can just kind of have that baked into my framework, sometimes with opinions, so they're not as flexible maybe as just doing it raw, I'm just getting to more meaningful work faster. And there's something to that. So, then let's walk through, like, the components of it, like, what makes up this thing? Yeah, they've got a handful of categories. If you go to the netflix.github.io, it's kind of their landing page for all sorts of projects. And they've got tons of categories, big data, runtime services, where we're going to spend our time, content encoding. You can imagine they've just got petabytes of content, data persistence, reliability, security. But when we look at the Netflix OSS services we're thinking about, and again, for the layperson, the one you may have heard of is things like Chaos Monkey. Now, Chaos Monkey is kind of the famous one from Netflix that just kind of turns off things within a particular area of the cloud for them. They just turn boxes off. And the premise is, their system should keep working. So, this is almost a test in production sort of service that says, let me just go in there and randomly turn things off. And if I've built my system correctly, that shouldn't impact anything. Things should be self-healing. Things should be discoverable. Now, I contend if you unleashed Chaos Monkey within most enterprise data centers, you'd probably shut the business down in four minutes.

And that's just, you know, the nature of how they've built apps. It's not necessarily, it just is. So, they've also built some other chaos things in their family that turn off a whole region and things like that. And the idea is, to really test resiliency, you've got to be able to lose components all over the place in ways you might not have thought of and prove that things work. Now, there's no Chaos Monkey in Spring Cloud. It doesn't really have that same concept. But that's really the most famous of the Netflix services. When you get into the ones that are in Spring Cloud Netflix, it's a more famous one. So, you have Eureka, if you've come across that. That is, service discovery in this microservices-y world where, you know, instead of two monolithic apps, I have 400 microservices. The question is, how do I find stuff for load balancing purposes or what have you? How do I know that the order service is here so I can call it? Now, there's also a whole school of thought that says, well, service discovery is, I don't like that concept anyway. I wish I just had a message bus that could pass messages and say, hey, here's a new order. You do something with it. I don't want to look up an order service. I just want to have all these things hanging off a bus. And that could be cool and that could work. But there may be synchronous examples where I need, like, give me Coté's customer record. Maybe that doesn't go through a bus. Like, there's reasons to know that's the service. And even in that case, you need some sort of directory that tells you how to get to the bus, right? Like, no one's born at the bus stop. Like, you have to know, like, how to locate yourself to it. And it is, I mean, that's, you know, going back to, that's the, it's sort of the my daughter versus people who don't tell you what they're doing model of broadcasting versus looking things up. And so it seems to me, I mean, Eureka is basically a directory, right? Like, as we used to call it in the JEE world, I don't know what they call it in .NET land, but, you know, there used to be like JNDI and all that. And, like, it's sort of like the first step to any application that uses the network, get a hold of the thing that tells you about other things. And there's all sorts of, like, gymnastics you always go through.

It's almost like it's the prime mover thing of, like, you know, who tells the network thing where the network is. Like, eventually, someone has to give you some information. But at least in general, in a larger system, you just go to something like Eureka or the directory to say, like, where's my thing that does, I don't know, that looks up what movie to stream or authorizes this customer or do this thing. And that's kind of basic. Now, I'm no expert on all this stuff, but it seems like something that Eureka does that's slightly different than traditional directories is it has a fair amount of, like, health checks and monitoring built into it. So, I guess maybe it's also a source of, like, is this thing healthy or are there healthier ones that you could use? Yeah, there's a lot of good integration with some of their other libraries that do things around, you know, other load balancing and circuit breakers. So, Eureka is unique from just traditional, you know, Amazon Elastic Load Balancer or their DNS service because it also does local stuff. So, there's a client and a server, if you will. So, my web app actually pulls things into memory about where my different services are in the directory. And then it can make local decisions about, well, let me route to here or to here. And so, there's some smarts that say, let's not just have a single point of failure on my registry either. Let's actually push some of that data to each client. They can make local decisions and then just refresh regularly. So, a neat model. And again, Netflix builds these things because they don't see it in the core service. And then we all reap the benefit of a more intelligent sort of ecosystem here. And this is one of those that's like, ultimately, you can configure it with like a Git repo or something, right? Yeah, I mean, pretty simple stuff. And this is one that's also baked into Spring Cloud services. So, if you're a PCF customer today, this is a button click to get your service discovery set up. So, it's a little different than config server, which does, you know, use a Git backend and things like that for just config values. But when I do need to look up my stuff, I don't remember all the backing stores for Eureka. But it's nice to have, I think you have some choices there. And then, you know, last item, it sets the stage that there's going to be a lot of silly names for things.

Nothing is named like some serious adult stuff. It's all fun stuff. Not with that many microservices. It's one thing when you get two services, right? You can go with some Lord of the Rings characters. But now you're going like B-side when you get the 400 microservices to name these things uniquely. You'd have to use the Simpsons naming scheme. I think that's the broadest universe available. The extended Marvel universe something. You're clearly hitting the long tail of names here. Yeah, so the second one, which it starts to get more advanced, but Hystrix, which, I don't know, sounds like something my doctor gives me a cream for. But it's meant for a circuit breaker. So, this idea of, you know, as I have more and more services, you know, Coté, you're probably familiar with this idea of, you know, you look at nines. Everyone wants five nines, three nines, whatever. If I have, you know, they have the example on their web page. I think it's 4D services with three nines. You know, on the, you know, even four nines, you can look at that and go, that's pretty good. But all of a sudden, when you multiply 40 times 999, all of a sudden, I'm still taking a couple hours of downtime a month. Because you have to do the aggregate of all of those services if my app uses them all. Like, individually, it's great if you're online all the time. Collectively, that's not very good when I'm consuming all these services that individually still have downtime. So, how do I prevent cascading failures is the term. How do I make sure that if my customer record service is offline, everything doesn't crash to a halt? And so, the idea of hysterics or a circuit breaker is I'm going to make sure that when I detect an unhealthy service, I kind of open the circuit. I always do that wrong. I think I open the circuit. And, therefore, traffic might not go there anymore. And I have a fallback service or I might just return some cash data. And then, over time, it slowly closes the circuit, I think, and lets some data come through. And then, if it's healthy, it opens it all back up again or closes it. I don't have electronics, well. But it follows that model. But the idea is how do I make sure that a bad service gets quickly shut off so that my other things that might depend on it don't come crashing to a halt?

Yeah. You know, I think it took me a long time to figure out, like, why a circuit breaker is good. I mean, the full picture of it. Because it seems like, obviously, you know, if it's going to spew a bunch of stuff that's going to bring down your system, you should turn that off. But then, my thinking was always like, but then it doesn't work. Right. Right? Right. Like, you know, again, using the Netflix example, if, to greatly simplify, I'm sure, which is a much more complicated system, if I go request, you know, episode six of Strange Things and it's broken, the circuit breaker, I guess, opens the circuit and I don't get my video. So, it's broken. But, you know, on the other hand, I think the goal is that, as you're saying, like, and, you know, a lot of the problems, especially performance problems you encounter in applications are due to, like, cascading problems. And this thing happened over here that caused this to break. And there's a reason we have a whole, like, cult of root cause analysis, because you're always having to dig down to see what actually caused the problem. So, the idea is, if you, to mix the metaphors and make it confusing, if you close off that service, instead of, as you say, open it up. But if you close off that service, you hopefully can reduce the amount of, like, things further up the stack or upscreen, you know, issues that happen. But you bring up a great point there. I think for, like, very complicated distributed applications that are composing together multiple services, this is probably a pattern that you want to use a lot more than in, not so much non-complicated, but sort of, like, vertically integrated things. Where, you know, there's single calls going down instead of multiple things that you're waiting on that could blow everything up for you. Right. No, you made a good point there, specifically among many good points, of course. But, you know, there's a certain level of responsibility you take on now as a service consumer, because I can't just blindly assume your service is up all the time. I might need to have, you know, be able to handle cached results, or I need to be able to, you know, do something else.

Hystrix takes care of returning back data from a backup channel or things, but you can't just assume your endpoints are all, your dependencies are always online. And so even as a service developer, you do have to think a little bit differently. Yeah, and I guess, I mean, I don't know if this actually fits in the best way of doing it, but I guess you could also have, like, service degradation as sort of a pattern, right? Like, I can't serve up the HD video, but I can serve up the 480 video or whatever. Yeah, as a consumer, that's probably better, right? I mean, there's a fine line. I think we all know that I would rather have no internet than slow internet sometimes. I mean, there are certain cases where a degraded experience is actually worse than nothing. But if you do it right, then sure. You know, maybe I don't get the weird subtitles at the bottom or the options, but my video playback still works. I can tolerate that. Or, again, I'm a banking customer online or I'm, you know, a storefront. Maybe I can't show you recommended products because that service is offline, but I shouldn't fail to draw the page because I can't show recommended products. So I think it's just thinking of these components differently. And then once again, as with all of these things, or most all of them, the other part that makes it valuable, especially when integrated into a full platform, is you have the actual monitoring and management stuff on it, right? So whether it's like a developer or, I'm putting this in air quotes, a DevOps or an operator or whoever, they can actually see these things happening so that they can try to go fix them. And you can get a lot of information, especially if you throw in something like Zipkin or Spring Sleuth. You can start to, like, figure out, like, if something's going wrong and, let's see if I get this right, a circuit opens. Anyways, you shut down a problem. You can start going in there and tracing out, like, what problems you might have and things like that. So the other thing built into most of these tools is once something goes wrong, here's a whole bunch of information you would need to try to fix it in production, not just, you know, dump out a stack trace and go file a ticket and have someone fix it one day. Right. No, it's good.

The show notes for this will be Coté and Richard talk electronics. And, you know, when the zombie apocalypse hits, I will not sign up for electrician. That's right. Two software marketers walk into a radio shack. You can imagine what happens next. Good times. So, yeah, I mean, hopefully also the gist you're getting as we talk through these is that, you know, the sort of old client server model of I just build up a web app and I deploy it, you know, that is very different in this world of a lot of distributed components that might span on-prem and cloud or cross-cloud and I've got different availability. And, you know, everything has gotten more complex so that you can be more agile. It's just weird, probably sometimes it seems counterintuitive, but, you know, agility is hard to create. And to do it, you end up using services like this, which give you a lot of awesome controls, but complexity is going up. The next one is Ribbon, which you'll find out in Spring Cloud, it's not in Spring Cloud Services, but part of Spring Cloud. This is client-side load balancing. So, this is the idea of, again, integrating with the registry and others so that it can actually do client-based load balancing within your web app or whatever you've got. So, it's actually making some of those decisions about where to go. So, it's just an interesting model versus just having a pure server-based load balance. It gives you some additional flexibility for how to target workloads. Right. And my assumption is, like, this is the kind of thing where having the health information from something like Eureka is helpful. Because then, speaking of AI or, like, very simple AI, you can start to make some analysis of who you might call reliably and stuff like that. I mean, I assume that in most distributed systems like this, it's just sort of, like, that's nice. Let's just do round robin. Like that. Exactly. That seems to be what happens. And sometimes that is fine, but it is nice to know you've got that local flexibility and not relying on the single server for all of it. The next one to talk about, Zool, referencing, of course, Ghostbusters, is it's a nice kind of reverse proxy or an edge server.

So, this is something where, again, they send billions and billions of requests through this on a given day. But the idea of just giving you some more flexibility for routing and things at the edge. So, I haven't used this as much myself yet. This is one I haven't stood up. But the idea of giving you a way to, I think, not really expose a lot of your back-end services, even to the microservices thing, and then have this sort of front-door edge router that sends things. I don't think it's quite a load balancer, but the idea is it's a smarter routing engine. That makes sense. The one that I'm kind of excited about, and we talked about this at SpringOne, we should include some links from SpringOne, but Spinnaker. So, this is what Netflix built for. It's open source. Of course, all this is open source. But multi-cloud deployment. So, the idea of I've got my package and I want to go deploy this app to Amazon or I want to deploy it to Cloud Foundry or I want to deploy it to Azure. All of that through the same tool. Pretty exciting stuff. So, there were some good demos at SpringOne. This just got baked into Spring Cloud, I think, last week as its first milestone. So, you can just add some annotations and get some Spinnaker apps stood up. So, pretty cool stuff. We're actually going to have this deployable on Cloud Foundry itself. So, the Spinnaker service would run on PCF. So, you're kind of using Cloud Foundry to deploy to Cloud Foundry. Don't let your head hurt on that one. But it's a pretty kind of exciting way to have these multi-cloud deployment tools that is pretty good stuff. So, that's one you should definitely look at if you're looking at using more than one cloud environment. Yeah. You know, this reminds me of something. I need to go watch the videos from SpringOne platform on this. But I began to understand that multi-cloud means not only multiple infrastructure clouds you're using. But within a large organization, you have multiple of your own clouds that you want to deploy to. You know, whether they're, you know, development and staging and all these different environments are geographic. And I think more and more when you look at the Pivotal Cloud Foundry customer base, they're in this situation where they have multiple clouds that they own.

And so, they need to have consistent ways of deploying and using them, which is a whole other angle on multi-cloud that I think most people don't think about at first. Yeah, no, agreed. I think that's a good use case as well. So, the last one I wanted to point out to you, Mr. Coté, is Atlas. So, this is for time series data. As you might imagine, Netflix collects a lot of data. And so, how do I use this for operational purposes? How am I using this to trace? You know, this is something, if you've seen us talk about Zipkin and Spring Cloud Sleuth, this isn't using Atlas at this point. But the idea of doing distributed tracing, saying, how am I uncovering where I have latency, following the call path, as you said, with these vertical apps as well, so that I can see this call stack. And where am I hitting latency, maybe I uncover that a service is being called all the time and it's not supposed to be. Or, you know, it's a great tool to have, to be able to uncover these usage patterns because, frankly, I can't predict how my services are going to be used anymore when I've got this microservices world. I'm having a lot of composable apps. I have a lot of different interaction patterns. And so, being able to do real distributed tracing is huge. So, Atlas is kind of what Netflix OSS offers. And, again, you can download and run that. When you're using kind of a Spring Cloud Foundry world, we like Spring Cloud Sleuth based on Zipkin, which came out of Twitter. So, that's the stack of everything in there, huh? Yeah, there's another probably dozen and a half of them. And I encourage you to read the Netflix tech blog, which is always fantastic, techblog.netflix.com, which has some great stuff. And now, one question could be, well, sheesh, I'm a Node developer. You know, I'm a .NET developer. Why do Spring Cloud people have all the fun? Well, you know, hey, Netflix uses a lot of Java because that's what big boy companies use. But at the same time, you know, if I'm a .NET developer, we've actually been incubating the Steel Toe stuff, which you may have heard us mention. We talked about a little bit at SpringOne as well, which these are kind of connectors for .NET apps into Spring Cloud. So, whether I'm doing Eureka or Hystrix or the config server, I can do that from .NET apps.

Now, I can be doing circuit breakers for my .NET apps, or I could be looking up the registry from .NET apps. So, kind of cool to make .NET also a first-class citizen in there. And then when I was trolling through the JavaScript NPM repository, which is their Node Package Manager repository, saw some ones. I don't think they're from Netflix themselves, but people had built some JavaScript libraries to talk to these endpoints as well. Which is cool because many of these are just HTTP endpoints, of which we've wrapped up some good Java goodness to make these look like local calls. But nothing prevents me from having these other apps that call these endpoints and cache data locally and what have you. So, it's a pretty open framework. Obviously, all the love has gone into Java. But if I'm using JavaScript or Node.js or .NET, you know, you can party on this data. Yeah, I mean, I think that's a good signal that you're reaching some wide adoption and thus long-term stability for a system like this is that you have more and more language support. Especially if you jump into .NET land and JavaScript. You know, I think ensuring that'll be a good test for people to pay attention to, seeing that those are well done. Then having, you know, I don't know, three different language pools supported is always healthy and then actually used. Well, as always, this has been Pivotal Conversations. You can find the freshest, most latest episodes over in SoundCloud if you go to SoundCloud.com slash Pivotal Conversations. All one long word. You can practice how to spell conversations. Also, we put the show notes on our blog, which you can get to at blog.pivotal.io. And I would encourage you, and I'm sure Richard would as well, if you like this, it's always nice to share it with your friends, whether it's in computer land or in person. And if you want to take the time to go into iTunes and leave us a review or a star rating, that's always also helpful. And if you have any feedback on any of this stuff, feel free to email us at podcast at pivotal.io. Or you can reach out to us on Twitter.

I'm Coté, C-O-T-E, and Richard is R-Siroder, which is spelled pretty much how it sounds. There you go. And with that, we'll see everyone next time. Thanks, all.

Tanzu Talk · 🍕 Get more pizza.