Centralizing Configurations with Spring Cloud Config

Bing Liu Microservices, Spring Boot, Technology Snapshot Leave a Comment

When the Microservices approach became popular a few years ago, many companies rushed to build their own microservices or to convert their legacy applications into microservices. Over the years, companies have implemented an abundance of microservices, mostly with Spring Boot. Each of them manage their own configurations across deployment environments like Dev, Test, and Prod.

Due to the nature of a complex business process, there are many common configurations (e.g. databases, queues, email servers, and FTP servers, etc.) used in the distributed services. This can result in services having redundant and confusing configs on a distributed system. It can become challenging to update the configs for too many services on a distributed system across multiple environments.

Thankfully, Spring Cloud Config provides the implementation to successfully resolve these issues. It provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications.

In this post, I’ll demonstrate Config Server and Client with example code. I’ll show you how to use Git or a local repository as a central place to store all the config files. The diagram below illustrates how the distributed client services (e.g. Investment Position/Price/Reporting Data service) fetch their configuration from the Config Server, which in turn retrieves them from one central place.

Spring Batch Testing & Mocking Revisited with Spring Boot

Jonny Hackett Java, Spring, Spring Batch, Spring Boot, Technology Snapshot, Testing Leave a Comment

Several years ago, 2012 to be precise, I wrote an article on an approach to unit testing Spring Batch Jobs. My editors tell me that I still get new readers of the post every day, so it is time to revisit and update the approach to a more modern standard.

The approach used in the original post was purely testing the individual pieces containing any business logic. Back then, we didn’t have some of the mocking capabilities that we have today, so I went with an approach that made sense at the time.

However, there have been a few improvements in the past several years. One of those improvements has been the ability to Mock beans within a Spring Context. That’s where the @MockBean annotation comes to the rescue.

Quick Start: AWS SQS + Spring Boot Processing FIFO Queues

Brandon Klimek AWS, Microservices, Spring Boot, Technology Snapshot Leave a Comment

AWS SQS (Simple Queue Service) can provide developers with flexibility and scalability when building microservice application(s). In this quick start tutorial, we will demonstrate how to configure a FIFO queue for a fictional online marketplace.

What Is A FIFO Queue?

A FIFO (first in, first out) queue is used when the order of items or events is critical, or where duplicates items in the queue are not permitted. For example:

– Prevent a user from buying an item that isn’t available on a marketplace.

Spring Boot and React: Happily Ever After

Matt McCandless Problem Solving, React, Spring Boot, Technology Snapshot Leave a Comment

So you have mastered Spring Boot and started toying around with React. Now you want React to talk to your Boot app as your back-end API. That’s fabulous. You probably already know how to do this, but there is a kicker. You want to package them and start both of them as just one project.

Well, you’re in luck! This blog is going to take a couple of simple projects and combine them into one project. Lace up your boots and get ready to React!

Gaining Docker Image Size Efficiencies By Separating Application Layers

Luke Patterson Docker, Java, Problem Solving, Spring Boot, Technology Snapshot Leave a Comment

Problem

I was pushing a new Docker image tag for each application code commit, and the admins of the private registry were getting annoyed at how much space I was using.

Solution Summary

Yes, I know there are strategies to clean up old tags but I first wanted to reduce the impact of the tags I was pushing. With the right layering strategy, I knew I could reduce the net registry size increase of consecutive tag pushes.

I wanted to only push what had actually changed in the application. In addition to reducing the impact on the registry, having smaller tag deltas could possibly speed up rolling deployments since nodes could potentially have less to download.