Microservices, Kubernetes, and Serverless Computing
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- Kubernetes cluster components, pods, and scaling — covered in Lecture 18 (Docker and Kubernetes: Container Orchestration)
- Docker containers and the container runtime — covered in Lecture 18 (Docker and Kubernetes: Container Orchestration)
- Cloud service models — SaaS, PaaS, and IaaS — covered in Lecture 7 (Cloud as a Catalyst for DevOps)
- Serverless computing and function as a service — covered in Lecture 7 (Cloud Service Models: SaaS, PaaS, and IaaS)
- Auto scaling — covered in Lecture 17 (Configuration Management, Infrastructure as Code, and On-Demand Infrastructure)
- Canary testing, rollback, and deployment considerations — covered in Lecture 13 (Deployment Pipelines and Continuous Delivery)
- Value stream maps — covered in Lecture 3 (The Need for DevOps)
- SRE versus DevOps, and feature teams — covered in Lecture 4 (DevOps Misconceptions, Anti-Patterns, and Agile Methods)
- BDD, FDD, and TDD — covered in Lecture 4 (DevOps Misconceptions, Anti-Patterns, and Agile Methods)
Microservices, Kubernetes, and Serverless Computing
20.1 Microservices
20.1.1 What Is a Microservice?
Hook: Why can Netflix still stream your movie while its recommendation engine is down, yet a traditional banking app freezes for everyone when a single feature breaks? The difference lies not in better code but in how the application is cut up — as one big welded-together program or as many small, independent services.
A microservice is a software development technique — a way of designing your architecture. More precisely, it is a type of service-oriented architecture (SOA): it supports structuring an application as a collection of loosely coupled services. That means you divide your application into small, small services, and those services can be loosely coupled with each other instead of being welded together into one program. Because the components are separated and loosely coupled, the architecture improves the modularity of your code. Modularity, in turn, resolves maintenance issues much faster — if one piece breaks, you repair that piece rather than digging through a whole application. Reusability also becomes possible: a service built for one feature can serve another feature later.
Formalize — the two architectures side by side. Picture an application as a set of feature units , each handling one business function such as login, payment, or search. In a monolithic architecture, all units are compiled into a single deployable program ; a change to unit means rebuilding and redeploying all of , and a crash in can take down every other unit. In a microservice architecture, each unit runs as its own small service with its own data store, and the units talk to one another through explicit application programming interfaces (APIs) — most often REST APIs, which are plain HTTP requests to a service's URL. The unit of deployment, the unit of scaling, and the unit of team ownership are all the same: one small service, not the whole application.
The bigger organizational payoff is that microservices enable small autonomous teams. A small team can develop, deploy, and scale up or scale down its own service independently. They work independently and focus on their individual service, and they can easily deploy and scale that service without coordinating with everyone else. This even allows the architecture of an individual service to emerge through continuous refactoring — you are not locked into a design decision made at the start of the project.
How does this work in practice? The basic idea is to break your application down into smaller and independent services. The services should not depend upon one specific coding language: one team can opt for its own comfortable or preferred language rather than being restricted to a single shared language. Using the microservice ideology, you divide a large and complex application into smaller building blocks that are independent and loosely coupled.
The characteristics of microservices are worth memorizing as a set:
- They enable a process-oriented way of working, which naturally helps with a great amount of documentation.
- They are autonomous and flexible — because the modules are loosely coupled, you can plug and play with them; you can pull a module out and drop a replacement in.
- You can easily improve automation — and with automation, you can control the overall pipeline.
- They give you right sizing: right size means a small team working on a small service, choosing its own technology stack, instead of one giant team carrying a giant application.
Scope: the microservice model assumes a network of services that can actually talk to each other, teams large enough to own a service end to end, and a culture that can coordinate many small deployments. The model breaks when these fail: if every service quietly shares one central database, you lose the loose coupling and get a "distributed monolith"; if the organization cannot automate deployment, the sheer number of services makes releases slower than a single application. Note also the limit of the plug-and-play picture: pulling a module out and dropping a replacement in requires the replacement to honour the same API — otherwise every caller must change too.
20.1.2 Who Uses Microservices — the Netflix Example
Netflix is the classic example, and the story shows why the architecture matters for availability. Netflix has multiple features — you can watch OTT shows, you can watch movies — and one of its advanced features is the recommendation service: it shows you recommended videos based on your last-seen history, your last-watched content. That recommendation feature is one single service inside Netflix.
Sometimes the recommended feed shows content that is not in line with your interests — you watched horror movies, and it shows you comedy videos. When that happens, it is likely because that particular recommendation service is down, probably under maintenance or under some other constraint. Here is the key: that failure does not impact the overall Netflix app. You can still open Netflix, you can still stream videos. The failed service just shows static video content — not in line with your interest — while everything else keeps working.
The availability insight: in a monolithic application, a failing module typically takes the whole process down — one bad feature breaks the login screen and the payment page together. In a microservice application, a failing service degrades only itself: the request that would have used it falls back to static content, and every other service keeps serving real users. So microservice architecture buys you a great amount of availability: because your services are loosely coupled, if any one service is down, it does not directly bring down the whole application. And scalability is easy, because you scale only the service that needs it.
Visual intuition. Picture the Netflix app as a grid of small boxes — streaming, search, billing, profiles, recommendations — each box connected to the others by thin API lines rather than by shared memory. When the recommendation box goes grey, the lines around it go slack, but every other box keeps receiving traffic. Now imagine the same picture with one giant box labelled "Netflix": a failure anywhere inside it is a failure everywhere. That single contrast — many small boxes with detachable connections versus one big box — is the whole availability argument in one image.
Real-world: every major organization you have heard of uses microservice architecture for its application — Uber, Netflix, Amazon, eBay, Gilt, and Tesla are all names the industry routinely cites. The same pattern shows up in the Atlassian case study in the reference text: Atlassian's BlobStore microservice — about 2,500 lines of Scala storing file attachments in Amazon S3 with key mappings in DynamoDB — is owned by a team of five developers who deploy it to production themselves, often two or three times a day, exactly the small-team, independently-deployable service shape described here.
20.1.3 Monolithic vs Microservice Architecture
To appreciate microservices, compare them with the monolithic architecture that was standard 10 to 20 years back. In a monolithic application you have three layers: the user interface, the business logic, and the database access layer. Whatever request comes from the user interface has to be processed by the business logic, and to process that input you need database access — either to extract data or to update data. The entire application used to be compacted into one full-fledged application, developed as a compact solution within a single technology stack at a time. User interface, business logic, and DB access all lived together.
With the microservice architecture, the user interface still exists and users still reach your services through it — but there is no single business logic that serves every feature. You break the features into small services, and each microservice has its individual database. There can even be a chance that one microservice calls another microservice to fulfill one particular user request. Each microservice having its own database gives the team the flexibility to choose their own coding language and their own database — nobody is stuck with a single database, and nobody is stuck with a single coding language for the whole business logic as in monolithic. Small autonomous teams can work on their own preferred language and preferred DB, which reduces errors because they are scaled with the technology they know well.
The professor's comparison of the two approaches:
| Dimension | Monolithic | Microservice |
|---|---|---|
| Development approach | Traditional way of development — waterfall, spiral, any traditional software development | New approach that brings more agility |
| Team | Large team working on a single complex application | Small handful of developers, each on an individual service |
| Understanding | No single developer understands the entire application | Developers understand their individual services thoroughly |
| Reuse | Limited reuse is realized | Services reuse other services by simply calling REST APIs |
| Scaling | Scaling is a challenge | Services scale independently — scale up or scale down easily |
| Operational agility | A challenge | Services and teams become more agile |
| Development stack | Single development stack | Autonomous service development stack per team |
A few benefits flow directly from the microservice shape. Scalability is efficient — you can scale up or scale down individual services. Modifiability comes from modular code, so modifications are made very easily. And management of microservices is easier than managing a full-fledged code base: you are managing small, small services instead of one huge application.
Pitfalls:
- A distributed monolith: breaking an application into deployable units while still sharing one database or one rigid integration point gives you the worst of both — microservice deployment complexity with monolith coupling. If a request still passes through every service in a fixed chain, you have not gained independence.
- Deployment complexity is not zero: a microservice code base is smaller, but the moving parts around it — deployment pipelines, networks, logging, metrics, service discovery — are far more than for one application. Real-world teams report the first microservice rollout is the slowest, and the platform work around it often takes the most time.
- Independence does not mean isolation: a service that crashes can still stall its callers if they wait synchronously for it. Availability comes from combining loose coupling with timeouts, retries, and fallback content, not from the architecture alone.
- Letting services grow back: without discipline, a microservice quietly absorbs feature after feature and becomes a monolith in disguise. Teams must be willing to refactor and split services as they grow — the professor's point that architecture should be allowed to emerge through continuous refactoring.
20.1.4 The E-Grocery Application: Monolithic and Microservice Views
The e-grocery application — used throughout the course to explain software development concepts — shows the difference concretely.
Monolithic view. Even if the application is deployed on a container solution, all the services are intact inside the same container; they are monolithic. From a gateway, the user accesses the application and reaches these API endpoints: add item to cart, payment gateway, login, and email user. Each endpoint pulls in the services it needs:
- Add item to cart needs cart storage and inventory storage.
- Payment needs the payment engine service and cart storage — because the calculation depends on what items are in the cart — plus third-party authentication.
- Login needs third-party authentication and account storage, where the username and credentials are verified.
- Email user (when you want to send something to the user) needs an SNS provider and account storage.
Worked example — decomposing the payment gateway.
Step 1 — trace one request in the monolith. A user clicks "pay". The request enters through the gateway and lands on the payment endpoint. That endpoint reaches into three things: the payment engine (computes the total), cart storage (reads the items, because the total depends on what is in the cart), and third-party authentication (verifies the payer). All three live inside the same container as every other feature — login, email, inventory, cart. If the payment logic throws an exception, the whole container process is affected, and the app is broken for every feature, not just checkout.
Step 2 — cut the payment piece out. Now break the payment gateway engine out as a separate service. You have a payment API endpoint segregated from the rest of the application's services. The payment service can still access the payment engine, cart storage, and third-party authentication — but cart storage and authentication are now API access: the payment service calls the REST API of cart storage and the REST API of third-party authentication.
Step 3 — the failure drill. Think of the situation where this one service is down: the payment service goes to maintenance, the checkout page cannot complete a transaction. What happens to the rest of the application? It keeps working fine. Users can still log in (login service is up), still browse the catalogue, still add items to the cart. Only the checkout feature degrades — exactly the Netflix recommendation story at a smaller scale.
Step 4 — the final architecture. The same idea extends to every function: payment is one service, add item to cart is another, login is another, email service is another. All services are broken down into single, single services, and each calls the others through REST APIs. That is the microservice architecture in practice.
Sense-check: in the decomposed view, each service carries its own storage and its own API, and no service shares a process or a database with another — so a single-point failure in one service no longer becomes a whole-application failure.
The same decomposition pattern runs through real systems: the reference text's Atlassian case study describes exactly this shape — BlobStore exposing a small HTTP API, JIRA and Confluence calling it through a client plug-in, with the consumer applications decoupled from BlobStore's deployment cycle. When a service is shared this way, teams must also think about fallbacks and caching, because a network call to another service is slower and less reliable than an in-process function call.
20.1.5 Microservices and DevOps Working Together
How do microservices and DevOps come together? DevOps promotes effective people management and small teams: DevOps is a culture that follows the same process as Agile, with some amendments, and Agile encourages working in small teams. So DevOps promotes small, empowered, autonomous teams equipped with automation tools, and with those automations in place you need measurements as well. There is great potential for a fantastic improvement in how IT and business work together.
Microservices and DevOps reinforce each other. Microservices break the application into small building blocks, so small services can be delivered by small teams — that enables the DevOps culture. But the challenging part is the pipeline.
The pipeline needs an architect's mindset. Setting up a pipeline for new automation tooling — DevOps promotes CI/CD pipelines — gets harder when the application is split into many services. Setting up that pipeline requires a mindset of architects, because you are changing the architecture diagram itself: you are not writing one pipeline for one application, you are designing a pipeline per service. In practice, organizations adopt a distributed version control system to support microservice architecture: you need multiple branches for multiple features, and every feature is an independent service that should have its own pipeline. In each feature branch you have the source code repository, and inside that repository there is a Jenkins file written for that particular feature. That is how the pipeline architecture for a microservice application looks.
Seen from the other side, microservices enable DevOps because small autonomous DevOps teams start producing small components — microservices. It makes sense to produce small deployable components for a business function: you support a workable product, not a non-workable one, and small deployable components get there faster. If you move to a cloud platform instead of working on your local environment, you get speed improvements of 5 to 10 times more, which speeds up delivery to the end customer.
Recap — the professor's summary: DevOps and microservices are more or less inseparable — they hardly exist in separation. If you are adopting DevOps culture, you need agility, and if you need agility, your architecture should support microservices. Each side feeds the other: microservices hand small, independently deployable units to small DevOps teams, and those teams build the per-feature pipelines (feature branch + Jenkins file) that microservices demand.
Real-world & domain connection. This is the standard shape in the industry: Netflix and Amazon ship hundreds of services with per-team pipelines; Atlassian's BlobStore team keeps its microservice in a Git repository with short-lived feature branches and a Bamboo pipeline that reaches production about an hour after merging to master. In every case the same two facts hold: the architecture is built of small independently deployable units, and the organization is built of small autonomous teams with automated pipelines around each unit. One caution from practice: distributed teams must also manage inter-service dependencies — one team's deployment can block another's if the interfaces do not stay compatible.
Exam note: expect a conceptual question connecting DevOps and microservices — the "inseparable" relationship and the per-feature pipeline idea (feature branch + Jenkins file) are the points examiners look for. Be ready to state both directions: microservices enable DevOps (small components for small teams) and DevOps enables microservices (automation makes many small services manageable).
20.2 Kubernetes
20.2.1 What Is Kubernetes?
Hook: You have deployed twenty containers across three machines. One container crashes at 2 a.m., another machine runs out of memory, and a third has spare capacity. Who notices, who restarts the crashed work, and who moves work to the machine with free capacity? Doing all of that by hand is what Kubernetes was built to eliminate.
Kubernetes is an open source system designed and developed with a single concept in mind: managing containerized applications. Everything — configurations, load balancing, sending information to all the nodes where containers run — should happen with automation. To achieve that, Kubernetes was launched, and it provides the basic mechanism for the deployment, maintenance, and scaling of applications. It is hosted by the Cloud Native Computing Foundation (CNCF). Many people and organizations simply call it K8: the abbreviation is derived by replacing the eight letters between "K" and "s" with the number 8.
What it manages. Kubernetes runs and coordinates containerized applications across a cluster of machines — a group of machines that work together as one system. You want to maintain, manage, and automate the configuration of multiple machines at a time. It is a platform designed to completely manage the lifecycle of containerized applications and services: creating them, watching them, restarting them, scaling them, and tearing them down. Kubernetes provides methods that deliver predictability — the cluster behaves the way you declared it should; from that predictability you can achieve scalability — scale up or scale down. Kubernetes also guarantees high availability: if any instance, service, or container shuts down, Kubernetes automatically brings it back up. That automatic recovery is what achieves high availability.
The mental model to keep for the whole section: you declare what you want, and Kubernetes makes the machines match your declaration. The human writes configuration once; from then on the system continuously compares reality against that declaration and corrects any drift — that single loop powers the predictability, scalability, and high availability claimed above.
20.2.2 Control Plane Components (the Master Node)
The Kubernetes cluster is divided into a master node and server nodes (client/worker nodes). On the master node you configure everything — the automation scripts, creating those scripts, enabling trigger events. You access the master node either through a command line editor or through a user interface. The nodes — node 1, node 2, node 3 in the diagram — are managed by the master node.
Visual intuition. Picture the cluster as a small railway yard. The master node is the control tower: it holds the timetable (what should run where), takes requests from the dispatcher (you), and sends signals down to the yard tracks. The worker nodes are the platforms where the actual trains — the containers — sit. Each platform has a local agent that carries out the tower's orders and reports back, and each has a signal box that routes arriving traffic to the right platform. The control tower's components are the subject of this subsection; the platform-side agents are covered in the next one.
The master node has four components:
- etcd — by the name itself, this is a storage device. It is the globally available configuration store: all the distributed key-value pairs, all the configuration information, are stored in this etcd store. It is configured to span across multiple nodes — whatever number of nodes the master supports, those nodes should be able to access the etcd store. etcd can be configured on a single master server, but for production scenarios organizations generally prefer it distributed among a number of machines.
- kube API server — by name, an API, an interface. This is the main management point of the cluster. It allows the user to configure Kubernetes workloads and organizational units, and it is responsible for making sure that the etcd store and the service details you created are in agreement — the details of deployed containers are kept in line. The API server also implements the RESTful interface so that the end nodes can access the etcd store.
- kube controller manager — by name, it controls. Different controllers regulate the state of the cluster, manage the workload lifecycle, and perform routine tasks. The replication controller is one such service: it ensures that the number of replicas defined in the etcd folder is actually in place. Say you define that the payment service needs two instances — two replicated services for the payment gateway. Once you define that, the replication controller ensures two instances exist and keeps them running; if one shuts down, it automatically reinitiates it. If you later want to scale up the payment engine from two to three or four instances, you just change the configuration in the etcd folder — "I want four instances for this service" — and the replication controller automatically makes four instances. When a change is seen, the controller reads the new information and implements the procedure that fulfills the desired state.
Worked example — the replication controller chasing the desired state.
Step 1 — declare the desired state. The team writes the configuration: the payment service must run two replicas. This value — replicas: 2 — is written into etcd. The replication controller reads it and creates two container instances of the payment service.
Step 2 — the steady state. Both instances are running. The controller checks the cluster, sees two live instances, compares with the desired value 2, and does nothing. Desired state and actual state match.
Step 3 — failure and automatic recovery. One instance's container crashes. The controller's next check sees only 1 live instance while the desired state is 2. The difference is 1, so the controller creates a fresh instance — the payment service is back to two running instances, automatically, without a human being paged.
Step 4 — scaling up by changing the declaration. The payment engine is under load. Instead of restarting servers, the team edits the etcd configuration: replicas: 4. The controller reads the new desired value, compares it with the current 2, sees a gap of 2, and launches two more instances — four payment instances now run, still automatically.
Step 5 — scaling down. Load drops; the team sets replicas: 2 again. The controller terminates two instances until actual matches desired.
Sense-check: at every moment the controller is a pure loop — read desired value, count actual instances, create or terminate until the two match. Nothing human intervenes, which is exactly why Kubernetes can promise high availability and effortless scaling.
- kube scheduler — the process that assigns the workload to a particular node in the cluster. This is how the cluster achieves load balancing. The scheduler tracks the available capacity on each host, so workloads are never scheduled in excess of available resources. It finds the node where capacity is more and not being used, and pushes the request to that particular node to get it fulfilled for the end user.
The whole set of master components is called the control plane: they work together to accept user requests, find the best way to schedule container workloads, authenticate clients and nodes, manage cluster-wide networking, and take responsibility for scalability and health checking — if something goes wrong, bring it back up automatically. These components can be installed on a single machine or distributed across multiple servers.
20.2.3 Worker Node Components
In Kubernetes, the servers that perform work by running containers are known as nodes. Each node has a few necessary requirements: communication with the master component; configured container networking so that the node is uniquely identified in the IP network; and the ability to run the actual workload assigned to it. Fulfilling all this needs a container runtime — every node must have a running container. The requirement is satisfied by installing and running Docker, or any other containerized technology that creates and runs containers. The container runtime is responsible for starting and managing the containers defined in the workloads submitted to the cluster.
Two node-side components keep the node connected to the cluster:
- kubelet — the main contact point for each node with the cluster group. It relays information to and from the control plane services, and it interacts with the etcd store — reading configuration details, or writing new values when there are changes. The kubelet service communicates with the master component to authenticate to the cluster and to receive commands and work.
- kubeproxy — manages individual host subnetting and makes the service available to other components. This process forwards requests to the correct containers, and it can do primitive load balancing.
Q: How do worker nodes access the configuration stored in etcd? A: They access it through the master components. As described earlier, the API server implements a RESTful interface so that the end nodes can access the etcd store; the content needed by a particular worker node is made available to it through the master node components. The worker nodes never read or write etcd directly — the API server is the single door into the configuration store, which is also how the cluster keeps configuration changes controlled and consistent.
Pitfalls:
- Confusing the roles: the control plane (master) decides and stores — etcd holds configuration, the scheduler picks nodes, the controller manager enforces the desired state; the worker node executes — the container runtime runs containers, kubelet carries orders, kubeproxy routes traffic. An exam answer that lets a worker node read etcd directly is wrong: that path goes through the API server.
- Scheduler is not the replicator: the scheduler assigns new workloads to nodes with free capacity; keeping the right number of running instances is the replication controller's job. They answer different questions — "where?" versus "how many?".
- Forgetting the container runtime: a node without Docker (or an equivalent runtime) cannot run a workload at all — it is the node's most basic requirement, not an optional extra.
- etcd is not a general database: it stores configuration and cluster state (key-value pairs). Teams that put application data in etcd misuse the store and complicate production setups.
20.2.4 Pods — the Kubernetes Object
The core Kubernetes object is the pod. If you remember Docker, where a stack holds services that are tightly coupled, Kubernetes pods work the same way: one or more tightly coupled containers are encapsulated as a single object called a pod. A pod generally represents one or more containers that should be controlled as a single application because they depend on each other. Some services are dependent, should share the same lifecycle, and should always be scheduled on the same node — for such containers, you encapsulate them as one object. The containers inside a pod share their environment, shared volumes, and even IP addresses. A pod consists of a main container that satisfies the general purpose of the workload and, optionally, some helper containers that help with closely related tasks. The memory rule: when it is a pod, it is more than one container, encapsulated in a single object, because they are dependent and share the same lifecycle.
The professor's analogy — a pod is like a Docker stack. In Docker, a stack groups services that must run together; in Kubernetes, a pod encapsulates the containers that must be treated as one unit. The containers in a pod are tightly coupled — they share the same environment, the same volumes, even the same IP address — whereas the services in the previous section were loosely coupled. That contrast is the whole point: pods are for containers that depend on each other and must share a lifecycle, while the application's features stay independent at the service level.
Scope — when do you pod, when do you not? Pods exist for containers that must always be scheduled together on the same node and share their fate: a web container and its log-shipper sidecar, or a main container plus a helper that prepares files for it. If two containers do not need to share a lifecycle or live on the same node, they belong in separate pods — bundling independent containers into one pod couples their scaling and scheduling for no benefit, and a single pod is still a single failure domain.
20.2.5 Benefits and Docker Swarm Comparison
Kubernetes delivers great portability — you can shuffle the resources and port applications very easily. It is 100% open source: there are online labs for Kubernetes with very good user interfaces — search Google for free Kubernetes labs and you can start executing Kubernetes commands, creating pods, creating containers, orchestrating a containerized solution, all free of charge. Kubernetes allows easy container management (the primary goal when it was launched), workload scalability, and high availability. It is efficient: you are creating an orchestration of containerized solutions and using all your resources efficiently.
Compare this with Docker Swarm, the orchestration service that Docker provides with automated configurability for containerized solutions. Previously, Docker Swarm had no dashboards; they have since launched a small dashboard so teams can use a user interface, but it is still not mature. Kubernetes, by contrast, has a great, mature dashboard. Refer to the comparison deck for the remaining row-by-row points.
| Dimension | Kubernetes | Docker Swarm |
|---|---|---|
| Hosting / governance | Hosted by the Cloud Native Computing Foundation (CNCF) | Part of the Docker ecosystem |
| Dashboard / UI maturity | Mature, feature-rich dashboard | Dashboard launched later, still not mature |
| Scaling & scheduling | Scheduler tracks capacity across nodes; per-workload scaling | Automated configurability; simpler model |
| Ecosystem | Huge community, online labs, broad tooling | Tightly integrated with Docker tooling |
When to pick which: if you need the mature dashboard, the broad ecosystem, and fine-grained scheduling across many nodes, Kubernetes is the standard choice; Docker Swarm is the lighter alternative for teams already living inside Docker's tooling and wanting automated container orchestration without Kubernetes' operational weight.
Recap: Kubernetes is an open source container orchestrator — you declare the desired state (how many replicas, which images), and the control plane (etcd, API server, controller manager, scheduler) drives the worker nodes (runtime, kubelet, kubeproxy) to match it, restarting anything that dies and scaling on demand. Its unit of deployment is the pod — one or more tightly coupled containers sharing a lifecycle.
Exam note: the K8 abbreviation, the CNCF hosting, and the four master components versus the two node components (kubelet, kubeproxy) are standard short-answer material. Learn the four-versus-two split exactly, and be ready to say what each component does in one line.
20.3 Serverless Computing
20.3.1 What Is Serverless Computing?
Hook: Imagine paying for electricity only while your kettle is actually boiling — nothing for the wires, nothing for the power station, nothing for the meter. Serverless computing brings that same logic to code: you pay only while your function actually runs, and the provider owns everything underneath.
After IaaS, PaaS, and SaaS, the next cloud computing model is serverless computing. Serverless means you do not have to pay any computational cost upfront — you are just writing a standalone code and it gets executed. You are not bothered about where it is executed from or where the computational power is coming from; the provider handles that. More precisely: you pay only for the compute time you consume. You are charged only when your code is actually running — during the time your code is in process. If the code is not running, you do not pay a single rupee. That is the logic of serverless computing: no servers to provision, no servers to manage, just code that runs.
The payment model and the abstraction. In IaaS you rent machines (even idle ones), in PaaS you rent a platform, and in serverless you rent executions. The unit of billing is the compute time — measured in milliseconds of function execution — not the hour of a virtual machine. The function is standalone: it carries its own logic and dependencies, the provider finds a machine for it at the moment of invocation, runs it, and releases the machine when it finishes. "Serverless" does not mean there are no servers — it means the servers are invisible to you: no provisioning, no patching, no capacity planning, no idle-cost.
The professor's intuition: you are just writing a standalone code and it gets executed. Where it runs, on what machine, with how much memory — that is the provider's problem. The moment the code finishes, the bill stops.
Scope — what serverless assumes and where it breaks.
- Stateless functions: serverless functions are born for each invocation and disappear after it. Long-lived session state, in-memory caches, and open connections must live elsewhere (an external data store) or they will be lost between calls.
- Short execution windows: providers impose time and memory limits on a single function run. Heavy batch processing or multi-hour jobs do not fit the model.
- Cold starts: an idle function may take extra time to spin up on its next call; latency-sensitive interactive paths need the warm-up behaviour measured, not assumed.
- Cost visibility: the pay-per-execution model is cheap for spiky, occasional work but can become expensive for constant high-volume traffic, where an always-on reserved instance may cost less.
- Vendor fit: code, event triggers, and data stores are tied to the chosen provider; moving a serverless workload between clouds is not as simple as moving a virtual machine image.
20.3.2 AWS Lambda and Other Cloud Offerings
AWS Lambda is the service of AWS that provides function as a service (FaaS) — serverless computing. It is a compute service that lets you run your code without provisioning or managing servers: you are not provisioning anything, you are not managing any server, you are just running your code. You pay only for the compute time you consume.
Even serverless code works with data, so Lambda functions can write the state of your code — the output — to external data stores via web requests. If you talk about AWS, those data stores are solutions like S3 buckets, DynamoDB, and RDS. As spoken in the lecture these last two names sound like "Dynamite" and "Rateshift"; the standard AWS services are DynamoDB — Amazon's NoSQL key-value and document database, ideal for fast lookups of items like cart contents or user profiles — and RDS — Amazon's Relational Database Service, which hosts classic SQL databases (MySQL, PostgreSQL, Oracle, SQL Server) in the cloud. You can also connect with other solutions such as PostgreSQL, Cassandra, and Kafka. That flexibility to integrate with external data stores is a deliberate feature: because the function itself is stateless and short-lived, its state has to be written somewhere durable, and the store is chosen per use case — object storage for files, a key-value store for quick lookups, a relational database for structured business data.
Other clouds have the same offering, because serverless computing is common to all cloud vendors: Azure Functions is the Azure service providing serverless computing, and Google Cloud provides a serverless service as well — named in the source only as "cloud engine". The standard names on Google Cloud are Cloud Functions (the direct equivalent of Lambda and Azure Functions — small pieces of code triggered by events) and Cloud Run (a container-based serverless option for larger services). The shape is the same on every vendor: write the code, declare its trigger, and pay per execution.
| Vendor | Serverless offering | Typical trigger | Pay-per-... |
|---|---|---|---|
| AWS | AWS Lambda | S3 uploads, HTTP requests, events | Compute time (milliseconds) |
| Azure | Azure Functions | HTTP, queue messages, timers | Compute time / executions |
| Google Cloud | Cloud Functions, Cloud Run | Cloud Storage events, HTTP | Compute time |
Pitfalls:
- Confusing FaaS with the platform: serverless (FaaS) is not a fourth "as a service" replacement for IaaS/PaaS — it is a model where the unit you rent is the function execution, and it still needs data stores, identity, and networking around it.
- State in the wrong place: writing state into the function's local file system or memory is lost on the next invocation; state must go to an external store (S3, DynamoDB, RDS) — which is exactly why the lecture emphasizes the data-store connection.
- Idle-cost misconception: serverless saves money on idle compute, not on traffic. A function called a million times a day bills for a million executions, so the cheapest answer depends on the workload's shape.
- The names: "Dynamite" and "Rateshift" are not AWS services — in answers, write DynamoDB and RDS.
20.3.3 Case Study: Settle Times on AWS
Settle Times is a newspaper provider organization, and it is a real case study of how serverless computing and AWS services helped a company. Settle Times decided to migrate its website to a contemporary content management platform. Initially, to avoid the cost of configuring new hardware infrastructure, maintaining it, and hiring staff to maintain it, they chose a fully managed hosting vendor. But after several months, the software engineering team found they had sacrificed flexibility and agility in exchange for less maintenance responsibility. The hosted platform struggled with managing traffic: when there was great news and a great amount of traffic on the website, scaling their services was compromised.
They explored other solutions — self-hosted machines on premises, more flexible managed hosting options, and various cloud providers — and ultimately decided to go with Amazon Web Services (AWS) because of the auto-scaling capabilities built into AWS services. That was their first requirement.
Worked example 1 — the six-hour migration.
Step 1 — the requirement. Settle Times needs a platform that scales itself when breaking news drives traffic up, and shrinks again when the crowd leaves. Auto-scaling is the first requirement, so AWS wins the selection.
Step 2 — the move. The migration itself was fast: Settle Times deployed their system in just six hours. The website was moved from the previous platform to the AWS platform between 11 p.m. and 3 a.m. — a four-hour window chosen so readers are asleep and traffic is minimal.
Step 3 — the handover. Final testing was completed by 5 a.m., and the website was ready for the next news on the next day — the morning edition went out on the new platform without missing an issue.
Step 4 — life after the move. The end results: Settle Times can now automatically scale up very rapidly to accommodate spikes in website traffic. When a big story breaks and they know many hits are coming, they scale up the VMs and the capacity; when there is very low traffic and a story will not attract a crowd, they scale down the servers to reduce cost. For Settle Times, auto-scaling was the real clincher — with AWS they achieved it with speed and efficiency, and they could meet demand and deliver a better reading experience to their end customer.
Sense-check: every number in the timeline is consistent with the goal — a night-time move (11 p.m.–3 a.m.), a two-hour test window, and readiness by 5 a.m. for the day's news cycle, all while the auto-scaling rule replaces the manual capacity guessing the old hosted platform could not do.
Where does AWS Lambda come in? Lambda helped Settle Times achieve extremely fast image resizing.
Worked example 2 — one upload, ten images, zero servers.
Step 1 — the problem. Every news photo must be delivered in 10 different sizes to support different platforms and devices — a thumbnail for the mobile feed, a medium crop for tablets, a large image for the desktop site, and so on. Before Lambda, the team used to serially resize each news image into those 10 sizes: take the original, resize to size 1, wait, resize to size 2, wait — ten sequential jobs per photo, each waiting on the previous one.
Step 2 — the event trigger. The workflow: the news image content is uploaded to an Amazon S3 bucket. As soon as the bucket has a new input, it automatically triggers the Lambda function — the upload event is the function's start signal, with no polling and no cron job.
Step 3 — the function. All the logic of resizing the image into 10 different images is written inside that Lambda code. The function reads the uploaded original from S3, resizes it 10 ways, and writes the 10 outputs back to storage.
Step 4 — parallelism replaces serialism. Now, with AWS Lambda, all 10 images are created at the same time — Lambda achieves parallel operations, producing 10 different sizes of the same news image simultaneously — and this is faster, with no server maintenance involved. They did not maintain any server; they just wrote a code that resizes the image.
Step 5 — the output. As an output, the function produces the 10 different images that can support web, mobile, tablet, and other platforms and devices — all at the same time, without maintaining or managing any server.
Sense-check: the serial path needed up to 10 sequential resize jobs per photo, each a small latency step; the Lambda path runs the resizes in parallel and bills only for the milliseconds of compute. Same photo, same 10 sizes, far less wall-clock time and zero idle servers.
Real-world: this S3-bucket-triggers-Lambda pattern is a canonical serverless design — an event in object storage starts a function that does the compute, and you pay only for the milliseconds the function actually runs. It appears across industries: generating thumbnails and previews, processing uploads, transforming files, and fanning a single event out to several downstream integrations — always with the same shape: storage event in, function compute out, no server in between.
20.4 SRE and DevOps — Clearing a Misconception
20.4.1 Same Crown, Different Gems
Hook: People feel that "after DevOps, we need to do SRE." The professor's correction: there is no link between DevOps and SRE in that sense — one is not a step after the other. Think of Agile, SRE, and DevOps as the three gems of the same crown — and that crown is nothing but your customer. All three exist to serve the customer; they are different cuts of the same stone, not a sequence of upgrades.
SRE and DevOps have the same goal; the difference is that DevOps is more toward the human side — how teams think, collaborate, and share ownership — while SRE is more toward practices and process. They are the two sides of the same coin: SRE is more focused on a set of practices and metrics, DevOps more on the mindset and collaboration — but both ultimately want you to grab more business.
20.4.2 Goals, Focus, and Teams
When were they coined? SRE was coined in 2003 at Google; DevOps was coined in 2009 by Patrick Debois. The goal of SRE and DevOps is the same — bridge the gap between development and operation — but the focus differs. SRE focuses on availability and reliability; DevOps focuses on continuity, speed, early time to market, while also achieving stability.
| Dimension | DevOps | SRE |
|---|---|---|
| Coined | 2009, by Patrick Debois | 2003, at Google |
| Nature | Shared mindset and ways of working | Practices and process |
| Focus | Continuity, speed, early time to market, stability | Availability and reliability |
| Team shape | Wide range of roles — product owners, developers, QA, SREs — collaborating in one DevOps team | Engineers with development skill plus operations skill; the operations team is converted into an SRE team |
| Adoption | Needs buy-in and enablement from every department | A set of practices and metrics — implement and use them (process change) |
The team structures differ too. Site reliability engineers come with operations and development skills: you are hunting for engineers who have the operations skill set and, at the same time, the coding logic — development skill plus operations skill. In DevOps you have a wide range of roles — product owners, developers, QA, SREs, etc. DevOps teams include SRE engineers, but SRE is a practice and process while DevOps is a shared way of working.
Look at the big picture of both. In DevOps, you have a development team and an operation team, and you want to collaborate them into a single DevOps team working together with great collaboration. In SRE, you still have a development team and an operation team, but the development team works at its own pace using automation tools and technology, while the operation team has been converted into an SRE team that automates as much as possible of the operational tasks. Ultimately the SRE team understands the development pain points, because its members carry development skill alongside operations skill, while the development team works independently to develop the software. So SRE and DevOps are not the same — their goal is the same, but the shape is different.
Q: Is it correct to say SRE engineers use DevOps practices to achieve reliability, while developers focus more on business logic and use SRE recommendations to bring reliability to the application? A: No — they are not using DevOps practices. They are using the ITIL operational methodology we discussed earlier. SRE exists to automate operational tasks with tools and technology: writing the scripts, achieving great reliability — that all happens with SRE, and it requires operational skills. It is more about practices.
20.4.3 Adoption Effort and Organizational Choice
If an organization wants great collaboration between development and operations and faster time to market, some organizations opt for SRE — because implementing SRE is really easy. You have a set of practices and processes; you just use them, and within one or two years (at least, based on the maturity level of the organization and team) you are there. DevOps is a culture, so you have to have buy-in from all the departments of your organization and then enable them with new processes, new practices, new tools, and new technology. Implementing a culture takes more time than implementing processes and practices, because culture involves a great amount of enablement.
That is why some organizations opt for SRE rather than DevOps, and some opt for DevOps and do not look for SRE. And once an organization has DevOps in place to increase its operational capacity and keeps a separate team for operations and development, it can still hire SRE engineers — that is always possible. You can plug and play between the terminologies; it is an organizational decision.
Recap: SRE (2003, Google) and DevOps (2009, Debois) share one goal — bridging development and operations — but differ in kind: SRE is practices and process focused on availability and reliability, DevOps is a culture focused on continuity, speed, and early time to market. Choosing between them is an organizational decision about effort: SRE can be adopted in one to two years; a culture like DevOps needs whole-organization enablement.
Exam note: since this is explicitly outside the syllabus, treat it as background understanding — but the SRE-versus-DevOps contrast (culture vs practices, availability/reliability vs speed/continuity) is exactly the kind of confusion the question paper likes to probe.
20.5 Last Year Question Paper Walkthrough
The professor walked through last year's question paper to show the style and the expected answers. The questions below are organized by theme; each carries the professor's recommended answer and the justification that earns the marks.
20.5.1 Significance of DevOps and Its Functions
Q: What is the significance of DevOps? How may DevOps help a team with software delivery?
The significance is faster time to market. It also helps with great transparency: whenever anyone wants any service, they can easily use it — everybody knows from where and what to get. The fundamental functions of DevOps are: continuous integration, continuous code inspection, continuous build, continuous testing, continuous delivery, continuous deployment, and continuous monitoring. Note the pattern: every step of getting code from the developer's desk into production is made continuous and automated — integrate, inspect, build, test, deliver, deploy, and monitor.
Q: What is the relation between DevOps and the Agile process?
Agile is there to bring agility into the team and the business; DevOps is there to achieve greater — faster — time to market. DevOps uses the agile process with some amendments, to increase collaboration with the operation team. One amendment: involve the operation team as a first-class stakeholder during your requirement gathering. So the relationship is not "DevOps replaces Agile" — Agile supplies the working style, DevOps extends it by pulling operations into the same loop.
Q: Do we need automated testing in CI/CD?
Yes. The justification: since you have automated testing, next time you make small changes, the same scripts are reused for testing — that brings more confidence, reduces the manual testing effort, and fastens the overall process. The key exam point is the reuse argument: automated tests are written once and replayed on every change, so the cost is paid once and the confidence is gained every time.
20.5.2 Agile Practices, Value Stream Mapping, and Adoption Challenges
Q: Which agile development practice should one use to concentrate on communication, visibility, and end-user satisfaction?
The best answer is BDD — behavior driven development: when it comes to visibility and user satisfaction, you are working with scenarios. FDD is also acceptable — you can give FDD or BDD — but give a proper justification, because marks follow the mindset shown in the justification. Nobody should answer TDD. The reasoning: BDD is built around describing behavior in user-understandable scenarios, which is exactly where communication, visibility, and end-user satisfaction live; TDD is a developer-internal testing discipline and does not target those outcomes.
Q: Value stream mapping scenario. During a value stream mapping exercise, a team identified that a change process using multiple change advisory boards was slowing down their workflow. The hint in the question is "traditional SDLC." Traditional SDLC methodologies do not have standard practices for operational methodology, so the answer is to suggest agile and ITIL — the operational methodology. Those are the two pinpoint answers: agile for the delivery workflow, ITIL for the operational methodology the traditional SDLC lacks.
Worked example — DevOps adoption: where do I start, and what challenges will I face?
The scenario asks you to suggest solutions to each challenge. The professor's complete mapping:
| Challenge | Suggested solution |
|---|---|
| Inconsistent environment | Configuration as code — automated configuration management — gives a consistent environment |
| Manual testing | Automated testing |
| Collaboration between development and operations | Adopt DevOps practices; give operations a room during requirement analysis; allow access to the code from the version control system |
| Manual deployments | Human-free deployments |
| No integrated tool architecture | Integrated tools like Jenkins, TeamCity, CircleCI, or Hudson |
| No DevOps metrics | Whatever practices and tools you use to automate must support measurements |
| Limited transparency | Effective people management to increase transparency in the team |
| Waste in existing process | Value stream mapping |
| No standard SCM repository | Source code management like Git or Bitbucket |
| Agile confined to developers | Let the whole team use Scrum boards or Kanban boards to be more effective and agile |
How to use the table in an exam: read the challenge, then give the one-line solution and one sentence of why it fixes that specific challenge. For example: "Manual testing → automated testing, because the same scripts are then reused on every change, which removes the repeated manual effort and speeds up delivery." The justification is what carries the marks.
Q: In a DevOps adoption scenario, how do we remove waste from an existing process? A: Use value stream mapping. It identifies and removes the waste in your workflow — the recommended practice when a team's change process is slowing down delivery. Recall the question-paper scenario above: multiple change advisory boards were throttling changes; value stream mapping surfaces exactly that kind of wait state so it can be eliminated.
Q: Which transformation delivers software into the hands of customers faster? A: DevOps transformation. Discuss its phases — starting with the create phase, where workshops enable people to understand the new DevOps terminology — and then the remaining stages of the transformation. The phrase "create phase" is the anchor point examiners expect: transformation begins by creating shared understanding before changing processes and tools.
20.5.3 Deployment Strategies and Cloud Service Selection
Worked example — choosing a deployment strategy under three different constraints.
Scenario 1 — limited availability, rollback needed. An organization is planning to re-ramp its infrastructure and host its application on cloud platforms, but has a production limitation on availability — if something goes wrong you need rollback, and you have limited availability. That means you cannot use a deployment strategy that consumes capacity for upgrades. The proposal here is rolling upgrades: they upgrade one instance at a time. Because only one instance is out of service at any moment, the strategy needs almost no spare capacity, and if something goes wrong you roll back instance by instance.
Scenario 2 — no budget constraint. Then: no budget constraint for the transition. No budget constraint means you have full cost available, so suggest blue-green: the strategy is maintained with two infrastructures, two identical production environments, and switching between them is really easy — since no cost is involved, it is great to go ahead. You deploy the new version into the idle environment, run smoke tests, and flip the router; rollback is one more router flip back to the old environment.
Scenario 3 — strict budget constraint. With a constraint on budget, you can go for canary or rolling upgrades. Give the inline justification: with limited availability, rolling upgrades avoid using capacity for upgrades, and blue-green's two identical environments make switching easy when cost is not an issue — so when cost is the constraint, the two-environment blueprint is off the table.
Final answer summary: limited availability → rolling upgrades; no budget constraint → blue-green; strict budget → canary or rolling upgrades, each justified inline.
Q: Identify the business-to-cloud offering (IaaS/PaaS/SaaS). Three mini-cases, each needing a justification:
- A solution company expanding its growth in India after COVID-19, primarily targeting R&D solutions for next-gen technology — they should go for platform as a service (PaaS), because they are only bothered about developing R&D solutions, not about the infrastructure. The platform gives them runtimes, services, and a deployment target so their engineers stay focused on the R&D product.
- NCache, an organization targeting to set up operational and support operations in India, with major concerns of compliance and security — they should go for infrastructure as a service (IaaS), because they need security and control: they cannot afford the strict nature of a cloud service where they cannot change the network topology or the firewall. IaaS hands over the machines, networks, and firewalls so the compliance team keeps control.
- An e-commerce organization like NIC Mart, expecting to acquire market share for daily needs — that is software as a service (SaaS), enabling the end customer to use their application via web or other platforms. The customers consume the finished application directly; no infrastructure or platform concerns reach them at all.
In all three, you have to give the justifications — the selection without the reason earns little.
Q: Comment on private cloud vs public cloud. A private cloud means you implement your own cloud environment in-house — grabbing machines, creating a cloud infrastructure in-house. Organizations in the banking domain do not opt for public cloud; they go for their own private cloud. A public cloud means you opt for cloud services from a vendor like Amazon, Google, or Azure. The decision is a control-versus-cost trade-off: private cloud keeps data and infrastructure in-house (the reason banks choose it), public cloud rents the vendor's economies of scale.
20.5.4 Short Questions and Their Expected Answers
Q: Two scenarios where infrastructure as a code reduces OPEX. Infrastructure as a code provisions environments — you can provision 10 or 100 environments with the same team size; you never scale up the team. With configuration as a code, you have written one script, so the same person can maintain and manage 10 or 100 servers at a time — when your application grows and you increase the infrastructure, you would otherwise have to hire more operations staff. Both scenarios cut operational expense by turning environment and server work into reusable scripts that one team runs at scale.
Q: Feature teams over component teams — when do you opt for feature teams, and what are their benefits? One scenario: if you are working with microservice architecture, definitely suggest feature teams — you have a team of full-stack developers who are good at delivering, deploying, and testing their solutions; they know the interface, the business logic, and the DB logic. A versatile team, in other words. The benefit is end-to-end ownership: the same people who build the feature can deploy and test it, which connects directly back to the microservice/DevOps pairing from 20.1.5.
Q: Failure detection monitoring — what is the source of data? Audit logs — but from both layers: infrastructure as well as application, because failure can happen at the application level or at the infrastructure layer. A one-sided answer (only application logs) misses the point the question is probing.
Q: Compatibility considerations for application deployment. The two compatibility constraints — an application should be forward-compatible and backward-compatible; explain with a scenario of your own. Example scenario: an API that still serves the old request format (backward compatibility) while new clients already send the new format (forward compatibility) lets you upgrade clients and servers in any order without a coordinated break.
Q: When will you opt for top-down instead of bottom-up monitoring? One scenario: your application is on a cloud platform and you do not have good access to the infrastructure — you are not bothered about infrastructure — so you go top-down and monitor your application-level logs closely rather than infrastructure-level logs. Bottom-up is for when you own and can instrument the infrastructure below.
Q: Flow-based over non-flow-based agile methodology. If the project is in a manufacturing department and runs on multiple sites with a large project size, use flow-based agile like Kanban — you cannot work with non-flow-based there. Non-flow-based is for co-located teams. The deciding dimension is whether work flows continuously across distributed sites (flow-based, Kanban) or fits iteration boxes in one location (non-flow-based).
Q: User interface monitoring. If the goal of monitoring is the user interface, the source of data to monitor is the application data.
Q: Rollback in application deployment — when and why? If the error is not easy to debug and provide the solution, instead of getting a penalty the best option is to revert to the previous version and keep the application available; then, in normal working hours, trace down what the problem is and fix it. The reasoning: production availability comes first; debugging happens later at leisure, not during an incident at 2 a.m.
Q: Benefits of containers over virtualization. Easy, portable, light-weighted — this is a direct question with no logic or trick behind it. Containers start faster than virtual machines, ship the whole runtime with the app, and consume far fewer resources because they share the host operating system.
20.5.5 Exam Conduct and Anti-Copying Advice
A strong word on copying: all our five fingers are different — two people will never write the same English the same way. If two papers contain an exact line with the same words, the same full stop, the same comma, the same English write-up, that is copy-paste, and it is easy to identify who copied what. So do not copy directly from internet sources — the answer is graded on your understanding, so write in your own words. Even when two answers and justifications are conceptually the same, the wording will differ, and marks follow the justification.
Q: What is the Safe Exam Browser, and is it needed for this course? A: It is a web browser that will not allow you to open any other site while the exam runs — the same kind used for competitive exams taken on a laptop or desktop. For this course you do not need to draw anything and upload images, so you do not even need to access the web camera; answers are typed in a text box.
A few other expectations shared: there will be no questions on dependency graphs, and no scenario where you must scan and upload an image — the paper is designed so text-box answers suffice. Practical lab sessions: expect questions about which practices and processes to automate and what kinds of tools will help — not "write a script" or "give the Jenkins settings to integrate with GitHub" — you do not have to mug up that kind of thing.
Q: If someone scores around 12–15 out of 40 in the comprehensive exam, will they still pass? A: Yes. With 22 in the mid-semester, having attended the quizzes and submitted the assignment on time, the total comfortably stays above the passing requirement — above 5.5 CGPA.
Exam Guidance Summary
- Mark distribution: mid-semester exam 30 marks, quizzes 5 + 5 = 10 marks, assignment 20 marks — that is 60 marks done — and the remaining 40 marks are the comprehensive exam. Assignment grades will be updated by the 23rd.
- Paper style: answers are typed into a text box; there is no scanning or image upload, no web camera needed, no dependency graph questions. The Safe Exam Browser blocks other sites during the exam.
- Question types: expect conceptual and justification-based questions. Practical lab sessions contribute questions on practices, processes, and tool selection for automation — not script writing and not tool configuration details (no "integrate Jenkins with GitHub" style questions). No cron-job expression questions in the regular exam.
- Answering style: write in your own words and justify every choice — marks follow the justification. Identical wording across two papers is detected as copy-paste.
- Study priorities: microservices (Netflix example, monolithic vs microservice comparison, e-grocery decomposition, DevOps + microservices pipeline with feature branches and Jenkins file); Kubernetes (K8 abbreviation, CNCF, the four master components etcd/API server/controller manager/scheduler, node components kubelet/kubeproxy, pods, Docker Swarm comparison); serverless computing (AWS Lambda pay-per-execution model, S3-triggered image resizing, the Settle Times case study).
- Reference resources: a book on microservice architecture was shared as a reference document; the Kubernetes official website, a VMware Kubernetes article on YouTube, and an AWS Lambda YouTube video are the suggested external materials.
Key Industry Applications
- Microservices in production: Uber, Netflix, Amazon, eBay, Gilt, Tesla. The Netflix recommendation-service failure story shows how loosely coupled services keep the whole app available; the e-grocery example shows the REST-API decomposition pattern used by real teams.
- Kubernetes everywhere: hosted by the Cloud Native Computing Foundation (CNCF); free online Kubernetes labs let anyone create pods and containers without paying; Docker Swarm is the alternative orchestrator with a younger dashboard.
- Serverless at scale: AWS Lambda (function as a service), Azure Functions, and Google Cloud's serverless offering (Cloud Functions, Cloud Run); the pay-only-for-compute-time model; the Settle Times case study — a newspaper migrating to AWS for built-in auto-scaling, deployed in six hours, and using S3-triggered Lambda functions to resize images into 10 sizes in parallel.
- CI/CD tooling: Jenkins, TeamCity, CircleCI, Hudson for integrated tool architecture; Git and Bitbucket for source code management; Scrum and Kanban boards to extend agility beyond developers; ITIL as the operational methodology behind SRE-style automation.
ITD Lecture 20 notes · Microservices, Kubernetes, and Serverless Computing
Sections Breakdown
Microservices divide an application into small, loosely coupled services, each with its own database and small autonomous team; the Netflix example and the e-grocery decomposition show how availability, scalability, and modifiability follow.
Kubernetes (K8, hosted by CNCF) manages containerized applications across a cluster: the control plane components — etcd, kube API server, kube controller manager, kube scheduler — enforce the desired state on worker nodes, and the pod is its core object.
Serverless computing (FaaS) bills only the compute time your code runs; AWS Lambda, Azure Functions, and Google Cloud offer it, and the Settle Times case study shows auto-scaling and S3-triggered parallel image resizing.
SRE (2003, Google) and DevOps (2009, Debois) share the goal of bridging development and operations but differ in kind: SRE is practices and process, DevOps is a culture.
The professor's walkthrough of last year's paper: the significance of DevOps, BDD over TDD, value stream mapping and adoption challenges, deployment strategy selection, and cloud service choice with justification.
Mark distribution, paper style, question types, answering style, and the study priorities for microservices, Kubernetes, and serverless computing.
Real-world usage: microservices at Uber, Netflix, Amazon, eBay, Gilt, and Tesla; Kubernetes under the CNCF; serverless at scale with AWS Lambda and the Settle Times case study.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
Microservices
Must-know: Microservices are loosely coupled services, each with its own database and small autonomous team, giving availability (one failed service does not bring down the app, e.g., Netflix recommendations), scalability, and modifiability. DevOps and microservices are inseparable.
⚠️ Top pitfall: A distributed monolith: splitting deployment while sharing one database or a fixed service chain gives microservice complexity without microservice independence.
Self-check: In the e-grocery example, what does the payment service access after decomposition, and why does the rest of the app keep working when it is down?
Connects to: Section 20.2, Section 20.3
Kubernetes
Must-know: Kubernetes (K8, hosted by CNCF) is an open source system managing containerized applications: the master/control plane has four components (etcd, kube API server, kube controller manager with the replication controller, kube scheduler) and worker nodes have a container runtime plus kubelet and kubeproxy.
⚠️ Top pitfall: Worker nodes do not read etcd directly — they access configuration through the master components; the API server is the single door into the etcd store.
Self-check: If you change replicas from 2 to 4 in etcd, what does the replication controller do, and why does the app stay highly available when a container crashes?
Connects to: Section 20.1, Section 20.3
Serverless Computing
Must-know: Serverless (FaaS) charges only for compute time while your code runs; AWS Lambda is the canonical example, triggered by events such as S3 uploads and writing state to external stores (DynamoDB, RDS); Settle Times used AWS auto-scaling (six-hour migration) and Lambda to resize each news image into 10 sizes in parallel.
⚠️ Top pitfall: Serverless functions are stateless and short-lived: state must live in an external data store, and idle-cost savings do not mean high-volume traffic is cheap.
Self-check: What event triggers Settle Times' Lambda image-resizing function, and why are 10 images produced at the same time instead of serially?
Connects to: Section 20.1, Section 20.2
SRE and DevOps — Clearing a Misconception
Must-know: There is no 'after DevOps comes SRE' link: SRE (coined 2003 at Google) is practices and process focused on availability and reliability; DevOps (coined 2009 by Patrick Debois) is a culture focused on continuity, speed, and early time to market. SRE automation follows ITIL operational methodology, not DevOps practices.
⚠️ Top pitfall: Claiming SRE engineers use DevOps practices — they use the ITIL operational methodology and automate operational tasks with tools and technology.
Self-check: Why can an organization adopt SRE in one to two years but needs more time for DevOps, and which team does an SRE engineer combine skills from?
Connects to: Section 20.1
Last Year Question Paper Walkthrough
Must-know: DevOps gives faster time to market and transparency through continuous functions (integration, code inspection, build, testing, delivery, deployment, monitoring). Deployment strategy: limited availability → rolling upgrades; no budget constraint → blue-green; strict budget → canary or rolling. Cloud choice: PaaS for R&D focus, IaaS for compliance/security control, SaaS for end-customer consumption — always with justification.
⚠️ Top pitfall: Answering TDD for the communication/visibility/end-user-satisfaction question — BDD (or FDD) is the accepted answer, and marks follow the justification, not the acronym alone.
Self-check: Why do the change advisory boards matter in the value stream mapping scenario, and which two answers does that question expect?
Connects to: Section 20.1, Section 20.2, Section 20.3, Section 20.4
Exam Guidance Summary
Must-know: The comprehensive exam is 40 marks (total: mid-semester 30 + quizzes 10 + assignment 20 + comprehensive 40). Answers are typed in a text box; questions are conceptual with justification; no dependency graphs, no image uploads, no camera.
⚠️ Top pitfall: Copy-pasting exact wording — identical English across two papers is detected as copy-paste; answers are graded on understanding and justification.
Self-check: What are the four mark components of the course total, and which three topic areas should you prioritize for study?
Connects to: Section 20.1, Section 20.2, Section 20.3, Section 20.5
Key Industry Applications
Must-know: Microservices: Uber, Netflix, Amazon, eBay, Gilt, Tesla. Kubernetes: hosted by CNCF, free online labs, Docker Swarm alternative. Serverless: AWS Lambda, Azure Functions, Google Cloud; Settle Times migrated in six hours and resizes images into 10 sizes via S3-triggered Lambda.
⚠️ Top pitfall: Assuming one vendor owns serverless — Azure Functions and Google Cloud (Cloud Functions/Cloud Run) offer the same model as AWS Lambda.
Self-check: Which companies routinely cite microservice architecture, and which orchestrator is Kubernetes' main alternative?
Connects to: Section 20.1, Section 20.2, Section 20.3
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.