Gtmhub: Architecture, Scalability, Security and DevOps

Posted by Ivan Osmak
on February 8, 2018

We often get asked by prospects to tell them more about Gtmhub – The Software. This is obviously an interesting topic for many of the IT departments, so in this blog post, I am going to briefly describe how we build software.

Architecture

Gtmhub is a cloud-based SaaS software.

It is based on the microservice architecture. At the moment, Gtmhub consists of 57 microservices. Microservices are completely decoupled and communicate with each other through a RabbitMQ message queue.

Different programming languages are used, depending on what needs to be done. Mostly, one will find:

  • Java
  • Go
  • JavaScript
  • SQL
  • R
  • Python

In addition to the programming languages, we use a lot of YAML which we use to describe connectors, APIs, and insights. It is this paradigm that allows us to build hundreds of connectors and insights, with a relatively small team.

We use three different databases, all for different purposes:

  • MongoDB – used for metadata
  • PostgreSQL – used for client data and metric calculations
  • Redis – used for caching of stale metrics

Gtmhub has a fully exposed REST API. Both, web app and mobile apps, are using this very same API for all of their communication with the backend services.

Gtmhub REST API
Gtmhub REST API

An interesting point about Gtmhub is that it can be deployed on-premise as well as on following cloud platforms: AWS, Microsoft Azure, Digital Ocean, SoftLayer, and Packet.

Scalability

Gtmhub is running on Docker, with all microservices being stateless and horizontally scalable. The public access to different services is orchestrated by nginx.

Centralized logging for all of the microservices is used to monitor the performance of the entire system. Scaling of the particular microservice is immediate and without downtime.

The frontend "team"
The frontend one-man-army

Databases are set up in a way which allows horizontal scalability or scaling out. MongoDB is deployed in a replica set, with multiple nodes allowing for seamless and infinite horizontal scaling. In similar fashion, PostgreSQL – which is tasked with heavy duty work in Gtmhub – can scale out horizontally. Due to the logical separation of different tenants, this scaling process happens without incurring performance penalties.

Security

Gtmhub, by default, uses OAuth2 authorization mechanism – both for user access and API access. For API access it is also possible to enable per-user API keys, though this is not enabled by default. Authentication is handled by a 3rd party, SOC 2 compliant provider.

In addition to traditional username/password logins, Gtmhub also supports social logins – Google and Facebook. Finally, federated logins are possible through Active Directory, Google G Suite, and Okta.

All of the communication with Gtmhub application or between different microservices of Gtmhub is happening over SSL with 128-bit AES encryption. The connection uses TLS 1.2, it is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism.

Only one of the 57 microservices is actually exposed to the public, while all the others are protected with firewall.

The client data is logically divided within the databases, with unique authentications – preventing accidental human errors and leaking of the data between the tenants.

Not necessary a security point, but in this day and age it is important – all of the Gtmhub data is hosted within EU and does not leave EU (DigitalOcean, Amsterdam data center), providing yet another layer of security and privacy.

Finally, Gtmhub has passed several security and IT audits by public companies.

DevOps

Gtmhub product team consists of 5 people, all with over 10 years of experience in developing enterprise software. There are no DevOps people, as we believe that is an oxymoron.

Reviewing logs
Reviewing logs

The team has made over 700 deployments to the production environment in 2017. The developer environment, staging and production environment are all identical. The deployments themselves are automated and are passing an automated pipeline, which is triggered once the pull request has been approved. The entire process of compiling, running automated tests (thousands of them), static analysis, container building and deploying is automated – which allows 5 people to deliver value to customers on average twice a day. All this with 99.999 uptime in 2017.

Any problems or crashes within the microservices are automatically detected and restart themselves.

 

Previous post