Nerd For Tech
Published in

Nerd For Tech

Microservices with Spring Boot

Spring Boot Is the Most Popular Way to Build Microservices Applications

Most of the job postings for microservice architects and developers ask for experience with Spring Boot. But is Spring Boot the best way to implement your microservice applications? Let’s take a look at the answer.

What Kinds of Issues Do Microservices Address?

The microservice architectural pattern addresses some of today’s more pressing software development, deployment, and operational issues by:

  1. Shortening software development cycles by optimizing agile software development, delivery, and maintenance practices.
  2. Enabling rapid application feature iteration by simplifying software testing, continuous integration, and continuous delivery.
  3. Exploiting the automated deployment, scaling, and fail-over capabilities available with cloud containers and container orchestration.

How Do Microservices Address Those Issues?

Done correctly, the microservice pattern meets or exceeds all the points and the purposes of the famous memo that helped set the stage for Amazon’s unparalleled business agility. This memo is well worth taking a moment to read. It is fundamental to the reasons why microservices make good business sense.

To accomplish its objectives, an individual microservice:

  • Implements a task (or set of closely related tasks) within a single domain bounded context. This is a fundamental characteristic of a microservice and promotes the high level of granularity and separation of concerns that preserves microservice autonomy and independent deployability.
  • Is loosely-coupled, communicating via message passing or events, and needs little or no knowledge of the definitions of other microservices — enforcing separation of concerns.
  • Is autonomous and can be developed and modified with less coordination among the involved development teams — promoting sound agile development practices.
  • Is independently deployable and can be individually tested, rolled out, and rolled back without impacting other microservices — enabling cloud-based automated deployment, scaling, and failover.

Keep these four basic constraints in mind. If an application component does not meet them, it may still be a service, but it is not a microservice — and it is unlikely to deliver all the benefits promised by the microservice architectural pattern — making it difficult, if not impossible, to realize the full promise of microservices in the cloud.

What is Spring Boot?

Spring Boot is an open-source micro framework maintained by a company called Pivotal Software. It provides Java developers with a platform to get started with auto configurable production-grade Spring framework applications. With it, developers can become productive more quickly without losing time on preparing and configuring their Spring application.

Spring Boot makes creating Service-Oriented Architecture (or SOA) services cleaner and easier by hiding the complexities of building and configuring services that run in Java servlet containers — and Spring Boot creates executable JAR files that can be deployed in cloud containers.

DISCUSSION: The term container should not be confused with the Web container (also known as a servlet container) that is the component of a Web server that interacts with Java Servlets. The Web container creates servlet instances, loads and unloads servlets, creates and manages request and response objects, and performs other servlet-management tasks. Often, the proponents of Spring Boot wrongly assume that their services are deployed in containers because they execute in servlet containers.

What’s Wrong with Spring Boot?

Absolutely nothing, as long as you understand that you are building and deploying traditional SOA services — not microservices. Spring Boot is an excellent choice for building and deploying SOA applications, but every Spring Boot-generated executable JAR contains an embedded Web server and a subset of the Spring framework. It is not a microservice.

So, how do the SOA services of Spring Boot stack up against the required attributes of true microservices? Let’s take a look:

  • Spring Boot SOA services are optimized to implement the synchronous HTTP request-response messaging model. Well-designed services utilize the REST architectural pattern to expose services through a defined REST API. With only one caveat, that is a good thing. That caveat is its synchronous request-response messaging model, which is a fundamental limiter of performance. True microservices can implement REST APIs through WebSockets and are designed to implement high performance asynchronous communications between a client and server.
  • Individual Spring Boot SOA services are not independently deployable and cannot be individually tested, rolled out, and rolled back without impacting other services. Though you could package each service separately, each deployable executable would include its own embedded Web server and whatever Spring framework libraries it used — a far from optimal solution. A Spring Boot application can be deployed in a cloud container and orchestrated by Kubernetes. But an application cannot be scaled at an individual service level and certainly cannot implement failover at an individual service level.
  • Because individual Spring Boot services are not independently deployable, they cannot be tested, rolled out, and rolled back independently. That is one of the more serious impediments to realizing the intended benefits of microservices.
  • Whether a Spring Boot service is autonomous and can be developed and modified with limited coordination among involved development teams is a matter of the design principles and development practices within your organization, not with Spring Boot itself. But the fact that a Spring Boot service cannot be tested, rolled out, and rolled back independently makes it more difficult to achieve high levels of service autonomy and development agility.
  • The server side of Spring Boot is essentially a layered architecture. The parts of the Spring ecosystem you wish to use are deployed along with your spring Boot Services. It is important to be aware of both the benefits and the costs of that approach. Those Spring libraries represent reusable functionality that would cost you time and money to implement yourself — assuming you had the skills and resources available. They represent a tangible benefit. Though it is unlikely that you will need all of the features, functions, and code within an entire library — you will still need to deploy the whole thing (including the other libraries that it depends upon) along with your Spring Boot services. There’s nothing micro about that and it certainly impacts the loosely-coupled constraint of the microservices architectural pattern. Choose wisely.

Wrapping Up

Spring Boot is an excellent way to build traditional SOA applications. Before the advent of hybrid cloud computing, it was one of the higher value, lower risk, ways to go. This post is not intended to denigrate Spring Boot as a well-engineered micro-framework. Nor is it intended to be critical of its power to implement and manage traditional SOA services.

However, this post intends to make clear that Spring Boot, though it may be an excellent way to build 20th Century SOA services, was not designed for implementing microservices. Spring Boot’s official documentation states its purpose as:

  • Create stand-alone Spring applications.
  • Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files).
  • Provide opinionated ‘starter’ dependencies to simplify your build configuration.
  • Automatically configure Spring and 3rd party libraries whenever possible.
  • Provide production-ready features such as metrics, health checks, and externalized configuration.
  • Absolutely no code generation and no requirement for XML configuration.

Those familiar with building SOA (Spring or Jakarta) applications, know what a labor saver that can be. But Spring Boot cannot create the autonomous, independently developed, independently testable, independently deployable, independently scalable, and independently switchable (for failover) microservices required for truly cloud-native 21st Century microservices applications.

If your organization needs to exploit the advantages of hybrid cloud computing with agile development, Spring Boot is not the answer.

Spring Boot was designed and implemented for a computing environment and a time that are already passing. The fundamental issue is one of granularity — the level of component granularity at which you can manage component development, testing, deployment, scaling, and failover. All other things being equal, finer grained is better.

The future is in the cloud and true microservices are far superior to SOA services for realizing the benefits of cloud computing.

If you are interested in reading more about the advantages of microservices and cloud computing, we suggest that you take a look at Designing Microservices and Software Architecture for the Cloud posts.

Thank you.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store