# Our microservice stack

DevFeed: [Our microservice stack](<https://devfeed.tech/articles/our-microservice-stack-20099.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/our-microservice-stack-db50aa2b17d6?source=rss----bd77d16a0035---4>)

Author: Emmanuel Joubaud

Published: 2023-03-31T10:34:09Z

Content type: article

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [Microservice](<https://devfeed.tech/topics/microservice.md>), [gRPC](<https://devfeed.tech/topics/grpc.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>)

Tags: [go](<https://devfeed.tech/tags/go.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

Jobteaser describes its microservice implementation, including Ruby and Go service chassis, gRPC APIs, Kafka-based data replication, and Kubernetes deployment.

## Source excerpt

This is an introduction to how we've implemented microservices at a mid-size scale-up called Jobteaser, with a mix of Go and Ruby service chassis, gRPC APIs and data replication via Kafka. Foundation: The service chassis Back in early 2019, when Jobteaser decided to get serious about breaking up its decade-old Rails monolith into microservices, we assembled a Foundation team that started working on an in-house service chassis. It was soberly coined service and came in two flavours: the rb-service framework in Ruby and the go-service framework in Go. Four years later, they still form the foundation of our fleet of about 20 services. They provide a lean set of consistent features across the Ruby and Go flavours: a gRPC server component to power our gRPC APIs (more below) a Kafka consumer, to consume messages from a Kafka message queue a Prometheus exporter, to expose monitoring metrics a low-level lib (no ORM) to interact with Postgres, that would be the default database of each service, and optionally Redis for services who require one consistent logging, metrics and error reporting for those components a bunch of CircleCI, Dockerfiles and Kubernetes (k8s) config files to enable automatic deployment in staging and production an executable to start the service a generator script, to scaffold a new service's Walking Skeleton with all of the above and get it deployed to prod in less than a day For a while, the various workloads would all run as threads inside a single process: each instance of a service would run a thread pool for its gRPC server, one for its Kafka consumers, one for its Prometheus exporter, one for its background jobs, etc. That was great for the local dev environment because you didn't need to run a different Docker image for each workload, but we quickly came to split the types of workloads into different pods in production, to avoid issues where a buggy background job could take down the API. Cloud-native Infrastructure All our services are containe