Cogastro. DevOps practices for isolated single-tenant application architecture

Cogastro: Offering Cutting-Edge Solutions for Sustainable Protein Production

Cogastro is a leading software company in the field of insect farming. With their innovative software, insect farmers can easily monitor and optimize their insect populations, resulting in healthier and more productive insects for use in animal feed, pet food, and even human consumption.

Cogastro’s technology is revolutionizing the way we think about food production, offering a more environmentally friendly and efficient alternative to traditional protein sources.

The Problem

Cogastro, as a specialized SaaS company working hard as the pioneer of a tailored product for insect farming, realized that more and more customers demanded an isolated single-tenant solution (to ensure the highest possible security, privacy, and ownership of their data). To meet the demand, Cogastro decided to rebuild its application architecture to support single-tenancy by default.

Also, with an ever-growing customer base, Cogastro experienced a long queue of customer requests for features. Like most young businesses, they understood the need to deliver new software features quickly and use the momentum.

Being a software company, Cogastro was familiar with DevOps practices in general. However, they sought an experienced partner to help them design a new full-proof DevOps practice for faster feature deployment and a solution ready to serve many customers with the least operational effort.

Solution and Architecture

The primary services used to build the solution are Amazon ECS, AWS Fargate, EC2, S3, and ALB.

Cogastro. Devops Practices For Isolated Single-Tenant Application Architecture 1

The infrastructure code is stored in a private GitHub repository. Separate AWS accounts are used for staging and production environments. To deploy to the accounts, GitHub actions are used with the utilization of Terraform. For the application layer, ECS Services and 3 ECS tasks are created by tenants that run on AWS Fargate. The docker images are stored in ECR. Three availability zones are used for high availability. The data layer – MongoDB runs in cluster mode in production, where each instance resides in a different availability zone. We created one cluster/tenant. The least privilege principles are applied in all layers of the infrastructure.

Infrastructure as Code

We created separate branches to store the code for production and staging environments. We chose to use Terraspace because of its automation capabilities, making it easier to separate the tenants using its modular approach and the resources needed to organize a tenant in VPCs. We set up AWS-managed shared resources in the VPCs among the group of tenants like Application Load Balancers and Fargate cluster.

This solution also isolates noisy neighbors since some resources belong to each tenant separately. We grouped these resources and created a Terraform module for the shared and tenant-specific resources. We reused the modules to create the stacks and used different environment variables. The container secrets get stored in AWS Secrets Manager.

CI/CD

We created different workflows to deploy the VPC’s, shared, and tenant-specific resources. AWS credentials needed for the GitHub workflows are stored in GitHub secrets. Before deploying to production, the staging environment is used for testing. The workflows are triggered based on which paths are affected during pushing the code to the repos. Also, only pushing to the staging and production branches can trigger the workflows.

There is one pipeline for each tenant – we could achieve this by using the matrix strategy in the GitHub workflow. The first job gathers which paths are affected and then parallelly runs the matrix job upgrading the tenant’s environments.

Metrics for Success

A new single-tenant solution makes it now possible to isolate customer workloads and data, thus significantly increasing data security by reducing the surface of attacks and giving the ownership back to the customer (which was highly requested). As a result of the new architecture and DevOps practices implemented, Cogastro is now able to deploy new features and fix bugs 2x faster than before. This already proved to be a great decision as their product features development pace allowed them to respond to the needs of their customers and build a great product.

Ready To Find Out Why Over 300 Startups Like Cogastro Trust Cloudvisor?

Cogastro chose to work with us because we think like a startup and have a leading DevOps team. We understand startups’ unique pain points and the importance of rapidly adopting effective solutions without getting bogged down in unnecessary bureaucracy.

How can we help you take your AWS implementation to the next level? Schedule a call with our team today and discover it! Contact Cloudvisor today and get the most out of AWS.

Other Case Studies