Welcome back after an elongated break to the Cloud Native in 15 Minutes podcast. If you haven't listened before, the goal of the podcast is simple, to explain some complex but increasingly important technologies and topics and about the time it takes for a coffee break or a short commute. Usually it takes a little more than 15 minutes, but not much. I'm Derek Harris from VMware, which still sounds a little weird. And today's topic is Spring, the open source job development framework that still gets over a million downloads a month, and more specifically, Spring Cloud. Joining me to explain it is Spencer Gibb, a staff engineer at VMware and co-founder and lead for Spring Cloud. Now we start off a little slow, but stick with it because it gets really informational and Spencer shares some great insights into how Spring Cloud simplifies and expedites the process of building distributed applications and why that's important, not just for developers, but also for CIOs and other execs who made developer productivity a key tenet of their modernization efforts. And the interview with Spencer will begin in just a few seconds after I remind you to please leave a review for the podcast on your platform of choice. It's very helpful. Thanks. All right, Spencer. So to get started, can you quick walk listeners who are unfamiliar with Spring, like walking them through what is Spring and why is it so popular? Spring is a Java application framework started 18 or 19 years ago, kind of as a response to the complexity of the J2EE model. It includes a dependency injection container as well as a web framework, messaging framework and things like that. And why, I mean, Spring is used by like tens of millions of developers. What does it bring to the table, I guess, that other Java application frameworks didn't or that you're not going to get from just writing straight up Java code? One of the goals of the Spring philosophy is to eliminate boilerplate.
2:02Maybe in today's words, eliminate toil, right? Things you do manually over and over and over. Let someone else whose core competency is that do that for you. And then you can focus on what makes your particular project unique. So what are some of the examples like that? So, I mean, we'll get into Spring Cloud in a moment. But what is like a real quick example of, if I'm not using Spring or I'm curious about it, I'm trying to empower my developers, like what's a real fast, easy example of, hey, we're using this and now we've reduced this toil, right? We've minimized this effort. It could be a number of things with framework. Some simple ones that come to mind are things like Web Client, which is kind of an HTTP agnostic, HTTP client agnostic framework for making restful calls to other services. It's really elegant and really well done and is typical of the patterns that the framework provides for other things. So they have things for making HTTP calls, making JDBC calls, making messaging calls, whether that's JMS or AMQP or whatever. There's this idea of making those things simple to do. The other thing, just for anyone who's not well-versed in the world of Spring, it's a Spring Boot. Can you quickly just, because we hear that a lot, especially if you attend like any pivotal conference, you'll hear about Spring Boot an awful lot. So can you quickly walk through what is Spring Boot? Sure. I mean, the way you used to deploy a Spring application was in some kind of container, whether that was a simple servlet container like Tomcat or some monolithic Java EE container. So you're creating wars or ears, and there was lots of XML, and that part of it was still painful.
4:06The writing code part was much, much better, but the deployment was absolutely painful. So probably the most popular framework that popularized the idea and one of the 12-factor tenets is that your application should just be that. It should just be an executable and listens on a port. And so there were a number of things that came together to create Spring Boot, one of those being embedded containers. So you have Tomcat and Jetty and Undertow and now Netty that are just libraries that Spring Boot can consume. And so now, instead of deploying to a war, it's a simple Java application, and you just Java-Jar start your app, and it listens on a port. There are other things that make deploying simpler with boot. External configuration, so the ability to configure your projects. And then auto-configuration, so based on your class path, you include some, what the boot team calls a starter, and it brings in a curated set of dependencies and enables that functionality in an automated way, usually driven by configuration. So, for example, there are starters for JDBC, for RabbitMQ, just for web framework pieces, for example. So that makes dependency management much, much easier. So all in all, it makes getting an application up and running a trivial exercise. All right. Again, that seems to be an important piece of the puzzle. Spring, yeah, Spring Cloud couldn't have existed without Spring Boot first. Okay. So, yeah, let's get into Spring Cloud. What was the impetus for developing Spring Cloud? And then let's start with that, and then we'll get into the various pieces of it. Kind of from my side, at the time, I was not a then-pivotal employee, but I was doing work in the cloud.
6:13And when you're building distributed systems, there are certain problems that are fairly common among them. So the idea with Spring Cloud was to, again, eliminate some of the toil and boilerplate initiative that is involved with overcoming those problems and allow those kinds of things to be easily dealt with by developers. When I look at Spring Cloud, there are a number of various subcomponents, right? There's Spring Cloud for basically every cloud provider platform. There's Spring Cloud Dataflow. There's Spring Cloud Streaming. There's Spring Cloud Kubernetes. There's a wide variety of modules or whatever. What are some of the key pieces if you're going to be using Spring Cloud to write apps? And what are, like, maybe just like, why are these the pieces? Why have we settled on this handful of maybe a dozen or two? Sure. Initially, Spring Cloud was a set of interfaces that implemented certain concepts that are common in distributed systems. So service registration and discovery, distributed configuration, circuit breakers, and some other strategies for dealing with failure in the cloud. And as we progressed, things expanded. So Stream is, with Spring Boot, it's fairly easy to have a HTTP-based service using Spring Framework and Spring MVC or WebFlux, and you get a simple application. So Stream brought message-based services in a simple manner. And then taking that concept even further, Dataflow is then, okay, now that I can create these little independent consumers and or producers of data, now I want to create declarative pipelines of them.
8:17How should my data flow through a system? And it very much looks like a Unix command line. This piped to that, et cetera. And that's what Dataflow is. So it's a higher level, even above Stream. Okay. So basically, I mean, it's a collection of things basically to kind of, I don't know if automate is the right word, but to make it easier to solve some of these inherent issues you run into when you're building a distributed application, which is any sort of microservice or most cloud-based or cloud-native, quote-unquote, applications, right? And then the other bit that you mentioned is integration with cloud providers and infrastructure. So there are projects that are run by some of the top IaaS providers. So Microsoft, Google, Alibaba, et cetera, all have projects that are target Spring Cloud and allow. Some of them have implementations for Spring Cloud Stream, Discovery, Service Registration, or different circuit breakers and things like that that they implement, as well as Spring integration with their services, whatever those may be, you know, implementations of databases or messaging or whatever that is. All right. And this might be a very naive question, but if someone who is new to the Spring community and just getting started, like when I look at a Spring service, let's say around Dataflow or Streaming, how does that compare with, or how does Spring work with other services designed to do things like that, like a Kafka or a RabbitMQ or any of these other, let's say, streaming or... Well, that's usually the beauty of Spring as well, is that they typically have an abstraction and then implementations for various providers of that abstraction. So Stream has binders for both RabbitMQ and Kafka. And so your programming model doesn't change.
10:17In fact, Mark Heckler, who is one of our developer advocates, he does a talk about Stream. And in the middle of the talk, he switches one service from RabbitMQ to Kafka. It's listening to Rabbit and then outputting onto Kafka, for example, within a few seconds. So very nice abstractions so that your programming model doesn't change, even if the underlying system that you're using might. I tend to spend a lot of time looking at customer stories and whatnot. And a lot of times it's, we need to get something up and running ASAP or change something up ASAP. And Spring always seems to be the first order of business there, like in terms of, like, yeah, we just need to switch from one model to another. Well, you know, there was a huge investment in Java EE, but I think enterprises, so there are lots of competent developers out there that are comfortable in Java, that they're already using Spring. And as they move to something that benefits them, whether it's the ability to deploy more often, to have automated pipelines to test things, you know, whatever the case, microservices they want the teams to deploy independently, whatever the reason there is for changing their organization and changing their architecture, Spring and Spring Boot and Spring Cloud allow them to kind of have that warm, fuzzy, that they're still competent in all these things. Because now we just have a different model of deploying and consuming services. So I think that's really, really beneficial. And if they want to get into alternative languages, even like that feel, Java sometimes gets a bad rap as a language, which it's evolving and that's very, very good. But with first-class support for Kotlin, for example, you can get that modern language feel and everything is supported still. All right. I see this debate pop up every now and then.
12:19I say this specifically because there's a service, Spring Cloud, Netflix, which like you mentioned, Circuit Breakers, and it brings in a lot of these sorts of features that Netflix helped to popularize and then open source eventually. And this debate is like, well, most enterprise developers don't need to be Netflix engineers. So the logic being ergo, why do they care about any of these things? But on the other hand, like these are valuable patterns and valuable things. My argument is you probably should care about these things. Whether you need to do them on Netflix scale is another story, but like they're valuable. Yes. Like the scale of whether it's Netflix or Facebook or Google or whatever, Twitter, whatever internet darling you're looking at, not everyone deals with that. There are certainly enterprises that do. I mean, whether that's financial institutions or big box stores or whatever, that they do need that scale. But not everyone does. But if they have independent teams and want to deploy independently, they change architectures, microservices. They might not have hundreds of instances. They might have 10. But the problems are still there. You may as well. Like one thing that Josh Long says, it's like you're pair programming with the spring team. You don't have to come up with this all on your own. There's lots of experience going into not only the downstream libraries from companies like Netflix or HashiCorp or Microsoft or Google or whoever, as well as the spring team in integrating those and doing it in a way that's easy to consume and hopefully easier for developers to understand. Yeah, I think the idea, too, if you can do this with a line of code or a flag or something, it's worth it, especially as you were dealing with a distributed application where stuff could go wrong.
14:19And I think that's the thing, too, that gets missed out on, is something like a lot of what spring does is it's basically very simple commands to get this stuff integrated and functioning within your application, correct? Yeah, so you go to somewhere like a spring initializer, start.spring.io, and you choose the pieces you want. It automatically creates a skeleton project for you, and you can get up and running pretty quickly. For a long time, we were asking, well, okay, cloud computing is a thing, but everyone's just running the same types of applications. When is this going to start to change? And I think the answer is now and probably over the last several years. But still, for a lot of people, it needs to be easier than this big engineering project where you need to build stuff from scratch and DIY everything. The easier you can make it to run, I guess we would call cloud-native applications, the better. I think there's always a, do you need microservices? Will a monolith work for you? And I think the answer is yes. For certain situations, those are just fine. I mean, the principles in how you organize your monolith and how you organize your microservices are still similar. You want a well-organized monolith, even if you're not doing microservices, for example, and don't need some of the things that Spring Cloud provides because you just have a single application that you're running. And then finally, Spencer, I want to ask, so much naturally of the Spring conversation focuses on developers and why developers should care about a new Spring. Is there a rationale for executives or maybe up to the CIO? Why should they care about a development framework like Spring? I'd like to hear from you where it ties into bigger picture items, whether that's modernization broadly or digital transformation or whatever these terms that folks care about are. Sure. I'll start with a tweet that I saw recently, and it was someone complaining about the power of the laptops that some enterprises are buying for their developers.
16:27And through that conversation, someone had done a blog post a number of years ago that moving from a spinning hard drive to a solid state drive, the cost of the drive versus the time saved was in a few days, the drive paid for itself. And just from a productivity standpoint, I see similar things with Spring. Spring and Spring experience is a thing in the industry. You can hire someone with experience using Spring Boot. And that's one of the reasons, actually, that Netflix is standardizing on boot as opposed to some of the custom stuff they did before because they can hire people with the experience already. If they want to do training, we can come in and train them, things like that. And then, and even more recently is the Pivotal Spring runtime, the commercial support for the Spring stack standalone on wherever you're deploying, as well as the JVM that goes along with it. So you get supported JVM and supported Spring projects. So I think you have this spectrum of things from developer productivity to training to commercial support that I think are all well worth it. Well, listen, we are out of time, Spencer. Thank you so much. Thank you for having me. And thanks, everyone, for listening. There you have it, folks. If you're writing Java apps and not using Spring or using Spring and not taking full advantage of it, I hope you learned something here that will convince you to give it a try. And for more information, you can always visit spring.io. For more episodes of this podcast, as well as blog posts and guides to help you navigate the landscape of digital transformation and its underlying technologies, visit pivotal.io slash intersect. That is it until the next episode.
18:27Thank you.