Hands-On Microservices with Spring Boot and Spring Cloud
Build and deploy Java microservices using Spring Cloud, Istio, and Kubernetes
Magnus Larsson
- 668 pages
- English
- ePUB (mobile friendly)
- Available on iOS & Android
Hands-On Microservices with Spring Boot and Spring Cloud
Build and deploy Java microservices using Spring Cloud, Istio, and Kubernetes
Magnus Larsson
About This Book
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.
]]>
Frequently asked questions
Information
Section 1: Getting Started with Microservice Development Using Spring Boot
- 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
- 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
My way into microservices
Benefits of autonomous software components
- 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
- 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...