Book Image

Hands-On Microservices with Spring Boot and Spring Cloud

By : Magnus Larsson
Book Image

Hands-On Microservices with Spring Boot and Spring Cloud

By: Magnus Larsson

Overview of this book

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.
Table of Contents (26 chapters)
Title Page

Rolling back a failed deployment

From time to time, things don't go according to plan, for example, an upgrade of deployments and pods can fail for various reasons. To demonstrate how to roll back a failed upgrade, let's try to upgrade to v3 without creating a v3 tag on the Docker image!

Let's try out the following shorthand command to perform the update:

kubectl set image deployment/product pro=hands-on/product-service:v3

Expect to see the following changes reported by the kubectl get pod -l app=product -w command we launched in the Preparing the rolling upgrade section:

We can clearly see that the new pod (ending with m2dtn, in my case) has failed to start because of a problem finding its Docker image (as expected). If we look at the output from the siege test tool, no errors are reported, only 200 (OK)! Here, the deployment hangs...