Microservices in Practice: tools used for ludotheca-share-mesh

Github repo: https://github.com/marco13-moo/ludotheca-share-mesh

Resources, Tools and Libraries Used

Java Java was used as the programming language across all microservices.

Spring Boot Spring Boot was chosen as the main framework that the system shall be based upon. Spring Boot helped accelerate development and complemented the microservices architecture. Useful features included the use of each microservice having its own embedded Tomcat server, and the use of Spring Boot Actuator. Spring Boot’s MVC and REST annotations further provided rapid API development within the controller subdomain of the core microservices. The framework further aided in seamlessly integrating health checks into each service using Spring Boot actuator.

Spring Boot Actuator Provides health endpoints for the service.

Spring Data JPA Provides rapid implementation of accessing data between Java objects and the persistence layer.

Spring Cloud Spring Cloud provided the necessary distributed systems tooling needed to build out the microservices-based system. The use of Spring Cloud based tooling in development speed up its close Spring integration.

Spring Cloud Netflix Eureka Although a majority of Netflix OSS libraries often used for microservices development are now deprecated, Netflix Eureka was used for client-side service discovery.

Spring Cloud Gateway Spring Cloud Gateway was used to host the API gateway microservice.

Spring Cloud Load Balancer Spring Cloud Load Balancer was used for client-side load-balancing across services when client-side service discovery with Eureka is present.

Spring Cloud Netflix Ribbon The default, yet deprecated, Ribbon load-balancer was used for client-side load-balancing when Kubernetes native service discovery is present.

Use of Gitlab and Gitlab Repositories The development process adhered to one microservice per repository. The reason for this was to allow for each microservice to be developed independently and to be characteristic, being able to leverage the use of autonomous teams to build and deploy each service independently. Thus, a team in software engineering can easily divide into sub-teams and take ownership of specific repositories relating to each microservice.

RabbitMQ Message broker software was used to demonstrate asynchronous messaging patterns as a minor extension.

Dependency Management Tooling Maven was used as most students are familiar with its functionality.

Databases:

• MySQL – This provided compliance with the primary functional requirement of adhering to an RDBMS that is familiar to students.

• H2 – An in-memory database that can be optionally used to work around setting up MySQL locally for developers. Thus, allowing for faster deployment of the system for teaching purposes.

OpenAPI: Allows for auto-generated API documentation of the core microservices.

Testing Tools:

• JUnit – Used for service subdomain unit tests.

• Postman – Used for integration testing of microservice’s controllers.

• Jackson – For request deserialization and response serialization in the context of controller integration tests.

Google Cloud Platform GCP was the main deployment platform for the microservices-based system. The following tools found within GCP were used within a deployment context:

GKE/Kubernetes Google Kubernetes Engine – Used for container orchestration, scaling, as well as leverage of GCP native service discovery. No GCP specific features besides monitoring tools and VPC mapping to GCP-hosted persistence were used. Thus, containerized microservices can deploy on any (managed) running Kubernetes.

Jib and Docker Extensive use of Google Jib was used to build Docker containers of the Spring microservices. Jib was used to build and push the Spring microservices if an additional UI environment is added to each Spring microservice.

GCR/Io GCP’s exclusive Docker registry was used.

CloudSQL MySQL based databases hosted in GCP were used with the cloud deployment of the system.

GKE Monitoring GCP specific monitoring was used when the system was running on a Kubernetes cluster.

Use of Branching As the project can run with either an Eureka or Kubernetes based service discovery implementation, the project have been produced. Each version is clearly annotated with regards to the discovery annotations. Spring configuration settings of each microservice as well as service discovery dependencies according:

• Eureka – Can run on a local Eureka node or in a cloud-based Eureka service discovery. Does require microservices to be containerized.

• RabbitMQPubSub – relates to lending service only, runs with RabbitMQ and forms part of the Eureka branch.

• Master branch or KubernetesBranch – relates to microservices that operate using Kubernetes service discovery. Can run locally or in the cloud.