Engineering Team | Employment Information | Colorkrew

Challenges in the Project

My name is Akagawa, I’m leading the MSP (Managed Service Provider) project.
I’m always trying to step into unknown territory, keeping in my mind to update myself with the latest information of cloud area, which progresses and improves every day.

“脱・TOEIC難民！500点以上UPしたエンジニアのサクセスストーリー”

Read More ▼

Cloud integration
Although the fundamental system of infrastructure is gradually shifted to cloud services in today’s business scenes, in most cases, the reality is that companies just transfer existing structures into cloud servers.
As it is said with the expression “lift and shift”, in the next phase of the following time, the systems need to be shifted to the one with cloud-native structures, and proposals taking advantages of cloud computing such as cost efficiency or adaptability to high-load environment, will be needed.
Depending on situations, we propose “hybrid” system of on-premises and cloud, and for the new projects without precedents, we offer feasibility verification through POC.

To sum up, in the MSP project, the members are asked to catch up with the latest information in cloud area that progresses and improves each day, give proposals that best fit the client’s desires, and have opportunities to give a try in unprecedented situations.

“3大クラウドに挑む、インフラエンジニア”

Exodus from traditional, old-fashioned infrastructure engineers
Since “Infrastructure as Code” was advocated, I have been working on utilizing Ansible and Chef, and these days, not only the structure management by CloudFormation coding, but also opportunities for function coding by Python is increasing.

We are trying to be a group of engineers who can do from proposing the system structure that best fits the client’s needs to conducting actual operations such as structure management of infrastructure content and the whole cloud, or even writing event driven codes and organizing deployment environment.

“時代に合わせたクラウド設計、ハイブリッドクラウドで新たな挑戦”

What I am trying to achieve as an engineer

Before joining Colorkrew, I belonged to a support desk of a mobile communications business, or SES company for which I worked at its clients’, that are mostly System Integrator, sites.
At the former job, I had a chance to verify AWS and was greatly shocked when I learned that servers are activated by just few clicks; this motivated me to change my job and work at Colorkrew.

Soon after the entrance to Colorkrew, I was asked, “which project do you want to work in, on-premises one and AWS environment?” and I immediately answered “AWS!” although I didn’t have actual experience of AWS development.

I raised my hand for accompanying sales visits for new projects and participated as a pre-salesperson, although I did not have experience in pre-sales.

Even though it was soon after my child’s birth, I raised my hand for the position of supporting engineers at a subsidiary of our parent company (at that time) in Singapore and transferred AWS skills to the local engineers, although I cannot speak English.

I choose what I do not based on if I have done it before and I can judge if I should continue after I gave a try.
I know this might sound a little reckless, and I am, of course, careful with situations that might have an effect on our services, but this is my idea which I keep in my heart while working.

We often hear people talking about jobs that will be taken over by AI, and I think the demand for infrastructure engineers will be decreased with the development of cloud vendors.
The future cloud vendors want to provide is where “people get rid of unnecessary management and focus on their business”; I don’t have any disagreement and I believe that should be the future.
This might not be a bright future for infrastructure engineers.
However, we cannot stop the change in the world, so I think it is us that need to be changed.
Some instances in the latest situation include coding of infrastructures, automation and reporting of operations that are originally done by hands, system proposals that are free from IaaS.

As an engineer, I want to remain responsive to the changes in cloud situation and society, keeping in mind a challenging spirit, and keep changing and adjusting myself.

“障害にマルチ対応、運用監視のスペシャリスト”

Let’s do it together!

The challenges of this project

My name is Akiyama, I'm the person in charge of infrastructure.
As a technical challenge, we have introduced Docker to the production environment with Mamoru Biz.

Read More ▼

The reason of the introduction
The infrastructure used to run Docker is “Web App for Container”, a PaaS Service of Docker developed by Microsoft Azure.
The reason for using Docker in the Mamoru Biz development is that we could use it to make the development environment and the performance environment similar and get a portability that was not locked it on a specific cloud, assuming that Mamoru would have had an over-all usage of Azure.
Even though Web App for Container has just been officially released in September 2017, I was already using it for the customer environment in the infrastructure operations of another project different from Mamoru, so there was not much opposition to its introduction.
You can find an article posted in Colorkrew's blog (Colorkrew Blog) on the link below about the other service that uses roughly the same structure (in Japanese):
“LAMP のシステムを Azure の PaaS に移行しました”
Obstacles to the introduction
A primary obstacle to the introduction was that the team did not have much experience in Docker.
However another Member, who was developing Mamoru Biz with me, was really enthusiastic about it,
so we made it through safely.
“Web App for Containers” is a PaaS that is specialized in operating one Docker container through the web. The Dockerfile could be created by the developer and I only reviewed it.
The deployment flow used Docker Hub's private repository and GitHub continuous integration. From the beginning the flow was simple and over the time the team could learn more and more about Docker.
There is also an article on Colorkrew Blog about the deployment flowchart (in Japanese):
“Azureエンジニアから見たDockerを取り巻くDevOpsサービスのまとめ”

Engineer at Colorkrew
When carrying on projects like this, there are many cases where I will explain to programmers how to use basic Azure service and the important points before getting them used to use it by themselves.
Many people are also carrying other projects, so our time working simultaneously on a single project is limited.
Even while sharing knowledge, it is essential for each engineer to be "self-driven" at Colorkrew.
It might be suitable for those who enjoy large discretion.

Goals as an engineer

I was originally a programmer and now I'm doing infrastructure engineering.
DRY and YAGNI principles do not mean only service functions, even in project activities, we always keep them in mind at work every day.

For example, while Azure is 2nd on the cloud market just behind AWS, engineers that have experience of having worked at AWS are overflowing not only at Colorkrew but all over the world.
There were not many engineers pursuing Azure in Colorkrew when I joined the company, so I thought that activity opportunities may increase by opening up that area, and I took the initiative to deepen my understanding of Azure.

Also, there weren't any resistance to writing programs among the infrastructure engineers, it feels like there aren’t so many people who have a sense of what they are pursuing in infrastructure through service development.
I think as an engineer who has both infrastructure and programming perspectives, I can provide feedback to Colorkrew.

Also, personally, I manage to keep hacking a little bit.
Rails, Electron, React, RaspberryPi etc., caught my interest at that time.
In the IT world, the technology you’ve been playing with will be used in your work 1 year later which is what happens to Zara.
It’s important to keep light footwork in mind.
I’m very happy to be able to feel the moment when “someday the things I did will come back to me”.

Let’s do it together!

The challenges of this project

My name is Yoshida, I am the lead engineer of Goalous.
Some time ago the performance of all the services on Goalous have been greatly enhanced, and to achieve this we switched over to HTTP/2.

Read More ▼

The reasons for switching
One of the main characteristics of HTTP/2 is that it allows the browser to create one stream of multiple requests (multiplex). I wanted to use it to increase the speed of the website.
With HTTP/1.1, the network creates requests individually.
Most browsers try to work around this by sending multiple requests at the same time, but there is a limit of the number of requests that can be sent at once. This causes a new request to be “blocked” until an old one is completed if there are too many (“Head-of-line blocking”).
An example that showcases this problem is the high number of images that take a large place in Goalous. It had a negative effect on the performance as the browser had to wait on old images to download before it could receive new images.
However, HTTP/2 solves this issue of HTTP/1.1 by setting up a stream, allowing multiple requests on a single TCP connection (stream multiplexing) which minimizes “blocked” requests. This results in less time for the user to wait on the browser to download files, which is what I wanted to achieve by switching to HTTP/2 as one of the measures to increase Goalous’s performance.
Difficulties that we have faced
We use a development tool called Chef to configure our application. AWS provides a resource called OpsWorks that allows us to operate Chef configurations in a cloud setting. Updating both Chef and OpsWorks to use HTTP/2 proved to be complex.
With HTTP/2, we needed to change a setting in AWS’s Load Balancer. The original setting, ELB, needed to be changed to ALB. While we were quite comfortable with working on ELB through the console, there were challenges when trying to prepare ALB’s settings.
But after a lot of hard work and testing, we were successful in updating the Opsworks environment to HTTP/2.
This was “the first step”
Honestly, we cannot consider that we are making the best use of HTTP/2’s merits yet.
From now on we plan to keep improving by exploring all its possibilities gradually, as it allows stream priority, flow-control, server push…
However, switching over to HTTP/2 was a good preparatory challenge to make Goalous an even faster and better system.
Indeed, I think that it is important to take care of this kind of groundwork from the start to ensure the future of a service.

There is also an article on Colorkrew’s blog (Colorkrew Blog) about this switch to HTTP/2 (in Japanese):
“そうだ、HTTP/2に移行しよう(OpsWorks基本編)”
“そうだ、HTTP/2に移行しよう(OpsWorks実践編)”

Goals as an engineer

I think that the important thing is “am I working in a good mood?”.
It means “am I doing a challenging work?”, but also “how can I turn boring tasks into something fun?”, or “how can I get rid of the boring tasks?”.

The tasks that need to be done even though they are boring are overflowing.
For example, doing the boring manual procedures that have become a routine, or correcting the parts of an application that have become a hindrance… this is the kind of tasks that maybe no one wants to do, right? (smile)
Therefore, we think of improvements consisting of how to reduce the boring manual procedures as much as possible so that we can focus on the interesting tasks.
One of the ways to achieve this is the “automation”.
Adding automated testing to our deployments, Travis CI for server testing and Selenium for browser testing, helped lighten the burden of important, yet mundane tasks.
Automating and getting rid of boring tasks in that way then allow you to focus on more interesting tasks.

Of course, there are some things that just cannot be automated, but I think that it is always necessary to search for the origins and the causes when an unnecessary task comes up.
Eagerness at work and performance are directly linked with each other. This is the reason why from now on I want to keep being aware of all the things that could go against my motivation at work.

Let’s do it together!