5 stages of microservice development
All those who have heard a lot about microservices, but did not dare to do a single one, are dedicated.
For the reasons for creating and describing all the pros and cons, hundreds of articles have already been written - here I will tell you about the practical side of creation and use.
So, after much deliberation, you decided to do this miracle, maybe because you have turned up a task on the project, which is well suited to the microservice approach, or everyone has already written a few, and you have not had one.
The article does not focus on how to write microservices, each has its own methods, here I will tell in general about the stages of development and delivery of the service to production and test.
I divided the creation process into stages. And here is the first one:
To begin with, we define what tasks microservice will solve. Usually, this is access to some resource on the server (database, queues, or file system) with a little logic on the service itself.
Suppose we need to implement data return for display on a map from a slow storage. The rendering of the microservice will, of course, be done by the client itself. The data represents the coordinates of points on the map with some kind of title.
')
There is a task, now we are determined with the technologies of its solution. Data storage is slow and will not cope with a large flow of requests. In such cases, you can use elasticsearch - it copes well with large loads and can shard and replicate out of the box. We put in it the data in a separate script for later search by it.
Since in our company Wheels Roof Market, it is customary to write microservices on Go, and I have experience writing on Go, it was decided to write on Go. In your case, it can be anything - Nodejs, Java, PHP or any other, preferably compiled language. Since the technology stack also depends on the architecture of the service, at this stage you need to think about it, as well as consider the logic of the work. Here it is worth collecting info from all clients that will use our microservice, in particular from the mobile development team, if any.
After all thoughts on the stack of technology and architecture, the logic of the service we proceed directly to encoding. Determine whether we will write the code base from scratch (I do not recommend it) or start some kind of ready-made framework.
In addition to the main service methods, we describe a special stats method that will return service information via http: the microservice version, the number and codes of processed requests, as well as the launch date - will be used for service purposes and in particular for healthcheck. In order to be able to run microservice in different environments (development, testing, production), you need to create configs for each environment.
After writing the main part of the code, we proceed to the documentation of the service, because this is the most important part - there is no documentation, no service . We describe absolutely all the features of microservice. It is best to get the Readme file for synchronous updating in the project root for this purpose. Or you can use a swagger if someone likes more beautiful.
In principle, it can be said that at this stage the development of microservice is complete, since the code is written, the documentation is written and you tested it (honestly). But actually not. Since the most important, in my humble opinion, the issue of delivery of the service to production is not resolved. And now we have come to the last stage - delivery.
For these purposes, we will use the Docker Swarm CI manager and technology.
I will talk about the assembly in terms of Bamboo (since we use it at home).
The build cycle involves 2 related build plans. The first is to compile a binary file from the microservice source code that is pulled from the repository source code. Compilation takes place in a special Docker container with the version we need. At the output of the first plan, we will have an artifact with a ready-to-run binary. Immediately after the successful completion of the first plan, the dependent (second) plan starts. In the second plan, a docker image is being prepared with the service itself, its configs and deployment parameters from another repository.
For convenience, we configure the first build plan so that when changes occur in the master branch, the build starts automatically.
Next you need to create and configure the Deployment Project for the deployment of microservice. In this project we describe two environments - Test and Production.
Immediately after the successful deployment of each replica, an attempt will be made to launch it and, in case of failure, the deployment will stop so as not to put the remaining running replicas.
We configure the trigger on the Test environment, so that if the master branch is successfully assembled, the warmth to the test is performed automatically.
That's all, now, when the master branch changes, the binary build will start, then the image will be assembled, after which an automatic deployment will take place in the Test environment, and a special Deploy button will be active for the Production environment.
From personal experience I will say that the main problem and complexity of microservices is their delivery to the production server, but if you have people who are friends with the docker, then the problems become several times smaller. Previously, for deployment, we used deb packages, which forced us to do “manual work” with each update of the service and, moreover, degradation of the service was imposed due to the fact that it had to be restarted after installing the new package.
I managed to identify 5 main stages for the development of microservice, I hope this will benefit you and bring into your life a new piece of creativity that we are developing.
For the reasons for creating and describing all the pros and cons, hundreds of articles have already been written - here I will tell you about the practical side of creation and use.
So, after much deliberation, you decided to do this miracle, maybe because you have turned up a task on the project, which is well suited to the microservice approach, or everyone has already written a few, and you have not had one.
The article does not focus on how to write microservices, each has its own methods, here I will tell in general about the stages of development and delivery of the service to production and test.
I divided the creation process into stages. And here is the first one:
1. Task
To begin with, we define what tasks microservice will solve. Usually, this is access to some resource on the server (database, queues, or file system) with a little logic on the service itself.
Suppose we need to implement data return for display on a map from a slow storage. The rendering of the microservice will, of course, be done by the client itself. The data represents the coordinates of points on the map with some kind of title.
')
2. Technology
There is a task, now we are determined with the technologies of its solution. Data storage is slow and will not cope with a large flow of requests. In such cases, you can use elasticsearch - it copes well with large loads and can shard and replicate out of the box. We put in it the data in a separate script for later search by it.
Since in our company Wheels Roof Market, it is customary to write microservices on Go, and I have experience writing on Go, it was decided to write on Go. In your case, it can be anything - Nodejs, Java, PHP or any other, preferably compiled language. Since the technology stack also depends on the architecture of the service, at this stage you need to think about it, as well as consider the logic of the work. Here it is worth collecting info from all clients that will use our microservice, in particular from the mobile development team, if any.
3. Coding
After all thoughts on the stack of technology and architecture, the logic of the service we proceed directly to encoding. Determine whether we will write the code base from scratch (I do not recommend it) or start some kind of ready-made framework.
Lots of implementation on Go
It was decided to start github.com/labstack/echo - it seemed to me the most lightweight and lively project. Further, since we have to go for the data in the elastic, then you need to choose either for working with the elastic github.com/olivere/elastic . For logging we will take github.com/sirupsen/logrus . As a monitoring, you can take github.com/rcrowley/go-metrics or something simpler github.com/cactus/go-statsd-client .
We connect all dependencies in main.go, and in the same file we describe the processing of all public methods.
We connect all dependencies in main.go, and in the same file we describe the processing of all public methods.
In addition to the main service methods, we describe a special stats method that will return service information via http: the microservice version, the number and codes of processed requests, as well as the launch date - will be used for service purposes and in particular for healthcheck. In order to be able to run microservice in different environments (development, testing, production), you need to create configs for each environment.
4. Documentation
After writing the main part of the code, we proceed to the documentation of the service, because this is the most important part - there is no documentation, no service . We describe absolutely all the features of microservice. It is best to get the Readme file for synchronous updating in the project root for this purpose. Or you can use a swagger if someone likes more beautiful.
In principle, it can be said that at this stage the development of microservice is complete, since the code is written, the documentation is written and you tested it (honestly). But actually not. Since the most important, in my humble opinion, the issue of delivery of the service to production is not resolved. And now we have come to the last stage - delivery.
5. Shipping
For these purposes, we will use the Docker Swarm CI manager and technology.
I will talk about the assembly in terms of Bamboo (since we use it at home).
The build cycle involves 2 related build plans. The first is to compile a binary file from the microservice source code that is pulled from the repository source code. Compilation takes place in a special Docker container with the version we need. At the output of the first plan, we will have an artifact with a ready-to-run binary. Immediately after the successful completion of the first plan, the dependent (second) plan starts. In the second plan, a docker image is being prepared with the service itself, its configs and deployment parameters from another repository.
For convenience, we configure the first build plan so that when changes occur in the master branch, the build starts automatically.
Next you need to create and configure the Deployment Project for the deployment of microservice. In this project we describe two environments - Test and Production.
Depla is performed through your crutch python deploatorIn the deployment parameters, depending on the environment, it is indicated in which cluster to deploy (we currently have 4), the number of replicas, processor, memory limits, etc.
Immediately after the successful deployment of each replica, an attempt will be made to launch it and, in case of failure, the deployment will stop so as not to put the remaining running replicas.
We configure the trigger on the Test environment, so that if the master branch is successfully assembled, the warmth to the test is performed automatically.
That's all, now, when the master branch changes, the binary build will start, then the image will be assembled, after which an automatic deployment will take place in the Test environment, and a special Deploy button will be active for the Production environment.
From personal experience I will say that the main problem and complexity of microservices is their delivery to the production server, but if you have people who are friends with the docker, then the problems become several times smaller. Previously, for deployment, we used deb packages, which forced us to do “manual work” with each update of the service and, moreover, degradation of the service was imposed due to the fact that it had to be restarted after installing the new package.
I managed to identify 5 main stages for the development of microservice, I hope this will benefit you and bring into your life a new piece of creativity that we are developing.
Source: https://habr.com/ru/post/331674/
All Articles