Xiaobo Wang: focuses on high concurrent Internet architecture design, distributed e-commerce trading platform design, big data analysis platform design, and high availability system design. With more than ten years of rich experience in technical architecture, technical consulting, and a deep understanding of the importance of technology selection for e-commerce systems.
Tongcheng Yilong is not quite the same as Tencent, we are a company that mainly deals with air tickets. This company actually does quite a lot of things that are relevant to everyone's lives.
Serverless in the same application, in fact, we can see that what Tencent Cloud just shared is Serverless in the cloud. I'm going to talk about why we're doing Serverless for the same trip. It actually comes from the thought that how far is a SQL to a service? Why are we doing Serverless? It's because we grab time. Time is the real cost to us. Back when we were doing this, we were able to have new releases every day. But on the flip side, it doesn't really matter what you post every day, or it doesn't mean you can have any power. What is the real capacity? Can you go live at night for a product's morning requirements? This one is important for e-commerce. So we thought about doing Serverless.
This was done relatively early, in the second half of 2016, and most of the ones that moved to Serverless were moved up in 2017. Why are we so bold to try it? Because in late 2014 and early 2015, containerize all the applications of the same trip. We completed the microservice switch in 2015. What else did we find to do after these two things were done, we found that they were improved for us, but not revolutionary. Let's go back to this, in really diverse application scenarios SQL is something that's very common and services are something that's very common. How far is the distance from SQL to the service application output if it's actually very, very far. All the questions here cause programming to be unhappy, like where is the test environment, where is the development environment, where is the CASH server, where is the load balancing, because these don't make sense to me, I just want to make it my code. This is something to think about, can you make the distance from a SQL to a service even shorter.
How do we shorten this thing? The first thing is the development environment, the test environment, the production environment, the grayscale environment, all kinds of environments. Everyone think back to the various environments and how they were created when there was a failure. When we do high availability or do online checks we tend to keep a tight rein on the production environment, but we think this breaks down at our expense, but does the development test environment pay much attention? No, it's hung up because of its own hang-up. You actually have less demand, which leads to longer times, and subsequently leads to a less competitive market.
There are also frameworks, which come and go. 3,000 developers in the same company can build a whole bunch of frameworks, but such frameworks tend to have a lot of problems and are not uniform. And then next are these environments causing programmers to be unhappy? But to say that as a good programmer you shouldn't know this? Actually, that's right too. Because of course for a full-stack engineer knows these things, but the problem is that we do engineering, and engineering should have its pipeline and division of labor, so this problem becomes a barrier in the pipeline.
Are these the only obstacles? Not. And deployment. Looking at today's go-live from a traditional look, an app release can be six months, a year. Once I read a Japanese guy say they were doing Japanese insurance. It says it's a big project, six months in development and six months online. What did I say about deployment? Said deployment was quick. Then there's O&M, which is the artificial division of technical staff into business developers, who write code, and another category called O&M engineers. Is there any contradiction between them? We've always said that product students and development students are the most conflicted. But on the other hand, have you ever thought about the fact that it's the operations engineers and programmers who are at odds with each other? Why is that? When the first app went live, I believe there was no Ops engineer, because the Ops work must have been done by the engineer himself. But by the time today's division of labor is so large a problem is found, the gulf grows wider and wider, and eventually there is a fight. Can we scrap O&M, this is not to say we don't want him, but let him hide in the background and make him invisible. There are so many serverless, and one of the big ones in there is ops-less, allowing ops to hide behind technology. Another thing is scaling, this thing is also done a lot, of course, there are also high, automatic scaling, but can never avoid when the traffic rushes over will hang a little, so how to do scaling? The simplest is to bury some servers up, I do not run, today on a billion traffic over, I will put two hundred million servers, do not hang it, expand what capacity? But this resource is wasted, and how to use it. This one looks to be cost-efficient related.
Do these things add up to be a motivation for us to go Serverless? Actually, not yet. Another piece, for our service behavior, like our debugging, imagine the misery we brought after microservicing all of our applications back in 2015. In fact, today frankly we do very well with microservices. Why am I saying today that microservices are difficult? Maybe when we have a small number of services, for example, I spoke to a fellow Nifty student and he said they have a lot of servers. How much of it is in the same ECLA? There are close to a thousand apps for just one airfare operations platform. It's still an app. What's the concept of an app? It's a collage of N services. We have thousands. How many independently deployable microservices do thousands of microservices bring? Very scary. And it's iterating on microservices. The debugging that comes with basically scratching your head and providing a bunch of tools to back him up, this is a huge pain. And performance, every programmer is concerned about performance, but is performance something that every programmer should be concerned about? If from a purely technical point of view everyone should be concerned. But being concerned is not the same as being able to fix it. Because not every programmer can get the performance right. So is there a good way to fix it? Like high concurrency this performs better, this high concurrency to where it turns off and makes it fuse. This would free up the programmer to design the business model.
There's also security, which isn't seamless to every programmer, and how to empower those capabilities through a platform where programmers don't have to do other technical things. All of these things add up to the reason we're going to Serverless. From the time we started designing it, to the time we developed it to go live, it was really far. One of the reasons this is so far away is that there is no way to write code in peace, because the core here is the application thread. And at the heart of the application is the model of the business, the line of business. There were too many tigers on the business line that we had to fight off, so we did Serverless. We're doing this platform in late 2015, and when we're done we'll put the same app that can go into it for the app. Why do I say it's accessible? Because we are also completely private from the bottom, to isolation and so on, we do it thinking that to a large extent we are correcting the trouble that microservices are causing now, so a lot of our framework scheduling is encapsulating and updating the microservices framework, and we'll talk about why that is later.