Blog

Claudio Petrini

### The Open-Closed principles

```
A software artifact should be open for extension but closed for modification.
```

The behaviour of a software should be easily extendible without having to modify the artifact.
This is a principle that guides the design of classes and modules.

If component A should be protected from changes in component B, then component B should depend on component A.
This way higher level components are protected from changes made in lower level component like a hierarchy.


SOLID principle #2: Open-Closed

  
### What is service account ?

A service account is a special kind of account used by an application rather than a person.Service accounts are managed by Identity and Access Management(IAM).

Service account can be of two types:
1. user managed service accounts
2. Google managed service accounts (service agents)

Only user managed service accounts can be attached to a Compute Engine instance.

GCE default service account (user managed):
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```

Google-managed service accounts are used by the instance to access internal processes on your behalf.

GCE identifiable email:
```
PROJECT_NUMBER@cloudservices.gserviceaccount.com
```


### Authorization of a GCE instance

Authorization is limited by:
1. roles of the service account
2. access scopes set on the instance

Both of these configuration must allow access before application can access a resource.

### Default scopes of a GCE instance:
A new Compute Engine instance is automatically configured with the following access scopes:
- Read-only access to Cloud Storage `https://www.googleapis.com/auth/devstorage.read_only`
-  Write access to write Compute Engine logs: 
`https://www.googleapis.com/auth/logging.write`
- Write access to publish metric data to your  projects: `https://www.googleapis.com/auth/monitoring.write`
- Write access to Cloud Trace `https://www.googleapis.com/auth/trace.append`

Best practice is to set the `cloud-platform` (`https://www.googleapis.com/auth/cloud-platform`) access scope and control service by granting it IAM roles.


GCP concepts

### Single responsibilty principle

Name is inappropriate, it doesn't mean that every module should do just one thing (there is a principle for that but it's not SRP).

### Definition

```
A module should be responsibile to one, and only one, actor.
```

By `module` we mean a source file/set of functions which implements some business logic.

By `actor` we mean a group of people who require a specific change.

### Example

As an example having a class which is able to write from the database (eg: through a `save` method) and run an algorithm based on those information is violating the SRP (eg: through a `doPayroll`).

The reason for that is that the main actor of the `save` method is a DBA while the `doPayroll` method main actor is probably the CFO.

### Symptoms of violating it
1. Accidental duplication
2. Merges causing conflicts

### Solution

Separate code that supports different actors. 

`Facade` pattern can help.  

#### References
- Robert C. Martin, Clean Architecture


SOLID #1: Single responsibilty

Hello world with Next.js



## Commands

### Get information about pod
```
kubectl describe pods mypodname
```

### Get Kubernetes secret in YAML format
```
kubectl get secret <name> -o yaml
```

### Add label to a pod
```
kubectl label pods <pod> key=value
```

### Apply changes from url
```
kubectl apply -f url
```

### Scale with a parametric number of replicas
```
kubectl scale deployment <name> --replicas #
```

### Open an SSH shell on the pod:
```
kubectl exec -it <pod> -- /bin/bash
```

### Investigate deployment
```
kubectl get deployment <name> -o yaml
```

### Show labels
```
kubectl get pods --show-labels
```


Kubernetes cheat sheet

### What is a label?
Labels are key/value pairs that are attached to objects, such as pods.
They can be used to organize and to select subsets of objects (via `.spec.selector`).

### What is an annotation?
It's just metadata attached to objects. 
You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata.

### Deployment
A deployment is a declarative way to update Pods and ReplicaSets.

### Stateful set
Provides and guarantees about ordering and uniqueness of the pods.
Used for stateful applications such as dbs.

### Deamon set
Runs a pod of the service for each available node.

### Replica set
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. 
As such, it is often used to guarantee the availability of a specified number of identical Pods.


### Service
Abstract way to expose an application running on a set of Pods.


Blog

SOLID principle #2: Open-Closed

GCP concepts

SOLID #1: Single responsibilty

Hello world with Next.js

Kubernetes cheat sheet

Kubernetes concepts