1/191
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced |
|---|
No study sessions yet.
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
Cloud-based databases (definition)
Offer scalability and flexibility; accessible from anywhere.
Traditional databases (definition)
Operate on-premises; ideal for structured data and direct access.
Traditional databases (speed)
Excel in speed.
Traditional databases (scalability)
Lack scalability compared to cloud options.
Traditional databases (security control)
Provide full control over security.
Traditional databases (cost)
Higher initial costs.
Traditional databases (when to use)
For businesses needing data control and instant access.
Hybrid option (cloud + traditional)
Combine both approaches to tailor for business needs and security requirements.
Cloud REST APIs & microservices (relationship)
Complementary technologies used together to build modern, scalable, flexible apps.
REST API (definition)
Representational State Transfer Application Programming Interface.
Microservices (definition)
Architectural style where a large app is broken into smaller, independent, loosely-coupled services.
REST APIs in microservices
Common and effective way for services to communicate with each other and clients.
RESTful principles (list)
Statelessness; client-server separation; uniform interface.
SOAP vs REST (purpose)
SOAP = protocol for communication between applications; REST = architecture style for designing communication interfaces.
SOAP vs REST (design exposure)
SOAP API exposes operations; REST API exposes data.
SOAP vs REST (transport)
SOAP works with any transport protocol; REST (in slides) works only with HTTPS.
SOAP vs REST (data format)
SOAP supports only XML; REST supports XML, JSON, plain text, HTML.
SOAP vs REST (performance)
SOAP messages are larger and slower; REST is faster due to smaller messages and caching.
SOAP vs REST (scalability)
SOAP is difficult to scale (server maintains state); REST is easy to scale (stateless).
SOAP vs REST (security)
SOAP supports encryption with overhead; REST supports encryption without affecting performance.
SOAP vs REST (use case)
SOAP for legacy/private APIs; REST for modern/public APIs.
Docker (what it is)
An open platform for developing, shipping, and running applications.
Docker (why)
Standardized local containers streamline development and CI/CD workflows.
Docker lifecycle tooling
Develop in containers → container is unit of distribution/testing → deploy as container or orchestrated service.
Docker deployment environments
Works the same across data centers, cloud providers, or hybrid setups.
Docker building best practices (multi-stage)
Use multi-stage builds to create reusable, smaller images.
Docker building best practices (base image)
Choose Docker Official/verified/sponsored base images.
Docker building best practices (rebuilds)
Rebuild often; avoid stale cache.
Docker building best practices (.dockerignore)
Exclude files not relevant to the build.
Docker building best practices (ephemeral)
Create ephemeral containers that can be stopped/destroyed/rebuilt with minimal setup.
Docker building best practices (minimalism)
Don't install unnecessary packages.
Docker building best practices (single concern)
Decouple apps; one concern per container.
Docker building best practices (sort args)
Sort multi-line arguments alphanumerically for maintainability.
Docker building best practices (cache)
Leverage the build cache appropriately.
Docker building best practices (pinning)
Pin base image versions; tags can be updated by publishers.
Docker building best practices (CI)
Build and test images in CI.
Kubernetes (what it is)
Most popular container orchestration platform.
Kubernetes patterns (foundational)
Health Probe; Predictable Demands; Automated Placement.
Kubernetes patterns (structural)
Init Container; Sidecar.
Kubernetes patterns (behavioral)
Batch Job; Stateful Service; Service Discovery.
Kubernetes patterns (higher-level)
Controller; Operator.
Serverless computing (definition)
Develop/run code without provisioning or managing servers/back-end infrastructure.
Serverless computing (developer experience)
Servers are invisible to the developer; managed by a CSP.
Serverless history (GAE)
Began in 2008 with Google App Engine.
Serverless history (AWS Lambda)
2014: Amazon introduced AWS Lambda, the first serverless platform.
Serverless use cases (microservices)
Supports microservices architectures.
Serverless use cases (API backends)
Functions can be exposed as HTTP endpoints (web actions) via API gateways for security.
Serverless use cases (data processing)
Suited for structured text, audio, image, and video tasks (enrichment, transformation, validation, cleansing).
Serverless use cases (massively parallel)
Great for large parallel tasks; each parallelizable task invokes an action (e.g., MapReduce, web scraping, HPT, genome processing).
Cloud storage development (definition)
Build apps leveraging third-party managed remote servers for internet-based data access.
Cloud storage development (steps)
Choose tech; design secure/scalable architecture; configure secure connections/access; automate backup/monitoring.
Cloud storage development (benefit)
Scalability, cost efficiency, flexibility over owning physical data centers.
Cloud storage key aspects (architecture/design)
Design for future demand; choose object/file/block storage appropriately.
Cloud storage key aspects (security)
Use VPC; strong authorization; encryption and access controls from providers.
Cloud storage key aspects (integration)
Integrate via APIs/SDKs with compute, networking, analytics.
Cloud storage key aspects (backup/recovery)
Automate backups for disaster recovery.
Cloud storage key aspects (monitoring)
Monitor usage, performance, and capacity to preempt issues.
Cloud storage benefits (scalability)
Scale capacity up or down to match demand.
Cloud storage benefits (cost)
Pay for what you use (OpEx vs CapEx).
Cloud storage benefits (flexibility)
Select storage mix for security/compliance/performance needs.
Cloud storage benefits (accessibility)
Access and build from virtually anywhere with internet connection.
Containerized database (official images)
MySQL, PostgreSQL, MongoDB have Docker Official Images on Docker Hub.
Containerized database (why official)
Curated with best practices; latest features and security updates.
Containerized database (how-to)
Check Docker Hub page for run/config/customization instructions.
Containerized database (GUI/CLI)
Run via Docker Desktop GUI or CLI (examples use CLI).
Containerized database (container shell)
Use container shell for admin, commands, management.
Containerized database (docs)
See: https://docs.docker.com/guides/databases/
Persist database data (why)
Ensure data survives container restarts/removals.
Persist database data (how)
Use Docker volumes to store DB files outside container's writable layer.
Persist database data (run)
Use -v with docker run to attach a volume to the DB data path.
Persist database data (auto-create)
Docker auto-creates the volume if it doesn't exist.
Customized database image (what/why)
Bake configs/scripts/tools into a DB image for specific env needs; e.g., add init SQL.
REST (acronym)
Representational State Transfer.
REST (origin)
Roy Fielding's 2000 PhD dissertation, describing a networked systems design pattern.
REST (style)
Architecture style for web services; widely used by major web services.
HTTP (role in REST)
Application-level protocol; operations transfer representations between clients and servers.
HTTP methods (CRUD mapping)
GET=Retrieve; POST=Update; PUT=Create (client controls URI); DELETE=Delete.
POST vs PUT (creation)
POST can create; use PUT to create only when clients can assign URIs.
REST design principles (list)
Use HTTP methods explicitly; be stateless; expose directory-like URIs; use proper content type.
REST performance scaling
Distribute services across servers for performance; intermediary servers require complete independent requests.
Postman (what it is)
API development tool to build/test/modify APIs.
Postman (features)
Supports GET/POST/PUT/PATCH; env saving; code generation for languages (e.g., JS, Python).
Monolith vs microservices (definition)
Monolith = single unified unit; Microservices = smaller, independently deployable services.
Monolithic services (coupling)
All processes are tightly coupled; run as a single service.
Monolithic services (scaling)
Scaling one process often requires scaling the whole application.
Monolithic services (complexity)
Feature additions become complex as codebase grows; experimentation harder.
Monolithic services (availability risk)
One process failure can impact the entire app due to tight coupling.
Microservices (composition)
App built as independent components, each running a specific business function.
Microservices (communication)
Communicate via well-defined, lightweight APIs.
Microservices (independent ops)
Update, deploy, and scale services independently.
Microservices characteristics (autonomous)
Developed, deployed, operated, and scaled independently; communicate only via APIs.
Microservices characteristics (specialized)
Each service focused on a specific capability; can be split further if it grows complex.
Microservice data (ownership)
Each microservice owns its domain data and logic; data is private to the service.
Microservice data (access)
Access via synchronous APIs (REST/gRPC/SOAP) or async messaging.
Traditional data approach (monolithic)
Centralized/normalized SQL database shared across the whole application.
Docker (containers vs images)
Image = package with code/runtime/tools/libs; Container = running instance of an image.
Containers (portability)
Run the same on Linux/Windows across infrastructures.
Containers (isolation)
Software is isolated from environment, ensuring uniform behavior across stages.
Building images (Dockerfile)
Images are built from Dockerfile instructions with docker build.