Lego Monolith

A monolith microservice POC.

Overview

For many organizations a full microservice architecture will present many organizational and technological problems. In order to be "tall enough" to use a full microservices architecture an organization should meet the following basic characteristics (http://martinfowler.com/bliki/MicroservicePrerequisites.html):

1. Rapid provisioning of new servers. Ideally cloud native.
2. Monitoring. Concepts such as correlated tracing, circuit breaking and self-healing services require a high degree of maturity in your monitoring capabilities.
3. Rapid application deployment. Continuous Deployment. A DevOps culture.
4. Autoscaling. Ability to scale a single service when load increases.
5. Governance around service contracts.

Many organizations struggle with several aspects of this; the lego monolith will allow product teams to embrace several aspects of microservices without having to meet all the prerequisites. The benefits:

1. Decoupled Design. Each service lives in it's own bounded context that can only communicate with other services over decoupled interfaces, e.g. REST or SOAP.
2. Choice of language. Not to the same extent as a true microservice architecture, however each service can be built in any JVM language. e.g. Java, Groovy, Scala, Kotlin, etc.
3. Choice of persistence. Each service should own the data source. e.g. traditional RDBMS, document DBs, flat files, etc.
4. Asynchronous. This POC includes an ActiveMQ message broker that services can publish and listen to.

Build & Run the application

The application can be run from the command line: ./gradlew bootRun

To build the application execute: ./gradlew [clean] build. clean is optional.

The executable jar file will be created in parent-web/build/libs/ and can be executed from the root of the project using this command: java -jar parent-web/build/libs/parent-web-1.0.0.jar