Motiv Solutions

Introduction

It’s been said that if the only tool in your toolbox is a hammer, then every problem looks like a nail. While Motiv believes in using the right tool for the right job we also recognize the importance of having a standardized set of tools in our toolbox. Motiv is an innovative company that will continue to learn and continue to grow our Technology & Standard content seeks to cover the primary suit of technology we use to create amazing products, solutions, and software

While not all software we integrate with and work with conforms to the principles and architecture below, what follows is the core philosophy of who we are as engineers at MotivLabs.

MotivLabs Core Coding Principles

Whenever possible software should be scalable and fault tolerant
Motiv software and solutions can run on common hardware and/or cloud infrastructure making it the perfect platform for mission-critical data.
- This means when Motiv engineers code the software is coded from the standpoint that it can run on hardware that is expected to fail WITHOUT taking the server or service down
Test Driven Development
- Motiv Engineers will never fix a bug, write an API, create a function, nor implement any functionality without creating a Test and then coding against that test
- Motiv Accomplished this through a combination of both Integration and Unit Tests
MotivLabs prefers the use of Containers for coding new software, services and projects. This makes code easier to test as Containers help to stabilize the environment allowing better reproducibility of errors and issues
Motiv UIs should only call APIs and remote calls that already exist. In summary this means all buttons and features of the UI can be executed WITHOUT the UI through Remote Calls.
- We like JAMStack and Static generation.
- This is not to say we cannot work with or integrate with systems that do not follow this pattern but when we at MotivLabs code a UI this is our preferred philosophy
MotivLabs prefers stateless applications. Again Motiv expects all hardware and to fail at any given point in time. Hardware failure should not take our services and software down

MotivLabs Software Architecture

MotivLabs loves MicroServices. We use the following patterns and architecture for our MicroServices

Low Coupling - Decoupled

If we make some changes in service A, we don't want them to affect service B

High Cohesion

If we need to implement a new feature or even fix a bug, we want the least possible number of services to be affected

High Autonomy

If some service fails we don't want the whole system to be down

Responsible Granularity

We understand network trips are not free

Stream Processing/Bus

Services should communicate via events or a stream processor

We don't want our services to be aware of each other since it reduces maintainability and couples them together

There are times we might need a dispatcher to call services but in general services need to be their own thing

Ensures that new services and code can be deployed without affecting other services and code

Decentralized data

A service shouldn't share the way information is stored. Just like a good object it exposes behavior not data

Persistent Storage - DB

In short summary we will have a Scheme (keyspace) per microservice.

ONLY 1 Microservice should connect to that schema. NO Schema Sharing. Do NOT do it. Nope not even for that case ….

MotivLabs does code will not use persistent storage to pass data within a transaction or single action. We consider this to be an anti pattern

PCompliance and Security

At MotivLabs all our code is written with a focus on compliance and security

From a data perspective we have written and write code that conforms to standards like GDPR, SOC2, ISO27001, HIPAA, FERPA etc…

While writing and architecting code and software MotivLabs engineers ask questions like What are we storing? Who has access? Can a user’s credentials be scrubbed properly?

Cassandra

At MotivLabs we use many DBs ie.. MySQL, Oracle, MongoDB, Postgres, and MSSQL

From a data storage philosophy when we at Motiv write our own services and code we are looking to avoid a single point of failure that often exists with traditional RDS (relational db solution) While you can cluster RDSs there tends to be problems and tradeoffs that hinder scalability. Motiv requires data storage that is modern, redundant, and can handle petabytes of data.

Cassandra has the ability to scale up and down around the globe. Casandra is decentralized meaning it runs Multi-Master which provides MotivLabs services and code tremendous scalability.

GO

MotivLabs engages on a daily basis with Java, PHP, NodeJS, Python, Bash, and Ruby our preferred language for most services is GoLang

Motiv is currently using GO as it’s primary language. GO has the following advantages

An Amazingly Cute Mascot

Requires NO JVM or Runtime. Can be packaged statically linked. Statically linked means you do NOT need to have GO installed to run a program we write in GO.

Concurrent allowing for better performance. Google actually created the language cause while they loved Python they required something more performant than Python

While it compiles and is statically typed it is easy to write similar to an interpreted language.

GO has great tooling and standards for enforcing proper documentation

Built-in frameworks for testing and profiling

Containers/Docker

Motiv believes in the pattern of using Containers to deploy code. If for no other reason Containers can provide the same environment everywhere the software is running with static versions of all libraries and processes. In addition to this Containers if used properly can greatly ease deploying, delivering and testing code.

While Motiv is not married to Docker or Kubernetes as we believe these techs will move and change the idea of containers is core to how we want to build and deploy software

Angular

Javascript frameworks have proven to move quickly. Currently Motiv sees Angular as the best framework for build Web Applications. An Application is different from a Web Site. Angular compiles and has great tooling behind it. It also enforces proper MVVC patterns. In addition it allows for reusable Code making use of industry standard patterns like Dependency Injection.

We do make heavy use of GatsbyJS, React and NEXT.js for web sites and static generation

Kafka

The intention is to have no direct microservice to microservice communication. We will use kafka and expect it to be fault tolerant as a message queue

Kafka is a Message Queue, Message Broker or Stream Processor. It is similar to ActiveMQ. At a high level Kafka allows Motiv Microservices to function together without ever having to directly talk or call each other. Kafka is designed to never lose messages (fault tolerant) and to handle millions of requests at a time. Having Micro Services not talk directly to each other is what allows us to have more maintainable software that doesn’t suffer the pains of monolith software such as huge upgrades and small changes taking down unexpected parts. In addition to this Kafka empowers us to have small properly tested Microserves which leads to much more stable and reliable software.