background

About five years ago, when I joined Alibaba in 2013, when DevOps was just beginning to take off, one company claimed to be able to release dozens or hundreds of releases a day, which meant they could respond to business needs several blocks ahead of the weekly releases of traditional software companies. And there’s no way overtime can make up the difference. Today’s AliExpress technical team is only a few hundred people, but dozens of releases a day are common. This is mainly due to three aspects:

Very thorough microservitization, very fine-grained split, and very clear opposition to binary libraries.

Ali Group’s overall operation and maintenance standardization, especially the comprehensive coverage of Docker technology.

The AliExpress SRE team constantly strives to ensure stability.

Efficiency, however, is something that you never say, “Enough, enough soon,” especially in today’s consumer society, where everyone is a consumer, and consumers want your goods or services to be in front of them as soon as they have a desire in their head. Moreover, as we continue to internationalize, new factors will inevitably affect the original high performance.

Communication bandwidth attenuation problem

The first factor is the development and change of the r&d team. Today, the AliExpress technical team has become a truly distributed international team, working in Hangzhou + Shenzhen + Moscow + Madrid + other Eurasian cities. The proportion of foreign students is 15%, and we can see that the proportion will continue to increase. New overseas duty stations will also increase. Such a team, compared to a group of Chinese on the same floor, is fundamentally different.

We can do analogy, communication and network communication between people, we know there are bandwidth network communication, from the early dial-up dozens of K, to the present dozens of hundreds of M, the mainstream of broadband in homes to the data center internal LAN G level of orders of magnitude, the greater the bandwidth, can transmit information the more waste (usually more). The communication between people can also be considered to have bandwidth. For example, a small team of trusted Chinese engineers usually eat, walk and chat with each other. They know each other well and communicate smoothly. For a distributed international team, however, this communication bandwidth degrades dramatically:

• Chinese to English conversion, decay once. For most people, English is not their native language, and communication efficiency naturally decreases.
• From one site to many sites, decay once. Phone calls, video, and nails are not as effective as face-to-face communication. (Otherwise no one would brush their faces at the same time.)
• Time difference, decay again. The time difference between Hangzhou and Moscow is 5 hours, so basically we can’t contact the students in Moscow in the morning of Beijing time.
• Cultural differences decay again. For example, there are many ways we can use to strengthen our relationship, such as playing karaoke and eating chicken. Foreign students may not be interested at all.

One might say, given the high cost of communication, how easy is it to recruit all Chinese engineers in one place? It’s simple enough, but how do you attract the best talent from around the world? Besides, AliExpress’s users are mostly foreigners, so if the talent behind AliExpress is all Chinese, it doesn’t sound like a viable business, does it? Google, Microsoft, Amazon, who doesn’t scour the world for top talent?

Therefore, since the attenuation of communication bandwidth is inevitable, we can only improve the utilization of this bandwidth. Here are some things we have done or are doing:

As far as possible with the industry mainstream technology, reduce the cost of learning engineers. We did alibaba ecological integration based on open source Spring Boot, and abandoned ANTX, WebX and Pandora, all of which are the same idea.

English First: notes, documents, tools, English mandatory, Chinese optional.

Service discovery, making all microservices visible, enhanced self-description, searchable.

Embrace the Kotlin

In terms of development efficiency, I personally think that all Java programmers should take a hard look at Kotlin, because the language is so simple and interoperates seamlessly with Java that it is perfectly suited for use in production environments.

In terms of simplicity, I changed a block of Java code to Koltin the other day, and with no loss of readability (in fact, readability has improved), the line of code has no problem being reduced by a third.

In addition, I can’t help but share a feature I wrote recently to publish functions as HSF services based on Sergey’s Kotlin HSF DSL:

It takes less than 15 lines of code to launch a Spring Boot application and publish a string lowercase function as an HSF service, just to give you a sense of how much Java needs to write. The language level upgrade opens up more possibilities for framework, middleware, and API design, which allows us to cut back on more scaffolding and make business code leaner and more elegant, which in turn leads to increased efficiency.

As a programmer, it’s very dangerous to master only one language, because the design of that language can imprison your mind. I read a few other languages in my spare time, but I can barely write Java in my day job (I have written some shells if shell is a language). From now on, I’ll be writing as much Kotlin code as I can, and my team will be switching from Java to Kotlin. We’re not even Early adoptors anymore. Ray roll has been preaching Koltin and launching an app for over a year. Sergey and other students in The Russian office of AliExpress have already used Kotlin in production. Sergey personally shared his experience in many places.

We will push AliExpress to embrace Koltin to improve our efficiency at the language level.

Lei Jul, a senior technical expert of Alibaba, wrote many things in his recent article about programmer learning, which I agree with very much. One paragraph in particular would like to like:

Don’t talk about your programming history with a programmer. Many of the lessons you learned are not applicable today. 2-3 years of not focusing on technology, basically no programmer and programming, not absolutely, but usually not wrong.

Keep learning and encourage with you.

FaaS

Function as a Service, another new Buzz Word? Yes, but I really believe in the Buzz Word. AWS Lambda, Google Cloud Functions, Microsoft Azure Functions are coming out and everybody is trying to move their business up there. What makes sense?

If you are a cloud service provider, this is obvious. Your opponent charges docker instance, starting from 2 core 4G, how much is it for an hour? If you can charge per call, 30 runs in an hour. That price difference must be order of magnitude, with this move can kill opponents in seconds.

This is purely a cost of hardware consideration, but we also need to look at it from an efficiency perspective.

Firstly, since Function is inherently stateless and lightweight enough, it is theoretically possible to achieve auto scaling at the MS level. Graalvm, for example, has great potential in this respect.

The auto scaling of MS level can not only significantly improve resource utilization rate, but also improve operation and maintenance efficiency, and development almost no longer needs to consider capacity. For example, on Double 11, we did a lot of pressure measurement, to a large extent to ensure that the water level of each part of the system was on the predicted safe line. If real-time expansion and contraction were achieved, it would be better to expand when the traffic peak came.

What is lightweight?

Today many engineers may have forgotten the concept of light weight, people are all kinds of intrusion, write a simple application, type jar package, business code is often less than 1/10.

Never mind how much memory might be wasted and how much startup time might be added unnecessarily. The most troublesome consequence of this client and share flying around is that the development often has to do various upgrades, and a liter of failure, a check for a long time. Heavy clients in the name of performance are anti-servitization; Incompatible upgrades resulting from a variety of poorly designed apis (and promoted by force, without upgrading cards) are anti-engineer ethics.

A good microserver should accumulate a large number of lightweight interfaces that don’t even need to introduce any share/open/client dependencies, just use HSF generalization calls, so that users don’t have code intrusion.

We have already tried (and launched) AliExpress to write functions based on Koltin DSL and HSF generalization calls. Users only need to rely on a very simple FaaS SDK to write business code. Based on the Archimedes service discovery mentioned earlier, It can quickly reuse existing services and perform aggregation and filtering operations to meet business requirements, which is very useful in a wireless-close business. Of course, this is just the beginning, but we’ve seen that there’s a lot of business logic (5/1 to 1/3 in AliExpress) that doesn’t depend on data itself and can be made into functions, and we can make it so that it doesn’t depend on any business binary library. It is even independent of any middleware client with technologies such as Service Mesh. The owners of these businesses don’t need to worry about messy upgrades, don’t need to worry about capacity, and really only care about their business logic.

I think that’s what FaaS should be, and my team and I are working hard to make that happen.

The authors introduce

Xu Xiabin, senior technical expert of Alibaba, author of Maven In Action, translator of Maven Authoritative Guide and co-translator of Cucumber: Behavior Driven Development Guide, used to be responsible for maintaining Maven central warehouse and participated in the development of Maven warehouse management software Sonatype Nexus. He has spoken many times at ScrumGathering and AgileTour conferences. I like reading humanities and running in my spare time.

The original link