Skip to content

Checkpoint 4

Checkpoint 4 happens during the 16th week of the course, during phase 4, where the main topics were production readiness: automatic scaling, failure tolerance, observability, and templated deployments.

Introduction

During the checkpoint, you are asked to demonstrate the development, operations, and documentation requirements of phase 4. All the tasks given in the phase are mandatory, but we will check a random subset of them.

The process is rather straightforward:

  1. Prepare your project, systems, and team for the checkpoint.
  2. During your allocated time slot, come to the session. In the case of an in-person class, please wait until you're invited to the class.
  3. Connect your devices, and prepare to present.
  4. During the presentation, TAs ask you to show specific functionalities of your application or demonstrate how you've done something.
    • Try to keep it short and concise, as it helps you have time for the rest of the session.
    • This is to earn the 15 team-wide points which everyone shares.
  5. During the presentation, we will also direct specific questions to random members of the team.
    • This is to earn the 5 individual points.
  6. After you're done with the presentation, we'll give you an overview of how you did, and you can leave the session.
    • We might not give you the score right then - sometimes we'll go to check the work done in GitLab afterward, if there's anything ambiguous.
  7. At the end of the week, we'll add the points to the SIS.

Here is a quick overview of development, operations, and documentation tasks required for checkpoints. For detailed descriptions see the lab guides mentioned previously.

Info

During the checkpoint, we will be asking you to demonstrate a subset of the tasks below.

Attention

When you are coming to present.

  • All team members should have their application ready and opened on their laptops .
  • All team members should have their code editors open with the project loaded and ready to go.
  • All team members should have their project repo open in Gitlab.
  • All team members should have access to the Kubernetes cluster.
  • All team members need to be familar with their project.

Development requirements

Attention

All the previous development requirements are still mandatory if they have not been 'overwritten' by other requirements. Making changes should not break other parts of your application.

Statelessness:

  • Show us that you a storing files and images in an object store or on a ReadWriteMany Longhorn volume
  • Show us that your post/user related Data is stored in the database
  • Show us that you are storing Sessions related information in a replicated store or databse

Dedicated production Grafana dashboard:

  • Show us vizualisations that display that your application healthy
  • Show us that pod health and health "history" is visualised e.g. was it healthy an hour ago
  • Show us how you have visualized KEDA/HPA scaling of your deployment, are your autoscaling decisions visible in your visualizaions
  • Show us that you have visibility into all of the critical components of your applications

Tip

  • Visualization titles should be concisce
  • Visualizations should be quickly understandable
  • Visualizations should have readable concisce labels
  • When representing usage of a certain amount of resources the thresholds should be visually represented
  • State of services should be represented with current status and with a time series representation of your choice e.g. to quickly display if there has been service gaps in the last 6 hours.
  • When you visualize one of the four golden signals, can you add thresholds to them as to visualize a potential problem happening with your application

Operational requirements

Templating:

  • Show us that you are using Helm or Kustomize
  • Show us that you can deploy different configurations with Helm or Kustomize

Safe deployments:

  • Show us that you have Atomic Rollback implemented
  • Show us that a pipeline has failed and successful deployments in regards to atomic rollbacks

Secrets Management:

  • Show us that your secrets are stored in CI/CD variables and only injected into the pipeline in the necessary stages

Production Deployment:

  • Show us that you have a separate deployment for production into prodction namespace
  • Deployment to production needs to happen in a Gitlab pipeline

Autoscaling:

  • Show us that you are using HPA or KEDA
  • Show us that your autoscaling works, due to low traffic configure the autoscaling to be visible
  • Show us that you have applied autoscaling to necessary parts of your application

Affinity and topology constraints:

  • Show us you affinity/topology constraints

Security scanning:

  • Show us that you have implemented security scanning inside your pipeline for container images you are building

Documentation requirements

  • Templating - what, why, usage
  • Secrets hangling - strategy, storage, usage
  • Statelessness - how, where, why
  • How is statelesness implemented
  • How is deployment to production implemented, how does it differ from staging
  • Automatic scaling - what, how, metrics
  • Affinity/topology constraints - how do you assure application uptime incase of a Kubernetes node failure
  • Security scanning - what, why, how
  • Production dashboard - what metrics, how does it help diagnosing issues

Attention

The documentation must form a coherent whole. All the requirements presented in phases 1 and 2 are still mandatory if they are not overwritten by a new requirement. The documentation must still give an understandable overview of the parts that were not changed in this phase.

Scoring

The maximum score for the checkpoint is 20 points. Of these, 15 are team points and 5 are individual points.

  • If any requirements are not met, the team will lose points.
  • Team points are distributed as follows: 3 points for development tasks, 8 points for operations tasks, and 4 points for documentation tasks.
  • If a team member does not contribute and/or cannot answer individual questions, they will lose individual points.

Warning

Penalty for team member not present during the presentation

It is mandatory for all team members to attend the checkpoint presentation. If a team member is not present they will loose their 5 individual points and 50% of their project points. This means that if the teams project gets the maximum of 15 points the two members present will get 15 points from the team points and the member not present will get 7.5 and loose their individual 5 points as well.

Info

Personal points graded as follows:

  • Adhere to the 10 minute time window
  • Answer what is asked of you in a concise manner
  • Demonstrate application functionality and code familiarity
  • NB! Not fitting the demonstration into the 10 minute time window can result in ending the session, in which case, if any questions are unanswered, the team won't be able to earn those points.

Info

If a team member can not participate due to health related issues the must notify the TAs 24h beforehand and provide proof from familiy doctor.

Feedback

We will be using a Google feedback form to collect feedback from the students to improve the course. Please fill it out as soon as possible.

You can stay anonymous if you wish, but we ask to be as honest as needed with the feedback. We will use the feedback only for course improvement purposes.

Feedback form