Bio Josh Long is the Spring Developer Advocate at Pivotal. He is a Java Champion, author of 5 books (including O'Reilly's upcoming Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry), 3 best-selling video trainings and is an open-source contributor (Spring Boot, Spring Integration, Spring Cloud, Activiti and Vaadin)
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
I am Josh Long. I am a Spring developer advocate on the technical advocacy team at Pivotal. I work with the community and all matters sort of cloud and Cloud Foundry and Spring and so on. Author of five books, contributed to numerous open source projects, a Java Champion, former InfoQ editor - one of the biggest and brightest feathers in my cap.
Advocating! It's been quite the busy ride, man. As you know, these last several years have been interesting, right? So these last few years at Pivotal, we started this little startup back in 2013 called Pivotal and that is the new home of Spring. So the whole point with Pivotal is that we're supposed to build this platform for this new opportunity, this new frontier optimizing for continuous and safe delivery of applications into production. That is the goal. And it really is starting to come together. Knock on wood but it is really starting to come together. We are seeing a lot of -- I think it is buoyed obviously by what else is happening out there. The front page of InfoQ is basically the tidal wave we’re riding. And so these last few months has just been anybody and everybody I can talk to. They are out there you know. It's just been crazy. I have been on a few planes.
Little bit. Little bit.
Well, so Spring is, as you know, it has been around. We wanted to build a framework. We want to build technology that was optimized for building apps in this new platform. The economics of how we would build apps has changed. Even compared to the way we would have done it 12 years ago with Spring no less. Even that has changed. The economics of how people think about applications, deploy them, test them and then deployment to production, that whole process has drastically changed. So the way you build apps for that new world is different.
Spring is just the most efficient way to build apps but there is this really large picture around continuous delivery. And that is what I think is so exciting is that people are starting to understand where Spring fits in into this larger picture and this narrative is much more -- it is bigger. There is a much more mature ecosystem now. I don't think developers can -- you remember what it was. There were roles. We used to talk about different roles for building applications; it would take seven roles to deploy a standard J2EE application.
Charles: Yes. I can't remember what they all were now but it was like packager and deployer and all of those kinds of things.
And again, I am not taking anything away. That made sense, I suppose, for some definition of sense, at the time. But it just goes to show you how far we have come. That was just seven roles to do with the app.
Charles: Yes, packaging and getting it into production.
Yes. But I mean it wasn't deployment. It wasn't operations. It wasn't database. It wasn't sort of -- there is the whole thing. There is a whole process of before and after that has to happen and now we are looking at ways to short circuit the whole thing into as few people and as few bumps on the road as possible. Before, it was seven different stops on the conveyor belt just for the app. It was just crazy. We are looking at how fast can we go, how fast can we get a concept deployed, get it out there, and then what does the application have to do to support that process.
Spring Boot, if you are asking what is popular in the Spring ecosystem, Spring Boot is this integration of all these best of breed technologies and practices to support that; to support that new role, that new dynamic; and then Spring Cloud is sort of this other thing that builds on top of Boot to support microservices, to support what happens when you move. If Spring Boot is a good way to build small batches and deploy it and standup APIs, Spring Cloud is a great way to manage the complexity that that architecture implies. You've got microservices, lots of small singly focused APIs. You are now squarely in the camp of distributed computing. There is complexity there, right? That is what Spring Cloud manages. It is not even -- the thing about it is, as you know, it is not even all that new. It is just Spring Boot and Spring Cloud integrate all this great stuff.
Yes. The giants of the web, right? Naturally there are gaps. We know that there are gaps in what has been open sourced, what is out there for people to use. We are plugging those gaps but whenever we can, as is our fashion, we integrate the best of breed stuff. We're standing on the shoulders of proverbial giants. And there is a lot of good stuff out there. It is just sort of like each of these organizations, these high performing organizations, a lot of these organizations have taken the stuff that has been good, the diamonds from their considerable many roughs. That's open source now and so we can learn and we can all sort of move together. There is this virtuous feedback.
Charles: That's a massive change for us as an industry. I mean going back to your late 90s early 2000s J2EE server when everything was propriety and people were very reluctant to talk to each other. And now you've got this huge shift where pretty much everything is being done in the open, people are talking about how they're building distributed systems and how they are solving these hard problems. I think it's a really exciting time.
Exactly, very exciting. It feels a little bit -- I hate to use the term but it feels like the Wild Wild West. There is just a lot of like anything is possible hopefully not in a bad way, but there is a lot of opportunity, it feels like. I think it is the economics. It is the new frontier. That is the cloud. That is a really, really exciting place that the economics of how we built apps before are gone. In fact, new languages have come to life since the way we would have built apps ten years ago. So things like shared dynamically linked libraries. Again, that made perfect sense when you're trying to save space on disk and so on. But now it is more trouble than it's worth. Languages like Go don't even have that and you see that at the micro level there but at the macro level it is even more profound how that impacts your architecture. It's Java. We just celebrated 20 years of Java and yet I don't feel like -- the language is still boring but the JVM and the community are as vibrant and as exciting as ever which is good. You want a boring language in a vibrant community.
Charles: Absolutely. Absolutely. So if you are building a microservices architecture with Spring today, what are the bits that make that up? You’ve obviously got Spring Boot as your main development platform and then you are deploying those as JARs I guess.
Yes. Going back to that statically linked assembly idea versus shared class path, we are seeing a lot of developers. We are seeing a lot of organizations. And this is not new even before. Organizations are looking for ways to certify what they have got and then move them into production and to rest assured that what they've tested, developed on their machines, and then in Q&A is exactly what they get in production. I have seen, and I am sure you have seen this, I have seen enough organizations you go into their organization and you say, what are you doing? Well, you've Tomcat. Tomcat is pretty popular. They have got server.xml, the configuration file for Tomcat baked into the code, sat in their GIT, and version controlled with the code because they have things that are unique to the configuration for that app and they're certainly not deploying more than one app per container per Tomcat. They want one app, one Tomcat. And the reason is because they want the isolation. They are not trying to save the RAM of running multiple apps adjacent today. They can run as many Tomcats as they need till the cows come home, right? The cloud changes the economics behind that.
So they are much more interested in guaranteeing that what they have built is what is deployed and what they have tested is what is deployed, instead of having side effects creeping in from class loader issues and sharing the same memory space and all that stuff. So you see server.xml checked in the version control. Or sometimes I've even seen organizations chuck the whole Tomcat distribution into version control, which is pretty disgusting but you understand why. I mean they are just trying to guarantee that what they have tested is what they have got. This continuous delivery, they want to bake it and deliver it all the way through the pipeline.
I think that is the smell. The economics of yesteryear- said, well, we want to have a central management place. Well, that does not exist anymore. It is the cloud. It is not going to be a single container. And then we want to share wherever we can including class path. Well, it is a terrible idea. I don’t want to share a class path anymore. That's the last thing I want to do. I want to keep it nice and isolated.
And so the surface area, we are trying to reduce the surface area of what can change from one environment to another. That is why you see people moving to cloud platforms as well; it’s where things like Cloud Foundry or even Docker. It is sort of how can I lock up what is the known definition of my app and then promote that all the way through. So the natural reaction to that in Spring Boot and indeed other technologies like Play and Grails and Drop Wizard and so on: use a JAR. If you need a web container, if you need a web server to stand up a web end point, great but it is just an HTTP engine. You just stand it up and it will listen to the right port. You don’t need to deploy the code into a container. Just stand up the engine. It is just a library at that point. It is all about reducing that surface area.
Charles: So what you doing essentially is you are looking for patterns that allow you to move faster, that allow you to develop faster and get stuff into production more quickly.
Yes. The faster we can go the better. It is all about velocity these days. My friend Andrew Clay Shafer, he likes to say you are either building a software business or you are going to be beaten by somebody who is building a software business. And that is true. We have seen all the disruptive companies out there. They are all software first. What is the largest taxi company? Uber, naturally, right? And what is the biggest video rental company? Netflix, right? I mean these are software first companies. That is how you disrupt. And if that is true, then he or she who delivers software faster hopefully wins.
What can we do to deliver software faster? We are finding that there is a feedback loop that has to happen. We know this and we know that if you gate that movement of code from development to production, if you gate it with all these different throttle points, conveyor belt stations like in manufacturing, you get waste, you get inventory. So we have seen that and if we have empathy for operations and sort of collocate operations with developers, you get increased velocity because at least in that little cycle you go faster.
Well, now we see if you take that whole systems thinking, that empathy, even farther make it bigger start with product management, UX, developers and operations and all the operations people after that and testing people, collocate them all, and think in terms of small batches, small features, you get microservices. That is a feature team. Netflix talks about that all the time, small feature teams instead of having different stations where you have all this work that flows. It is a feature team. Two pizza box team. And the whole goal with that is to take an idea, develop it, polish it off, move it through testing and then get into production without having to wait for a whole massive titanic code base to stabilize and get shipped. The faster you can move through that loop, the better you can get responses, the better you can get feedback and that is what microservices is. So what we are doing right now with Spring is we are trying to help people go faster. It seems that microservices is a very common way to do that, but of course when you start doing small batches independently deployable code that implies distribution.
Distribution is hard, right? Let us not pretend it isn't. It is way, way harder to create a distributed system than it is to create a monolithic app. So now you got these patterns and you got these things you got to address; these non-functional requirements that are going to wreak havoc in your life. You're going to make your life miserable if you don’t address them up front. And so Spring Cloud tries to commoditize or codify those patterns as best practices for dealing with distributed systems. Is it easier than a monolith? No, nobody ever said it is but you do get the ability to go faster and safer.
Charles: So give me some examples of some of the kinds of patterns that you are standardizing in Spring Cloud.
Oh, boy, again centralized configuration, things that have to change from one environment to another. Good cloud hygiene. Twelve factor apps. We talk about that all the time. Good cloud hygiene suggests that you should externalize configuration from your application. Spring Boot sure supports that but there are some use cases that aren't well served by just environment variables. How do I centrally change or update configuration? How do I version configuration and roll back if something should go wrong? How do I encrypt or store passwords at rest encrypted and then decrypted symmetrically, that is to say in a single place and then inflate decrypted in the client? All these things, they call for a little bit more than just twelve factor apps configuration. We have a configuration service. What about service registration discovery? How do I decouple the information about what is the state of my system, the topology of my system from DNS? Because DNS hides and masks information like which instances are sick. How do I do client-side load balancing? Your FI router is going to do basic round robin load balancing but if you've got anything beyond that, you are going to need something on a client. It is even better if it is on a client. If it is on the client, then you can check it, you can unit test it, you can version it, you can deploy it. So you see that. And of course there are things like the Netflix Eureka we support, Consul, ZooKeeper, ETCD I think is on the pipeline you know.
What about messaging? REST is a great way to read data but in a distributed system when you want to do state synchronization, you might reach for something like distributed transactions but that is a terrible way to run a railroad. So how do you do state synchronization? Well, eventually consistency. That usually implies messaging and then from that you get things like CQRS or actors. So we have support for that as well. There is how do you do a single sign on if you got more than one service? Sure security is not so bad if you just have to do it once but if you got ten services or n services, how do you protect them with a single kind of token and then do that cleanly and easily and consistently?
What about distributed tracing? If you got more than one node, one node should call another and another and the second one should fall down, how do you correlate the request that triggered the accident, the problem? We all know what that basically looks like. You have a UUID that you propagate from ingress and egress points in the services but it is boring, boiler plate work. You don't want to write that code. Nobody wants to write that code. So you can use Spring Cloud's support for -- we have an abstraction called Sleuth and we have an implementation with Twitter's Zipkin. I mean the list goes on and on and on. Cluster management, leadership election. In a distributed system, not all nodes are always created equal.
There you go. Circuit breaker patterns. There is a great speaker, Fred George; I am sure you have had him here at QCon. He gives one of my favorite examples. He likens the human body to a microservices system and he suggests that it would be preposterous if when you cut yourself you blue screened, right? You need to degrade gracefully, naturally. So in a distributed system, we know, we just know in a sufficiently distributed system high availability goes down to zero eventually given time. And instead, you must optimize for time to remediation, how quickly can you recover, how quickly can you fail over? And so a circuit breaker gracefully degrading, that is a very, very important thing to do in a distributed system.
If you can move a system to remediation to zero - if it takes zero seconds to remediate - you're effectively 100% highly available. But it is a different way of thinking. There is just a lot of stuff here. It took me a long time just to say those sentences and that was super, super high level -- I mean imagine the code that you have to write. So that is why what you were talking about earlier, all these organizations sharing ideas and sort of iterating on each other, this is really exciting. So Spring Cloud pulls it all together and we are following all this excitement. We hope people will use it. We have a platform called Cloud Foundry but Spring Cloud works on anything. It doesn't just require that. But they are part and parcel. If you build these kinds of apps, you're going to need a platform somewhere. It doesn’t have to be ours of course; it can be anything. But I think the cloud has enabled people to see that there are these other patterns out there.
Charles: Give me some examples of the companies that are using Spring Cloud in production today.
Well, there is a small video rental company here in the Valley called Netflix that is using it pretty extensively. I have spent some time with some companies in China. Baidu and Alibaba, they are both Spring users, and they, sort of independently and on their own. Indeed actually with Alibaba, they are a huge company, huge, huge, huge, enormous, bigger than Walmart in profit. I mean they are just crazy and they have several different verticals each of which is very -- they sort of like they have their own PayPal, they have their own Amazon Web Services, they have their own eBay and Amazon.com kind of thing. They are not alikes but it's easier to compare. These organizations, these verticals in Alibaba itself all sort of standardized on Spring years ago, years and years and years ago. But they had to layer on top of Spring support for these distributed systems' problems naturally in order to be able to scale, just as Netflix did. Netflix has been using Spring for a long time as well but they've had to layer the stuff on there. And I was really excited. I got to go visit them again this year and say, "Look what we have done. Look at what is here now." You can rebase. And they are excited because they can take that layer of code they are maintaining. Sometimes they even within Alibaba, for example, there are different organizations. They had Spring and they had different solutions to the bits on top. So yes, it has just been really amazing.
Ticketmaster, they sell tickets but they are huge scale. They have moved to Spring Boot and Spring Cloud as their platform. So yes, a lot of people are really excited about this because I think most of us knew this stuff was required. We just didn't know how to get there. Now it is definitely doable. I mean obviously we're still dealing with distributed computing. There is no free lunch here but it's nice to know that at least there are pointers in the right direction so to speak.
Charles: That's great. Josh, thank you very much.
Well, thank you. Thanks for having me. A lovely show. Amazing. Just great community. This is the crème de la crème. Of course I am super honored to be here. Thanks for having me.