Hello everyone! My name is Viacheslav Aksenov. I am a professional Java/Kotlin backend developer in a large enterprise. I am developing microservices for high-load projects. In my free time, I am writing small pet projects, you can find some of them on my GitHub: https://github.com/v-aksenov
I was thinking about the architecture for another pet project to keep myself busy in my free time and decided to choose a stack that I saw on one of the projects where I worked - Spring Boot + Spring Cloud for configs. Let's go in order.
What is Spring Cloud?
Spring Cloud is a Spring module that has a lot of different things for developing a microservice architecture. There are pieces of infrastructure and other useful goodies. One of the main things that is there is Service Discovery. For example, you can keep in your Spring Cloud application addresses of your other services.
Using Spring Cloud on a large project consisting of 50+ microservices greatly helps to structure the storage of configuration files, configure interaction between microservices, and also simplify the separation of configurations for different circuits - test, stage, production.
But is it justified to use it for a personal project?
My architecture with Spring Cloud for my pet project
My idea was as follows - a Spring Boot application that handles requests for a Telegram bot. The source codes of the application itself are on my GitHub and open for everybody: https://github.com/v-aksenov/whid-bot
I wanted to make it as open as possible so that anyone can use the bot and at the same time not store all configs in GitHub Secrets.
Disclaimer - I find GitHub secrets a very convenient mechanism for storing environment variables that are needed for deployment, but not for configuring an application in production.
In this regard, I needed a place where I could safely store the configuration, change it at any time with minimal effort to run the application.
In my case, this place was the private GitHub repository, where the config file is located, which contains sensitive information. The link to this GitHub repository is stored in a private Spring Cloud project, which stores the private key to access the private repository.
And finally - my Spring Boot service, which connects to the Spring Cloud application at startup in order to get the necessary configs.
What have I achieved?
- security for storing configs of your pet project
- convenience in changing the configuration - made a commit to the configs and restarted the application. No rebuilds or manual restarts
- convenient organization of configs for your future pet projects - you just need to add a configuration file for a new project and that's it
- economical consumption of resources - a spring cloud application has enough 256MB of RAM to work
But any solution has its drawbacks, it was not without them
- 3 repositories instead of one. Yes, I received a template for the future, but not the fact that it will be convenient for me to use it.
- The requirement for monitoring +1 service, which the rest are tied to
- The inconvenience of running locally. Spring cloud is always required to run along with the main application.
- I either need to write configuration for tests separately and assign profiles, or write it inside the application
Conclusions
The architecture I chose has a very interesting feature when used for pet projects - when you try to automate some of the worries during the project, you will not get a wow effect. To fully appreciate the benefits of DevOps practices - you need to use them at least at a minimal level - but in all steps of your project development.
If you want to build a full-fledged pipeline for the CI/CD of your project, then you have to take care of the full-fledged environment. You won't be able to stop halfway.
P.S. Here's what I additionally did to make life easier for myself in the future
- Setup a CI/CD pipeline in GitHub actions, which checks the master branch when new commits appear in it
- since each GitHub action is launched from inside the container, configs located locally in the resources of the tests are used to run the tests
- If the tests are successful, then the artifact is wrapped in a container and sent to the digital ocean container registry
- A script is launched to deploy the container on my image
- All necessary configs for such a CD process are stored in GitHub Actions
Thus, I managed to simplify my life and automate the process of storing configs. I would be glad to read in the comments your solutions that you use for your projects.
Also, I am always open to feedback on my GitHub: https://github.com/v-aksenov
Good luck and clean code to everyone!
Photo by Caspar Camille Rubin