In any profession, being able to speak and understand the vernacular goes a long way toward feeling comfortable in your role and working effectively with your colleagues. If you’re just starting your career as a cloud engineer, you will likely hear these terms throughout your workplace for cloud computing.

Availability
The amount of time that a service is “live” and functional. This is often expressed in percentage terms. For example, if someone says their ser‐ vice has a yearly availability of 99.99%, that means it will be unavailable for only 52.56 minutes in an entire year.

Durability
Even for the most reliable devices, any data stored on a computer is ephemeral over a long enough time frame. Durability refers to the chance that data will be accidentally lost or corrupted over a given time period. Like availability, it’s typically expressed as a percentage value.

Consistency
Consistency refers to the notion that when you write data to a data store, it (or the latest version of it) might not be immediately available. This is because cloud-based data stores are built on distributed systems, and distributed systems are subject to the CAP theorem. (Also known as Brewer’s theorem, it holds that there are three things a distributed data store can guarantee—consistency, availability, and partition tolerance— but it can never guarantee all three at the same time.) Different cloud environments and services will handle this differently, but the important thing is to be aware of this nuance in designing cloud-based software applications.

Elasticity
One of the main advantages of the cloud is elasticity: the ability to dynamically match hardware or infrastructure with the demands being placed on an application at any given time. Elasticity has benefits in two directions. Sometimes, like during high-traffic periods, you might need more resources; at other times, you might need fewer. Because your resource cost will be proportional to your provisioned resources, elastic‐ ity is a means of better matching your costs with the actual load on your application.

Scalability
Scalability is similar to elasticity. Whereas elasticity refers to the notion of dynamically increasing or decreasing your resources, scalability refers to how your resources are actually augmented. Typically, scalability is decomposed into two concepts: horizontal scaling and vertical scaling. Horizontal scaling refers to adding host machines in parallel to meet application demand. Vertical scaling refers to adding resources within a given machine (such as adding RAM). These scaling approaches have advantages and disadvantages, and are appropriate in different scenar‐ ios. The proper choice depends on your system architecture.

Serverless
Serverless refers to modern technology that allows you to run application code without managing servers, hardware, or infrastructure. Sometimes this capability is also referred to as function as a service (FaaS). Many cloud providers offer their own forms of this. These serverless offerings also provide the benefits of high availability and elasticity, concepts dis‐ cussed previously. Before serverless technologies, deploying software involved managing and maintaining servers, as well as working to make them available and scalable to meet traffic needs. Using serverless com‐ pute environments saves you from the burden of managing and main‐ taining servers in this fashion so you can focus your time and energy on the application code. However, various trade-offs are involved.

Fully managed
In the early days of cloud computing, we typically interacted with basic computing resources that were made available in the cloud: servers, data stores, and databases. While this provided significant advantages, the responsibilities of the software engineer were largely the same as those in on-premises datacenters: managing and maintaining low-level hardware resources. Fully managed resources are cloud resources that are offered at a higher level of abstraction. The cloud provider takes responsibility for some aspects of these resources, rather than the software engineer. The trade-off is that fully managed services are typically more expensive as a result, and often introduce various limitations or restrictions as compared to operating on the more basic resources.