Serverless computing: Projects

CS 260r Spring 2019

Final project writeups


Your project is a system that measures, uses, or extends the serverless computing model.

The primary outcome of the course will be a project writeup of sufficient density and polish that you would feel comfortable submitting the writeup for peer review (6–12 pages). You will also submit:

All course material is due on our final deadline, Friday May 17 at 11:59pm. There is a coursewide extension until Monday May 20 at 7:00am. That extended deadline is a hard deadline: no further extensions will be granted.

Project writeup

The final project writeup should be a PDF no more than 14 pages long. Follow the format of a typical research paper: 11pt font, two-column, single-spaced. Do not double-space.

Writeups will be shared with the class and posted publicly unless you explicitly withhold permission to do so.

Research papers from the Spring 2017 Verified Systems class

Michael Ernst has some interesting advice on how to write a technical paper. (He has other advice too.) Some key points:

“The goal of writing a paper is to change people’s behavior: for instance, to change the way they think about a research problem or to convince them to use a new approach. … As a general rule, your paper needs to convince the audience of three key points: that the problem is interesting, that it is hard, and that you solved it.”

“A common mistake is to focus on what you spent the most time on. Do not write your paper as a chronological narrative of all the things that you tried, and do not devote space in the paper proportionately to the amount of time you spent on each task. Most work that you do will never show up in any paper; the purpose of infrastructure-building and exploration of blind alleys is to enable you to do the small amount of work that is worth writing about. Another way of stating this is that the purpose of the paper is not to describe what you have done, but to inform readers of the successful outcome or significant results, and to convince readers of the validity of those conclusions.”

“A related work section should not only explain what research others have done, but in each case should compare and contrast that to your work and also to other related work. After reading your related work section, a reader should understand the key idea and contribution of each significant piece of related work, how they fit together (what are the common themes or approaches in the research community?), and how your work differs.”

But do not get too hung up on these points, especially in the context of a class project. There are many ways to write a good research paper, and different communities have different standards. Regarding the quotes above:

Your contribution is a key aspect of the project writeup. What did you do that adds to, or slightly inflects, the sum of world knowledge?

A typical writeup will follow this format, which is not mandatory.

  1. Title. Something grabby that correctly describes a part of the contribution.

  2. Abstract. A paragraph or two that concisely describes the motivation for the work (the problem the work addresses), the contribution of the work, and a highlight of your results. The abstract tends to target an already-expert audience.

  3. Introduction. A page or so that expands on the abstract. The introduction is written for a broader audience than the abstract; its purpose is to situate the technically adept, but not necessarily expert, reader with the research problem as you define it. Your introduction, for example, might start out with a brief explanation of serverless computing, followed by a description of the issue with serverless computing that you address.

    Often an introduction will end with a list of contributions, and an “outline” paragraph that says “The rest of this paper is organized as follows. Section 2, etc.”

  4. Related work (this may also appear just before the conclusion). A description of related research, especially research closely related to your own work. The purposes of this section are citation and comparison. Foundational work requires citation only; “Amazon Web Services introduced modern serverless computing with AWS Lambda in 2014 [19].” More recent work requires comparison. Describe for each group of citations (1) the core idea, (2) what is complementary with your work, (3) what is more advanced than your work, and (4) what is advanced upon by your work. (2)–(4) are optional—some papers will be entirely complementary with or orthogonal to your work. (Hopefully no work will be entirely more advanced than yours!)

  5. Architecture. A half-page defining the context in which your work runs.

  6. Design. The system you built, or the experiments you designed, described in enough relevant detail that a skilled system builder could replicate your work. Design is not about the names of your classes or your software engineering prowess, though you should include these details when they are relevant. Multiple pages.

  7. Implementation. Aspects of your system that are not relevant to the design, but might be relevant to understanding your evaluation. Typically a page or less.

  8. Evaluation. For systems work, this will often include the following subsections:

    • Experimental setup. Describe how you ran your experiments. What kinds of machine? How much memory? How many trials? How did you prepare the machine before each trial?

      Systems Benchmarking Crimes, by Gernot Heiser

    • The experiments themselves, grouped by purpose. Include figures.

    • A summary of the experimental results.

    Some good evaluations are organized around performance hypotheses: statements that the experiments aim to support or disprove.

    Not all projects will have systems evaluations, but every project should be evaluated. If you are introducing a new computing model, for example, you could evaluate whether existing systems would fit the model.

  9. Discussion. This optional section can speculate about your work. Feel free to put stuff here that is based on intuition and that you haven’t backed up with experiment. Do you think, in the end, that the project was a good idea? What would you do next? What should readers learn?

  10. Conclusion. A paragraph or so.

Do not punt the writeup. In previous years, I have seen writeups with “lorem ipsum dolor” text in the abstract, and an introduction that said “Our verification VERIFIES SOMETHING HERE”. Bs were assigned.





Serverless Relational Database Migration