Translated from 日本語 • View original Hello. This is Akiyama from Azure Cloud Solution Architect. In this article, we will write about the story of moving to k8s at our Mamoru Biz.
It looks like it will be longer than I thought, so I will divide the article as follows.
- Vol.1 Deciding <- 本記事
- Vol.2 AKS(k8s) 移行の下準備
- Vol.3 AKS(k8s) 移行
App Service
移行した話の前に、 Mamoru Biz チームと App Service の関係について書きます。
Microsoft の to Migrate from App Service to AKS App Service is a good service for startups that makes it easy to publish web apps. When I started Mamoru Biz, it was just a startup, and I needed to build infrastructure in a short period of time while I was working on a contract business, so I introduced App Service, which I had experience with.
I remember that at that time, the Docker version was just available in the Japan region. It was just around the time I wrote this article.
The development team of Mamoru Biz was almost entirely dedicated to application engineers, and infrastructure engineers were concurrently working on other tasks (mainly contract projects). The infrastructure was built by infrastructure engineers, but in reality, it's not that difficult if you just use App Service.
When they wanted to launch a web server, application engineers began to build infrastructure environments. (From a quality point of view, the Staging/Production of Dev/Staging/Production was built by an infrastructure engineer.)
Background of the Transition
Architecture
Mamoru Biz serves customers with iOS/Android app + web app. App Service is responsible for the web app part, but gradually there are cases where App Service is not involved. One of them is job execution.
App Service (for Container) requires the Docker container you deploy to respond to http requests. (Reference: Your container must respond to an HTTP ping.)
You don't need a web server to run the job, but there was no other good way to run the job on App Service at the time. App Service requires a web server, so you can use a supervisor to run both the web server and the job. From a Docker container perspective, containers were built specifically for App Service, which wasn't a very good situation.
Later, Container Instances were released, but it was a bit cumbersome because it required control from a separate service, such as Logic App, to manage the lifecycle of containers.
I started to feel that building infrastructure in cases where App Service did not fit in was redundant.
Developer Growth
At Colorkrew, we value growing through challenges.
As developers became more proficient, there was a desire to implement it quickly using something other than PHP/Laravel, which was the main one used in Mamoru Biz. Specifically, they want to use Go parallelism. It's important to create a place where developers can take on more challenges, and of course, if it can reduce development costs, there is nothing to say.
As mentioned earlier, concurrent infrastructure engineers have less time available, so having an application engineer autonomously add containers is a plus for the team. The idea arose that we wanted to reduce the overall cost by reducing the cost of adding containers.
Inquiries in a contract business
In the contract business, Kubernetes inquiries are gradually increasing. By incorporating k8s technology into your SaaS service, you can expect to share knowledge and make it easier for engineers to move between both businesses.
Conclusion
After comprehensively judging the technology, culture, business, etc. that have been listed so far, we decided to move to K8S.
Needless to say, App Service and Azure Kubernetes Service are both good services and need to be used according to your requirements. The story is that Mamoru Biz quickly started its service with App Service and migrated to AKS as it expanded.
It's been a long time so far, so I'll write about it in another article.