Dimensigon

A game-changer in Cloud Era

Get Elastic!

Introduction

Dimensigon (“DM”) is an open-source python-based technology designed to coordinate or orchestrate complex inter-server automation regardless if the servers can directly reach each other or not.

DM can act as some combination of the following functionalities:

  • Coordination of inter-server operations
  • Standalone Automation
  • Distributed Management of servers

The bet for decentralization comes from the reality in companies for creating silos, verticals, or microservices with multiple subnets or network separation. Through decentralization, DM aims to solve the connectivity problem and creates a mesh network that can help teams or each application vertical to perform event-triggered orchestrations in any number of servers.

Thanks to DM, users in each vertical can preserve the value created with their current automation technology and embed it to Dimensigon to integrate with other tools at the company-level.

Dimensigon can be used not only for automation but for driving company-wide operations such as Auditing, Log Federation (a topic we will cover later on), for compliance or Governance

Continuous Automation

Most automation technologies have been designed for a one-off deployment operation.

Dimensigon has been designed to retain control after automation and interconnect the company fully to monitor, react, and adapt the company to its needs through our concept of continuous automation.

Continous Automation is for us a philosophy that it means that most maintenance operations can be event-triggered and finally automated to get higher automation levels and maturity in the company.

The Preparation phase in Automation

It is very often that the preparation of the automation to work is high, it implies controlling and testing it until it works and its requirements at users’ end, and each target server is considerable.

This is what we call the preparation phase, the time expended until certain automation is triggered and it works as expected.

Software Management in large companies (Repos and Distrib.)

Due to network separation, many software companies have to create more than 1 software repository or to create mirrors in each regional unit of the company.

It is often the case that the Software Repository is not directly reachable from the nodes you want to automate something. To avoid creating software repository mirrors or opening network rules to most servers, we have added the Software Library capability.

Software Library

The Software Library helps to make available remote Software locally or in any server when required.

You can pull a Software as a step inside your orchestration with a single command.

Log Federation

Log Federation is a term Dimensigon (DM) is introducing the first time in the IT Market.

It makes it possible to subscribe to logs and full directories to forward the information to another server.

It comes after 3 specific needs:

  1. For each software deployed, we need to have a scalable way of Log Analysis, either through third-party software or human-driven analysis. In the case of managing a considerable number of machines, for example, managing 30 Webservers or managing a huge HDFS cluster, it is easier to find all logs locally, like a tree organization rather than having to connect to each machine to check what it is going on.
  2. Also during an orchestration execution, if we want to check in-detail and quick, what is it going on in a good number of servers with minimum effort, the best is to have all logs accessible locally.
  3. As we provide support to multiple customers, we do not hold access to their infrastructure 100% of the time. In most cases, we need a VPN and credentials to connect to each customer. As we want to provide very responsive support, we found a very practical way of forwarding the logs only from the customer, so in case there is a software failure, the customer does not need to expend time in sending us the logs and both parties save time in ping-pong emails. We can focus on the issue directly and without time delays.
Maintaining Images VS Metadata

It is a trend to create and deploy images in the form of containers or virtual machines as part of automation. The maintenance of such images and its metadata, it supposes a great effort for companies that it is often understood for granted in companies and not challenged.

With Dimensigon (DM) we want to provide the option of maintaining only metadata instead of both (metadata and images). Thanks to the functionality we are disclosing, DM is flexible and can deal with any scenario to create automation with the less preparation effort possible.

 

The conception of Dimensigon (“DM”)

Dimensigon has been designed and created to tackle down the following scenarios or targets.

Scenario A

We want to generate a number of Servers N, deploy them in Cloud X, transform them in a service Y and in the middle of the process get the logs for each server locally available where we have launched our automation in order to know in detail the status of the operation in each node. We want that each node had the possibility to interact with any other node through RESTful and being able to notify another node its own will to get resized on-demand.

We do not want to:

  • Manage images because we have a wide portfolio of Software and image storage has a cost in the Cloud and its maintenance.
  • Distribute SSH Keys between the servers
  • Have to connect to each node to control its operation.
  • Have to install third-party for monitoring.
  • Have to open network rules to transport the software
Scenario B

We want to re-use automation playbooks from Ansible, or being able to run polyglot orchestrations where we can have a first step using, for example, Terraform, another step SHELL in another server and then Ansible in the servers that were created but at the local connection level, which it is simple to configure and execute.

With this approach, we avoid selecting a single automation technology and we can embrace all automation technologies together to coordinate them for a higher purpose.

Scenario C

In case automation is failing, we want to be able to execute distributed commands to quickly check what it has been missed or it has to be added to continue and minimize the effort to have successful automation.

  • That's why DM has distributed commands through "cmd" functionality in DShell or via RESTful.
Scenario D

We want that Client A deploys our orchestration and we can get the logs without pinging the customer in case of failure. We want to minimize the effort at the customer side and minimize the communication to providing directly a workaround or solution.

This level of proactiveness will allow us to have a differentiator while providing remote support.

We do not want:

  • To have ping-pong emails to start troubleshooting an issue.
  • To have to connect through VPNs or introducing credentials for each customer just to get basic logs or any logs necessary.
  • Avoid connecting to check customers' operation every time a failure happens.

The limitations of DM are up to your imagination as DM can be extended without limitations and it is a REAL open source software where you can make your own integration easily through RESTful or any other way.

Our own definition of Real Open Source Software

A Software with its source publicly available with no actual or planned offering of premium versions or tiers, please note, this is a common practice in the market and it is called “Freemium” Software.

We commit to returning all contributions or improvements directly to the community through our open-source version, publicly available.

 

8 + 2 =

© Dimensigon 2020. All rights reserved.