Microservices with Spring Boot & Spring Cloud

Monolith

Before we talk about microservices, let us go back to our era where we use to model enterprise application as large modular monolith, i.e bigger deployable artifact in the form of web app /enterprise app (WAR/EAR). Of course we need external server to deploy this and test the application. Any changes needed for any of the module, we need to redeploy complete enterprise app and test those changes. It is very time consuming and of course it is most resource intensive.

We need to do capacity planning well in advance and procure the resources accordingly to serve the user demand. We need to put all those resources in clustering well in advance to serve the business need. Most of the time ,resources are idle ,only few moments we may see peek load and this clustering environment will serve our most of our architecture

NFR, increasing the total cost of ownership.

Challenges of Monolith

• Resource Intensive

• No Agility

• Increase total cost of ownership

• Technology update/rewrite is complex - No Polyglot

• Multiple team share the same codebase

Today the era of cloud computing which gives better control, flexibility and can acquire the resources on demand. This will help us to reduce the total cost of ownership, robust, scalable, fault tolerance & resilient. That is where most of the organization, migrating to Cloud. In this context, Cloud Native Strategy play a an important role.

Cloud Native Strategy promote

• Microservices

• Containerization

• DevOps

• Agility

Let us discuss below

• Why Microservices

With Microservices Architecture and containerization, we do support cloud native application development which helps us to overcome the challenges of larger monolith as described above.

It promotes

1. Single codebase per service

2. Independent service team developing each service

3. Service per business capability

4. Independent development & deployment

5. Decentralized Governance

6. Agility

• What exactly is Microservices

Microservices is an architectural style that structures an application as a collection of small autonomous services, modeled around a business capability.

Each Service is independent, self contained, build around business capability. It promotes SRP principle.

Challenges of adopting microservices

1. Being distributed in nature, need more skilled resource

2. Getting domain boundary

3. Fault tolerance & Resiliency

4. Observability Metrices

5. Security

Microservices Features

• Decoupling – Services within a system are largely decoupled. So the application as a whole can be easily built, altered, and scaled

• Componentization – Microservices are treated as independent components that can be easily replaced and upgraded

• Business Capabilities – Microservices are very simple and focus on a single capability

• Autonomy – Developers and teams can work independently of each other, thus increasing speed

• Continuous Delivery – Allows frequent releases of software, through systematic automation of software creation, testing, and approval

• Decentralized Governance – The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems

• Agility – Any new feature can be quickly developed and discarded again

Principles Behind Microservices

• Independent & Autonomous services

• Scalability

• Resilient & Fault Isolation

• Seamless API integration

• Continuous Monitoring

• Decentralization

• Continuous Delivery with DevOps Integration

Microservices Best Practices

• Service per business capability

• Each service can be developed with different polyglot stack

• Have a separate version control strategy for each service

• Containerize your microservices to build consistent experience across environments

• Loosely coupled, high cohesion & single bounded context

• Adopt DevSecOps model to mitigate security vulnerability in microservices

• Make use of API & Events for communication between microservices

• Separate build for each microservice and automate the build & deployment with CI/CD

• Centralized Logging & Monitoring system

Tools & Techniques to develop microservices

Spring Boot

• Is the most popular and widely used Java framework for building Microservices.

• Opinionated view and maven configuration

• Autoconfiguration to load default configuration

Today most of the organization make use of Spring Boot to design, develop and deploy the applications/services in a Cloud environment. For this we need to make sure that it is Cloud Native, that is where Spring Cloud fill the space.

Spring Boot Actuator

In essence, Actuator brings production-ready features to our application.

Monitoring our app, gathering metrics, understanding traffic, or the state of our database become trivial with this dependency.

Actuator is mainly used to expose operational information about the running application — health, metrics, info, dump, env, etc. It uses HTTP endpoints or JMX beans to enable us to interact with it. Once this dependency is on the classpath, several endpoints are available for us out of the box. Please refer below endpoints for reference

• /beans returns all available beans in our BeanFactory. Unlike /auditevents, it doesn't support filtering.

• /health summarizes the health status of our application.

• /metrics details metrics of our application. This might include generic metrics as well as custom ones.

• /prometheus returns metrics like the previous one, but formatted to work with a Prometheus server.

• /conditions, formerly known as /autoconfig, builds a report of conditions around autoconfiguration.

• /configprops allows us to fetch all @ConfigurationProperties beans.

• /env returns the current environment properties. Additionally, we can retrieve single properties.

• /auditevents lists security audit-related events such as user login/logout. Also, we can filter by principal or type among other fields.

• /heapdump builds and returns a heap dump from the JVM used by our application.

• /info returns general information. It might be custom data, build information or details about the latest commit.

• /logfile returns ordinary application logs.

• /loggers enables us to query and modify the logging level of our application.

• /sessions lists HTTP sessions given we are using Spring Session.

• /shutdown performs a graceful shutdown of the application.

• /threaddump dumps the thread information of the underlying JVM.

Spring Cloud

is essentially an implementation of various design patterns to be followed while building Cloud Native applications. We can make use of various Spring Cloud Modules and focus on solving business problem than worrying about infrastructural concerns.

Following are just a few of Spring Cloud modules that can be used to address distributed application concerns:

Spring Cloud Config :

To externalize configuration of applications in a central config server with the ability to update the configuration values without requiring to restart the applications. We can use Spring Cloud Config Server with git as config repository.

Spring Cloud Bus :

We can link multiple microservices to message broker for the common configuration changes to be broadcasted.

Service Registry and Discovery:

As there could be many services and we need the ability to scale up or down dynamically, we need Service Registry and Discovery mechanism so that service-to-service communication should not depend on hard-coded hostnames and port numbers. Spring Cloud provides Netflix Eureka-based Service Registry and Discovery support with just minimal configuration. We can also use Consul for Service Registry and Discovery.

Cloud Gateway/Netflix ZUUL

We need API gateway to control service communication, security (authentication, authorization ),routing the request based on URL pattern to respective microservice.

Spring Cloud Security: Some of the microservices needs to be accessible to authenticated users only and most likely we might want a Single Sign-On feature to propagate the authentication context across services. Spring Cloud Security provides authentication services using OAuth2, JWT

Spring Cloud Data Streams: These days we may need to work with huge volumes of data streams using Kafka or Spark etc. Spring Cloud Data Streams provides higher-level abstractions to use those frameworks in an easier manner.

Spring Cloud Contract: There is a high chance that separate teams work on different microservices. There should be a mechanism for teams to agree upon API endpoint contracts so that each team can develop their APIs independently. Spring Cloud Contract helps to create such contracts and validate them by both service provider and consume

Spring Cloud Sleuth: One of the pain-point with microservices is the ability to debug issues. One simple end-user action might trigger a chain of microservice calls, there should be a mechanism to trace the related call chains. We can use Spring Cloud Sleuth with Zipkin to trace the cross-service invocations.

Circuit Breaker: In microservices based architecture, one service might depend on another service and if one service goes down then failures may cascade to other services as well. Spring Cloud provides Netflix Hystrix based Circuit Breaker to handle these kinds of issues.

Tools for Testing API

Swagger2: Swagger2 is an open source project used to generate the REST API documents for REST services. It provides a user interface-swagger-ui to access our REST services via the web browser and test those endpoints.

POSTMAN : Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration. It helps you be more efficient while working with APIs. Using Postman, you can construct complex HTTP requests quickly, organize them in collections and share them with your co-workers.