Meet Maaz: Diving into DevOps at adjoe

“If you ask any other DevOps engineer about what they do, they won’t say the same thing. There is no defined role.”

Maaz Malik, adjoe’s DevOps working student, defines his individual role at the company as managing and working above all with AWS Lambda, Elasticsearch, GitLab, infrastructure as code, and CI/CD pipelines. As adjoe’s business and tech stack evolve, however, he knows that his role within the DevOps team will also evolve. Particularly, with the company’s upcoming switch from Amazon ECS to Kubernetes to run its services.

Enrolled at the Hamburg University of Technology, Maaz is currently writing his thesis on identifying security features in open-source code with machine learning. Since working with adjoe’s DevOps team, Maaz has accompanied his studies by absorbing practical knowledge in various domains such as Terraform, network infrastructure, adjoe’s extensive tech stack – and from adjoe’s senior DevOps engineers themselves.

Working with Infrastructure as Code

After taking programming modules at university, Maaz was no newbie to working in Go. However, working at adjoe meant learning to use Terraform for the first time. adjoe’s DevOps team uses Terraform for provisioning resources centrally, which includes DynamoDB tables, SQS queues, EC2 instances, lambda functions, and Redis Clusters. As Terraform is a code that can be pushed to a version-controlling tool like Git, it allows Maaz and his team to also rapidly track changes after configuring them.

Let’s break this down. Maaz provisions resources, such as EC2 instances, via Terraform. If he needs more of such instances with the same configuration, he only needs to specify the instance count. This eliminates the need to specify configuration for the subsequent instances, making deployment faster and more manageable.

Deploying an EC2 Instance on AWS

provider "aws" {
  profile = "default"
  region  = "eu-central-1"
}

resource "aws_key_pair" "ubuntu" {
  key_name   = "ubuntu"
  public_key = file("key.pub")
}

resource "aws_security_group" "ubuntu" {
  name        = "ubuntu-security-group"
  description = "Allow HTTP, HTTPS and SSH traffic"

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "terraform"
  }
}


resource "aws_instance" "ubuntu" {  count         = 2
  key_name      = aws_key_pair.ubuntu.key_name
  ami           = "ami-04qy3944f2c35j470"
  instance_type = "t2.micro"

  tags = {
    Name = "ubuntu"
  }

  vpc_security_group_ids = [
    aws_security_group.ubuntu.id
  ]

  connection {
    type        = "ssh"
    user        = "ubuntu"
    private_key = file("key")
    host        = self.public_ip
  }

  ebs_block_device {
    device_name = "/dev/sda1"
    volume_type = "gp2"
    volume_size = 30
  }
}

resource "aws_eip" "ubuntu" {
  vpc      = true
  instance = aws_instance.ubuntu.id
}

Logging with Elasticsearch

Using Terraform, Maaz is able to deploy everything. This includes Elasticsearch as a logging service, which he has also learned to manage at adjoe. In order to work with the Elasticsearch service, which is installed in multiple EC2 instances inside AWS, Maaz learned how to create and maintain clusters. These are formed by master nodes and data nodes – as well as indices and shards.

Managing Elasticsearch is a job within itself. As its “guardian,” Maaz checks an AWS cloudwatch for the Elasticsearch cluster’s health metrics to see that the entire cluster stays healthy. He manages the Elasticsearch clusters, and the clusters manage all the logs. If any issue regarding indexing or sharding occurs Maaz needs to fix it. If a shard – the unit of data that Elasticsearch distributes around the cluster  – becomes unallocated, the team loses data. This means that they are unable to monitor the system’s health or read logs to gauge how the application is working.

In this situation, Maaz needs to identify the reasons for a shard becoming unassigned. In his experience, a reason could be that a node disc is full.

Rerouting an Unassigned Shard

Let’s see how Maaz is able to reroute an unassigned shard in Elasticsearch using the request GET _cat/allocation?v.

First, Maaz investigates why the shard is unallocated by running the request GET _cluster/allocation/explain?pretty.

Next, Maaz identifies that this shard needs to be rerouted to another node. It can also be deleted if it is a single node deployment.

Similarly, if one of the nodes reporting to a master inside a cluster goes down, Maaz needs to correct the error so that the node is able to rejoin a cluster.

What More Is in Store for Maaz?

Defining the exact role of an adjoe DevOps engineer is tricky – as Maaz recognizes himself. The role is just as abstract and fast-evolving as the new technologies and custom solutions the engineers work with. But defining the importance of Maaz’ role as part of the bigger picture is pretty simple. By managing Terraform and Elasticsearch (as well as creating and fixing the CI/CD pipelines), he fixes infrastructure-related problems, such as provisioning of resources. This is necessary to deploy the code in a more streamlined and automated manner. Without this, adjoe’s developers cannot deploy their code onto the infrastructure.

So, what’s next for Maaz? He was initially drawn to adjoe for first-hand experience with Elasticsearch, microservices inside AWS, and cloud computing. Now, Maaz is keen to progress in his career as a DevOps engineer with the strong support of his tight-knit team. He’s excited to collaborate on further projects, enjoy greater ownership of new projects, and master new technologies. And there are particular projects in the pipeline he’s eyeing up … With adjoe’s switch from Amazon ECS to Kubernetes, he hopes that learning Kafka and using it in combination with Kubernetes will achieve a more simplified and scalable architecture.