Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This is the second of a two part article about building centralised configuration with Spring Cloud Config Server. In this post we’ll take the the two Spring Boot services created in part one and run them on Kubernetes.
We’ll initially deploy to a local cluster before stepping things up and deploying to Azures manged Kubernetes Service, AKS. By the end of this post you should have two Spring Boot services deployed to an AKS cluster as shown in the diagram below.
This is the first of a two part article where I’ll show you how to use Spring Cloud Config Server to build centralised configuration for your microservices. In this first post we’ll create a Config Service that pulls its data from a Git repo and exposes it to other services. We’ll also create a consumer, a Config Consumer Service that pulls from the Config Service on startup. The diagram below shows how the services will interact.
In part two of this article we’ll take the two services and deploy them to Kubernetes. We’ll initially deploy and test on a local Kubernetes cluster, before deploying on Azures manged Kubernetes Service, AKS.
One of the great things about RestTemplate is its simplicity. You simply instantiate it like this... RestTemplate restTemplate = new RestTemplate(); and off you go. Under the hood, Spring automatically creates and registers a number of message converters to handle various data formats for requests and responses.
A MappingJackson2HttpMessageConverter uses Jackson to map POJOs to JSON and vice versa. When the MappingJackson2HttpMessageConverter is created it's given a new instance of ObjectMapper. A default instance of ObjectMapper is fine is many cases, but there are times when you might want to customize the ObjectMapper used.
I’ve always been a fan of commenting code. To me, it’s a no brainer, the sensible thing to do, and a fundamental part of building software that’s easy to understand and maintain. Not everyone agrees though. Some argue that comments are unnecessary and simply shine a light on code that isn’t as expressive as it should be. In this post, I’ll try to counter those arguments and tell you why I think quality comments are an important part of building software that easier to understand and maintain.
You may also like: Should I Read Books as a Software Developer?
As developers, we spend a considerable amount of time reading and trying to understand other people's code. At times this can be a difficult and frustrating task. Most of us have been in a situation where we’re neck-deep in legacy code with no documentation, no unit tests and not a comment in sight. Chances are the guy who wrote it isn’t around anymore and we’re left to our own devices to figure out WTF is going on. Not much fun, is it?
This post is based on one I wrote a few years ago about building contract first web services with Apache CXF and Spring. The previous post didn't use Spring Boot and most of the Spring and CXF configuration was via XML. This post moves things forward a bit by using the latest version of CXF and Spring Boot.
We're going to build a simple Spring Boot app that exposes SOAP web service using Apache CXF. The service will have a single operation that takes an account number and returns bank account details. If you're impatient and want to jump ahead you can grab the full source code from GitHub.
In this post, I'm going to show you how to test a Spring REST endpoint without a servlet container. In the past, integration tests were the only meaningful way to test a Spring REST endpoint. This involved spinning up a container like Tomcat or Jetty, deploying the application, calling the endpoint, running some assertions, and then stopping the container. While this is an effective way to test an endpoint, it isn't particularly fast. We're forced to wait while the entire application is stood up, just to test a single endpoint.
An alternative approach is to write vanilla unit tests for each REST controller, manually instantiating the Controller and mocking out any dependencies. These tests will run much faster than integration tests, but they're of limited value. The problem is, by manually creating the Controller outside of the Spring Application Context, the controller loses all the useful request/response handling that Spring takes care of on our behalf. Things like:
Managing application configuration in a traditional monolith is pretty straight forward. The configuration is usually externalized in a properties files on the same server as the application. If you need to update the configuration you simply amend the properties file and restart the application. Things can get a little tricker with microservices, but why is that?
Microservices are composed of many small, autonomous services, each with their own configuration. Rather than a centralised properties file (like the monolith), configuration is scattered across multiple services, running on multiple servers. In a production environment, where you likely have multiple instances of each service, configuration management can become a hefty task.
Java is often criticized for being unnecessarily verbose when compared with other languages. Lombok provides a bunch of annotations that generate boilerplate code in the background, removing it from your classes, and, therefore, helping to keep your code clean. Less boilerplate means more concise code that’s easier to read and maintain. In this post, I’ll cover the Lombok features I use more regularly and show you how they can be used to produce cleaner, more concise code.
Lots of languages infer the local variable type by looking at the expression on the right-hand side of the equals. Although this is now supported in Java 10+, it wasn’t previously possible without the help of Lombok. The snippet below shows how you have to explicitly specify the local type:
The guys at Netflix have developed and open sourced (among many other things) Feign and Ribbon. These libraries can help you as a developer to build robust, fault-tolerant service integrations. Best of all, they've been tested in the wild by Netflix, who use both libraries extensively in their own microservices architecture. In this post, we'll look at Feign and Ribbon to see how they can be used in the context of a Spring Boot application.
Feign is a library that helps developers create declarative HTTP clients by simply defining an interface and annotating it. At runtime, Feign creates the HTTP client implementation for the interface. We'll look at this in detail with some sample code later.