ARGLabs projects list

Here is a list of project repositories of use cases we developed.

Read more: ARGLabs projects list

In order:

Organization administrators scope:

AIO Scope – SRE Team

ARGLabs tech stuff summary

This is for quick reference about our design decisions.

Where terraform data is stored for the company, teams, how DNS works etc.

Everything here is covered by complete articles explaining why.

This is just a quick reference summary.

Read more: ARGLabs tech stuff summary

Environments

Environments used in ARGLabs:

  • Default: where IaC is developed and every unique stuff is deployed.
  • Prd: production environment derived from the default environment.

Scopes

We’ll have just one scope named AIO (for All In One).

AWS Accounts

Read about here: AWS multi-account model and ARGLabs

One account for each environment per scope.

This means:

  • AIO Default
  • AIO Prd

Network

Each environment will use only one VPC in which each team will have it’s own network.

  • Default: 10.255.0.0/16
    • SRE Team: 10.255.0.0/24
    • Team01: 10.255.1.0/24
    • Team02: 10.255.2.0/24
  • Prd: 10.0.0.0/16
    • SRE Team: 10.0.0.0/24
    • Team01: 10.0.1.0/24
    • Team02: 10.0.2.0/24

CIDR Control is done at this repo: https://bitbucket.org/arglabs/arglabs-main-org-cidr-control/src/master/

Terraform

Remote state bucket

  • arglabs-terraform-states: company-wide stuff. Used for resources outside the teams accounts.
  • arglabs-aio-terraform-states: Used to store all AIO account terraform projects.

Terraform and providers versions

We decided to use latest versions because

DNS

Projects

AIO BigBang

AIO Account

SRE Infrastructure

Pending

  • AIO bigbang wont have state aggregator anymore and will only save state on the main account s3 bucket.
  • Infrastructure repos should get remote state from the main account but stores its states on the bucket inside the default account.
    • change-data should help to do this

ARGLabs fictitious company

So you are a newcomer on our company. Congratulations !

Our DevOps culture

We like the DevOps “You build it, you run it.” culture.

It means that our Cloud Engineers (call them DevOps, SRE, infrastructure guys or whatever you want), will help you with the basic cloud infrastructure on which your applications will run, but they won’t be called to solve your apps problems and incidents, so please, take the ownership of everything you bring up on the cloud, including costs, incidents etc.

Cloud Engineers can always help you with architecture decisions and deployment pipelines, but once it’s running, it’s up to you to keep things up.

Continue reading

Why a .church domain ?

Because churches are places of faith.

I love IaC. I really do IaC. I think I understood what we can really do with IaC.

But I’ve seen many “good practices” out there that I thought aren’t good enough, many written by famous people and others even by the tool suppliers themselves.

In fact, everyone can write and publish anything and call it a “best practice”, and in fact, it could be for them, for many reasons. Good practice is what works best for your way of working.

ARGLabs is my church because this is where I’m going to show what I believe are best practices for the work I do.

In ARGLabs Church, I am the law (as Rodrigo Goes says 🙂 ).

These are not intended to be best practices for everyone.

What is ARGLabs ?

Take ARGLabs as a fictional company where we’ll be running some applications like a real company

And with “real company” we mean that we’ll bring up everything needed to run our applications.

Every tech company “just” need to “run their applications”. By design, no specific tools are needed as long as the chosen tools meet the applications needs. With that in mind, we’ll choose the simplest tools and only those which allow us to configure them as code.

So what makes ARGLabs worth it, and why you would read more about it ?

Our tech design principle is: “If it can’t be done as code, it cannot be done.”

With that, many other benefits come along:

  • Knowledge is written down in code and no more in anyones head.
  • Disaster recovery or any number of dev/testing environment is just a matter of cost, but without managing effort.

And countless benefits more. Majority of them already included by the above mentioned (please don’t ask me to tell you every single benefit. If you can’t see them, maybe you should ask you tech staff after reaching us)

We’ll use many tools (where a free account could meet our needs) that a real company would use.

We’ll try to have every tech stuff a modern company usually have:

  • Public and private applications
  • Deployment pipelines, CI/CD
  • Monitoring tools and metrics
  • Incident Management
  • Communication platform and integrations