To create and spread fun, engineers are indispensable.
We gather people with a lot of different tastes and skills.
Number of engineers
Works, initiatives and policy of the engineers that support the services of ISAO.
This is a presentation of their challenges and the mindset that they have when they carry the projects forward.
The “Goalous” Project
Goalous is a company-oriented internal SNS service designed to make people reach goals together as a team.
It adopts the concept of “GKA”.
A “Goal” is set as the large objective in a project, and “KR (Key Results)” are the necessary indicators to achieve it. Everyone can post and share the “Actions” that they make on a daily basis to get close to the goal, along with a picture. Making your activity openly visible creates a succession of new collaborations.
Goalous is a teamwork service that encourages the invigoration for not only one project but for the whole organization.
Members breakdown：4 web engineers, 1 PL
Back end: PHP7, CakePHP, MySQL, Redis, Nginx
Front end: React, Redux, Angular, jQuery, webpack
Infrastructure: AWS (EC2, ALB, OpsWorks, RDS, ElastiCache, S3, etc)
Tools: GitHub, TravisCI, JIRA, Confluence, Slack, Vagrant, Chef, etc
If an American engineer that can barely speak a few words of Japanese suddenly joined your team, what would you do?
Ask to be transferred, be troubled, start doing weight training, calm down your mind with sutra chanting… every person will probably have a different reaction.
At that time, everyone in the team was Japanese, and no one was really good at English.
However, if the team keeps communicating in Japanese, he will end up being left out and useless. But English is difficult… so after discussing about it with everyone, we came to a decision.
"OK! From now on, basically, let's use English!!!"
Since then, we have conducted all the morning meetings, Slack, Git comments, source comments, JIRA&Confluence... all in English, until now.
When we started to switch to English, frankly speaking, the development efficiency decreased and the team members were feeling some stress. The reason why we kept using English despite that is because we already understood that English was indispensable to work as an engineer.
If we look at the bright side, we can have business conversations in English with an American native speaker on a daily basis, there is no environment as privileged as this.
Even if it is not perfect yet, now we are able to have technical discussions in English.
In addition, a Brazilian engineer and an Indonesian engineer have joined, making the team even more international and fun.
English did not bring only communication with the new members.
We are now able to read a large amount of technical documents written in English and ask technical questions to other engineers all around the world through the Internet.
This is definitely one of the ways to broaden our scope as engineers.
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.
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 ISAO’s blog (IsaB) about this switch to HTTP/2 (in Japanese):
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.
The “Mamoru" Project
Mamoru is an authentication app & service that protects user's important information with a new sensory two-factor authentication.
This time, we will introduce Mamoru Pay of the Mamoru series which is an in-house payment service.
A variety of “small things” are being sold in ISAO's office: small snacks and pastries, drip coffee, different types of alcohol at the bar counter, etc... managing this variety of things and prices is very troublesome.
Mamoru Pay lumps these in-company charges together by using QR Code to read barcodes when making purchases.
The purchases are recorded and centralized in the accounting department and their amount is deducted from salary at the end of the month, making it a cashless system.
Members Breakdown: 1 PL and Marketer, 3 Programmers, 1 Infrastructure Engineer, 1 Designer, 1 Back-Office
Back-end: PHP7, MySQL, Redis, Laravel
Infrastructure : Azure (Web App for Container, SQL Database, Redis)
Tools: GitHub, Slack, Docker, engineer's preferences for the edition, etc.
Let's start with the technical side.
Mamoru provides a two-factor authentication service, an intra-company payment service, and a few more services not yet disclosed. These are all developed by a single team.
Since each service of Mamoru is still developing, it is very often for a team member to build a new function for service A today, and fix a bug on service B for tomorrow. Therefore, we are trying to have as many members as possible to be able to develop every service.
To put it simple, each member has his/her own confident technical field, and is extending their reach to cover more areas.
When inducing a new technology on Azure, it will be mainly members who are skillful with Azure to get involved, but other members will also help when building on the existing environment. Members who do not write codes on daily basis will also send PullRequest to GitHub on occasions. After someone finishes the Code Review by merge request, the service will be released in the internal staging environment, then released in the production environment.
Not only digging deep into one's own confident skill, but also widening their technical range. While one side of the story would be member redundancy, it also shows what ISAO is treasuring – the opportunity to "Grow".
On the business side, measures are designed with a focus on Project Leaders who have plentiful Domain knowledge in each service. They have many connections with the industry as well. Just recently, we were thankful to have an external person, who is leading a famous security group, to hold a seminar for us. A unique asset for Mamoru Team may be the opportunity to gain these valuable experiences.
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 Pay.
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 Pay 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 ISAO's blog (IsaB) 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 Pay 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 IsaB about the deployment flowchart (in Japanese):
Engineer at ISAO
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 ISAO.
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 ISAO but all over the world.
There were not many engineers pursuing Azure in ISAO 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 ISAO.
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”.
Engineers need to have the driving force to keep pursuing spontaneously the techniques that evolve every day.
However, if they limit themselves to that, they might stay partial and narrow-minded. So, what should they do?
This is a presentation of how ISAO organize open knowledge exchanges.
Regardless of whether you are a new graduate, a recent graduate, or an experienced professional, ISAO recruits year long.
If you want to make the services that make the world fun and improve your skills at the same time, please apply!