Course map and syllabus

Start from the question this lecture ends on. A client sends images to a pipeline that resizes each image, detects objects and draws bounding boxes. Where should each step run: on the client device, on a nearby edge box, on a fog node or in a distant cloud data center? And which latency number backs that choice? The last part of this lecture builds exactly that answer, and every idea before it supplies one piece.

The outline looks like a list, but read it as a chain in which each item answers a question the previous one raises. Take the running example of the lecture, a lamp you switch on from a web browser. To build it you first need a model of the system: which parts exist and who talks to whom. That model immediately asks how bytes move between machines, which is the job of the TCP/IP stack. Moving bytes is not enough; the browser and the lamp need a shared language for asking something to happen, and that language is HTTP. Your code then needs a programming interface for sending and receiving over the network, the socket. With those in place you can write an actual application, with a frontend in the browser and a backend on a server.

Only now can you ask the question the course is named after: where should that server run? The range of places between a device and the cloud where computation can live is the edge-to-cloud (E2C) continuum. The tool for choosing a place on it is the latency budget, the ceiling τ that a request's end-to-end response time must stay under. Placement is a latency decision, and latency comes from the network, which is why the lecture cannot skip the networking material to get to the interesting part faster.

A syllabus is a contract about scope: it tells you what can appear in exams and what counts as fair ground for your research project. COE 558 has two versions of that contract, and knowing both saves you from picking a project topic that is too narrow.

The slides describe what is taught this term. The official KFUPM catalog entry is the formal scope: it lists COE 558 as 3-0-3 (three lecture hours, no lab, three credits) with Graduate Standing as the prerequisite, and its description is broader than the nine topics taught in class.

The practical rule: study the taught topics for exams, but when you pick a research topic, anything in either list is in scope. Storage models and big-data frameworks get only one short line in class, yet they are rich research areas.

The foundations: three questions about the same application

The nine topics split into two blocks. The first three are the foundations, and they read as three questions about the lamp application from the lecture arc.

1. How do things communicate? Topic 1, this lecture: the TCP/IP stack, client and server roles, sockets, frontend and backend, and how latency shapes a web service on the edge-to-cloud continuum.
2. Where can it run, and how is it packaged? Topic 2: system thinking applied to the edge, fog and cloud layers, then virtualization: virtual machines, hypervisors and Docker containers.
3. Where should it run? Topic 3: what makes something a cloud, what edge computing adds, and when to combine both.

Packaging is the first place the course gets concrete. Docker's own documentation gives three short definitions worth memorizing now. An image is a read-only template with instructions for creating a container. A container is a runnable instance of an image. A registry stores images, and Docker Hub is a public registry. A virtual machine, by contrast, runs a whole guest operating system on virtualized hardware managed by a hypervisor, which is why containers are said to deploy faster. Treat that claim as a simplification. Docker says a container is relatively well isolated by default, but containers share the host kernel while each VM runs its own, so faster startup comes with weaker isolation than a VM, a trade-off you will study in topic 2.

Once something is packaged, the next question is what it means to run it in a cloud. The standard definition comes from NIST Special Publication 800-145. It names five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. The course emphasizes self-service, scalability and elasticity. NIST describes rapid elasticity as capabilities that can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.

Build and operate: the remaining six topics

With the foundations in place, the other six topics move from understanding to building and operating real services. In order: what you rent from a provider (service and deployment models), a real open-source cloud you can run yourself (OpenStack), how services talk to each other (HTTP, REST and JSON through a Web API), how to run them at scale (containers, orchestration, monitoring), how to handle data at Internet scale, and how to keep all of it secure.

The thread running through them is the service. Service-oriented architecture builds an application from separate services that talk over the network. Microservices push that idea further: many small services, each deployed on its own. REST (REpresentational State Transfer, capitalized to spell out the acronym) is the usual way those services expose a web API: each thing is a resource with a URL, and clients act on it with standard HTTP methods such as GET and POST.

What you rent determines how much of that service stack is yours to manage. NIST defines three service models. With Infrastructure as a Service you rent virtual machines, storage and networks and manage everything above them. With Platform as a Service you deploy your code onto a managed runtime. With Software as a Service you simply use a finished application. NIST also defines four deployment models, which describe who the cloud is for: private, community, public and hybrid.

OpenStack makes those models tangible: it is an open-source platform for building your own cloud, assembled from separate services that talk to each other through APIs. In other words, it is itself a service-oriented system. The course names four of its services, and the official documentation describes each in one line.

Where the scope meets your project

Two of the build-and-operate items connect straight back to the placement problem at the end of this lecture. Client-service interaction for cloud and edge deployments is about requests crossing the continuum, and end-to-end processing pipelines are chains of steps that can each run in a different place (a service pipeline). Deciding which step runs on the edge and which in the cloud, under a latency limit, is a natural research direction, for example latency-aware task placement. Start a list of candidate topics now; the next concept explains why that list needs to exist in week one.

Start with the numbers, because they decide how you should spend your semester. The course has five assessments, and the research project inside them is split into three components.

Read the rubric as a pipeline

The three project components are graded separately, but they work best as stages of one pipeline, much like the image pipeline this lecture ends on: each stage consumes the output of the one before it.

• Reviews and critiques (8%). Critical reading, identifying a research gap (a question or setting existing papers leave open), analysing the methodology, weighing strengths and weaknesses, and finally proposing an initial research question. The question is the output of this stage.
• Seminar (7%). Technical understanding, presentation quality, critical discussion and Q&A. You are graded on whether you can defend a paper under questions, not only summarize it, so present a paper close to your research question.
• Final research study (20%). Problem formulation, literature review, proposed methodology, implementation or simulation, results and the final report. That is months of work, not the last two weeks.

Feeding the pipeline: reading papers in three passes

The first stage only works if you can read many papers without drowning in them. S. Keshav's widely used method reads a paper in up to three passes, each deeper than the last, so you spend real time only on the papers that earn it. The first pass takes about 5 to 10 minutes: title, abstract, introduction, section headings and conclusions. It should let you answer the five Cs: category, context, correctness, contributions and clarity. The second pass takes up to an hour: read carefully, skip proofs, study the figures and mark references you have not read.

The third pass means virtually re-implementing the paper, making the same assumptions and recreating the work in your head. Keshav estimates about four or five hours for beginners and about an hour for an experienced reader. By the end you can name implicit assumptions and weak points, which is exactly what the critique rubric asks for. For a literature survey he suggests finding three to five recent papers, reading their related-work sections, then following the citations and venues they share.

Protecting the pipeline: office hours

A pipeline is only as good as its earliest decisions, and in a research project the expensive ones are scope and method. A concept you did not follow can be re-read here. A research question that is too broad, or a methodology the instructor considers infeasible, costs weeks if you discover it at the seminar. That is what office hours are for.

The venue is written as Building #24 244, which reads as Building 24, Room 244. If you are unsure on the first day, check the room number on the registrar schedule.