Injecting Cloud-Native Thinking Into Java With Spring Boot

August 6, 2015 Coté

 

sfeatured-podcastThis is a two part episode on Spring Boot and Spring Cloud. In the first part, Josh Long and I talk about the Spring Initializr and Spring Boot. We discuss the idea of doing process-based design (a key part of cloud-native application development) in Java and how Initializr and Boot help with that. Also, we discuss how Boot can help with more governance and controls, while at the same time giving developers more autonomy and speed. Also, we talk a bit about China.

PLAY EPISODE

SHOW NOTES

TRANSCRIPT

Coté:
I was reading some of your trip notes recently, you’ve been traveling around and I saw something that I thought was a funny joke of yours, I forget which city it was in China but you’re like, “Oh, I went to this adorable city, it was only a little bigger than New York. It was super cute.”

Josh Long:
Adorable, amazing. It’s not even in the top five, I think that was probably Shenzhen, not even in the top five biggest cities in China but it’s like 15 million people.

Coté:
Yeah, it sounds like the people over there are interested in programming. They are asking you all sorts of very detailed questions and things like that. That’s delightful.

Josh Long:
I love China because right now they have this huge opportunity, which is even within the borders of their own country, it’s a huge, huge opportunity and if they win there, they get to be number one in the world, just by winning in that one country because it’s so big and then they have to do it quicker so there, a lot of these companies, a lot of these organizations are looking not to reinvent the wheel, you know? Google, for example, had to … They invented the wheel, the proverbial wheel for scaling to that kind of size but every company after that one should not have to do it, right, if there’s any kind of precedent, any kind of existing code.

In China, they have been very, very, very smart. A lot of these big companies, in order to succeed and to go fast, they’ve taken really, really good stuff, like Cloud Foundry, for example, and Baidu and Spring also at Baidu and Alibaba and so on. They’re just building on top of that. They’re plugging in these pieces that are tried and true and tested and they’re delivering and why bother inventing Hadoop when there is already Hadoop.

Coté:
Yeah, it seems like most of the places you visited, they have in a good way, all the same problems, right?

Josh Long:
Right.

Coté:
They have large scale and so the stuff needs to work but they also need it to be manageable but both from a software developer sense of “We are not developing our own unique thing but we’re using normal, standard stuff, and then also, we can actually run it in production at a large scale.”

Josh Long:
Right, the maturity is much more important for them than not invented here. I’ve got to tell you, I have this feeling that if it’s more than a week old in the West, I think we sometimes feel this itch to reinvent it.

Coté:
Right.

Josh Long:
It doesn’t seem like a great reflect but in China they have this very grounded sort of “Let’s just look at all these people, all we’ve got to do is deliver. Let’s just go faster. Why reinvent?”

Coté:
Yeah, and I think you see that reflected in regular IT, in real world IT where there’s still people who want to reinvent their own stuff, the wheel as you call it, but there’s also people who … and I don’t necessarily think this is bad but especially since we have Spring you go and visit with them and like, “Oh, yeah, we’re running [Apache] Tomcat in Spring,” and then they almost speak of it in like a guilty way when in fact …

Josh Long:
Good for you.

Coté:
They’re not following shiny objects of the year, let alone the week or whatever.

Josh Long:
Right, exactly. Here’s what works.

Coté:
I think what’s valuable for them is they’re not necessarily interested in developing infrastructure software, right. They’re just … and this is … It’s been a long time since I programmed but that was the nice thing about the Java community is it was … and to some extent still is, but way back in the early 2000’s it was pretty fast that in a good way, regularizing and commoditizing best practices. That was almost a thing that the Java community … I don’t know if invented, but perfected …

Josh Long:
Right.

Coté:
Like the idea of “Here are the best practices and ways of doing stuff and if you’re not doing those, you’re wrong.

Josh Long:
Yeah.

Coté:
That was an annoying part of it but it resulted in a lot of stability.

Josh Long:
I liked and I still like, the thrashing that is then quickly followed by a settling of dust and then moving on, right? There are alternatives, for example, to Hadoop but there were infinite options in terms of web frameworks for the JVM back in 2002 and 2001, but again now we’ve all … At the time we coalesced on struts and now it’s by far, it’s bring MDC and on, again, the wheel, the wheel is fine, keep moving. We have other problems to solve.

Coté:
I thought it would be fun to finally get you on the podcast here. I was reading an excerpt from a book you’re working on about … I don’t know, how would you characterize it, before I do?

Josh Long:
It’s a book for … I want to put down recipes for building the kinds of things that we hear or discuss in abstract ivory tower kind of terms, otherwise, right, these theories, these patterns for building Cloud-Native Applications. I feel like the Pivotal Stack is the ultimate stack. It is the recipe you need at every layer for these kinds of applications. Let’s write about it. Let’s talk about it and there’s a … I have a fear that as soon as I link to Kindle this is going to be out of date but on the other hand, it will be nice to have a cohesive thing and I’m willing to upgrade it and update the book as necessary and we’ve got just this amazing, amazing opportunity in that.

I feel like finally at Pivotal, we have this crazy, crazy good stack. I mean I don’t have to tell you, obviously, but we have this really, really powerful stack and people love different parts of it. I mean individual communities, whole sub straits of the IT community, the technology community love, with like a cult-like affection.

I mean crazy, crazy inspired, passionate people love individual sections of this technology stack and now, last year, I’m sure you’ve noticed as well, it’s all really, really started to come together. It’s started to really gel and they work together. You don’t need one to build, to benefit from the other, for example, I think there’s this commentarial effect and that’s the genesis of this book is I want to be able to light that pathway, light that road.

Speaker 1:
Yeah, I think it’s been about six months now that I’ve been here.

Josh Long:
Welcome.

Coté:
Yeah, even in that short time there’s been a huge amount of growth in that overall Pivotal Cloud Foundry stack, if you will, and I was looking at some charts of various Spring usage downloads, too, and those have been skyrocketing and that’s like the main thing I wanted to go over, are basically Spring Boot and Spring Cloud which have … True to what you’re saying, again, over the past I would say six to 12 months or so, I often see them being at the center of the style of development, the Cloud-Native style I guess …

Josh Long:
Yeah.

Coté:
That Pivotal do with Cloud Foundry and I think when I started on back in January, we sat down and you gave me an exciting quick little demo of a couple of them and, anyways, I mean you’ve also been traipsing about talking about them and with your pun-fulled title of the presentation you give, that’s also always nice. Why don’t we start with those two things, first of all what … Are those two projects the same thing or related to each other? What are those two things?

Josh Long:
Right, before, to anybody who’s listening, start that Spring.IO, that’s where you should go, bookmark it, read it to your children, keep it under your pillow. It’s an amazing little website, just go there, there’s a … It’s a dashboard where you can find all sorts of checkboxes, lots of checkboxes and every style as long as it’s that one style that the browser provides. You click the checkboxes, hit generate and you get an application.

Some of those things that you can specify, for example, I want to build a web app or I want to build something that there’s batch post seeing or integration or whatever, those are concerns for building applications, single applications and services, building a REST API, for example, is something you’re going to care about if you’re building a single service and then other checkboxes on there are about non-functional requirements, things that will plagued your efforts, frustrate your efforts to go to production if you don’t have them and we want that to be part of the package, right, so we’ve got those as well.

Then part of those checkboxes are things that are going to be more necessary as you start to scale out and build an micro service system, a distributed system and again, in that world, you have complexity that’s incumbent in having distributed moving pieces and that complexity necessitates also non-functional requirements as well. Part of those checkboxes are things that address that space and that’s why I think there’s maybe some confusion is some of those checkboxes are Spring Boot and some of them are Spring Cloud but in that Spring Cloud, builds on top of Spring Boot.

You don’t really have to think too much about them. They work the same way. They layer on top of each other but they are definitely distinct … They have different domains.

Coté:
You’re like selecting your needs, when you go there, right.

Josh Long:
Yeah, ala carte, absolutely. Yeah, you go shopping, right. You go shopping and say, “I say need to build a web app that has a REST API and then I don’t need the rest of this …” This is not like a Ruby & Rails where when you generate an application, it assumes that your app, your application or service is going to be of a certain form or shape, right. It’s you pick the piece that you need and nothing more and you use that. This is not like, Java EE, where your app is going to be assumed to look like a certain shape as well, right?

You pick the piece that you need or the pieces, they compose well, of course, and for Spring Boot, you may want to say, “I’m going to build a REST API. I’m going to talk to a database. I’m going to pull in security and I need to also handle reporting and metrics management and health endpoints and things like this.” Those pieces, they come together and you get an application that is now … You can pull together the code. You can actually build an application pretty quickly, but again, you don’t actually have to deploy or manage or think about more than the pieces that you need.

So you end up with these really small applications which as you can imagine, lend themselves to the cloud, right? Lend themselves to a managed environment and in fact, now we’ve got it to the point where that little application is Java minus Jar.

Coté:
I mean, so essentially, you go to that page or as you have set up and it’s as much about building up all the things you need as it is carving away the things you don’t need. It reminds me of … I saw someone Tweeting the other day that like, “Why do I have the Cups Drivers in this image? There’s no printing in the cloud.”

Josh Long:
What even is the cloud?

Coté:
Exactly and the other part that I find interesting about that is presumably … Actually, I’m trying to remember who it was but there was, it was one of our customers who was talking about they had customized that wizard, if you will, to work internally.

Josh Long:
Right.

Coté:
They pared it down to what they wanted to offer internally and then it … As long as the developers and teams of developers go use this selection of services, it fulfills the contract that the company’s IT department can run it …

Josh Long:
Right.

Coté:
Have fun with that.

Josh Long:
Right, and that seems … Oh, so many, so many points on that … I just talked to a senior architect recently at a large $200 billion plus commerce shopping company that … Maybe that number whittles the list down a bit, that’s the market cap in dollars … This is a huge company and they have as you can imagine, a huge fleet of developers and that fleet of developers is, same kind of thing, they’re trying to deliver services and they have a need to build, to deliver quickly and iterate quickly and iterate quickly and so what they’re looking for is a common … They want to constrain the shape of their services but within that shape, they can do all manner of things.

They want to take that same wizard, which by the way is open source, it’s GetHub.com/springio and it’s called the Spring-initializr without the penultimate “e,” right, the penultimate letter. Just initialize ZR, right. You can actually clone it, tailor it, and then deploy it yourself and it runs very naturally on, for example, Cloud Foundry. Yeah, we see that a lot and people are trying to … They’re trying to take that as like just “Start here experience,” and then Spring Boot itself, provides this really, really great component model and you can use it to stand up things by convention.

You can say, “Contribute this definition,” suppose my services all need to do security in a consistent way, right? They all need to talk to the same identity provider. They all need to talk to the same whatever it is. Maybe it’s Author or SAML or LDAP or Active Director, whatever that thing is … I’m going to use the word “enterprisee” but you can imagine the infinite, myriad possible choices there. Spring security can invariably talk to them and getting that configuration right is hard enough one time. You don’t want to have to repeat that.

With Spring Boot, it’s very natural to define that configuration and say, “Okay, every service is going to need this wiring. It’s going to need to know how to talk to this thing,” and you can describe it, put it in a jar, package it and then create a file called Spring.factories which has a one line and that’s the line that tells Spring Boot where to find this auto configuration Java class. That Java class when the Spring Boot app starts up attempts to contribute all these objects that you’ve wired together to the working application.

You get this consistent running image. You get security. Maybe you have health end points that need to be exposed a certain way or maybe you have a certain framework speci— Maybe you only want certain types of templates or you only talk to this data source or whatever that is, you can package that up, get the formula right, once put it in a jar and then your organization, they can go to this start.spring.io, you can tailor it, customize it or indeed add custom checkboxes and so on.

They pull down their custom auto configuration jars and things just work. Public static void main, one line, they start up the app and you could have an organizational centric frameworks in place. You could have security set up a certain way. If you’re doing, if you’re in a large organization, you may have a PCI, this is something where it’s really, really tedious and you don’t want to have to reinvent that wheel every single time and I’ve seen customer after customer they have this giant, crazy Wiki page that if you printed it out, I’m sure ran 20, 30 pages.

Here’s what you need to do to create a new service, right, and this thing is the bane of every organization’s existence because they’re trying to move fast but they’re bogged down by all this process and you don’t begrudge them the process. They need it to be compliant with the … Whatever, right, regulation, the architects, whatever that stress is, that pressure but it shouldn’t be so painful. Spring Boot gives you a way to describe that, package it up and not even worry about it. It’s just on the cause pack and you’re done.

Coté:
Let me …

Josh Long:
Yes, sir.

Coté:
Attack’s the wrong word … but let me attack this from a few angles here.

Josh Long:
Sure.

Coté:
This last thought we went over there. It seems like … Correct me if I’m wrong here but it seems like a lot of what Boot does, one way of thinking about it is if you go and look at the old 12 factor application stuff.

Josh Long:
Yeah.

Coté:
Which I think I’ve read that thing 15 times now and it keeps getting stranger every time I read it, not in a bad way but it’s like … That stuff is almost to the incipherability of poetry at this point versus Boot’s, but one of the substrates in there that you notice is there’s a lot of emphasis on how configuration is handled, right?

Josh Long:
Right.

Coté:
If you slice together a bunch of the stuff, I don’t know how you slice things together but if you pull together a lot of the things, a lot of how you were describing Boot works … It’s 12 factor things are trying to get you to do that, which is to say and for Spring people this is like, “Yeah, welcome to the party, but you’re basically injecting configuration at run time or … and that run time could be production or development or whatever but you’re essentially delegating as long as possible configuring something or actually having state.

It seems to me a long time ago, as I should avoid saying back in my day, we liked to do this to enable testing. It was really hard to test things and if you could extract out configuration, it meant that you could stand things up and test them quickly. Now in our cloud era, that kind of configuration injection, I don’t know … Late binding or whatever …

Josh Long:
Right.

Coté:
Is really handy for the way that you just manage clouds and production, right.

Josh Long:
Yeah.

Coté:
You keep your application as ignorant as ignorant as possible and then inject the configuration as needed.

Josh Long:
Right, de-coupled and I should …

Coté:
Yeah, and then the other thing it gets you is you can check that configuration in, right?

Josh Long:
Right.

Coté:
That configuration becomes part of your project and then with the right kind of run time, which also sounds like Spring Boot does and also if you go full blown and start using Pivotal Cloud Foundry to run it, then you have a whole system that manages all this stuff for you and can start to run it for you, but it seems like a lot of it starts with having a system like Spring Boot that basically combines together an executable for you and basically handles all the initialization and configuration without it being a manual process and creates the contract, if you will, for doing all of that.

Josh Long:
Right, and actually, we just talked about configuration and I should know better. I even put together a blog about this that the curious could find, I’m sure on Spring.IO blog, on 12 factor wrapped style configuration versus what we commonly talk about when we say configuration in the Spring world. There’s two kinds of configuration, there’s a things have changed from one environment to another or these are … This is the 12 Factor wrap style configuration, right, 12 factor.net/config, database locators and credentials, and ports and host names, these kinds of things are things you want to keep external to your code, right?

Of course, the example they gave in the 12 Factor post on that is if you were to open source your project right now would anybody discover your passwords? And that I think is a good litmus test. Spring of course does support late binding of that kind of configuration. You can externalize it from the application and provide it however you want. There’s all sorts of different inputs and … but they all end up in a canonic biased format and your Spring app is aware of that but also, referring to the …

Speaking to what Spring thinks about when they say the word configuration, you can also wire together objects and you can make the decision as late as possible, just like you said, about for example, where those objects come from. Right, I can say, “If I’m in this environment, I expect to find my data source,” for example, “Cloud Foundry by teasing it out of the environment variables,” but if I’m running on a Legacy application server, then perhaps, I might need to look it up inside of JNDI.

Coté:
Right.

Josh Long:
That decoupling gives you portability and that makes it very, very natural to move one application from a Legacy environment into a more modern environment like Cloud Foundry which gives you more, gives you a lot more operational support there, right?

Coté:
Yeah, I hadn’t thought about it in that angle but it does … Like in the excerpt of the book I was reading, there’s a lot of discussion of moving from older ways of doing things … What we would call in the Cloud Foundry world, backing services or whatever.

Josh Long:
Right.

Coté:
To some extent, it’s interesting to think that if you have this way of introducing your configuration at run time, it’s not like it’s easy, but it’s easier to swap the data sources that you might be using, depending on where your application is using and what stage of the life it’s been, right.

Josh Long:
Right.

Coté:
I mean inevitably, you’re always like you’re going to screwed by the class loader at some point, but whatever.

Josh Long:
Hopefully, not, right. I mean …

Coté:
Right, right, I mean when dealing with Legacy code, that does depend on things as you were pointing out in that excerpt there but that’s another valuable thing of extracting the configuration and doing this late binding is if you’re doing rolling updates or something. You might be running kind of the same application code but it’s using different backing services that might be updated on different intervals so they need to be able to configure differently, to talk to different data sources or just middle ware or whatever.

Josh Long:
Right.

Coté:
It gives you more flexibility and then another thing I was thinking about is as going back there is I think for the developer oriented, a word like “governance” is always like a bogeyman word. It’s like the man telling you what you’re going to do but the other thing that having the initializr and then Boot and then also the broader controls that something like a Cloud Foundry gives you is if you’re the ones responsible for making sure the applications come up and stay up and running, you have a certain amount of control over what that configuration is and whether you want to restrict it or just change it over, it’s a lot more than having the mystery meat of some build that comes over from develop …

Josh Long:
Right.

Coté:
That you have to spend a lot of time looking over and analyzing and making sure that it conforms to policy, right. I mean it’s probably still … It’s still a good idea to actually look at it instead of just blithely pass it through unless you’re really highly functioning but you know what, I think that gets to another thing that I think is useful for people who want to … I don’t know … to use the business term, increase time to market. They want to deploy faster, is if you want to deploy faster, you need more governance.

Josh Long:
Yeah, absolutely.

Coté:
You need tools and things in place that allow you to enforce governance instead of just having like an anonymous black box zip file, masquerading as an application.

Josh Long:
Right, and that’s what I really like about Spring Boot is it gives you the … I think through the developers perspective, here’s what I’ve … The developer perspective is every developer imagines that their app is going to be the best app ever and it’s going to be a snowflake but that’s because it’s a work of art and nothing else has ever come before or after … and they balk at the idea of having constraints, right? I think a lot of that tension is not actually because of the imposition of certain things into the code base. It’s more about the complexity involved in the cognitive complexity, the extra weight that having to understand and maintain all this stuff imposes.

With Spring Boot, this is not about config— I mean with Spring Boot by default, hopefully, you write no code and you just get useful … You add a type to the class path and you get a health end point, for example, and the health end point, the actuator is a library, it’s a dependency that you can add in your Java, Maven or Greater Build. When you have that in the class path, it automatically stands up, health end point and in an ENV endpoint and a metrics end point and a trace log that shows you all the requests that have been made into the app and these are things that when you operationalize an application, you’re going to care about it but it’s not fun.

Nobody cares about … Nobody gets promoted for writing the best darned health check … Can I say darned?

Coté:
Of course, darned.

Josh Long:
I don’t know.

Coté:
Because you wouldn’t want to have to go buy new socks.

Josh Long:
Right, yeah. Nobody gets promoted for writing that health check, right. Nobody gets tapped on the shoulder saying, “Good job, you really delivered there.” That’s boring code but you’re going to need it and it’s going to be required in your operations teams, if they’re separate and certainly the team will work on it. If it’s not separate, if you’re doing dev ops, these are things that you’re going to care about if … app in production.

Having the ability to describe that ones, package it, and not have to worry about it, just add a jar and then not touch any code, yeah, it … Operations teams, the operational side, the governance side, they love that, right? They love that I can … That they can say, “Here’s the minimum of things that we need for this app to be able to exist in our ecosystem and for it to be something that we can manage and audit and so on.” Then from the corporate perspective, since it’s less code and you don’t worry about it, it feels like a tabula rasa as well, still a blank tablet.

Coté:
You were saying, so Boot spits out a jar that you can run.

Josh Long:
Right.

Coté:
An executable unit and so do people commonly just run that unit as the whole application or are there other ways that they take that and run it?

Josh Long:
Right, we have a new feature. Okay, there’s a couple of answers. First of all there’s Java minus jar. When you use the default settings on start.spring.io, if you go to the start.spring.io, you’ll have an option. You’ll be confronted with a choice. “Do I want to build a jar or do I want to build a war?” and the jar is … The jar is just that. It’s Java minus jar. It’s a so called Fat Jar in that it contains all the dependencies that it needs inside of it so you don’t even have to muck around with fiddling with the class path or anything. You just say Java minus jar … My jar, not jar and you’re done.

It’ll start itself up and you can configure everything in there and I mean, literally everything. You can configure, for example, G-set compression or SSL termination or whatever. I mean things that you would traditionally associate with the container. Those concerns are now expressible and then configurable within your app and the reason we see this, the reason we’re so keen on this approach at Pivotal is because as often as not, I’m sure you’ve seen this a million times.

You go to an organization and they have these concerns. They say, “Oh, well, my app needs to have G-set compression and it needs to be enabled for this port or it needs to be enabled for these paths. These are things that you have to configure in the container. They’re not something you can describe at the very least in classic Java E. In that world, you can’t describe them at the application layer and so you end up having configuration files. By that I mean XML config descriptors or deployment descriptors.

Coté:
Right.

Josh Long:
Checked in, into Git, into the version, collocated with the application itself. Sometimes I’d … Not sometimes … Far too often I’ve seen entire Tomcat instances checked into the code base and the reason is because these companies are trying to move quickly and they’re trying to … They want to guarantee that the version, that the container which has these concerns, that their application cares about is versioned and that it gets, they can control those configurations, those things.

They check the whole thing. They check the whole thing into version control and then manage that and that way they can guaranty that the one that’s run is the one that they described, build, and baked and then deployed, right, and of course, this is something that’s … It’s a natural tendency if you’re trying to do continuous delivery, for example, but it is kind of a smell, right?

If I’ve got my entire server checked into my code, my application and the goal, eventually, ultimately is to deploy my application into that server, that feels like there’s an asymmetry and a lot of times, you see applications, you see one application deployed to one container, one Tomcat and I know what we were all sold this idea that you should be deploying lots of different apps to one server, one container, right. I’m sure you remember this idea that you could manage and deploy and isolate multiple applications to one application server but really, that’s very rarely often the case, right?

Your application server can’t guarantee you isolation in terms of actual … I mean memory is a hard thing to get right with class loaders. It’s even harder to get right unloading and loading applications is … Hasn’t been provably reliable ever for the JVM and when it comes to isolating other things, like hard discs and security and process based environment variables and all that, you’re just … You just don’t have any hope for that. What you want is to let the operating system do what it does best, right. It can provide you all that isolation.

I see, more often than not, I see one application to one container and then they version control that container so that tells me that there’s something wrong. These two things are … Traditionally, the operation side, maybe that’s the same team now, but historically that would be a separate team, they would manage the configuration of the container and then the developers would manage the configuration of the app as it would live inside the container.

Invariably, the application that one person, one might express or control or … Change that configuration so they check them into the same version control. That’s the smell, so with Spring Boot, we provide the ability to just … You’ve got a jar, you’re done, and the jar stands up the embedded web server. If you want speak HTTP, great, speak HTTP but if you don’t, it’s fine. It’s still just a jar and you can … the management for that, from the deployment perspective, it’s still just Java minus jar and the nice thing about jars are they’re super small, they … You embed just the bits that you care about and it’s less to manage, right?

As you know, Cloud Foundry, doesn’t really care about Tomcat or Mongrel or WSGI. It doesn’t care about the middleware that you use to run applications, right? It just cares about processes or I guess, more accurately containers, right, so everything you can do to remove that middleman, that container that wraps your application, your perfectly working application is better, right? It’s faster, it’s smaller, it’s less busy work and it’s less complexity. It’s less to think about.

Java minus jar, whether you’re running a web application or you’re running an e-tail or back office thing, super simple and to be a little bit hyperbolic, I could send a Java minus jar to my grandpa and he can run app-let’s because he’s got an old computer, so he could run that, right? The complexity there is just … It’s nil. You still have a lot of things you need to stand up and support like log aggregation and actual … a cell termination and scaling, all that stuff, route management and that … Foundry so then Java minus jar, you just CF push and that jar is super simple. The build pack just takes that and runs it. It doesn’t have to wrap it in container bacon.

Coté:
What I’m excited about …

Josh Long:
Yes.

Coté:
Is that there’ll be a re-ascension of app-lets. It’s been too long.

Josh Long:
Right? It … Let’s not. Let’s just not … I’m saying you did, okay?

Coté:
Another thing as one of the things that always struck me about … or I shouldn’t say always but that back when you gave me that demo it seemed interesting and you were talking about it there, is when you have this self contained thing, right, this executable that you can push out very quickly, that also conveniently maps itself well to the idea of doing micro services.

Josh Long:
Right.

Coté:
It’s a little … and again it’s … You didn’t exactly call it this but it’s like the decentralization of Enterprise Java think.

Josh Long:
Right.

Coté:
Instead of having everything centralized with one container, it’s a confusing term, nowadays but what …

Josh Long:
App server, yeah.

Coté:
App server that you would be using nowadays? It’s more like, “Let’s just have all these executable jars that are running and … I mean, we’re going to need something to orchestrate how they’re all managed but let’s … That’s the next chapter.

Josh Long:
Right.

Coté:
Essentially, instead of having all of the different services and components of our application be one solid application, we can split it out more easily and it’s always possible, technically to do that but because you’re always centralizing it, and putting it all in one big application, it’s a little more difficult to do that. Whereas if you have the ability to just break them apart, conceptually, like it starts to fit a lot better with this … I don’t know, process de-coupling that micro services encourages …

Josh Long:
Right.

Coté:
Which is interesting to look at and then of course, I mean that management and orchestration, there’s a certain amount that you can do on your own and obviously, you and I and all the other people at Pivotal are here because we think there’s a need for an orchestration layer to take care of all that stuff for you and a management layer so you can just focus on your little … Your jars and what …

Josh Long:
That orchestration layer cares about processes. It doesn’t care about …

Coté:
Exactly.

Josh Long:
Multi-tenant application servers, there’s no … There’s a great talk, if people have a chance, there’s a … I’m sure the slides are available, maybe even a presentation. Eberhard Wolf talks about why the application server is dead and it spells out why people use application servers and why these concerns aren’t actually all that well addressed and eventually you just … It’s very naturally as it concluded, “Well, I’ll just run a process.”

That gives me the isolation, it gives me the flexibility and all that stuff that I need and of course, now you say, “Okay, I need to orchestrate that.” “By golly, I happen to have this Cloud Foundry thing and it’s great at orchestrating all sorts of processes.”

Coté:
Yeah, and I guess that’s another way of thinking about what Spring Boot does is it … It helps … I don’t know if it’s return. I don’t know if Java was ever process-centric but it helps make Java a process centric model for doing development.

Josh Long:
Right.

Coté:
Whereas it hasn’t really been process centric for a long time, like I’m in fact acknowledging the existence of a process is kind of a bad idea but …

Josh Long:
Right.

Coté:
Like, so much of what happened over the past 10 years that was unsettling to Java people was about we should do things the Unix and Linux way, right. We should focus on knitting together a bunch of small processes, not having like these gigantic ambling machines of things.

Josh Long:
Yeah, two gigs of RAM, well, sure. Here. Sign up for my one app that takes orders from the web form.

Coté:
Exactly and as some people have been pointing out recently, right, there’s no reason that Java can’t be lean like that. You just have to have the right approach to it like something that Boot does for you.

Josh Long:
Right, and then the … Now that you just said it, right, we’re not moving to this process centric model and when you’re moving to the micro service world that is a very natural … Because you get process concurrency, right? The JVM and .NET are the Java, JVM community and the dot.net communities are the only ones that have this … For want of a better word, a disease where we insist on taking perfectly good Java code and then wrapping it in more Java code.

Coté:
Right.

Josh Long:
Before we could even deploy it, right, and again, the operating system is perfectly graded, starting and stopping processes. You don’t need more Java code to do that and now that we’ve taken away that bacon, in the bad sense, not the great sense, right. Take away the bad bacon, things get more nimble and then of course, yeah, I mean, now you start thinking about everything is a process, everything is a small service that’s singly focused. You have that pipes and filters model but when you extend that out for that …

When you extent that pipes and filters model out across the network, you get micro services in that sort of logical next step and I think we can all see why that’s awesome. I mean it’s small, singly focused services that do one thing and do it well and describe one slice of the domain, one vertical, one bounded context, to borrow from Eric Evans, but of course when you move to that approach, now you’ve got complexity. Now you’ve got fragility involved in managing that, right?

Of course, a good platform like Cloud Foundry will help with a lot of that. For example, scaling and log … getting a joined up view of your logs as super, super viable, getting a dashboard to see all this stuff that’s super, super powerful, getting the ability to self-healing because again, you have … You want more, not less, right. Having the ability to just let the platform heal your applications and make sure that they look like what you asked them to look like. If I need five instances or if I need a 100 instances and one of them should fall down, I don’t want to get a pager. I just want it to restart it.

Coté:
Yeah. I think there’s … I don’t know if this is true but there’s probably a cycle that programming thing goes through which is you start off with doing the smallest thing that could possibly work.

Josh Long:
Yeah.

Coté:
To satisfy the requirements or the needs and then you start doing that and at some point you start wanting to build more and more and then sooner or later as someone … As, maybe not only but definitely as people who’ve done like Enterprise application development can understand, after several years, it’s impossible to do the smallest thing, right. The stereotypical thing is “It’s going to take us three weeks to add a new button to the page.”

Josh Long:
Right.

Coté:
Right.

Josh Long:
Yeah.

Coté:
“Why does it take so long to do that?” and it’s just because after a while, if you start moving from doing a bunch of small things, you just … It’s hard to even express why this happens but everything ends up depending on everything and then you can’t really move very fast because even a small change, it touches everything and maybe not literally, so to speak, but you have to retest everything and you have to rebuild everything …

Josh Long:
Certify.

Coté:
All this stuff and you’re also never quite sure that if you make some change, if it’s going to break something else, right, which is … That’ll be a good segue to talking about Spring Cloud a little bit but …

Josh Long:
Right.

Coté:
Part of what’s encouraging about the way development is done nowadays, and you’re alluding to this with the “Why wouldn’t you use the operating system for process management?” Right?

Josh Long:
Right.

Coté:
There’s almost this willingness that it seems like developers have nowadays to just assume Linux.

Josh Long:
Right. Yeah. Come on.

Coté:
Right and I think part of the reason that Java and .NET are as they are is because when they were created, and for a long time after they were created, you couldn’t just assume a common operating system or a common set of controls underneath there, right. It might be Solaris. It might be Windows. It might be this thing. It might be this wacky Linux variant. It might be this and so diversity was at the operating system layer which meant that you had to ignore it, right.

Josh Long:
Right.

Coté:
Nowadays, there’s not really a tremendous amount of diversity at the operating system layer and that I think as cloud platforms start to take over more and more, I don’t think they change that at all, right? They’re all pretty similar in thinking about … I mean they’ve all adopted Unix or Linux mindset to things and so it allows you to delegate down to them instead of worrying about doing that all on your own which I think in turn, gives you the ability to smoke, smokus … To focus on very small things, which hopefully, gives you the holy grail of being able to not only move fast but consistently, year over year, move fast and release quickly.

Josh Long:
Right.

Coté:
Which is the real trick of thing …

Josh Long:
You brought up a good point. I wonder were Java designed and developed today, in the market that we have today, would the … As we know now, not all that well, delivered in the first place, promise of right once run anywhere, portability, be all that crucial or game changing.

Coté:
Right, to mangle up a phrase, they’re probably more likely like write once, configure anywhere.

Josh Long:
Right.

Coté:
Just that kind of little slipping of the steps is interesting. I mean this is another total side jag that we can skip over but I’m always, like you were saying … Spring Boot gives you this one executable unit and as I’ve been learning about go more frequently, right, they also give you …

Josh Long:
Badly linked.

Coté:
One executable unit and back when you would build C stuff, it gives you one executable unit and … going back to the 12 Factor stuff and that consolation. There’s always a lot of hand wringing over dependency manage, things like that …

Josh Long:
Right.

Coté:
Which always seems a little weird.

Josh Long:
Yeah.

Coté:
I mean it does lead to weird practices like checking your server into your code but, yeah, man, managing dependencies is annoying if you have to do that.

Josh Long:
Yeah, just get it right once, bake it into the thing, so Spring Boot, actually, we have Java minus jar at the moment. The current GA of Spring Boot is Java minus jar and there’s a really slick new feature in Spring Boot 1.3, which you can try out on the start.spring.io, that is in 1.3 M2, at the milestone and it takes advantage of the fact that the JVM reads jar files from the bottom of the file, up, if you will.

Coté:
Right.

Josh Long:
Whereas the operating system, reads files from the top, down. What we’ve done is we’ve … If you want, you can configure an executable jar and what this will do is it will create a shebang line and write a shell script that … very much like the MCS, you hand drawing itself. It reads itself and the bottom of the file is the jar, byte code, the binary.

Coté:
All right.

Josh Long:
Yeah, so you can just do ./foo@jar and you’re off to the races. It’ll just start running. It doesn’t quite do the … It’s not quite as cool as the go approach because it’s … You still need a JVM somewhere and I asked them to write a little … A quick little thing so that if the JVM wasn’t on the class stack we’d download it and that way we’d be completely statically linked but, yeah, that’s … Very much that same mentality, that go mentality of like here’s … and people say, “Oh, well, I want to avoid the weight of having these jars …”

This is the old argument was there’s all these extra dependencies, they add, they ruin the figure of my jar, right? They add to t he waistline and they’re literally talking about the file size, the jar file size, so 20 megs of jars, right, to run an embedded web server and to have all the monitoring and all those that Spring Boot gives you, data access, everything, all that stuff is megs for a REST API with security and all that stuff and who cares? I mean I’ve got 20 megs over and over and over and over, I could run that a million times and I wouldn’t feel it.

The goal in Spring Boot, as with go is not to … I mean when think about why we have DLLs and why we have dynamically linked assemblies is because I wanted to be able to keep those dependencies external to my code and then load them dynamically, resolve them and link them and load them dynamically but that’s not really a useful thing and it introduces as you say, a lot of complexity, config, dependency, management complexity that we don’t care about anymore.

Coté:
Again, I mean, I think the architectural goal that you have is that cloud centric thinking of I should reduce this component down to the smallest thing that’s successful.

Josh Long:
Right.

Coté:
Also, it should be manageable as a process, right?

Josh Long:
Yup.

Coté:
This, what this gets me is … this basically get me that part of my gigantic architectural diagram of the whole system is one small batch to speak.

Josh Long:
Right.

Coté:
Managing one small thing that’s self contained is a lot easier than managing 50 things that are all interlinked with each other.

Josh Long:
Right, and what bugs me is that these, you have our … You mentioned earlier the tendency for sane people is to do the simple thing that could possibly work but as you know and I’ve run into more than a few, there are invariably the architecture astronauts. Eventually, as you said earlier, eventually over years and years of croft being accumulated across the system, you will have this morass of dependencies and one thing is if you shake the spider’s web, the other … everything else will vibrate but there are some people that want to create that spider’s web upfront.

Upfront, big deal but upfront, architecture astronauts, me, I’d much rather defer the … If I’m going to be stuck with that problem, let it at least be a few years away so I can move fast now or even better, just never get there in the first place and really relax the links between your system. If that link between components is just an HDP service boundary, right, and it’s … and you’ve standardize on some common messaging, for example JSON or Google protocol buffers, and you standardized on a common protocol, let’s say HTTP, it’s much, much easier to keep these things independently deployable and so if you shake one side, you don’t necessarily have to see vibrations in every other component in the system.

That’s another reason why people are moving to micro services, that transformation is so, so freeing and it’s particularly freeing if you’re starting to think about these larger apps. I think there’s this … We have this use case where we’re trying to build applications and people say, “Oh, well, I don’t need micro services because my app isn’t as complex as Google,” right, and that misses the point entirely.

First of all your app could very well be as complex as Google or certainly have the same kind of scale requirements, right. Today, just anyone could pick up their phone and build an app, deploy it and that goes viral. We all know how quick it is to become viral and get an app on the app store that drives traffic in ways that we didn’t even have to think about 10 years ago. What even is capacity planning in the cloud today? Do you worry about the slashdot effect?

I mean you shouldn’t right. There’s no … That’s a problem that we don’t care about anymore and that is something that is … That’s part of our generation. That’s part of this new world of technology so first of all, our apps could be the kind of scale and the kind of complexity of a Google but that’s not even the real benefit here. It’s the agility, right? The ability to say this team is going to focus on that piece or functionality and deploy it independent of these other …

Coté:
Yeah, I know, I think that’s totally accurate for most people is … Scaling is not really your concern.

Josh Long:
Right.

Coté:
Right, like scaling might become your concern once you’re like really successful and if you’ve built your system on things that can’t scale well but your concern will be like not being able to release your software frequently enough.

Josh Long:
Right.

Coté:
In order to achieve scaling and also compete in the market place, the consumer web companies that we’ve learned a lot of, how to do development and product from … over the past years, like it was almost a … Not a necessarily evil but it was just like a boring requirement that they needed to be able to release software quickly. It’s easier to scale things if you have these smaller batches to scale it up and make a process centric standpoint and if you want to release tiny new features all the time to compete with MySpace or whatever the people were doing back then, you want to be able to release frequently.

It’s like, well, we need to be able to release things frequently and I think the majority of people, I mean at several … Pivotal customers, they’re like large, global 2000 companies so they have scaling issues.

Josh Long:
Yup, naturally.

Coté:
In the volume of cases, for the most part. The real problem is I just can’t get software out the door.

Josh Long:
Right.

Coté:
You can adopt these cloud practices like even if you don’t really care about scaling, a side effect will be that you’ll be able to deploy more frequently because that’s a necessary thing for being scalable.

Josh Long:
Two kinds of … Yeah, isn’t it great that the … You’ve got two … That the modern organization today could have one or both of two problems. One is I need organizational scale. I need to be able to iterate faster and two is I have actual capacity problems … Scale at, big web scale and it turns out that the answer for both problems, the solution for both problems is the same thing, micro services. You’re going to need to break that stuff out into smaller pieces and then scale horizontally and it’s nice but I agree that more often than not, the first bit of friction you’re going to hit is organizational velocity.

How do I move fast? How do I release software? What some people are very dismissive off is this potential that they’re going to hit scale problems and I would say that’s … Well, it’s not likely that your app as conceived today and then deployed tomorrow is going to be the next big thing. You should be cognizant of the fact that there is a real potential that it could be the next big thing. The whole Flappy Bird thing, right, that went huge, not a lot of … Not a particularly interesting app but it was something that captivated people’s imaginations and it drove scale. It drove capacity. It drove a requirement to go out.

Same thing for any viral app these days, I mean simple things can become very popular and they can demand scale so it’s very reasonable to think, “Okay, I need to move fast,” and very conveniently, you may also need to scale out in terms of how much capacity … and I just like that for most of those situations it’s the same solution. It’s micro services, small singly focused things and how do you orchestrate a lot of small singly focused processes? Cloud Foundry, right?

Coté:
That’s the end of part one of my conversation with Josh Long and part two, as you can guess, we move on to talking about Spring cloud and how it’s related to Pivotal Cloud Foundry a little bit. As always, this has been Pivotal Conversations. You can check out more things about this podcast including the show notes if you go to Pivotal.io/podcast. That’s with an “s” or without an “s.” We’ve got the URL magic so that both of them work.

 

About the Author

Biography

Previous
Positive Sum Software & Spring’s New Bounce—SpringOne Platform Day 3
Positive Sum Software & Spring’s New Bounce—SpringOne Platform Day 3

Day 3 kicked off with Sam Ramji, who oversees the gestalt that is the open source Cloud Foundry Foundation—...

Next
Taking On The Monolith With People And Tech—SpringOne Platform Day 2
Taking On The Monolith With People And Tech—SpringOne Platform Day 2

Whether it was a “mono-horrific architecture”, how “silos are for grain”, or “cowboyism” development, the m...