Teaching
ECE1779
Introduction to Cloud Computing
Fall 2025 · Winter 2026 · Fall 2026
ECE1779 is a graduate-level introduction to modern cloud and edge computing for students with programming and basic systems experience but not necessarily prior experience with cloud platforms, containers, or orchestration.
The course progresses from cloud service models and infrastructure to containerization, orchestration, serverless computing, edge deployment, and observability. Hands-on assignments allow students to work with these ideas in running systems, while an open-ended team project requires them to integrate multiple technologies and make their own architectural and operational decisions.
My first priority is to give students a practical foundation in cloud technologies and the abstractions they provide. Alongside that foundation, lectures, hands-on work, and the project create opportunities to begin reasoning about system behavior, design trade-offs, responsibilities, and evidence.
Course Design Principles
These principles shape how I connect cloud concepts to hands-on work and how I design assignments, projects, and assessment.
Connect Abstractions to Real Systems
Cloud technologies are introduced in terms of the problems they solve, the responsibilities they abstract away, and the system behavior that remains visible to developers and operators.
Learn Through Deployment and Observation
Students work with running systems rather than studying cloud concepts only in the abstract. Assignments require them to deploy, configure, observe, and diagnose applications so that cloud concepts remain connected to concrete system behavior.
Look for Evidence Beyond Successful Execution
A deployment that appears to work is only a starting point. Assignments and project work ask students to examine system behavior, verify important properties, interpret evidence, and explain why they believe their system is behaving as intended.
Create Opportunities for Engineering Judgment
Open-ended project work gives students opportunities to make decisions about architecture, services, scalability, persistence, and evaluation rather than treating cloud development as a sequence of prescribed configuration steps.
How the Course Has Evolved
I revise the course after each offering based on student work, student feedback, patterns I observe during the term, and my own reflection on what the assessments actually reveal about student understanding.
Fall 2025
Building a Path from Abstraction to Operation
When I first took responsibility for ECE1779, the central challenge was designing an introduction that could support students with programming and systems experience but little or no prior exposure to cloud computing. I wanted students to understand the abstractions that make cloud systems useful while also experiencing the operational realities that those abstractions do not make disappear.
What I was trying to address
Students could encounter cloud platforms as collections of services and commands without developing a clear mental model of how the pieces fit together.
How I designed for it
I organized the curriculum progressively, beginning with cloud service models and responsibility boundaries before moving through infrastructure, containers, orchestration, serverless computing, edge deployment, and observability.
What I was trying to address
Conceptual knowledge alone does not prepare students for the uncertainty of configuring and operating distributed systems.
How I designed for it
I designed four hands-on assignments in which students provisioned infrastructure, deployed applications, worked with managed services and containers, and diagnosed failures using configuration, logs, and observed system behavior.
What I was trying to address
A large graduate class required consistent expectations while still leaving room for students to troubleshoot rather than simply reproduce instructor demonstrations.
How I designed for it
Detailed specifications and automated grading established a common technical baseline, while students remained responsible for diagnosing deployment problems, interpreting errors, and determining how to satisfy the required system behavior.
What I was trying to address
Individual assignments could teach specific technologies, but they did not require students to decide how multiple cloud mechanisms should fit together in a larger system or explain those decisions to others.
How I designed for it
I used an open-ended team project in which students designed and deployed their own cloud applications, made decisions about architecture, services, deployment strategy, scalability, and system integration, and presented their systems and major technical choices to the class.
The first offering established the course around a progression from understanding cloud abstractions to operating real systems. The goal was not simply to expose students to more cloud technologies, but to help them understand what each technology changes, what complexity it removes, and what responsibilities remain.
Winter 2026
Closing the Gap Between Examples and Real Deployments
The first offering showed me where introductory explanations were not yet sufficient for the systems students eventually wanted to build. For the second offering, I focused on areas where students needed a stronger bridge between classroom examples and more complete project-scale deployments, while also beginning to treat communication and AI-assisted development more explicitly as part of engineering practice.
What I learned
The initial Kubernetes material was sufficient for understanding stateless deployments, but students building realistic applications frequently needed persistent state and had to learn those mechanisms independently.
How I responded
I expanded the taught Kubernetes material to include persistent volumes, persistent volume claims, and the deployment of stateful components, giving students a more complete foundation before they encountered these requirements in their projects.
What I learned
Project presentations in the first offering highlighted an opportunity to provide students with more structured support for technical communication, particularly around prioritizing content, explaining technical decisions and their rationale, and making effective use of limited presentation time.
How I responded
I strengthened presentation support for the second offering and collaborated with Prof. Fiona Coll, lead of ISTEP's Graduate Communication Initiative, to provide targeted guidance on technical presentation and communication.
What I learned
Generative AI was increasingly becoming part of the workflows students used for code, configuration, debugging, and technical explanation, while cloud-generated output could look plausible despite containing subtle operational problems.
How I responded
I introduced the course's first explicit generative AI policy, clarifying acceptable use, attribution, individual understanding, and students' responsibility for validating and defending AI-assisted work.
The second offering broadened my attention beyond what technical material the course should cover to how students use that material in more complete engineering work. The changes addressed different parts of that transition: moving from simplified examples to more realistic deployments, communicating technical work clearly, and taking responsibility for work developed with the assistance of AI.
Fall 2026
Strengthening Opportunities for Judgment and Evidence
For the third offering, I focused less on expanding the technology list and more on what students could be asked to demonstrate after working with those technologies. The project and AI policy were redesigned to create more opportunities for students to reason about system design, evaluate behavior, justify important decisions, and show evidence that they understand and have verified their work rather than simply producing a functioning cloud system.
What I learned
The earlier AI policy explained what students were allowed to do and how AI use should be disclosed, but it gave less guidance on when students should think independently, how they should evaluate AI suggestions, and how they should verify AI-assisted work.
How I responded
I redesigned the AI guidance around explicit learning workflows. For assignments, students are expected to understand and attempt the work before using AI selectively and verifying the result. For the project, the process emphasizes thinking independently, consulting AI where useful, evaluating its suggestions, making a decision, implementing it, and verifying the outcome.
What I learned
Highly structured assignments are effective for assessing specific technical skills, but reveal less about how students navigate a larger, open-ended engineering problem with greater technical uncertainty.
How I responded
I increased the weight of the course project and revised its proposal, presentation, and final deliverable requirements and rubrics to place greater emphasis on planning, technical decision-making, evaluation, evidence, and communication alongside implementation.
What I learned
Successful execution captures only part of engineering quality. A strong project also depends on how well teams understand and explain their architecture, evaluate system behavior, and justify important technical decisions.
How I responded
I refined the project rubric to make these dimensions more explicit, distinguishing successful implementation from broader engineering quality through criteria covering system quality, engineering practices, evaluation and benchmarking, documentation and reproducibility, and reflection.
What I learned
A prepared project presentation can show what a team chose to present without revealing how well its members can reason about the system when the discussion moves beyond the script.
How I responded
I added a Q&A period to project presentations. This gives teams an additional incentive to understand their architecture and technical decisions while allowing the rest of the class to observe how others interpret questions, explain trade-offs, and reason about their systems in real time.
What I learned
Effective teamwork depends not only on everyone contributing, but also on ownership and technical decision-making being shared across the team rather than concentrated in a single person.
How I responded
I made expectations around shared ownership more explicit and introduced a confidential mid-project team health check. Git development history continues to provide additional context when individual contribution or understanding needs closer review.
What I learned
The effectiveness of optional support depends not only on its quality, but also on how easily it fits into students' existing course workflow, especially during demanding stages of a project.
How I responded
I embedded more presentation support directly into the course through detailed online guidance, concise discussion of communication principles during regular class time, and clearer expectations for presentation structure and Q&A.
What I learned
A course discussion platform is useful only if students are willing to use it regularly; familiarity and ease of access can matter as much as the platform's technical features.
How I responded
After students expressed a preference for Piazza over GitHub Discussions, I moved course discussion to Piazza within Quercus for Fall 2026. I am using the change to examine whether a more familiar, lower-friction platform encourages broader participation and more peer-to-peer help.
The redesign made several existing priorities more explicit and more consistent across the course. Rather than adding a new set of goals, I revised the project, assessment, and AI guidance so that technical understanding, evaluation, evidence, communication, and responsibility were reinforced more deliberately throughout students' work.