In 2009, uc Berkeley published a paper called “The Berkeley View on Cloud Computing” that correctly predicted The evolution and adoption of Cloud Computing over The next decade.

In 2019, Berkeley published A similarly titled paper, “A Berkeley View on Serverless Computing,” again predicting that “Serverless Computing will become the dominant form of cloud Computing in the future.” Serverless has high hopes, but also some controversy.

Now, seven years after Amazon Lambda was first released in 2014, we look back and wonder if those serverless promises have been kept.

No server promises and disputes

The term “serverless” first appeared in an article written around 2012 by Ken Fromm:

The term “serverless” doesn’t mean that servers are no longer involved, it just means that developers don’t have to worry as much about physical capacity or other infrastructure resource management responsibilities. By eliminating the complexity of the back-end infrastructure, serverless lets developers shift their focus from the server level to the task level.

While many of the tech gurus saw serverless architecture as “a major innovation that will soon catch on,” the concept was not well received at the time it was proposed.

The event that really brought serverless to widespread attention was the launch of Amazon Lambda in 2014 by Amazon Cloud Technologies. Then, as services from companies like Google and Microsoft entered the market, “serverless” became the buzzword.

There are several advantages of serverless computing over “traditional services” :

  • On a serverless platform, there is no need for users to maintain the operating system themselves. The developer simply writes the cloud function and selects the event that triggers the cloud function to run. Such as loading an image into the cloud or adding a tiny image to the database, let the serverless system itself handle all other system-managed operations such as instance selection, deployment, fault tolerance, monitoring, logging, security patching, and so on.

  • Better automatic expansion and contraction could theoretically handle sudden spikes in demand from “zero” to “infinity”. Decisions about scaling are made on demand by the cloud provider, and developers no longer need to write automatic scaling policies or define rules for the use of machine-level resources (CPU, memory, and so on).

  • Traditional cloud computing charges by reserved resources, while non-servers charge by function execution time. This also means a more granular approach to management. Using resources on a serverless framework only pays for the actual elapsed time. This is in stark contrast to traditional cloud computing, where users pay for computers with idle time.

As the next iteration of cloud computing, serverless computing allows developers to focus more on building applications in products without the need to manage and maintain the underlying stack, and is cheaper than traditional cloud computing, so serverless computing is hailed as “the fastest way to develop new applications with the lowest total cost”.

The Berkeley view even argues that serverless computing provides an interface that greatly simplifies cloud programming, a shift akin to “moving from assembly to high-level programming languages.”

Since its birth, “serverless” has been placed high hopes, but in the process of development, it is inevitable that there will be controversy, some problems involved in the past are:

  • Programming language limitations. Most serverless platforms only support running applications written in a specific language.

  • Vendor lock-in risk. There are few cross-platform standards for how “functions” are written, deployed, and managed. This means that migrating “functions” from one vendor-specific platform to another is time-consuming.

  • Performance issues such as cold starts. If a “function” has not been run before on a particular platform, or has not been run for a period of time, it can take some time to initialize.

2019 is expected to be a year of significant growth for serverless. At the end of the year, Amazon Cloud released Amazon Lambda’s “Provisioned Concurrency” feature, which allows Amazon Cloud non-server computing users to keep their functions “initialized and ready to respond in two-digit milliseconds.” This means the “cold start” problem is a thing of the past and the industry has reached a point of maturity.

While the technology still has a long way to go, we’re seeing serverless adoption continue to grow as more companies, including Amazon Cloud, Google, and Microsoft, invest in the technology.

According to Datadog’s Serverless Status report 2021, developers are accelerating the adoption of serverless architectures: Usage of Amazon Lambda increased significantly after 2019, with the average number of calls to Amazon Lambda functions per day at the beginning of 2021 3.5 times higher than two years earlier, And half of new Amazon Web Services users have adopted Amazon Lambda.

While Microsoft and Google have increased their share, Amazon Lambda, a pioneer in serverless technology, continues to lead in adoption, with half of all function-as-a-service (FaaS) users using Amazon Cloud. According to data published by Amazon Web Services, hundreds of thousands of customers are already using Amazon Lambda to build their Services.

See the evolution of serverless technology through Amazon Lambda

Amazon Lambda is an event-driven computing engine, a preview of which was released at Amazon Cloud Technologies’ Re :Invent Conference in November 2014. Competitors quickly followed suit, with Google releasing Cloud Functions in February and IBM releasing Bluemix OpenWhisk the same month. Microsoft released a preview Azure Functions the following March, and so on.

On Amazon Web Services’ product page, Amazon Cloud defines Amazon Lambda as: “Users can run code without preloading or managing infrastructure. Just write the code and upload it as a.zip file or container image.”

A Simple use case is that the Seattle Times uses serverless technology to automatically resize images needed for display on mobile, tablet, and desktop devices every time an image is uploaded to Amazon Simple Storage Service (S3), The Amazon Lambda function call is triggered to resize the image. The Seattle Times pays Amazon Web Services only after resizing an image.

Key developments for Amazon Lambda

Understanding Amazon Lambda is critical for teams exploring serverless technologies. Serverless doesn’t equal Amazon Lambda, but since its release in 2014, Amazon Lambda has almost become synonymous with Amazon Serverless services. In fact, Amazon Lambda needs to work with other tools to form a complete serverless architecture, such as sending HTTP requests through the Amazon API Gateway, Or call a resource in an Amazon S3 bucket, An Amazon DynamoDB table, or an Amazon Kinesis stream.

In the early days of release, only Amazon S3, Amazon DynamoDB, and Amazon Kinesis were available for Amazon Lambda functions. But since then, Amazon Cloud has gradually integrated many other services into the Amazon Lambda function, Examples include Amazon Cognito, Amazon API Gateway, Amazon SNS, Amazon SQS, Amazon CloudFormation, And Amazon CloudWatch.

When Amazon Lambda launched in 2014, it only supported Node.js. Java support was added to Amazon Lambda in late 2015, and Python support was added in 2016. As of now, Amazon Lambda natively supports Java, Go, PowerShell, node.js, C#, Python, and Ruby code, and provides a Runtime API that allows users to write functions in any other programming language.

With Amazon Lambda, in addition to uploading code (or building code in the Amazon Lambda console), users need to select memory and timeout times to create functions.

The Initial Amazon Lambda function timeout was 30 seconds, later extended to 5 minutes. In October 2018, Amazon Web Services set the timeout to 15 minutes, enabling users to run longer-duration functions and perform tasks such as big data analysis, batch data conversion, batch event processing, and statistical calculations more easily.

The Amazon Lambda function allocates CPU and other resources linearly based on the amount of memory configured. At the end of 2020, the memory limit for Amazon Lambda functions was increased more than three times to 10 GB, which means users can access up to six Vcpus per execution environment, enabling users to run multithreaded and multiprocess applications faster.

In the seven years since its release, every aspect of Amazon Serverless service has improved:

In 2016, Amazon Cloud technology released Amazon Step Functions, which can combine calls to multiple Amazon Lambda Functions and other Amazon services to visually express complex business logic into low-code, event-driven workflows.

In 2017, Amazon Lambda increased its default concurrency to 1,000 and provided a distributed tracking tool called X-ray.

In 2018, Amazon Cloud Technologies released Version V1 of Amazon Aurora Serverless, officially announcing that more complex relational databases (RDBMSS) can also have Serverless features, enabling load-based automatic start and stop and elastic expansion of cloud databases.

With the evolution of cloud services, Amazon Cloud Technology has released five Serverless database services, These include Amazon Aurora Serverless, Amazon DynamoDB, Amazon Timestream (a time series database service), Amazon Keyspaces (compatible with Apache Cassandra) ) and Amazon QLDB, a fully managed ledger database.

Currently, Amazon Aurora Serverless has evolved from version V1 to version V2, and Aurora Serverless V2 can scale database workloads from hundreds to hundreds of thousands of transactions in a second, compared to the cost of configuring capacity for peak load, Save up to 90% on database costs.

In 2019, Amazon Cloud Technologies released Amazon EventBridge, a serverless event bus service that acts as a centralized hub connecting Amazon Web Services Services, custom applications, and SaaS applications, Provides real-time data flow from event sources to target objects such as Amazon Lambda and other SaaS applications. Amazon Lambda now integrates with more than 200 Amazon Web Services and SaaS applications.

In the same year, Amazon Cloud Also launched Amazon S3 Glacier Deep Archive, further improving the smart charging level of S3 storage service according to the cold and hot degree of reading and writing.

Amazon Lambda will be upgraded to 1ms in 2021 with container mirroring support and Amazon Graviton2 processor support, compared to their x86-based counterparts. Amazon Graviton2 delivers up to 34% more bang for the buck.

Cold start and vendor lock

The performance improvement of Cold start is a landmark event. It takes some time for the FaaS platform to initialize the function instance. Even for the same particular function, this startup delay can vary widely between platforms, from milliseconds to seconds, depending on the libraries used, the computational power of the function configuration, and many other factors. In the case of Amazon Lambda, the initialization of the Amazon Lambda function is either “hot start” or “cold start.” A “hot start” reuses an instance of an Amazon Lambda function and its host container from the previous event, and a “cold start” requires the creation of a new container instance to start the function host process. When considering startup delays, “cold starts” are of more concern.

Amazon Cloud Tech is offering a major new feature in 2019 called “Provisioned Concurrency,” which allows for more precise control of startup latency by keeping functions initialized. All the user needs to do is set a value that specifies how many instances the platform needs to configure for a particular function, and the Amazon Lambda service itself ensures that there are always that many preheated instances waiting to work. Amazon cloud represents the end of the “cold start” debate that has been the biggest issue pointed out by critics of serverless technology.

In addition, “vendor lock-in” is also a highly controversial area. A few years ago, CoreOS CEO Alex Polvi, an opponent of serverless technology, called the Amazon Lambda serverless product “one of the worst forms of proprietary locking we’ve ever seen in human history.” Matt Asay, who works for MongoDB, countered by writing that “the way to completely avoid locking is to write all the underlying software yourself (event model, deployment model, etc.)”.

In short, many on the side of the argument argue that “locking” is not a black and white thing, but rather an architectural choice that itself needs to be weighed and weighed. Other technical experts say that you can minimize migration costs by separating application and platform design and standardizing technologies: If you use standardized HTTP, you can use the Amazon API Gateway to convert HTTP requests to the Amazon Lambda event format; If standardized SQL is used, the migration path of the database can be naturally simplified by using Amazon Aurora Serverless compatible with MySQL……

Best practice Cases

In what scenarios do users use serverless computing today? In fact, every year at Amazon Re :Invent, there are several teams that share their practical experience, including some representative cases.

At Amazon Re :Invent conference 2017, Verizon’s Revvel team described how they used Amazon Lambda and Amazon S3 to transcode video in different formats. Earlier teams were using EC2 instances, and if the video was 2 hours long or hundreds of gigabytes large, the problem became very tricky, the HD conversion could take 4-6 hours, and if the conversion was stopped or interrupted, the work would be wasted. Therefore, the new method adopted by Revvel team is to divide the video into 5M pieces and store them in Amazon S3 buckets, and then use Amazon Lambda to enable thousands of instances of parallel computation. After transcoding, the whole process is reduced to less than 10 minutes. The cost has also been reduced by a tenth.

At amazon Re :Invent conference 2020, Coca-Cola’s Freestyle Devices Innovation team shared their contactless vending machine solution: Build backend hosting services using Amazon Lambda and Amazon API Gateway, with Amazon CloudFront at the front, to launch prototypes in a week and scale Web applications from prototypes to 10,000 machines in three months, And then quickly occupy the market during the epidemic.

In his keynote speech at Amazon’s Re :Invent Conference this year, Dr. Werner Vogels spoke about a serverless solution for New World Game multiplayer.

It’s a very complex, massively distributed real-time game that can handle 30 actions or states per second, redrawing and computing requires a lot of CPU resources. It stores the user’s state in Amazon DynamoDB with 800,000 writes every 30 seconds, allowing the user to return to the previous game state in case of an unexpected interruption. After logging user operations, Amazon Kinesis is used to transmit log events at a rate of 23 million events per minute. The event stream is then pushed to Amazon S3 for analysis and processing using Amazon Athena. Using this data stream, the team can predict user behavior and change strategies in the game in real time. Operations within the game environment, such as logins, transactions, notifications, and other operational events, are implemented through Amazon Lambda serverless computation.

Serverless plays an important role in this multiplayer game, but this large architecture also poses significant performance challenges for serverless. Amazon Lambda hits 150 million calls per minute, which is several times higher than the industry average.

The serverless future

At the end of the year, Amazon Cloud launched five serverless products:

Amazon Redshift Serverless, which automatically allocates computing resources and uses SQL to analyze structured and unstructured data across data warehouses, operational databases, and data lakes.

Amazon EMR Serverless (Preview), a new option in Amazon EMR, enables data engineers and analysts to run petab-type data analysis in the cloud with open source analysis frameworks such as Apache Spark, Hive, and Presto.

Amazon MSK Serverless (Public Preview), a new type of Amazon MSK cluster that is fully compatible with Apache Kafka and does not need to manage Kafka’s capacity. The service automatically presets and scales computing and storage resources.

Amazon Kinesis on-demand for large-scale real-time streaming data processing. The service automatically scales and shrinks On demand.

Amazon SageMaker Serverless Inference (preview) allows developers to deploy machine learning models for Inference without having to configure or manage the underlying infrastructure, paid for execution time and amount of data processed.

As a result, we can see more and more Serverless services on the cloud, and the capabilities of Serverless computing have expanded from computing, storage, and database services to data analysis and machine learning reasoning. Previous machine learning reasoning required the activation of large amounts of resources to support peak requests. With EC2 inference nodes, idle resources drive up costs, while with Amazon Lambda services, there is no need to worry about cluster node management. The service automatically allocates, expands, and shuts down computing capacity according to the Workload, and only charges for the execution time and amount of data processed, which is a significant savings.

As Amazon Serverless continues to evolve, the computing architecture continues to improve. For example, you can configure an Existing Intel x86 processor with the Amazon Graviton2 ARM processor as a platform option for faster performance and 20% less. Some technical experts believe that the platform will also develop in a more intelligent direction, “now users need to change the configuration to choose a cheaper ARM processor, the future services can be fully automatic selection of computing platform.”

As an evolution of cloud computing, the serverless vision is bound to change the way we think about writing software. There has never been a way to think about how to design with millions of processor cores and petabytes of memory like cloud computing, and now serverless has moved to the point where it’s common and usable, and users don’t have to think about how to manage these resources.

As Dr. Werner Vogels said in his keynote, “These large architectures would not be possible without cloud computing. So now Build systems the way you always wanted to, but never could, with a 21st century architecture.”

References:

www.datadoghq.com/state-of-se… Readwrite.com/2012/10/15/… www.youtube.com/watch?v=xZ3… www.serverless.com//guides/ama… Aws.amazon.com/cn/blogs/co… www.techrepublic.com/article/clo… www.thoughtworks.com/en-sg/insig… Martinfowler.com/articles/os… Aws.amazon.com/cn/lambda/r…

Verizon Case: www.youtube.com/watch?v=lle…

Coca – Cola Freestyle case: aws.amazon.com/cn/solution…

New World Game Multiplayer case: www.youtube.com/watch?v=8_X…