Let’s start with a simple tic tac toe game that I forked. https://codepen.io/dovidkopel-the-bold/pen/zLvWbz. This is the original repository.

This article is not about the actual language you use as much as it is about the architecture you use. This example is in fact a web-based game. Generally JavaScript is the language used for scripting in the browser. I’m not going to deal with that at all right now. In fact I’m going to create a very simple Java version of the same game that has a Java backend. The first version will be ascii based and

I recently read this post and believe that many companies who jumped quickly on the microservices wagon may have many similar challenges.

As always I am going to be very direct and to the point. The businesses I have in mind in this article are growth oriented. If you are a small business unit that only has small goals please recognize that best practices need to be adjusted for each organization.

This is going to center around the general architecture for a complex system for an enterprise organization. I have recently noticed an increase in clothing labels using the phrase “one size fits most”, I just wonder if someone sued and they stopped saying “all”. I use this quip regarding #software #architecture.
There is simply no “one size fits all”.

A great deal has been covered on the topic of microservices, containerization, and serverless by many very smart people. I’m hoping to provide some direction and specific techniques.

I’m a big fan of the Spring Framework and their design patterns. Even if I’m not using the Java language I try to best follow many of their approaches. To begin with some very simple items that cannot be overstated Less is more, keeping things simple, isolated, and not repeating yourself are all really one.

• Eliminate code duplication.
• Keep code bodies simple and to a very exact purpose.
• Use interfaces.
• Use inheritance.
• Code should be self-documented with variable names, class names, and function names. Anything more complex should have explicit documentation.
• Functions or methods should not exceed a few lines (5 ideally).

Now without talking about SOA…whatever that is. Let’s focus on simply interfaces. If we create our code with strongly typed interfaces anything and everything we talk about after this point should be simple. I’m going to restate that. If we properly design our code with strongly typed interfaces and focus each interface on a very select set of capabilities. You will always be in a pretty good position.

What I’m trying to tell you is that before you even look at the monolithic or microservices discussion, you must be at this point. I haven’t mentioned infrastructure, DevOps, testing, or anything else. Those are important, but ultimately your code having proper modular (keyword) architecture is paramount.

Utilizing modules, packages, or namespaces you can modularize your code. Again, nothing new here at all. I’m a big fan of object oriented programming, despite its recent bad reputation. Let’s say I have an enterprise system that connects event-driven applications. I want to allow the user to be able to upload a new jar file to s3. From that jar the system may dynamically load and unload modules and subscribe/unsubscribe to specific events.
With java I can dynamically pull the jar object.

Then I would read through the jar and look for any classes the implement the established interfaces. Let’s say that we have an interface called MessageConsumer:

public interface MessageConsumer<T> extends java.util.function.Consumer<T> {
	// Returns an array of strings 
	// that are used to subscribe this
	// consumer to the topic.
	String[] getSubscriptionTopics();
}

Let’s say that we have a jar with a few implementations of that interface in it. The system would automatically load those classes and subscribe them to their respective topics. Now this jar was added dynamically at runtime by using a ClassLoader.

With the same sort of jar isolation you can simply have various jars loaded like dependency in a maven project.

Resources

Martin Fowler (My architectural mentor)

• https://www.martinfowler.com/microservices/
• https://www.martinfowler.com/articles/microservices.html
• https://martinfowler.com/articles/break-monolith-into-microservices.html
• https://www.martinfowler.com/articles/microservice-trade-offs.html

• https://www.martinfowler.com/bliki/MicroservicePremium.html

• https://adamdrake.com/enough-with-the-microservices.html

Others

• http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository
• https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9
• https://medium.com/@pavanbelagatti/microservices-mono-repo-vs-multiple-repositories-6e139b5ca44a
• https://medium.com/@somakdas/code-repository-for-micro-services-mono-repository-or-multiple-repositories-d9ad6a8f6e0e
• https://dzone.com/articles/concerns-around-managing-many-microservice-reposit