Cloud Development & Architecture: Databases, APIs, Containers, Kubernetes, Serverless

0.0(0)
studied byStudied by 0 people
0.0(0)
full-widthCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/191

encourage image

There's no tags or description

Looks like no tags are added yet.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

192 Terms

1
New cards

Design and Development Practices

Cloud topics covered in this module: 1) Cloud Storage & Databases 2) REST APIs & Microservices 3) Containerization with Docker 4) Orchestration with Kubernetes 5) Serverless Computing

2
New cards

Cloud-based databases (definition)

Offer scalability and flexibility; accessible from anywhere.

3
New cards

Traditional databases (definition)

Operate on-premises; ideal for structured data and direct access.

4
New cards

Traditional databases (speed)

Excel in speed.

5
New cards

Traditional databases (scalability)

Lack scalability compared to cloud options.

6
New cards

Traditional databases (security control)

Provide full control over security.

7
New cards

Traditional databases (cost)

Higher initial costs.

8
New cards

Traditional databases (when to use)

For businesses needing data control and instant access.

9
New cards

Hybrid option (cloud + traditional)

Combine both approaches to tailor for business needs and security requirements.

10
New cards

Cloud REST APIs & microservices (relationship)

Complementary technologies used together to build modern, scalable, flexible apps.

11
New cards

REST API (definition)

Representational State Transfer Application Programming Interface.

12
New cards

Microservices (definition)

Architectural style where a large app is broken into smaller, independent, loosely-coupled services.

13
New cards

REST APIs in microservices

Common and effective way for services to communicate with each other and clients.

14
New cards

RESTful principles (list)

Statelessness; client-server separation; uniform interface.

15
New cards

SOAP vs REST (purpose)

SOAP = protocol for communication between applications; REST = architecture style for designing communication interfaces.

16
New cards

SOAP vs REST (design exposure)

SOAP API exposes operations; REST API exposes data.

17
New cards

SOAP vs REST (transport)

SOAP works with any transport protocol; REST (in slides) works only with HTTPS.

18
New cards

SOAP vs REST (data format)

SOAP supports only XML; REST supports XML, JSON, plain text, HTML.

19
New cards

SOAP vs REST (performance)

SOAP messages are larger and slower; REST is faster due to smaller messages and caching.

20
New cards

SOAP vs REST (scalability)

SOAP is difficult to scale (server maintains state); REST is easy to scale (stateless).

21
New cards

SOAP vs REST (security)

SOAP supports encryption with overhead; REST supports encryption without affecting performance.

22
New cards

SOAP vs REST (use case)

SOAP for legacy/private APIs; REST for modern/public APIs.

23
New cards

Docker (what it is)

An open platform for developing, shipping, and running applications.

24
New cards

Docker (why)

Standardized local containers streamline development and CI/CD workflows.

25
New cards

Docker lifecycle tooling

Develop in containers → container is unit of distribution/testing → deploy as container or orchestrated service.

26
New cards

Docker deployment environments

Works the same across data centers, cloud providers, or hybrid setups.

27
New cards

Docker building best practices (multi-stage)

Use multi-stage builds to create reusable, smaller images.

28
New cards

Docker building best practices (base image)

Choose Docker Official/verified/sponsored base images.

29
New cards

Docker building best practices (rebuilds)

Rebuild often; avoid stale cache.

30
New cards

Docker building best practices (.dockerignore)

Exclude files not relevant to the build.

31
New cards

Docker building best practices (ephemeral)

Create ephemeral containers that can be stopped/destroyed/rebuilt with minimal setup.

32
New cards

Docker building best practices (minimalism)

Don't install unnecessary packages.

33
New cards

Docker building best practices (single concern)

Decouple apps; one concern per container.

34
New cards

Docker building best practices (sort args)

Sort multi-line arguments alphanumerically for maintainability.

35
New cards

Docker building best practices (cache)

Leverage the build cache appropriately.

36
New cards

Docker building best practices (pinning)

Pin base image versions; tags can be updated by publishers.

37
New cards

Docker building best practices (CI)

Build and test images in CI.

38
New cards

Kubernetes (what it is)

Most popular container orchestration platform.

39
New cards

Kubernetes patterns (foundational)

Health Probe; Predictable Demands; Automated Placement.

40
New cards

Kubernetes patterns (structural)

Init Container; Sidecar.

41
New cards

Kubernetes patterns (behavioral)

Batch Job; Stateful Service; Service Discovery.

42
New cards

Kubernetes patterns (higher-level)

Controller; Operator.

43
New cards

Serverless computing (definition)

Develop/run code without provisioning or managing servers/back-end infrastructure.

44
New cards

Serverless computing (developer experience)

Servers are invisible to the developer; managed by a CSP.

45
New cards

Serverless history (GAE)

Began in 2008 with Google App Engine.

46
New cards

Serverless history (AWS Lambda)

2014: Amazon introduced AWS Lambda, the first serverless platform.

47
New cards

Serverless use cases (microservices)

Supports microservices architectures.

48
New cards

Serverless use cases (API backends)

Functions can be exposed as HTTP endpoints (web actions) via API gateways for security.

49
New cards

Serverless use cases (data processing)

Suited for structured text, audio, image, and video tasks (enrichment, transformation, validation, cleansing).

50
New cards

Serverless use cases (massively parallel)

Great for large parallel tasks; each parallelizable task invokes an action (e.g., MapReduce, web scraping, HPT, genome processing).

51
New cards

Cloud storage development (definition)

Build apps leveraging third-party managed remote servers for internet-based data access.

52
New cards

Cloud storage development (steps)

Choose tech; design secure/scalable architecture; configure secure connections/access; automate backup/monitoring.

53
New cards

Cloud storage development (benefit)

Scalability, cost efficiency, flexibility over owning physical data centers.

54
New cards

Cloud storage key aspects (architecture/design)

Design for future demand; choose object/file/block storage appropriately.

55
New cards

Cloud storage key aspects (security)

Use VPC; strong authorization; encryption and access controls from providers.

56
New cards

Cloud storage key aspects (integration)

Integrate via APIs/SDKs with compute, networking, analytics.

57
New cards

Cloud storage key aspects (backup/recovery)

Automate backups for disaster recovery.

58
New cards

Cloud storage key aspects (monitoring)

Monitor usage, performance, and capacity to preempt issues.

59
New cards

Cloud storage benefits (scalability)

Scale capacity up or down to match demand.

60
New cards

Cloud storage benefits (cost)

Pay for what you use (OpEx vs CapEx).

61
New cards

Cloud storage benefits (flexibility)

Select storage mix for security/compliance/performance needs.

62
New cards

Cloud storage benefits (accessibility)

Access and build from virtually anywhere with internet connection.

63
New cards

Containerized database (official images)

MySQL, PostgreSQL, MongoDB have Docker Official Images on Docker Hub.

64
New cards

Containerized database (why official)

Curated with best practices; latest features and security updates.

65
New cards

Containerized database (how-to)

Check Docker Hub page for run/config/customization instructions.

66
New cards

Containerized database (GUI/CLI)

Run via Docker Desktop GUI or CLI (examples use CLI).

67
New cards

Containerized database (container shell)

Use container shell for admin, commands, management.

68
New cards

Containerized database (docs)

See: https://docs.docker.com/guides/databases/

69
New cards

Persist database data (why)

Ensure data survives container restarts/removals.

70
New cards

Persist database data (how)

Use Docker volumes to store DB files outside container's writable layer.

71
New cards

Persist database data (run)

Use -v with docker run to attach a volume to the DB data path.

72
New cards

Persist database data (auto-create)

Docker auto-creates the volume if it doesn't exist.

73
New cards

Customized database image (what/why)

Bake configs/scripts/tools into a DB image for specific env needs; e.g., add init SQL.

74
New cards

REST (acronym)

Representational State Transfer.

75
New cards

REST (origin)

Roy Fielding's 2000 PhD dissertation, describing a networked systems design pattern.

76
New cards

REST (style)

Architecture style for web services; widely used by major web services.

77
New cards

HTTP (role in REST)

Application-level protocol; operations transfer representations between clients and servers.

78
New cards

HTTP methods (CRUD mapping)

GET=Retrieve; POST=Update; PUT=Create (client controls URI); DELETE=Delete.

79
New cards

POST vs PUT (creation)

POST can create; use PUT to create only when clients can assign URIs.

80
New cards

REST design principles (list)

Use HTTP methods explicitly; be stateless; expose directory-like URIs; use proper content type.

81
New cards

REST performance scaling

Distribute services across servers for performance; intermediary servers require complete independent requests.

82
New cards

Postman (what it is)

API development tool to build/test/modify APIs.

83
New cards

Postman (features)

Supports GET/POST/PUT/PATCH; env saving; code generation for languages (e.g., JS, Python).

84
New cards

Monolith vs microservices (definition)

Monolith = single unified unit; Microservices = smaller, independently deployable services.

85
New cards

Monolithic services (coupling)

All processes are tightly coupled; run as a single service.

86
New cards

Monolithic services (scaling)

Scaling one process often requires scaling the whole application.

87
New cards

Monolithic services (complexity)

Feature additions become complex as codebase grows; experimentation harder.

88
New cards

Monolithic services (availability risk)

One process failure can impact the entire app due to tight coupling.

89
New cards

Microservices (composition)

App built as independent components, each running a specific business function.

90
New cards

Microservices (communication)

Communicate via well-defined, lightweight APIs.

91
New cards

Microservices (independent ops)

Update, deploy, and scale services independently.

92
New cards

Microservices characteristics (autonomous)

Developed, deployed, operated, and scaled independently; communicate only via APIs.

93
New cards

Microservices characteristics (specialized)

Each service focused on a specific capability; can be split further if it grows complex.

94
New cards

Microservice data (ownership)

Each microservice owns its domain data and logic; data is private to the service.

95
New cards

Microservice data (access)

Access via synchronous APIs (REST/gRPC/SOAP) or async messaging.

96
New cards

Traditional data approach (monolithic)

Centralized/normalized SQL database shared across the whole application.

97
New cards

Docker (containers vs images)

Image = package with code/runtime/tools/libs; Container = running instance of an image.

98
New cards

Containers (portability)

Run the same on Linux/Windows across infrastructures.

99
New cards

Containers (isolation)

Software is isolated from environment, ensuring uniform behavior across stages.

100
New cards

Building images (Dockerfile)

Images are built from Dockerfile instructions with docker build.