This blog series will introduce you to some of the foundational concepts of building a microservice-based platform using Spring Cloud and Docker.
What is Spring Cloud?
Spring Cloud is a collection of tools from Pivotal that provides solutions to some of the commonly encountered patterns when building distributed systems. If you’re familiar with building applications with Spring Framework, Spring Cloud builds upon some of its common building blocks.
Among the solutions provided by Spring Cloud, you will find tools for the following problems:
Spring Boot
The great part about working with Spring Cloud is that it builds on the concepts of Spring Boot.
For those of you who are new to Spring Boot, the name of the project means exactly what it says. You get all of the best things of the Spring Framework and ecosystem of projects, tuned to perfection, with minimal configuration, all ready for production.
Service Discovery and Intelligent Routing
Each service has a dedicated purpose in a microservices architecture. When building a microservices architecture on Spring Cloud, there are a few primary concerns to deal with first. The first two microservices you will want to create are the Configuration Service, and the Discovery Service.
The graphic above illustrates a 4-microservice setup, with the connections between them indicating a dependency.
The configuration service sits at the top, in yellow, and is depended on by the other microservices. The discovery service sits at the bottom, in blue, and also is depended upon by the other microservices.
In green, we have two microservices that deal with a part of the domain of the example application I will use throughout this blog series: movies and recommendations.
Configuration Service
The configuration service is a vital component of any microservices architecture. Based on the twelve-factor app methodology, configurations for your microservice applications should be stored in the environment and not in the project.
The configuration service is essential because it handles the configurations for all of the services through a simple point-to-point service call to retrieve those configurations. The advantages of this are multi-purpose.
Let's assume that we have multiple deployment environments. If we have a staging environment and a production environment, configurations for those environments will be different. A configuration service might have a dedicated Git repository for the configurations of that environment. None of the other environments will be able to access this configuration, it is available only to the configuration service running in that environment.
