Skip to content

Tech Specifications

🏁 As Code: Hundred of thousands lines of code

Written in: - [x] Terraform - [x] Groovy (Jenkinsfiles) - [x] Ansible - [x] Makefiles + Bash - [x] Dockerfiles - [x] Helm Charts

🏁 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 composible sub-modules

Which will be 100% - ⏩ modular - equivalent to other programming languages functions - Example for terraform - (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 it's oriented to work through 3rd 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 it together 2. 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. When creating a module, you should always use a separate resource. For example, the aws_route_table resource allows you to define routes via inline blocks. Otherwise, your module will be less flexible and configurable. So If you try to use a mix of both inline blocks and separate resources, you run into bugs where they will conflict and overwrite each other. Therefore, you must use one or the other (ref: 7. Use module-relative paths: The catch is that the file path you use has to be relative (since you could run Terraform on many different computers) — but what is it relative to? By default, Terraform interprets the path 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}/")}"

🏁 Solutions must be versioned

So as to be able to manage them as a software product with releases and change log. In this way we'll be able to know which version is currently deployed in a certain client and consider it's upgrade.

🏁 Env Parity

Promote immutable, versioned infra modules based across envs.

🏁 Updated

Continually make updates, additions, and fixes to the libraries and modules.

🏁 Orchestrated in automation

We use the leverage-cli for this purpose

🏁 Proven & Tested
Customers & every commit goes through a suite of automated tests to gran code styling and functional testing.

*   [x] Develop a wrapper/jobs together with specific testing tools in order to grant the modules are working as expected.
*   [x] Ansible: 
    *   [Testing your ansible roles w/ molecule](
    *   [How to test ansible roles with molecule on ubuntu](
*   [x] 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 to an organization, since they can reduce the overall cost of a system and also improve its quality, given that 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 ( so If you ever choose to cancel, you keep rights to all the code.

🏁 Documented

Includes example code, use case and thorough documentation, such as, --help command, doc-string and in line comments.

🏁 Supported & Customizable

Commercially maintained and supported by Binbash.