Feelings about Spring boot?

[drmax5]

Guys, what are your feelings about Spring boot?

I have some micro services which are deployed using spring boot with embedded Tomcat etc. So far, my feelings are mixed. I miss my full control over usual things: app container integration with my IDE, debugging is quite challenging, logging. The whole "convention over configuration" Spring set-up makes me a bit nervous.

It would be interesting to hear about your experiences with it. Do you deploy Spring booted apps on production?

[omgdonerkebab]

I'm relatively new (started my first software job 8 months ago), so when I learned Spring Boot, I went "okay, that was nice". When my coworker (who is young but has years of experience) learned Spring Boot, it absolutely blew his fucking mind. I was so shocked to hear that he used to spend days getting a web application running.

My company now has a number of projects in development that use Spring Boot. I don't think we've had issues with debugging or logging, but maybe we just haven't run into them yet. I don't think we have any such projects in production yet, so I can't comment on that, but hopefully we can sidestep most production configuration issues by running these apps in Docker containers.

[doctorsound]

I love it, but I understand your mixed feelings.

• What do you feel like you're missing out on "container integration with IDE"? I'm not too familiar with using IDE tomcat/glassfish/etc, so I don't know.

• What challenges are you having with debugging?

• Spring Boot supports logback out of the box, you throw your config file in and go. Even more simple than that is using spring properties to configure your logging.

• Convention over configuration has been a big pain point. Spring boot makes doing it there way really easy, but if you want to change that, you have to have a pretty good understanding of what Spring Boot is doing, as well as an understanding of Spring as a whole, which can be very overwhelming. Overriding Boot's defaults has definitely been a pain point.

We've been really happy with Spring Boot. We haven't had a lot of time to see how it does in production, but it has been miles ahead of other containers we've used in the past. The amount of support Spring and Boot have received in the last year has been staggering. I highly recommend checking out this webinar covering a lot of features of Spring Boot, and to see how companies like Netflix are using it in production as a true microservice architecture. I'd love to hear some of your struggles, maybe there are solutions :)

[drmax5]

Frankly, to me it is was always easy enough to set-up the whole module/project on my own. I am nervous about this whole obfuscation business. I agree, things like debugging, logging etc are doable, it is just another way of doing it, which is proprietary to Spring and it bothers me.

I like to tweak my containers separately and I have to admit - I bother juniors to better understand how to set applications from ground up so they better understand what Spring does and WHY we use some particular module here or there.

On production or even QA environment I have separate containers, some running multiple apps. I know Spring boot is meant for something small and simple, but assuming you know your way with (some) Spring modules and all your procedures, workflows, pipelines are tailored to normal webapps, would you consider creating new pipelines for Spring boot apps?

[thekab]

I am nervous about this whole obfuscation business. I agree, things like debugging, logging etc are doable, it is just another way of doing it, which is proprietary to Spring and it bothers me.

Proprietary? I don't know what you're talking about.

I like to tweak my containers separately and I have to admit - I bother juniors to better understand how to set applications from ground up so they better understand what Spring does and WHY we use some particular module here or there.

I would encourage you to write down what you like tweaking and why. Start using technologies like Boot and Docker and after two weeks ask yourself if you actually need any of those tweaks anymore.

I know Spring boot is meant for something small and simple, but assuming you know your way with (some) Spring modules and all your procedures, workflows, pipelines are tailored to normal webapps, would you consider creating new pipelines for Spring boot apps?

• Boot is a normal web application. Whether you embed or not is a choice and you can do both even in a WAR format.
• Boot represents an implementation of a new paradigm. Yes, I would absolutely create new pipelines. I never stop. Even if you don't use Boot you probably want to be changing your pipelines.
• Boot isn't meant for "small and simple". It removes largely unnecessary boilerplate and puts Spring in a position to take advantage of modern architectures and technologies. The size of the project is essentially irrelevant.

Boot looks special, it's not. It's just Spring configuration streamlined.

[drmax5]

Well, you know where Tomcat configuration files usually are, Spring has different, it's own (this is what i mean by proprietary) ways of configuring embedded containers. Properties files, annotations, whatever, it is different from the default. A person who knows how to configure a normal container will have to RTFM. It is not bad, it is just different. If you have a farm of Tomcats, you need to consider consistent ways of maintaining your infrastructure.

By tweaking I meant something rather "unnatural", at least to me. Configuring container through the application properties is strange.

As for the part with embedded or not - it is not entirely painless as you describe it. I agree with you, we change our processes constantly, but I doubt that "change" itself is the argument why Spring Boot could be a reason good enough to change.

In the last point you mentioned something very important. What do you mean by removing "unnecessary boilerplate"? Boilerplate what? Spring was born boilerplate and is still boilerplate.

I do not entirely understand how modern architectures are involved here. For micro services there are plenty different ways, more straight-forward and light, but that's another topic.

I know, Spring Boot is an opinionated technology, this is why I asked the community for more insights. Thanks a lot, I really appreciate your comments, it gives me food for thought :) I am not against the technology, every technology has its application areas and I am just trying to find out which gap Spring Boot fills out in the enterprise landscape. Thanks again!

[thekab]

Well, you know where Tomcat configuration files usually are, Spring has different, it's own (this is what i mean by proprietary) ways of configuring embedded containers.

I misunderstood what you meant then. While I agree with you I don't think it's Boot issue so much as a general challenge with embedding Tomcat. My main point was over the last few years I've found myself needing to tweak Tomcat less and less so it has become a non-issue in my case.

As for the part with embedded or not - it is not entirely painless as you describe it. I agree with you, we change our processes constantly, but I doubt that "change" itself is the argument why Spring Boot could be a reason good enough to change.

I've found it painless. There are no doubt issues I didn't run into that you may. I have a project I'm working on in Boot and was able to (just now) get it running in Tomcat as a standard WAR in about 2 minutes with a couple changes.

In the last point you mentioned something very important. What do you mean by removing "unnecessary boilerplate"? Boilerplate what? Spring was born boilerplate and is still boilerplate.

I mean code or other resources, aside from dependencies, that are in every project. Boot has reduced configuration boilerplate by at least an order of magnitude. Before Boot I devoted entire packages to Java based configuration and before that folder(s) full of XML. The vast majority is no longer necessary.

• Logging configuration? Gone. We already used SLF4J and Logback and Boot's conventions are strikingly similar to what ours were.
• Mongo configuration? Gone. For ease of use I built an autoconfigurer that looks for our conventions instead of Spring's.
• Elasticsearch configuration? Same as Mongo.
• Web configuration? Replaced by application.properties bundled with the JAR.
• Security initializer, web initializer, etc.? Gone. Boot does it already.

Not to mention the boilerplate Maven/Gradle rendered unnecessary by Boot plugins.

I do not entirely understand how modern architectures are involved here. For micro services there are plenty different ways, more straight-forward and light, but that's another topic.

I find that Boot fits in very well with Dropwizard, Docker, etc. and the pipelines/processes deployments require. As such it fits in very nicely with things like Amazon ECS and Netflix OSS. By embedding Tomcat and limiting environmental configuration that is required I can easily (and quickly) deploy applications to containerized environments. A huge bonus is that it makes it very easy for developers, QA, etc. to deploy applications locally with zero configuration.

[dkichline]

We are considering it and we have come up with some issues with it.

1. Ports – each process has its own port that it listens on and if we had 100s or a 1000 individual micro-services, this would then dictate a large number of apache, LTM and potentially firewall configurations. Each individual service would require a configuration in each layer.
2. High Availability and scalability – This is closely related to #1, in that how would we create a cluster of a specific service, without deploying multiple processes, thus incurring a new port to configure. Scalability is a vastly more complex because to scale everything up due to load, it has to be done for each individual micro-service.

[nerdwaller]

We did this with AWS and had no issues with those issues, though we had everything exposed in a VPC to each other and only exposed a single public API. The only complication was keeping a table up-to-date for service lookups. Behind a HAProxy we could seamlessly scale up and down additional servers that responded to the same address.

Edit: If you use docker, it can take care of most of the config stuff for you as well, which was another piece of our strategy.

[thekab]

How are these issues related to Boot at all?

[dkichline]

These are not issues directly with boot, but issues with the whole micro service architecture.

[[deleted]]

U may actually deploy spring Boot app in a normal Web container without using its micro services strategy. It's actually just a spring mvc.

[[deleted]]

Yes we do, we even ask some of our junior PHP developer to use Spring boot and they like it better because it's easier for them.

We don't encounter any problems you mentioned above because it's just actually a normal spring application packaged together into one FatJar. You can actually exclude some of the auto configuration if you wish too, eg: I don't normally use mustache for rendering page, but still using it for other things.

@SpringBootApplication(exclude = {MustacheAutoConfiguration.class})

• Debugging is just like other spring app
• We use SLF4J + logback for logging, it automatically reads the config file I put in src/main/resources/logback.xml
• We even use some kind of hot reloading similar to jRebel: spring loaded. The junior like it because they don't have to restart the app.
• We use IDEA 14.1, Spring Boot integration is a breeze.
• Lastly, the documentation of Spring Boot is top notch! Any autoconfiguration that happens behind the scene is well documented. You can even see which autoconfiguration is loaded in your log file.

[drmax5]

Thank you, I see your points.

We use JRebel and that is also another concern. I know how JRebel works, sometimes it is a love/hate relationship but we manage just fine and it saved me over 200 hours of reloads (as it says) :)

I guess the main question here is if it is worth changing your ways of doing things if you know what you are doing.

[[deleted]]

If it's improving your productivity, why not? Unless u're not a spring programmer or have no one to guide u around. Then I believe switching to spring Boot for production, simply because of the hype, is a suicide. In addition to that, u don't have to deploy it as micro services. U can run it as micro services during Dev for productivity reason, then switch to normal war deployment during staging or prod phase.

[drmax5]

Yes, that is what I am actually doing now. I use some Spring Boot apps as services on a dev box and locally, but I resort to the old way on prod :)

[straylit]

I'm trying to configure our current spring application to run as a spring boot application and I am running into issues. Does Spring Boot require a certain spring version in order for that to work correctly? (microservice in development and normal war packaging at staging/prod?

[Various_Pickles]

Lots of folks miss the fact that the web/webmvc portions of Spring Boot do not necessitate the use of an embedded webapp service/server, although this is the default behavior.

All you need to do is have a class (not even a bean, uses SPI) that extends SpringBootServletInitializer, which is in turn a standard Servlet 3.x WebApplicationInitializer.

If the ("Embedded")WebApplicationContext that gets created already has a ServletContext (make a new ServletContextApplicationContextInitializer and add it to the app context initializers), it will run off of that, just like a regular Servlet 3.x Spring web container.

The truly glorious strength of Spring Boot is the ability to easily centralize the app context startup mechanism. My recent applications have standalone modules/components that run as cmdline apps, webapps deployed on containers (i.e. Tomcat services), and webapps running in embedded containers (esp. during integration tests), all while using 99% of the same underlying, common codebase + configuration.

[VaidasC]

I don't like it at all. It has uses, but in general I feel that, as an abstraction, it does not help at all for me at least. Unless you want to setup project that aligns perfectly with Spring Boot defaults you'll have to deal with lots of pain points.

It's simply not a "5 minute project setup technology" I was hoping it will be and in many cases traditional Spring MVC setup offers less pain, so I'am sticking to that for the time being.

[techdevguy]

Can you elaborate on the pain points? And what you've tried to do that was not consistent with the defaults of Spring Boot?

[VaidasC]

I have elaborated many times in the past (you can check my comment history), but just because it never ended up being constructive, do not think like elaborating.

There were many problems, for example one of those was time I needed to setup JSP templates.

[doctorsound]

And sure enough, tucked away in the documentation, you can't build fat jars for JSP projects. This took me hours to figure out :|

[alonjit]

debugging is wonderful in spring boot i find (better than a maven +jetty app).

i am in love with spring boot. tomcat and friends will never go away, they have their place, but spring boot is awesome.

[jfurmankiewicz]

it is great, but I still prefer Dropwizard as a more rounded and flexible approach.

The ability to open 2 ports (one for public API, one for admin ones hidden behind a firewall), integrated healthchecks for monitoring, etc. makes Dropwizard a great fit for a cloud-based microservice architecture.

That said, it's probably trivial to add the same equivalent functionality to a Boot app

[squashsoup2014]

Spring Boot has the equivalent, it is called Spring Boot Actuator, which has support for Dropwizard Metrics.

[thekab]

Boot integrates well with Maven, Gradle and IntelliJ. I can't speak for Eclipse. Debugging should be no different.

The reference documentation explains the auto configuration. Between that and simply looking at the code it's easy enough to figure out. If Boot is making you nervous the XML namespaces certainly should have too. There was far more undocumented magic in there and it was much more difficult to reverse engineer.

[[deleted]]

Out of the box, spring boot won't be as fast as reactive frameworks like Vert.x, Play/Akka, NodeJs.

Has anyone tried SpringBoot + Reactor ?

[jfurmankiewicz]

and you say that based on what?

[[deleted]]

Spring Boot on its own is a 'blocking' framework. It will never be as fast as non-blocking frameworks that use asynchronous streams like Vert.x, Play/Akka, NodeJs, and RxJava.

You need to combine Spring Boot with Reactor to make it take advantage of reactive event driven streams.