Search
Online Courses
Pocket Guides
Last Update: 12.07.2017. By Jens in Spring Boot
Last week I was chatting with a friend and he told me how lucky he is that a part of their system moved to using Spring Boot. It made his life easier with development and testing. He actually loved writing tests now. However, one of his colleagues did question the decision to go with Spring Boot because Spring Boot is meant to be used with Docker and for microservices only. I was baffled but it seems there’s a lot of confusion what Spring Boot actually is and when to use it. This article does shed some light on it.
I think a lot of the confusion is because fellow developers do not understand what Spring Boot actually is. They ask questions like “Spring Boot vs Spring” or “Spring Boot vs Spring MVC”, see mentioning of cloud techniques and microservices and come to the conclusion it’s a new kid on the block for microservices. Understandable but totally wrong.
It is not a question of “Should I use Spring Boot instead of Spring?” or “Should I use Spring MVC or Spring Boot?”. The question is:
How do you want to use Spring?
Because Spring Boot is nothing more than a way to start and build applications using the Spring Frameworks quickly. Or to phrase it with their own words:
Takes an opinionated view of building production-ready Spring applications. Spring Boot favors convention over configuration and is designed to get you up and running as quickly as possible.
– Spring Boot page
To understand it better we need to take a look at the classic way of building an application with the Spring Frameworks.
Take a typical web application for example. We are probably going to use the Spring Core, Spring MVC for UI and REST, Spring Security for authentication and authorization and Spring Data JPA with Hibernate for accessing a SQL DB. In the old days, you had to:
Many of these steps are just gluing Spring Components together so they provide the services you need. This flexibility is one of the biggest advantages of Spring, just put your Legos together like you want. But at the same time, it is one of it’s biggest disadvantages when you start new projects.
If you have done this a couple of times, you’ll notice that many steps are the same as you will always use the same DB, same security setup, etc. And damn you or the guy who messed up. It’s a tedious and error proven task. Often leading to copy and paste setups from previous projects. And this is where Spring Boot actually steps in.
Spring Boot replaces this tedious setup and uses defaults which reflect common usage patterns.
But besides that, you still have the full flexibility as with the classic set up. It is still Spring after all. Need form based login instead of basic auth, just configure it.
Setting up a new project is now a task of a few minutes and not hours gluing stuff together.
That’s a huge timesaver.
Essentially everything you can use Spring for. But that answer, even correct, would make it too easy. One reason why developers are confused about the relation of Spring Boot with microservices is due to the fact, that the regular deployment of a Spring Boot application is NOT done with a war file or similar anymore but you rather deploy a single standalone application. Like you do in many programming languages.
When you build web applications in Java you have to work with either a servlet container like Tomcat or even worse with one of the enterprise application servers. The whole concept in Java for web is about these managing containers. Those containers are standalone applications, maintained separately and you can deploy multiple applications to them. That led to more and more complex specifications and bloated software. Almost everything in Java is standardized.
You need different skills to maintain them then you need for developing applications which run in them. Java developers are used to that and some are confused that you can deviate from this.
When we deploy a web application with Spring Boot, we do still have a servlet container but this one is embedded in the application so we can deploy a single executable. However, you usually do not notice it as a developer because you stop interacting directly with it; missing the deploy to Tomcat step.
So, the deployment got lighter. Instead of maintaining a Tomcat and your application on it, both with two different update cycles and often times different responsible persons, you now have one single component.
Sure, this is a benefit for microservice architectures and it is often used in this context but we are not limited to it. You can still build a monolithic, service orientated, or mixed application with it just using a different deployment concept. This, however, makes it possible to deploy your application to cloud services and leverage their advantages like dynamically adding servers, running multiple instances behind a load balancer without the need to maintain one, etc. Yet, you can also still deploy to the same infrastructure you were using before.
For example, the application mentioned in the introduction was responsible for validating and storing binary data for particular products. It did have a REST and Queue driven API and time-triggered tasks. Maybe it could classify as a microservice. However, the whole landscape wasn’t built with a microservice architecture. On the other side, it was the first system using Spring Boot instead of a regular Tomcat deployment in this team. So, it stood out and made this Java developer nervous.
Spring Boot is just one way of building applications with the Spring Frameworks and it is not exclusively for microservices. You can use it for the same types of applications as before, yet you have a simpler way of deployment now.
What do you think?