Translated from 日本語 • View original Hello. I'm Akiyama, Azure Cloud Solution Architect and DevOps Engineer. I am in charge of the infrastructure lead for our own services.
The last blog I wrote was two years ago, so here I will summarize the recent infrastructure situation. Looking back on the first anniversary of the introduction of AKS with our own service Mamoru Biz
Efficiency Increases with Growing Product Development Teams
This is the biggest change. Two years ago, it was the same as Mamoru Biz (now Colorkrew Biz), but now it has a wide range of products, including "Colorkrew ID", "Colorkrew Intra", "AI Chat system", and products under development. Both products leverage cloud infrastructure, so you need to efficiently build the infrastructure of new systems.
The infrastructure team for our services currently has four people, including me, all of whom are concurrently working on other tasks such as contracted projects.
In the past one or two years, we have roughly promoted the following contents to create a situation where infrastructure operations are not delayed.
- Template requests from the product development team
- Modularization of infrastructure deployment code
- Trial and error and feedback on the latest technology
This entry explains them in order.
Template requests from the product development team
We use GitHub for source code management. When new product development begins or when an existing product requires new cloud infrastructure, the infrastructure team will compile the content on GitHub Issue on their own.
And since it has become a general pattern, we have prepared an issue template and asked the product development team to write about it. ref: Set up an issue template for a repository
The contents are as follows
- Required cloud infrastructure resources (DB, Storage, ...) etc)
- Kubernetes resources (Pod, CronJob, ... etc)
- Deployment flow
- Due dates by environment (Debug is ASAP, Prod is 2 months later, ... etc)
It's inefficient to fill in the necessary information with a chat rally, so it's efficient to cover most of the information at once. In addition, by referring to the infrastructure requests of other products, the product development team can see the side effect of preventing silos and leading to horizontal connections and understanding.
Modularization of Infrastructure Deployment Code
Infrastructure - Terraform
Our team uses Terraform to manage the infrastructure of our services. Terraform provides a feature called Modules, which we aim to use to improve reusability and maintainability. (Unfortunately, not all of them are modules.) It takes a lot of effort to rewrite deployed code once written into a module. )
ref: Modules Overview
Kubernetes - Helm
For Kubernetes resources, we use Helm to manage the manifest. Since each application is made up of several patterns of technology stacks (Laravel, Go lang, etc.), we have a common template to accommodate this, so that each application side does not have its own manifest definition as much as possible.
ref: Library Charts
Applications - GitHub Action
We use GitHub Actions to deploy our applications. GitHub Actions provides a feature called Reusing workflows. This template was important because the application repositories are managed one by one in a separate repository, which makes managing the GitHub Actions template cumbersome to manage every time it is copied. ref: Reusing workflows
Modularity makes it much easier to maintain common parts and to enjoy uniform quality in each product.
Trial and Error and Feedback on Modern Technology
If you simply follow what you have made before, you can do it so far, but it is important to try and fail the latest technology in the ever-evolving IT technology. We actively try new technologies and features that have been announced, and feed back what works to the whole.
For example, Azure Static Web Apps is just the right service as a front-end for a web service.
ref: What is Azure Static Web Apps?
Previously, we were hosting within Azure Kubernetes Service, so we needed security updates for Docker images or built them for deployment. It works fine with new products, so little by little we are applying it to other products.
Conclusion
Colorkrew's services continue to expand, and both infrastructure and individual developers are required to do more to achieve higher quality and performance every day.
At Colorkrew, you can experience both the development of your own services and the contract business. If you are interested in our company, please enter from the recruitment page .