I published a video about it. Check it out:

If you are here probably you are in one of these situations:

1. You want to start using microservices
2. You are already using it

In both cases, you want to use it right and for the right reasons. At least I hope so…

When I go to conferences is common that people ask me about "how to start using microservices?", "what are the best practices?", and so on… and I always ask them the same question: "why do you want to use microservices?".

The usual answers that I got are:

• To scale my application
• To have smaller artifacts
• To save memory (what?)

I even got an answer from a big company where people said: "because our manager demanded it"... Ouch!

Let me tell you: all those answers are conceptually wrong! And the reason is:

You are using microservices to scale software, but it was made to scale people.

At this point, maybe you are uncomfortable on your chair, you are frowning, your disagreeing, or even you are mad at me! 

I get it… give me a few minutes and I'll explain it to you! ;-)

The reason why I'm saying that microservices are made to scale people is a foundation. A concept. A law. Something called "Conway's Law". It states that:

Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.

This was said by Mr. Melvin Conway in a paper written in… 1967! The link to the paper is at the end of this post.

Basically what Mr. Conway is saying is that the structure of your software is directly related to the communication structure of your organization. The way your company communicates is the way that it builds software.

But… how Melvin Conway came to this conclusion?

(I know, you are wondering what the hell all this has to do with microservices? You will get it, I promise…)

In this paper, he mentions a project where the team had 8 people and they needed to deliver two compilers: one for COBOL and another for ALGOL. After some discussions, they decided to assign 5 people for the COBOL compiler and 3 people for the ALGOL compiler.

At the end of the project they had: 

• A COBOL compiler that worked in 5 phases
• An ALGOL compiler that worked in 3 phases

In the paper, you'll see more examples of this human behavior when building software.

So basically it was a sociological observation that ended in a technological result. Interesting, right?

Alright, back to microservices! What does it have to do with Conway's Law?

Let's perform a mental exercise. 

Imagine that one company has 3 teams:

• DBA team
• UI team
• Middleware team

Those teams are organized around themselves. DBAs working together, UI people as well, and so on...

Then let me ask you three questions:

• What the DBA team will deliver?
• What the UI team will deliver?
• What the Middleware team will deliver?

It's quite obvious! DBAs will deliver databases, UI people will deliver UI, and Middleware devs will deliver services, APIs, and things like this.

This is called a siloed structure and it's the classical structure used for companies that build monolith applications.

Now let's imagine another company. It also has 3 teams, but they are structurally quite differently:

• Team 1 has a DBA, a UI dev and a Middleware dev;
• Team 2 has also a DBA, a UI dev and a Middleware dev;
• Team 3, guess what, also has a DBA, a UI dev, and a Middleware dev.

These are what we call cross-functional teams.

Now the one and only question for this company: what each team will deliver?

The tendency of each one of these teams is to deliver what we call a self-contained application. A deliverable that has a database, a UI, and a Middleware.

Can this deliverable be considered a monolith? Well, yes. But a very small one, because the team that built it is smaller.

If it's smaller, it needs to be more specific, more specialized. It addresses one business task that has interactions with the other business tasks built by the other teams.

That's the so-called… microservices!

This concept of siloed and cross-functional teams that led us from monoliths to microservices is very well explored in the famous article about microservices written by Martin Fowler. 

In fact, this article is so important that a lot of people include it in the history of microservices. The link to the article is at the end of this post.

Ok! So far you know:

• Conway's Law
• Companies' communication structure reflects the structure of their software
• Siloed structured companies tend to deliver monoliths
• Cross-functional companies tend to deliver microservices

After all… why did I say that you can be thinking about microservices for the wrong reasons?

Because another thing that I also said: microservices is something made to scale people, not software.

If you look to the companies who are well succeeded using microservices (Amazon, Netflix, Uber, Spotify, to name a few), what they have in common?

When they started getting really big they noticed they had a need of:

1. To scale their team management
2. To do it without loose agility (increasing it, actually)

So they came to the conclusion that they needed smaller and self-managed teams. 

And for those teams to have more agility, they needed to be as decoupled as possible from the other teams, for the sake of independence.

So these teams needed to be cross-functional and empowered enough to make their own decisions related to technology (languages, databases, etc).

(And yes, decoupled teams tend to generate decoupled services! Conway's Law again...)

And suddenly it was born: the microservices!

Notice that all start with a *need*. A need to rearrange the company structure, a need to distribute the teams, a need to increase communication agility. 

In this scenario, microservices are inevitable. And if you don't have any of these needs, you don't need microservices as well.

Alright? I hope I've made my point clear here, and I'm looking forward to seeing your comments about it, so do not hesitate to leave them down below.

References:

• http://www.melconway.com/Home/Committees_Paper.html
• https://martinfowler.com/articles/microservices.html

Have you ever had any doubts about how to start your microservices-based application from scratch? Or how to break down your monolith into many microservices?

Usually, the answers to these questions are not unique, not even likely, which is not helpful at all. What brings another question: is there any safe and solid path that I can follow to have success on my microservices projects?

You bet! Microservices have some specific design patterns that can be a life saving for any project, and this post will show you some of the best of them.

If you are much more a visual person (or would like to see all the code here really working), check its related video:

When using microservice for your projects it's important to do it in the right way and using the right approach, no matter if you are breaking down your monolith or starting a new project using microservice from scratch.

When doing it using design patterns, you'll be able to not only do it properly but also with less effort.

And of course, there are a lot of design partners for microservices. If you ever checked the content of Chris Richardson (which I recommend 100%) you know that he has mapped something around 40 to 50 microservices patterns. That's a lot! And so useful.

Today I'll cover five of them here and they are:

• Externalized Configurations
• Circuit Breaker
• Health Check
• Distributed Tracing
• API Metrics

Creating the project

I create my projects using the site: http://code.quarkus.io

If you do the same, configure your project with your preferences and choose these extensions:

• REST Client
• SmallRye Fault Tolerance
• SmallRye Health
• SmallRye OpenTracing
• SmallRye Metrics

When you are ready, click the "Generate your application" button, download the file, and unzip it.

Externalized Configuration

This is the code of an endpoint that is using an externalized configuration:

https://gist.github.com/eldermoraes/76185aedf5610a0b5f1194121765b3e6

If you compile and execute this code just as it is here, it will print:

Hello, Optional

Because it can't find the "config" property anywhere. So let's add it to your applications.properties file (available in the "resources" folder if you created your project as stated in the previous section):

https://gist.github.com/eldermoraes/7f8c7ce96ea751e44f5ddc2ab24a2ae0

Now, if you compile and execute your code again, it will print:

Hello, Config

It's better because it's getting the value from a config property, but it's still not so good because the property it's still inside the project. So let's move it to the environment.

If you are running your project using the Quarkus plugin for Maven you probably did something like this:

mvn compile quarkus:dev

So do it instead:

mvn compile quarkus:dev -Dconfig=Quarkus

Now if you execute the code it will print:

Hello, Quarkus

This externalized configuration can be at your container, your server, your cluster, wherever your application is running, It will get the configuration from the environment.

Circuit Breaker

Imagine in your house where you have your electrical circuit where all the outlets and lights and are connected. And the circuit is closed because everything is going well.

But once you have some problem inside the circuit (a short circuit, overload, etc), it will open. That way the energy will not flow inside the circuit anymore, keep this energy problem away from your home appliances.

The same happens when we are using microservices and apply the circuit breaker pattern. Once you have some failing microservice the circuit will open. By doing this it will not start a cascade of failing inside your "circuit" (=your microservices that are communicating to each other). 

For example, if you have a microservice giving a timeout error, the circuit will open and it will return an error right away, with no needing to all incoming requests to wait for the timeout to happen.

So, let's do it. This is the code of another endpoint that is using a circuit breaker design pattern:

https://gist.github.com/eldermoraes/f239294539d40d07a1282c2e93fd3227

The proposal here is to show you how to design a microservice using a circuit breaker pattern. So we have a service that is returning a timeout exception. Let's break it down for better understanding:

• @Timeout - defines a timeout limit for this microservice
• @Fallback - defines a method to be used in case of failure (note that the method is implemented at the end of the code with the name "fallback")
• @CircuitBreaker - defines that on every 4 requests (requestVolumeThreshold), if we have 50% of them failing (failureRatio) the circuit will open. Then it should wait 2 seconds (delay) and try to close back the circuit. If it has 2 requests that perform successfully (successThreshold) it will keep closed. Otherwise, it will open and try again after 2 seconds (delay). 

So imagine that you have thousands of requests coming to this microservice and getting this exception. Without this circuit breaker implementation, all those requests would wait until timeout unnecessarily, which would create a huge queue of requests waiting for a response that will not come. That's when a cascade failure happens.

By giving an exception right away you give the requester service to handle it properly and faster.

Health Check API

One of the key aspects of the Cloud Native approach is that your service should be observable. And one of the features you should implement the health checks probes.

There are two probes that you will implement:

• Liveness probe: it will "say" if your microservice is alive or not
• Readiness probe: it will "say" if you microservice is ready to handle requests or not

Usually, your liveness probe won't have too much complexity, so here it is an example of implementation:

https://gist.github.com/eldermoraes/2460cbc362dd87f1a7c47b7de5f96ede

So what makes a class to be your liveness probe:

• To implement the HealthCheck interface
• Be annotated with @Liveness 

Now to the readiness probe. Imagine that you microservice have some required dependency before start answering requests (access some database, third party service, a message queue, etc); here it is where you should validate if this dependency is available/ready before start handling requests:

https://gist.github.com/eldermoraes/5c12dc31ad703b9deec17428bff2af2e

Let's break this code down:

• Interface implementation: the same as for liveness (HealthCheck interface)
• Annotation: @Readiness
• call() implementation: here I made this probe to validate if my blog (http://eldermoraes.com) is up and running. If so, the readiness will be "up". If not, will be "down".

How do these probes work on a Kubernetes cluster?

(I'm assuming that you are writing microservices to be managed in some orchestrated environment and that Kubernetes is the standard option for it today).

• Liveness probe: if it returns a status code (HTTP) different of 2xx, the node manager will kill the pod (where the container is) and will replace it with a brand new one
• Readiness probe: if it returns a status code of 2xx, the manager will start sending requests to it. If not, it will hold on until it is… ready! :-)

Distributed Tracing

This is the easiest one.

https://gist.github.com/eldermoraes/3f78f330ea080a44236a25fe835accf3

You just need to annotate the class/method you would like to trace with @Traced. Now you just need some tracing tool (Kiali, Zipkin, etc).

Side note: for me, this is a great example of the advantages of using standards. It will ease your life in many ways.

Metrics API

Here is a class with some metrics being collected:

https://gist.github.com/eldermoraes/8538cc2306ffb00f330060950c3a3108

Breaking it down:

• @Counted: will collect statistics related to the frequency of calling to this method
• @Timed: will collect statistics related to the time consumed by this method

To see it working, just call these methods many times and then call this URL:

http://localhost:8080/metrics/application

That's it!

I hope it's useful for you. Remember, when we are using standards, we have a lot of heavy lifting of our coding being reduced by the standard. So that's why I like MicroProfile, especially when using it with Quarkus, which gives me a lot of productivity with its developer mode (and, of course, its crazy fast startup).

So this combination between MicroProfile and Quarkus is amazing!

If you tried to implement some of these design patterns, leave your comment here and tell me how it was your experience. And if you have any questions, I’ll be more than happy to answer them!

Learn how to connect external services and configure orchestrated applications in this tutorial by Sebastian Daschner, the author of Architecting Modern Java EE Applications.

The orchestration framework orchestrates and integrates enterprise applications in clustered environments. It takes a lot of work off the used application technology. Container orchestration also greatly simplifies the configuration of orchestrated applications and connection to external services.

Connecting external services

Client controls require URLs to connect against in order to integrate external services. The URLs traditionally have been configured in files, which potentially differed in various environments. In an orchestrated environment, the application can resolve external services using a logical name via DNS. The following code snippet shows how to connect against the cloud processor application:

@ApplicationScoped
public class HelloCloudProcessor {

   private Client client;
   private WebTarget target;

   @PostConstruct
   private void initClient() {
       client = ClientBuilder...
       target = client.target("http://cloud-processor:8080/processor/resources/hello");
   }

   public String processGreeting() {
       ...
   }
}

The same holds true for other URLs (for example datasource definitions). The application server configuration can simply point to the name of the database service and use it to resolve the corresponding instance at runtime.

Configuring orchestrated applications

Resolving services by logical names already eliminates a lot of configuration in the application. Since the same container image is being used in all environments, a potentially different configuration needs to be inserted from the orchestration environment. As shown in the previous example, Kubernetes config maps tackle this situation. The hello-cloud application expects that at runtime a properties file will reside under /opt/config/application.properties. The project code will hence access this location. The following demonstrates the integration of the properties file using a CDI producer:

public class HelloGreeter {

   @Inject
   @Config("hello.greeting")
   String greeting;

   @Inject
   @Config("hello.name")
   String greetingName;

   public String processGreeting() {
       return greeting + ", " + greetingName;
   }
}

The CDI producer is defined similarly to the configuration example shown previously:

@ApplicationScoped
public class ConfigurationExposer {

   private final Properties properties = new Properties();

   @PostConstruct
   private void initProperties() {
       try (InputStream inputStream =
               new FileInputStream("/opt/config/application.properties")) {
           properties.load(inputStream);
       } catch (IOException e) {
           throw new IllegalStateException("Could not init configuration", e);
       }
   }

   @Produces
   @Config("")
   public String exposeConfig(InjectionPoint injectionPoint) {
       Config config = injectionPoint.getAnnotated().getAnnotation(Config.class);
       if (config != null)
           return properties.getProperty(config.value());
       return null;
   }
}

The application loads the contents of the properties file into the properties map and produces the configured values using CDI. All managed beans can inject these values, which emerge from the Kubernetes config map.

In order to realize secret configuration values, Kubernetes includes the concept of secrets. A common practice is to make the contents of the secrets accessible in containers using environment variables.

Java applications use the System.getenv() method to access environment variables. This functionality is used for both secrets and config map values, respectively.

The demonstrated approaches and examples enable an enterprise application to be deployed, managed, and configured in a container orchestration cluster. They are sufficient for a majority of use cases.

You can now connect external services and configure orchestrated applications in Jakarta EE. If you found this tutorial helpful, you can explore Architecting Modern Java EE Applications, an end-to-end guide to designing and developing modern, business-oriented applications using Java EE 8. So if you’re a Java EE developer keen on architecting enterprise-grade applications, this book is a must-read!

First of all, let me tell you about the author. If you have no idea who Thorben Janssen is, you are really missing great content sharing by a great guy. With almost two decades of experience, he is blogger, author (of course!), trainer and consultant. He has been using Hibernate almost from the day one and has a lot to teach.

So have a break now and go follow him on Twitter: https://twitter.com/thjanssen123.

The book is made for developers with at least some basic knowledge of JPA and Hibernate. It is focused to help them with common tasks and problems, from the most basics to the most advanced ones.

The book is structured in a way that's impossible you don't find what you are looking for:

• Setting up
• Basic Mappings
• Advanced Mappings
• Hibernate Specific Queries and Mappings
• Java 8
• Logging
• JPQL
• Native SQL Queries
• Create queries programmatically with the Criteria API
• Stored Procedures
• Caching

And inside each topic you will find tons of solutions. Actually, 70 in total! ;-)

Each solution (may I call it a "recipe"?) use a "problem -> solution" approach: a common problem is described and a solution is showed up. With code! Thank you, Thorben!

Then you can download the full source code of the solution and get more information in the "Learn More" section.

With simple and "straight to the point" explanations, the book helps you to understand that crazy code that your IDE generates when you use some wizard to create entities from the database.

The texts are concise, clear and very well written.

Some of my favorite solutions:

1. From the Basic Mappings section, all solutions dealing with primary key values. Yes, it is basic... but also still bring some pain to many developers due to the different ways it can be done. So those recipes are like gold;
2. From the Advanced Mappings section, the solution that show how to calculate entity attributes using @Formula annotation;
3. The whole Java 8 section!
4. Cache section, specially because I discovered something that I was doing wrong... thanks again, Thorben!

That's my impression of the book. Have you ever read it? If so, leave your comments here and share yours.

Are you a Hibernate/JPA developer and didn't read it? Oh, come on... :-)

Lately many people has been asked me how they could begin with microservices, what they need to learn, what they have to do.

To help answer these questions (and also to help on organizing and prioritizing things), I made this small guide.

The tools mentioned here are not necessarily in order of importance or any other order at all.

Docker

No matter which server did you choose, I'd highly recommend to deploy your application using Docker. Why?

1. Isolation: It's easier to isolate your microservices from each other. You could deploy one microservice per container;
2. More options: You can mix many application servers and/or services in the same environment. Only thing you need to do is to run another container with the service you need. I've wrote an article called "Modular and Reusable Java EE Architecture with Docker" with Bruno Souza and André Carvalho where we explored it in more details;
3. Clustering: Of course, you can build a cluster without containers. But it's easier with them! You can easily manage the amount of nodes for each microservice with a couple of command lines. If you mess somethings, just remove the container and run it again. You can even work with some orchestration and add elastic features to your architecture;
4. Deploying: Deploy your application by deploying your container (called "appliance"). Lot of portability and will also help the Ops guys! See more at Step-by-Step High Availability with Docker and Java EE.

Payara Micro

Although you can use any Java EE compatible server to do it, Payara Micro will give you a much more "ready" environment.

It's small (< 70MB) and has automatic and elastic clustering. It's ready for the cloud and for containers. And it has also some cool ready-to-use integrations that will bring more power to your service without overload them.

Check it out: https://www.payara.fish/payara_micro

Oh... of course, they have a pre-built Docker image available at Docker Hub... ;-)

The API's supported are:

• Servlets, JSTL, EL and JSPs
• WebSockets
• JSF
• JAX-RS
• EJB lite
• JTA
• JPA
• Bean Validation
• CDI
• Interceptors
• JBatch
• Concurrency
• JCache

Microprofile Initiative (community for the win!)

If we will learn something, why not learn together? I'm an all about community person...

Eclipse Microprofile (http://microprofile.io) is a initiative that joins many vendors, communities and individuals around this hot topic. The target is to discuss and create proper standardization for microservice architecture.

You can join as collaborator (see the list at the site) or just watch the mail list and see what is going on. It's a great and not so common opportunity to help on defining the future of something really big.

A Mature CI/CD Process

If you have problems with building/deploying one single WAR, guess what will happen with dozens? Hundreds? Thousands?

Once you multiply independent services and distributions, you also multiply all the problems they bring with them (environment, setup, security, etc).

So if you are wondering if you should break down your monolith, first automate its lifecycle.

Once you are deploying a few artifacts using any level of automation you can evolve it to a more complex scenarios. And then when you reach microservices you will be more comfortable and less susceptible to a painful build, test and deployment processes.

So are you already using microservices? Did you migrate some monolith to this new architecture model? Leave your comments and experiences bellow.