Tech Specifications ¶

As Code: Hundred of thousands lines of code

Written in:

Stop reinventing the wheel, automated and fully as code

automated (executable from a single source).
as code.
parameterized
- variables
- input parameters
- return / output parameters
"Stop reinventing the wheel"
- avoid re-building the same things more than X times.
- avoid wasting time.
- not healthy, not secure and slows us down.

DoD of a highly reusable, configurable, and composable sub-modules

Which will be 100%

modular
- equivalent to other programming languages functions - Example for terraform - https://www.terraform.io/docs/modules/usage.html (but can be propagated for other languages and tools):
  1. inputs, outputs parameters.
  2. code reuse (reusable): consider tf modules and sub-modules approach.
  3. testable by module / function.
    1. Since TF is oriented to work through 3^rd party API calls, then tests are more likely to be integration tests rather than unit tests. If we don't allow integration for terraform then we can't work at all.
      1. This has to be analyzed for every language we'll be using and how we implement it (terraform, cloudformation, ansible, python, bash, docker, kops and k8s kubeclt cmds)
  4. composition (composable): have multiple functions and use them together
    1. eg: def_add(x,y){return x+y} ; def_sub(x,y){return x-y}; sub(add(3,4), add(7,5))
  5. abstraction (abstract away complexity): we have a very complex function but we only expose it's definition to the API, eg: def_ai_processing(data_set){very complex algorithm here}; ai_processing([our_data_set_here])
  6. avoid inline blocks: The configuration for some Terraform resources can be defined either as inline blocks or as separate resources. For example, the aws_route_table resource allows you to define routes via inline blocks. But by doing so, your module become less flexible and configurable. Also, if a mix of both, inline blocks and separate resources, is used, errors may arise in which they conflict and overwrite each other. Therefore, you must use one or the other (ref: https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d)
    As a rule of thumb, when creating a module, separate resources should always be used.
  7. use module-relative paths: The catch is that the used file path has to be relative (since you could run Terraform on many different computers) — but relative to what? By default, Terraform interprets the path as relative to the working directory. That’s a good default for normal Terraform templates, but it won’t work if the file is part of a module.
    To solve this issue, always use a path variable in file paths. eg:
```
resource "aws_instance" "example" {
  ami = "ami-2d39803a"
  instance_type = "t2.micro"
  user_data = "${file("${path.module}/user-data.sh")}"
}
```

Solutions must be versioned

So as to be able to manage them as a software product with releases and change log. This way we'll be able to know which version is currently deployed in a given client and consider upgrading it.

Env Parity

Promote immutable, versioned infra modules based across envs.

Updated

Continuously perform updates, additions, and fixes to libraries and modules.

Orchestrated in automation

We use the leverage-cli for this purpose

Proven & Tested

Every commit goes through a suite of automated tests to grant code styling and functional testing.

Develop a wrapper/jobs together with specific testing tools in order to grant the modules are working as expected.
Ansible:
- Testing your ansible roles w/ molecule
- How to test ansible roles with molecule on ubuntu
Terraform:
- gruntwork-io/terratest

Cost savings by design

The architecture for our Library / Code Modules helps an organization to analyze its current IT and DevSecOps Cloud strategy and identify areas where changes could lead to cost savings.
For instance, the architecture may show that multiple database systems could be changed so only one product is used, reducing software and support costs. Provides a basis for reuse.
The process of architecting can support both the use and creation of reusable assets. Reusable assets are beneficial for an organization, since they can reduce the overall cost of a system and also improve its quality, since a reusable asset has already been proven.

Full Code Access & No Lock-In

You get access to 100% of the code under Open Source license, if you choose to discontinue the direct support of the binbash Leverage team, you keep rights to all the code.

Documented

Includes code examples, use cases and thorough documentation, such as README.md, --help command, doc-string and in line comments.

Supported & Customizable

Commercially maintained and supported by binbash.