Last Updated on September 24, 2023 by KnownSense
Automation in Microservices is another key design principle for our architecture, and the main thinking behind this is to use tools for automated hosting, testing, and deployment.
Let’s deep dive in different automation strategies.
On-Demand Hosting
By automated hosting, we mean once we have our software architecture perfected, i.e. our production environment perfected, we want the ability to automatically, using various tools, to recreate that environment again either as a development environment or as a testing environment or even a pre‑production environment that we can use to check our changes before they actually go out to production. This type of automatic creation of an environment for our microservices architecture is only possible thanks to hosting technologies like virtual servers and cloud platforms and containers and the idea of having Infrastructure as Code.
The basic idea is we can centralize a configuration for our environment within an automation tool and then combine this with templating for virtual servers and containers, both which are a type of virtual machine that can basically run our microservices containing all their dependencies. But the key idea is I can have templates and images that are ready to go to host my microservices architecture. Then by combining this with centralized configuration for each one of our environments, along with code that describes our infrastructure and can actually recreate entire environments, we can both recreate entire environments as different environments, but we can also scale out parts of existing architecture to meet performance requirements. So as part of your microservices architecture development, definitely look at on‑demand hosting automation tools, which will allow you to recreate environments and scale out automatically. Remember, these tools are both available on‑premise and on major cloud platforms. All of this does affect design. Microservices architectures are complicated, and anything that you can do to make your lives easier is definitely useful, and having Infrastructure as Code concepts where you can describe your environments using code that you can version control is another step towards making things simpler.
Automated Deployment Pipeline
Automated Code Build and Compile
Another key part of your automation strategy needs to be an automated deployment pipeline, and this basically means all your microservice code changes are done by your developers and then committed to a central source control repository, which is basically a database of all the code that belongs to your microservices architecture. Then just by committing the code changes to this centralized source control repository triggers off an automatic build of that code to see if the code compiles and still works. This automation build tool has all the configuration to automatically create builds, and it has all the configuration to also pull in any dependencies that are required for the build. This centralization of all the build configuration using this automation build tool means that your builds are always consistent and reliable. Basically, nobody has to sit there and manually work out exactly how to build your microservices into a working application that could be deployed. By building your software automatically, you get quick feedback on if your code actually compiles, i.e. if your changes are actually workable at a code level.
Automated Test
But the feedback just doesn’t stop there. Our automation build tools can be also configured to run automated tests, tests which are basically code to test the functionality of our microservices to see if they still work as designed and to see if they still integrate with other microservices within our microservices architecture. These tests are normally known as unit tests and integration tests, but that are an amazing way of testing your software changes because they always consistently work in the same way and give you quick feedback. For a complex architectural style, like microservices manually testing everything, is just not an option. Regression testing all your software changes with all other functionalities will just take way too long. This is why automated tests like unit tests and integration tests are perfect, because they consistently run in the same way and give you quick feedback. So if your code change breaks something within the software architecture, you’ll get immediate feedback, and you can resolve the issue immediately.
Automated Deployment
So as well as automated builds an automated tests, automated deployment is also a key part of our automated deployment pipeline strategy. Again, for this, we use a special automation tool, which not only contains configuration regarding the environment we’re going to deploy to, but it also contains configuration for the releases, i.e. the releases of our microservices, as well as information regarding versions of our microservices. So not only can we automatically deploy specific microservices to specific environments, but we can also deploy specific versions. If things go wrong, we can automatically roll back specific versions to prior versions in order to rectify the issue. Again, doing all this manually and remembering the correct configuration for the release for the environment and for the versions would be a nightmare and especially a big nightmare if things go wrong and you need to roll back quickly. So automation deployment is definitely a key part of your strategy. All this quick automation and quick feedback also means we can have quality gates within our automated deployment pipeline. So when our developer has made their changes and automatically deployed their changes to a development environment, we can then promote that build to a test environment. Our testers, our QA professionals, can then run their own automated tests using their own specific test data for specific scenarios, and they can also then deploy the build to their own test environment, which, again, contains their own specific test data to test specific scenarios. Once deployed into the test environment, they can then do some explorative testing within the test environment just to make sure everything works end to end. Then as the next quality gate, we can do this whole process again in a pre‑production environment which is configured near to production‑level configuration. Once we are happy with all these quality gates, we are then ready to deploy to production, and again, we can use the same tools with production‑level configuration to deploy to our production environment, and again, all this is done automatically. If we face an issue, we can again quickly roll back our changes quickly because we know we have all the configuration within our automation deployment tool in terms of release configuration and in terms of environment configuration.
Conclusion
So hopefully you can see why automation as a design principle is key for our microservices architecture. Microservices architectures are complex, and anything we can do to reduce manual tasks to reduce errors is an advantage. And by centralizing and automating all the configuration for our releases, for our environments, for the versions of our microservices, we are basically eliminating all these errors that happen when things are done manually.