The development of Gamecraft starts with the choice of the technology stack and the preparation of a continuous integration environment with Travis CI for the automation of the developments and executions of the Gamecraft tests.
As one of the requirements of this project is to be able to adapt to any workload, it was thought to develop a microservice architecture to support the platform. In this way, being all divided into microservices, the platform can scale horizontally more easily than if a traditional monolithic architecture had been followed.
Software built following a microservices architecture can be broken down into multiple autonomous services so that each of these can be tweaked and then redeployed without compromising the integrity of the application.
Unlike microservices, a monolith application is always built as a single, autonomous unit. The problem is that all change cycles usually end up redeploying the entire application and if you need to scale specific functions of an application, you must scale the entire application instead of just the desired components.
From the way in which the architecture has been designed for this project, it will be much easier for the platform itself to be able to adapt to the workload, in the sense that if several projects are being compiled simultaneously within the platform , you can deactivate existing microservices that are not being used at that moment in order to obtain more resources for the tasks that are being executed or you could deploy more microservices related to the compilation function of the platform in other nodes. If a monolithic architecture had been followed, this would not have been possible and the entire platform would have to be deployed in the other nodes, consuming many more resources that could only be assigned to the compilation.
That said, it is necessary to choose very well what technological stack we are going to use to be able to mount this microservices architecture. As the project will be developed using the Java language, it has been decided to use the following libraries and technologies to shape the project (take care that this is not a definitive list and more libraries and technologies will be used as the development progresses, and it is possible that some technology or library will not appear here) :
- Spring Boot.
- Spring Security.
- Spring MVC REST.
- Spring Data JPA.
- Database updates with Liquibase.
- Elasticsearch to have search capabilities on top of the SQL databases of the platform.
- Angular 4 and Twitter Bootstrap for responsive web design.
- Build, optimization and live reload with Webpack.
- Testing with Junit, Karma, Headless Chrome and Protractor.
- HTTP routing using Netflix Zuul.
- Service discovery using Netflix Eureka.
- Caching with hazelcast.
- Log management with Logback.
Once the technology stack to be used was decided, it began to develop two of the most important components that the project will have. They are important because they are the ones that are going to give shape to the architecture of microservices and their absence would imply that the entire platform stops working correctly. These two components are the following (In the near future I will explain each of them in more detail in another post):
- Gamecraft Gateway is a special type of microservice that provides HTTP routing, load balancing, QoS and security with the rest of the microservices and the Gamecraft Registry.
- Gamecraft Registry is a special type of microservice that implements an Eureka server that serves as a discovery server for the microservices that are going to be deployed for this project. Also, this microservice implements a Spring Cloud Config server, that provide runtime and centralized configuration to the rest of microservices and provides some dashboards to monitor the platform.
Finally, and with the aim of increasing the quality of the project, it has been decided to use Travis CI to automate certain tasks. Currently, whenever a change is made in the repository, Travis CI will compile and execute the tests of the project but in the near future, I plan to link the project to Sonarcloud in such a way that once Travis has finished running the tests, it will upload the code to Sonarqube to analyze the quality of code and obtain reports.
To carry out the Travis CI integration, it was necessary to register a user account on the Travis page and then create a travis.yml file with the instructions to know how to compile the project. This file can be found at the Github repository of the project.