Now it is very fashionable to do startups to become a unicorn and to warm a belly for the rest of your life at sea and eat bananas to decide the fate of the IT-industry. This fate has befallen me, too. For a long time my team has been writing small MVPs (minimum viable products) for testing their ideas, whose backend was a monolith.
A little later, circumstances led us to the abyss of container development, and from there to microservices. This has significantly changed our view of development. This is what this article is about!
About how it is customary
Like any normal startupers, we attended a number of training events, gained wisdom and started looking for the very idea that would turn the world upside down. Naturally, we were told at once that first, we had to interview clients (CusDev), then create an MVP and go sell. The sooner we get through this cycle, the better, they said. That's what we all did.
The algorithm of actions when developing a minimal product was standard:
- We deployed a backend project
- have deployed a front-end project
- have made the necessary functionality
- published on a test server
Anyone involved in the design understands that these actions are repeated over and over again. The same ways of working with users, the same forms of registration and authorization, the same packages. Fortunately, a variety of new versions of the same packages and frameworks have been introduced)
Working for the future: the automation path
Like any lazy, normal person, I've decided to automate the routine. Moreover, if you are a startup, time is the most valuable resource. If you automate certain processes once, you will not have to waste time in the future.
The first to be automated was the server: we developed a bottle to deploy the development environment on a combat server. We also wrote scripts that created the project and even shaped it the way we wanted it to be: with all the copies and developments from other projects.
The next stage we needed was automatic publication. Here DevOps came to the arena and behind it dockers... We didn't want to get involved with a lot of new technologies, but the study of these technologies turned out to be not only interesting but also practically useful.
So where are the microservices here?
Good question! We decided that it's better to write the functionality needed in different projects once and then just plug it in as needed. In each project we need to work with users (authorization, registration, changing passwords and other entertainment), we need information blocks which are usually formed in the same way from the backend point of view, we need feedback from users, etc.
Yes, it will take time. You need to understand how the docker works, how to write microservices and how to teach them to communicate with each other. But we only need to write it once) Our developers turned out to be good and inquisitive, that's why we quickly understood the level sufficient for writing MVP. Then we went through the process in more detail and brought the code to a beautiful state.
So what's in the dry residue?
If you press everything described to a couple of paragraphs, you will get the following lists of advantages and disadvantages.
Positive points:
- Automation of development environment deployment
- Automation of project deployment
- Automation of project updates
- Speed of development (once write, always use)
- Fail-safe
Negative moments:
- High entrance threshold (new guys will have a hard time dealing with the entire stack of technology)
- Study of new technologies and approaches
- Sufficient time is needed to start working in this format
I think that's it! It's up to you to decide!
Bonus for curious
We have experimentally developed several microservices that can be useful in very different projects. The list is attached:
- Service for work with users (registration, authorization and other delights)
- User check service (separately to avoid loading the first one)
- Information service (articles, hints and other information for users)
- Service for communication (Email, SMS, Push, etc.)
- Service for payment systems
- Chat service
- Service for referral system
- Comment service