A series of major technological transformations

Yan Lin's technical team has completed a series of major technological transformations in the past six months. Here we share our thoughts on technological transformation. A technology that we no longer use doesn't mean it's bad, it just doesn't fit our company's development at this stage. Different companies or programmers can still choose the technology that suits them according to their own needs.

Cloud Computing Migrates from Alibaba Cloud to Amazon Cloud

We decided to migrate all kubernetes container applications to the aws EKS architecture. Making this decision is tough. The original intention is that we hope to use Terraform to realize the coded deployment of cloud service facilities, and the Terraform community support of aws is relatively richer. Some of the functions we expect Alibaba Cloud to support are not particularly friendly. Later, during the actual migration process, we found that AWS cloud facilities are much more complicated than Alibaba Cloud. The granularity of schema configuration is required to be very fine. This brings greater flexibility to our cloud architecture, but also brings many challenges.

At the beginning of the migration, we were also worried about data compliance issues. Later, it turned out that the operation of aws China is no problem from our point of view. Our initial deployment tool in aws was Circleci. Two months later, circleci suddenly couldn't push the packaged image to the ECR of aws normally. The research found that circleci's data push was blocked. This, on the contrary, reassures us, proving that AWS China is normally regulated.

Localization is another challenge. Some configurations are normally used in the aws overseas region, but some manual adjustments are required in the Chinese region.

Cost is another significant migration consideration. We estimate that the price of aws services will be more expensive than Alibaba Cloud. It turns out that it is indeed much more expensive. Our communication with aws found that many users immediately ran away after experiencing the price of aws in a short period of time. With the support of aws internal architects, we have done a lot of cost optimization, and finally reduced the daily expenditure of an aws account from ￥208 to around ￥28.

Customer service is not as bad as many people complain about online. AWS provides many initial entry-level course training for newcomers. Although we haven't used these courses much, we still feel the intentions of aws. AWS will also assign exclusive customer service to customers, with an exclusive senior architect. The entire aws cloud infrastructure is a very large system, and no one person understands all the architecture and all possible problems. When necessary, you still need to purchase its commercial support plan. 600 yuan per month, you can connect to technical customer service of different infrastructures online at any time.

Front-end technology migrated from Vue to React

We decided to completely abandon the Vue technology stack and use React. React responds faster to the latest technologies and has better compatibility, such as support for Typescript and Hook design. We expect to embrace the latest front-end technologies in real time. When using Vue, you are often forced to wait for Vue to slowly implement the latest front-end technology concepts. React's grammatical structure is more encapsulated than Vue, and the code directory structure level is more suitable for our company's idea of streamlining code blocks.

The applet technology migrated from Uniapp to Taro. The original intention of this migration is that uniapp does not support Typescript, and we hope to write high-quality strongly typed code similar to Java and Golang on the front end, so that possible problems in the code can be detected in advance during the compilation stage. This facilitates long-term code maintenance. Of course, this problem is also a problem of Vue, and now Vue has begun to support Typescript. In addition, uniapp is not open source. When we encounter some development problems, we don't know the internal design architecture, and it is often difficult to make a suitable solution. In contrast, Taro is open source and its design concept is open, which allows us to have a clear understanding of Taro from the inside out and use it more confidently.

We started to worry about scaling the React team. There is a relatively consensus in the market that the learning threshold of Vue is lower than that of React, resulting in significantly more domestic Vue programmers than React. Later found that this problem is not a problem. Although there are many Vue programmers, it does not mean that all of them are suitable for our company's development philosophy and technical requirements. Although there are relatively few React programmers, there are also many programmers who are suitable for our company's development philosophy.

In addition to the above two major technological transformations, we have also done many other technological migrations.

• To build the front-end website, we adopted Nextjs, which supports SEO static optimization and multilingual design.
• For the back-end management console, we use Ant Design, which has a cleaner interface than the previous back-end design.
• For mobile APP development, we directly use Flutter to support Android and iOS development simultaneously.
• Backend RDS database, we migrated from MySQL to PostgreSQL
• The cloud server migrates from the x64 architecture to the Arm architecture. We compiled and deployed React and Golang applications to run under the Arm architecture. Greatly optimized the server cost of our cloud.

If you are interested in a technology we use, welcome to communicate with us. Also welcome to learn about our latest vacancies 😉