---
# System prepended metadata

title: 7Shifts DevOps Challenge
tags: [personal]

---

---
tags: personal
---

# 7Shifts DevOps Challenge

This article represents my proposal for the DevOps challenge offered by 7Shifts

## Scenario

Based on the following repository: https://github.com/caragpe/k8sdemo

I would like to provide answers to the following questions

### We want to deploy two containers that scale independently from one another

The information provided in the [repository](https://github.com/caragpe/k8sdemo) offers a solution for one container (usersapi, in this case). We could easily expand the scope to two containers, as requested, by adding:
- a **shiftsapi deployment**, similar to the existing usersapi deployment, with a service acting as load balancer
- a **shiftsbd deployment**, similar to the existing usersbd deployment, with a service to enable internal communication
- a **shifts** secret component
- a **shifts** HPA component, to scale shiftsapi pod(s) independently


###  What types of IAM controls do you put in place so your development is not be able to run certain commands on your k8s cluster?

We may implement some strategy to control access to the Kubernetes API as described in [the official documentation](https://kubernetes.io/docs/concepts/security/controlling-access/) by setting an authentication method and stablishing rules based on groups. These rules will determine what a user can/cannot do.

### How would you apply the configs to multiple environments (staging vs production)?

One option would be to use [kubernetes namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) in order to group components by namespace. Each namespace can define its own specific configuration and therefore act as different environments.


### How would you auto scale the deployment based on network latency instead of CPU?

Metrics about CPU/Memory are offered by default by Kubernetes. The requested option will require to create d Prometheus adaptar component that will expose that information to the Kubernetes API and from there, the HPA component will be able to read that information and autoscale accordingly. More info in [this article](https://dzone.com/articles/prometheus-metrics-based-autoscaling-in-kubernetes)


## Author
[@caragpe](https://github.com/caragpe) - carlos.agullo@gmail.com