Code 401 Class 16 Reading Notes

What is Serverless Computing

Serverless is a cloud execution model that enables a simpler, more cost-effective way to build and operate cloud-native applications.

FaaS (Function as a service) is a subset of serverless, it’s the compute paradigm central to serverless, wherein application code or containers run only in response to events or requests.

Pros

• Individual Technical and Business Benefits:
  • Serverless enables development teams to focus on writing code, not managing infrastructure. It gives developers much more time to innovate and optimize their front-end application functionality and business logic.
  • Serverless customers pay for execution only. The meter starts when the request is made, and ends when execution finishes. Compare to the infrastructure as a services (IaaS) compute model, where customers pay for the virtual machines (VMs) and other resources required to run applications, from the time they provision those resources until the time the customer explicitly decommissions those resources.
  • Serverless is a polyglot environment, enabling developers to code in any language or framework - Java, Python, node.js - with which they’re comfortable.
  • Serverless simplifies deployment and, in a larger sense, simplifies DevOps cycles, because developers don’t have to describe infrastructure needed integrate, test, deliver and deploy code builds into production.
  • For certain workloads, such as ones that require parallel processing, serverless can be both faster and more cost-effective than other forms of compute.
  • Serverless application development platforms provide near-total visibility into system and user times, and can aggregate that information systematically.

Cons

• Technical and Business trade-offs to consider: -Stable or predictable workloads: Because serverless scales up and down on demand in response to workload, it offers significant cost savings for spiky workloads. But it does not offer the same savings for workloads characterized by predictable, steady or long-running processes, in these cases a traditional server environment might be simpler and more cost-effective.
  • Cost starts: Because serverless architectures forgot long-running process in favor of scaling up and down to zero, they also sometimes need to start up from zero to serve a new request. For certain applications, this startup latency isn’t noticeable or detrimental to users. But for others - for example, financial trading application, the delay is unacceptable
  • Monitoring and debugging: These operational tasks are challenging in any distributed system, but a move serverless architecture (or micro services architecture, or a combination of the two) only exacerbates the complexity. For example, teams may find it difficult or impossible to monitor or debug serverless functions using existing tools or processes.
  • Vendor lock-in: Serverless architectures are designed to take advantage of an ecosystem of managed cloud services and, in terms of architectural models, go the furthest to decouple a workload from something more portable, like a virtual machine (VM) or Docker container. For some companies, deeply integrating with the native managed services of a specific cloud platform is where much of the value of cloud can be found; for others, this cloud lead to material lock-in risks that need to be mitigated.

Things to ask before going serverless

1. Are there going to be spikes of processes or long steady processes.
2. Will the application require less startup latency throughout it’s usage?

Things I want to know more about

• What is the meter noted in the pros of serverless computing.
• What is it about monitoring and debugging makes it difficult for the serverless architecture? Is it because of the cold starts? What is expected min to max latency on average.
• More examples of disadvantages of Vendor lock-in.

<—BACK