Summary of "Lec 7: History of Distributed Systems"

Brief summary / timeline

The video traces the evolution of distributed-system architecture:

Monolithic → Service-Oriented Architecture (SOA) → Microservices → Serverless (current trend).
It explains motivations for each shift, key characteristics, pros/cons, and recommended practices (especially for microservices and serverless).

What it is:

A single large program contains all functionality as one deployable artifact running on one server.
Example: a single 10,000-line banking application handling withdraw, deposit, balance inquiry, PIN change, interest calculation, etc.

Problems / drawbacks:

Hard to maintain and understand; even a small change can require reading and testing the whole codebase.
High downtime for updates/bug fixes (single point of failure).
Platform dependency and costly migrations (language/OS/runtime upgrades).
Scaling and hardware failures affect the entire application.

Context:

What it is:

The monolith is broken into business-oriented services (withdraw service, deposit service, interest service, etc.).
Services are often exposed as web services (network-accessible endpoints).

Advantages:

Easier maintenance for focused functional areas (smaller code units than a monolith).
Reduced downtime for the rest of the system when a single service is changed.
Widely adopted by early internet-era enterprises; many legacy systems used SOA.

Limitations / why it regressed:

Services were often still deployed on the same machine or environment, so single-machine failures remained a risk.
Over time services tended to grow large as new features were continuously added (services became monolithic again).
By around 2013–2014 many SOA projects faced the same maintainability problems as monoliths.

What it is:

Decompose services further into many small services, each responsible for a single task (single-responsibility principle).
Promote independent deployability and ownership of small services.

Key principles / recommended practices:

Single responsibility: each microservice does one task/function.
Small code footprint per service (from thousands of lines to tens or low hundreds).
Independent development, testing, and deployment for each service.
Polyglot development: services can be implemented in different languages/tools (choose the best tool per service).
Deploy to cloud infrastructure (not a single on-prem server) to gain autoscaling, high availability, and to remove single-server failure risk.
Add new features by creating new microservices rather than modifying many existing ones.

Benefits:

Much lower downtime for changes; easier, faster deployments and testing at the service level.
Easier to scale and evolve parts of the system independently.

Caveats:

Increases the number of services to manage (can be thousands; e.g., Amazon reportedly has 23,000+ microservices).
Requires operational maturity: service discovery, monitoring, orchestration, CI/CD, networking, distributed tracing, etc.

What it is:

A development and execution model where developers write and run code on cloud-managed platforms (e.g., AWS Lambda, Azure Functions, GCP Functions) without managing servers.
Can be used with microservices (microservices implemented as serverless functions).

Characteristics / benefits:

Development, testing, and deployment can be done from any machine with internet access; no local installations required.
Cloud provider manages underlying servers, scaling, and resource provisioning.
Reduces developer dependency on specific local hardware or licensed IDEs.
Useful for remote work and rapid development cycles.

Notes:

“Serverless” means servers aren’t managed by the developer, not that servers don’t exist.

Serverless is positioned as part of the modern microservice deployment pipeline.

Evolution is driven by practical problems: maintainability, downtime, scaling, deployment, and changing feature requirements.
Each architectural shift solved some problems but introduced new trade-offs; organizational and operational practices must evolve along with code architecture.
Current best practice recommended by the speaker: design small, single-responsibility microservices, deploy them in the cloud, and consider serverless functions where appropriate.

Industry examples using these styles: Amazon (large microservice usage), Flipkart, SBI (banking), IRCTC, Tata, Vodafone, Jio.
Cloud/serverless platforms referenced: AWS (Lambda), Azure (Functions), GCP.

Unnamed lecturer / course instructor (primary speaker and narrator).
Mentioned/referenced companies and platforms listed above (examples, not individual speakers).