什么是无服务器计算？

Each cloud model overlaps in capabilities, an accounting app can be built atop a PaaS system, or sourced as a SaaS solution. Likewise, an accounting app can be built in a serverless environment. Serverless has many pros that enable teams to operate with more agility, transparency, and cost controls.

• Returns Time to Developers — Emancipates time for developers by abstracting back-end server management away from application development.
• Cost Controls — Consumers are charged on executions only; compared to other payment models, which may charge per virtual machine.
• Multi-Language Support — Serverless platforms can support multiple programming languages, but are well suited to support event-driven languages. However, newer developments, like Google Cloud Run, allows any language that can run within a container. And AWS lambda Layers makes allowances for bringing code written in other languages into a code base.
• Reduction of Complexity — Serverless, by its nature, reduces responsibilities in DevOps cycles.
• Transparent Usage — Serverless provides transparency into system usage. Typically, a dashboard offers a unified look at usage of all applications and services deployed across the organization.

• Not Cost Effective in All Situations — Serverless provides significant cost controls, namely charging only for usage, which is beneficial in peak times. However, predictable workloads, for say long-running processes, may be better served by traditional server environments, when traffic is well understood.
• Cold Starts — Serverless architectures do not use long-running processes, instead they offer resource provisions on-demand. This means that sometimes resources will start cold in order to respond to a request. For most systems this latency may not be a problem, yet for time sensitive applications this delay may be unacceptable.
• Monitoring and Debugging — Monitoring and debugging require a shift in thinking in a serverless ecosystem because serverless architectures, especially those using microservices, present different operational challenges.
• Vendor Lock-in — As with any cloud provider, vendor lock-in is a concern. Serverless providers give consumers an ecosystem of functionality, however, this requires deeper and deeper integrations to create more value for the application. As apps become more integrated they run the risk of deeper lock-in.

Microservices architecture refers to a design pattern where applications are broken down into smaller services, or microservices. The combination and intercommunication of these microservices constitutes the whole application.

There are many good reasons to choose microservices. First, in response to an alternative design pattern, the monolith, where applications contain all of the code, because a monolith can grow to become unwieldy, development teams are challenged to maintain the code base. Monoliths are not ideal for cloud native applications that are designed to responsively and rapidly expand and contract services to meet demand.

Second, microservices are ideal for the containerized operations of cloud architectures. Containers are smaller than virtual machine runtimes, and require less than they do, in both resources, and application overhead. Containers are well suited to holding microservices. They can come into existence when more of the same service is needed, and they can disappear when they’re not needed, saving resources.

Continuing with the concept of wrapping runtime environments around services, effectively containerizing them, we can further shrink a container to just encompassing and running a single function. In this way, when a function is invoked, a container comes up, runs the function and then closes. These kinds of containers are called stateless containers and support the Serverless event-driven model. This is in contrast to stateful containers which spin up and remain for a longer duration, which does not adhere to the ephemeral characteristic of Serverless.

In sharp contrast, serverless and microservices are only associated because they are within the cloud ecosystems, but as serverless offers developers a way to outsource backend responsibilities, microservices is a development design approach.

Because serverless environments utilize containers, Kubernetes is a common choice for running serverless environments. Kubernetes is not ready out of the box to run serverless environments. Instead, Red Hat Knative, an open-source project can be used to deploy code to a Kubernetes environment.

According to Red Hat, Knative consists of 3 primary components:

• Build - A flexible approach to building source code into containers.
• Serving - Enables rapid deployment and automatic scaling of containers through a request-driven model for serving workloads based on demand.
• Eventing - An infrastructure for consuming and producing events to stimulate applications. Applications can be triggered by a variety of sources, such as events from your own applications, cloud services from multiple providers, Software-as-a-Service (SaaS) systems, and Red Hat AMQ streams.

Knative is evolved over earlier serverless frameworks by allowing the deployment of any workload—monoliths, microservices, or functions.