2. I think an excellent place to ask this question which is – Spring started off as a light-weight POJO container, right? But now it seems to be be labeled as too heavy weight. Maybe by a few people, but they are saying that Spring is dead. That might be a little bit extreme, but how do you respond to critics like that? It is an interesting question, but since the interest rate reaction in the recent years was interesting in its own right. In many of the things that we have been doing, we have seen very, very positive reactions. At the same time, there are, say, certain voices in the industry who already have their vested interest in calling the Spring legacy or chose your negative term of the season. But my take on this is very different anyway. With Spring we are basically on ignition. We have a certain philosophy in how we evolve the framework . The framework has a strong assumption that infrastructure is basically there, not necessarily the developer’s choice. It is kind of one the fundamental principles: decoupled from the infrastructure, which means to a large audiences out there having to deploy the existing infrastructure. Our challenge, our value add is basically that we are allowing them to get the most out of the infrastructure that they have.



Spring brings very recent, very modern programming module styles onto, say, older infrastructure. That is something that we have always been doing and I would argue it is even more important these days now in 2014, 2015. It is more important than it used to be 10 years ago since what we are seeing in the industry is an increasing disconnect between what you find installed in production and what is being advertised as the latest kind of specifications these days. At this very point, most people have a 2009 era - Java EE 6 environment in some form. Spring Framework 4.1 is basically a late 2014 framework that should bring in very recent spice into that environment. It really spices up the environment to a very modern day web input module in particular, perfectly capable of running on 2009 era infrastructure, but not being stuck on the 2009 era programming concepts and programming limitations.



So, that is something we just keep doing. Every year basically, new infrastructure comes into the picture, but old infrastructure does not go away. So, we make sure that we run perfectly well on most recent infrastructure and we just preserve our ability to add the value of Spring to older data centers, all kinds of infrastructure. That is still very true, that is basically the one part of my thinking about this is that the values that Spring is providing apply even more than before and the other one is, connected to the talk I have given here at VOXXED Days, is the strong design philosophy behind Spring, even down to the very details. I could spend hours discussing the design philosophy behind specific Spring programming module concepts, between the choices we have made, the trade-offs we have made. There is always a little bit of history involved, but mostly it is specifically designed to be a comprehensive and coherent model for the present generation.



The idea behind it is that we are independently crafting a programming and configuration model that does not just follow along some common ground that somebody established somewhere. We rather had our own vision about it and evolve it based on our own vision. I find it pretty important these days, right? It is a diversity in the Java ecosystem which really adds value to that very ecosystem itself in its own right and we would like to just keep pulling towards our own vision there. We are often facing the question of specifications for specific purposes. Sometimes this is the answer when we are going our own ways, because this is our own vision is suddenly different from what may end up in specification documents. So we keep evolving Spring the way we did it for the past 10 years, for the same reasons, for very similar reasons that still very much apply.

3. Give me an internal perspective – how do you pick like a particular Spring project? And give me the other side: I am a developer – how the heck do I keep track of all this? Rags' full question: That might lead to the next question which is at the other extreme. It seems like Spring ecosystem keeps growing and growing in a way that there is Spring Batch, there is Spring Boot, there is Spring Cloud, there is Spring data, there is – you name it, right? So, give me an internal perspective – how do you pick like a particular Spring project? And give me the other side: I am a developer – how the heck do I keep track of all this?



Perfectly valid question. The one part of the story is why we are splitting our efforts into those projects. This has primarily to do with team structures and release cycles. We tend to set up a new project. If it is likely to have its own pace, it’s own release cycle, if it tracks third party efforts of someone like our Hadoop offering for example Hadoop.like bound to release cycles of the party products, then we just give it its life on its own, its release cycle of its own, not revving it along with the old framework. It started like that. In the mean time we have a lot of those efforts. Each of those projects has its own project team – that is the second part of the picture. Now Spring Framework has its own team, there is a dedicated Spring data team, there is a Spring integration team, somebody els for Batch and so forth.



They are kind of around a dedicated group of people – the first thing that they think about when they wake up in the morning is that very project that they are assigned to. There is a lot of stability to those teams, so mostly those projects are evolved by the same people who originally conceived them. So, the end result of course is quite a landscape. If you look at the project.spring.io page, there are quite a few projects on there, some nested ones even with Spring Data. So, if you approached this ecosystem from an outside perspective, it might look quite scary maybe – Oh, there is so much going on there! Of course, we have the more recent efforts like Spring Boot, the Spring IO Platform, our start.spring.io web - that we have recently accomplished. These go a long way towards mitigating a few of those concerns where we are providing unified dependency management either for our own projects and for associated third party projects.



So, it is rather easy to get started these days by using our IO Platform where you get started with a version arrangement that is known to work and where quite a few of the Spring projects, like our Spring modules, are being kind of driven in implicitly, where you do not have to consider the purpose of each and every one of those projects, where they are kind of brought into your project on a demand basis. As you declare in need for a certain feature, the dependent modules come in. So, those are efforts from the past year of two to quite some degree making it easier to use those projects from a more unified angle. In terms of the further evolution, it has proven to be very useful, both to us and to the community to have independent projects. So we are not trying to merge projects, we are just trying to kind of unify the evolution and dependency arrangements between those projects. That seems to be the best possible compromise for us.

4. The big sponsor for Spring is Pivotal and Pivotal is focusing a lot of its efforts on Cloud Foundry, correct? I know that there is a lot of symbiosis, or rather synergy I should say, between Cloud Foundry and Spring. Is there anything specific that you would like to address with respect to Spring being the first-class citizen in Cloud Foundry? The connection to Cloud Foundry has some history in the meantime already. It is mostly, for start, a Java perspective, a Java application development perspective for Cloud Foundry where Spring is the recommended, promoted programming model for that kind of perspective and for good reasons. The inherent ability in Spring to adapt to the infrastructure given in any kind of target environment – it applies perfectly naturally to a Cloud environment, and Cloud Foundry is a perfect example for this where the ways of managing the infrastructure there, how it is exposed to the application, is just quite different from traditional environments. Spring has no problem at all adapting to those and for that it presented itself as a natural choice. The efforts that we are spending in terms of a synergy between the two is in particular making sure that Spring kind of allows you to take the benefits that the Cloud Foundry has to offer and to actually expose them to the best possible degree in your Java based, Spring based environment. We do not believe in abstracting infrastructure, in kind of dumbing it down, avoiding to be all the same. We believe that certain kinds of infrastructure, Cloud Foundry in particular, have certain strengths that really need to be exposed. You need to make best possible use of those features and those capabilities and many efforts in Spring go in the same direction: smaller deployment units suggested by Boot, we even have a dedicated Spring Cloud offering in the meantime. There are dedicated Clouds support of some sort, but I find it actually more interesting to look at the more subtle effects of what we are doing and the different kinds of applications architectures, the different kinds of communication arrangements between the parts of the system. That is the impact that Cloud environments bring onto the table and different kinds of messaging solutions, messaging mechanisms and in Spring land we are trying to make sure that whatever we do with the programming module, it can naturally translate to that kind of infrastructure. And that is perfect input. It is the sort of input that is the best possible solution that you can come up with for a framework, if you are challenged from different sides, with very different requirements. So, it is what we keep doing.



Rags: So, in a large part, they are complementary to each other.



Absolutely. The idea behind Spring as a navigation framework is exactly that it stops where middleware begins and Cloud Foundry is basically a middleware arrangement on a flexible deployment platform so there is perfect separation of responsibilities there.

5. That leads into my next question. A lot of developers use the Scala and Play framework and they get really excited and they think it is a lot easier to use than Spring. Is that true? What do you have to say about that? I should say that I am not an expert on Play, so I do not claim any kind of particular expertise there. However, I have seen that feedback, I have heard such comments. It is to some degree related to any kind of Java based solution. There seems to be an audience out there who is really very much into Play and in particular, also Scala, the language. From my perspective, where we see our mainstream audience is a quite some different place. So I do not see any immediate overlap there. There seems to be a very specific audience that is attracted by Play and by all means, Play and the underlying infrastructure that uts trying to support are great pieces of engineering. No doubt about it. There is perfectly valid value in those frameworks. I am personally just not sure whether stylistically and structurally, the model that has been used there, that has been kind of imposed onto applications there is that attractive to, say, more like a traditionally Java-minded audience.



So, in that sense, the mission is a bit different. What we are trying to do in Spring is to take people where they are in the main stream and try to softly move them on to a more modern variant of doing things. We are not making radical jumps and we are not making radical breakages because that would mean we would lose people. We would like to keep pulling them along. The interest also is going to be different from a framework arrangement such as in Play where you say “Let’s start from scratch”, even in Play 2.0 – “Let’s start from scratch once again and just see what we end up with”. So, from my perspective, I personally really appreciate such efforts, such technical efforts. They are really inspiring and I mean I admire quite a bit of engineering achievement, but it is a different focus and a different mission in that what Spring is doing. So in that sense, they do not really compete against each other. I would rather see them as kind of being attractive to specific audiences and they do not necessarily overlap that much.

6. OK. That is fair. Everybody is talking micro-service and containers these days. No matter how you spin it as old wine in new bottle or completely new, we can debate about that endlessly. But is Spring doing anything in the direction of Docker, containers, micro-services and so on? The micro-services term. I personally prefer not to use it, frankly, since it is a bit of an overloaded term. There is a lot of meaning attached to it, depending on who uses it. But in terms of what it means, in terms of the trends, the impact that it has are very much appreciate it since it kind of makes us refocus on smaller units of deployment, on a different granularity that we are wondering about deployment units at the level of an operating system level container where a lot of consequences follow from it. It is very different from your traditional Java application server arrangement where you would think there is one JVM which owns the machine, right? And it does not want any other processes left or right. In a micro-services architecture, you have a very, very different layout, even at the operating system level.



In terms of the impact onto the programming model in Spring or in Java, the impact is not as radical as one might assume and a lot of the concepts that have been very popular in Java and in Spring in particular, they are apply very naturally in micro-services architecture but there is, of course, always baggage to provide towards specific modules and what we are doing in Spring Boot is very natural fit, I would say, with micro-services architectures, since Boot kind of naturally suggests smaller set contained units of deployment bringing in their HTTP engine and bringing in quite a bit of infrastructure through dependency management in kind of one deployment unit which kind of very naturally translates onto a micro-service architecture. But that is really the level that we are operating on, right? To some degree, that is quite orthogonal to how the operating system arrangement works. So in terms of Docker we do not really need to be very specific about supporting that kind of architecture. It kind of naturally fits, if you follow the same kinds of rules, both at the programming model in Java and in your deployment arrangements. So, I see a strong synergy between where that industry trend is going and between where we are going, but the connection is actually not that tight. It does not have to be. The value came in provided with a kind of loose alignment in terms of where we are going.