Add a spellchecker tool to CI and fix all existing typos.

This commit is contained in:
Nikolai Rodionov
2023-05-02 14:47:34 +02:00
parent 77447a18da
commit 67ff2bbdfd
14 changed files with 241 additions and 28 deletions

View File

@ -10,7 +10,7 @@ cover:
responsiveImages: false
---
Well, after I've posted my argo serie, I've found out that I couldn't really make myself understood. So now I want to talk more not about the way of implementation, but rather about the consequinces of different implementations. And maybe I will e able to finally make a point about why I don't like Terraform and why I think that ArgoCD is mostly mis-used by almost any SRE team I know.
Well, after I've posted my argo serie, I've found out that I couldn't really make myself understood. So now I want to talk more not about the way of implementation, but rather about the consequences of different implementations. And maybe I will e able to finally make a point about why I don't like Terraform and why I think that ArgoCD is mostly misused by almost any SRE team I know.
But first I'll try to describe how I see myself as a part of a team, the team as a part of a bigger team, and all the teams across different companies as links in the bigger chain.
@ -18,7 +18,7 @@ This is how I used to see development teams before:
![Chain](/posts/design-a-scalable-system/chain-1.png)
The whole team is using something as a service, for example `AWS`, the whole team is working together and producing something that is passed to a customer. But apparently this approach is only applicable to small teams, and I think it's working just fine. But there is a problem. Teams tend to grow without an understanding that they are growing, hence they keep acting like they're small but in the same time they don't change the workflow, and brick-by-brick they are building something that eventually is something unscalable at first and later unmaintanble.
The whole team is using something as a service, for example `AWS`, the whole team is working together and producing something that is passed to a customer. But apparently this approach is only applicable to small teams, and I think it's working just fine. But there is a problem. Teams tend to grow without an understanding that they are growing, hence they keep acting like they're small but in the same time they don't change the workflow, and brick-by-brick they are building something that eventually is something unscalable at first and later unmaintainable.
Example of an evolution like this: