Hands-On Microservices with Spring Boot and Spring Cloud

Build and deploy Java microservices using Spring Cloud, Istio, and Kubernetes

Magnus Larsson

• Editore: Packt Publishing
• Anno: 2019
• ISBN:
  9781789613520
• Argomento: Ciencia de la computación
• Categoria: Programación en Java

Apply microservices patterns to build resilient and scalable distributed systems

Key Features

• Understand the challenges of building large-scale microservice landscapes
• Build cloud-native production-ready microservices with this comprehensive guide
• Discover how to get the best out of Spring Cloud, Kubernetes, and Istio when used together

Book Description

Microservices architecture allows developers to build and maintain applications with ease, and enterprises are rapidly adopting it to build software using Spring Boot as their default framework. With this book, you'll learn how to efficiently build and deploy microservices using Spring Boot. This microservices book will take you through tried and tested approaches to building distributed systems and implementing microservices architecture in your organization. Starting with a set of simple cooperating microservices developed using Spring Boot, you'll learn how you can add functionalities such as persistence, make your microservices reactive, and describe their APIs using Swagger/OpenAPI. As you advance, you'll understand how to add different services from Spring Cloud to your microservice system. The book also demonstrates how to deploy your microservices using Kubernetes and manage them with Istio for improved security and traffic management. Finally, you'll explore centralized log management using the EFK stack and monitor microservices using Prometheus and Grafana.By the end of this book, you'll be able to build microservices that are scalable and robust using Spring Boot and Spring Cloud.

What you will learn

• Build reactive microservices using Spring Boot
• Develop resilient and scalable microservices using Spring Cloud
• Use OAuth 2.0/OIDC and Spring Security to protect public APIs
• Implement Docker to bridge the gap between development, testing, and production
• Deploy and manage microservices using Kubernetes
• Apply Istio for improved security, observability, and traffic management

Who this book is for

This book is for Java and Spring developers and architects who want to learn how to break up their existing monoliths into microservices and deploy them either on-premises or in the cloud using Kubernetes as a container orchestrator and Istio as a service Mesh. No familiarity with microservices architecture is required to get started with this book.

]]>

Section 1: Getting Started with Microservice Development Using Spring Boot

In this section, you will learn how to use some of the most important features of Spring Boot to develop microservices.

This section includes the following chapters:

• Chapter 1, Introduction to Microservices 
• Chapter 2, Introduction to Spring Boot
• Chapter 3, Creating a Set of Cooperating Microservices
• Chapter 4, Deploying Our Microservices Using Docker 
• Chapter 5, Adding API Description Using OpenAPI/Swagger
• Chapter 6, Adding Persistence
• Chapter 7, Developing Reactive Microservices

Introduction to Microservices

This book does not blindly praise microservices. Instead, it's about how we can use their benefits while being able to handle the challenges of building scalable, resilient, and manageable microservices.

As an introduction to this book, the following topics will be covered in this chapter:

• How I learned about microservices and what experience I have of their benefits and challenges
• What is a microservice-based architecture?
• Challenges with microservices
• Design patterns for handling challenges
• Software enablers that can help us handle these challenges
• Other important considerations that aren't covered in this book

Technical requirements

No installations are required for this chapter. However, you may be interested in taking a look at the C4 model conventions, https://c4model.com, since the illustrations in this chapter are inspired by the C4 model.

This chapter does not contain any source code.

My way into microservices

When I first learned about the concept of microservices back in 2014, I realized that I had been developing microservices (well, kind of) for a number of years without knowing it was microservices I was dealing with. I was involved in a project that started in 2009 where we developed a platform based on a set of separated features. The platform was delivered to a number of customers that deployed it on-premise. To make it easy for the customers to pick and choose what features they wanted to use from the platform, each feature was developed as an autonomous software component; that is, it had its own persistent data and only communicated with other components using well-defined APIs.

Since I can't discuss specific features in this project's platform, I have generalized the names of the components, which are labeled from Component A to Component F. The composition of the platform into a set of components is illustrated as follows:

Each component is developed using Java and the Spring Framework, and is packaged as a WAR file and deployed as a web app in a Java EE web container, for example, Apache Tomcat. Depending on the customer's specific requirements, the platform can be deployed on single or multiple servers. A two-node deployment may look as follows:

Benefits of autonomous software components

Decomposing the platform's functionality into a set of autonomous software components provides a number of benefits:

• A customer can deploy parts of the platform in its own system landscape, integrating it with its existing systems using its well-defined APIs.
  The following is an example where one customer decided to deploy Component A, Component B, Component D, and Component E from the platform and integrate them with two existing systems in the customer's system landscape, System A and System B:

• Another customer can choose to replace parts of the platform's functionality with implementations that already exist in the customer's system landscape, potentially requiring some adoption of the existing functionality in the platform's APIs. The following is an example where a customer has replaced Component C and Component F in the platform with their own implementation:

• Each component in the platform can be delivered and upgraded separately. Thanks to using well-defined APIs, one component can be upgraded to a new version without being dependent on the life cycle of the other components.
  The following is an example where Component A has been upgraded from version v1.1 to v1.2. Component B, which calls Component A, does not need to be upgraded since it uses a well-defined API; that is, it's still the same after the upgrade (or it's at least backward-compatible):

• Thanks to the use of well-defined APIs, each component in the platform can also be scaled out to multiple servers independently of the other components. Scaling can be done either to meet high availability requirements or to handle higher volumes of requests. Technically, this is achieved by manually setting up load balancers in front of a number of servers, each running a Java EE web container. An example where Component A has been scaled out to three instances looks as follows:

Challenges with autonomous software components

We also learned that decomposing the platform introduced a number of new challenges that we were not exposed (at least not to the same degree) when developing more traditional, monolithic applications:

• Adding new instances to a component required manually configuring load balancers and manually setting up new nodes. This work was both time-consuming and error-prone.
• The platform was initially prone to errors in the other systems it was communicating with. If a system stopped responding to requests that were sent from the platform in a timely fashion, the platform quickly ran out of crucial resources, for example, OS threads, specifically when exposed to a large number of concurrent requests. This caused components in the platform to hang or even crash. Since most of the communication in the platform is based on synchronous communication, one component crashing can lead to cascading failures; that is, clients of the crashing componen...