An abstraction exposes the behavior you need while hiding underlying implementation details. It lets you work with a stable interface instead of wiring your code directly to a concrete system. section 1.3.5 section 6.1
An electrical plug illustrates the idea: the lamp uses a consistent outlet without depending on household wiring, transformers, or the electricity source. Software interfaces provide the same replaceable connection between components. section 6.1
Use abstractions to:
- Separate application code from databases, file systems, and other integrated systems so tests can use stubs or mocks. section 1.3.5
- Depend on interfaces rather than concrete implementations, making components easier to replace, test, and improve. section 6.1
- Choose how much infrastructure to manage through services such as IaaS, PaaS, and FaaS. section 4.4
Choosing the boundary
A managed platform can hide servers and speed application iteration, while a lower-level service exposes more control. Higher abstraction can increase financial cost and hide features; lower abstraction shifts cost toward developer time and system maintenance. section 4.4 section 1.3.9
Figure 4.7 Each type of “as a service” product provides various levels of abstraction that you as the customer interact with and provide releasable items based on this abstraction. Below the abstraction are various elements of servers that in the past have been the responsibilities of entire teams to maintain.
Use the abstraction-layer diagram to compare which server responsibilities remain visible across IaaS, PaaS, and other as-a-service models. section 4.4
