Posted on

Leveraging CloudAMQP Within My Heroku-Based SaaS Solution

In the "Using Heroku to Quickly Build a Multi-Tenant SaaS Product" article, I documented the foundation for a new SaaS solution that I am building (initially for my sister-in-law) — utilizing the Heroku ecosystem. Using Heroku allowed me to deploy the app quickly, without having to worry about infrastructure, DevOps, scalability when the app gets popular, etc. The "Integrating Twilio Into My SaaS Solution In Heroku" publication provided an example of how easy it is to create a Twilio instance and integrate the solution into my Fitness-based SaaS solution. This current journey has resulted in a feature set that both trainers and their clients have been able to enjoy.

This article is going to focus on invoicing clients for services that have been performed and will utilize messaging solutions within the Heroku ecosystem. The goals of the invoice process are as follows:

Posted on

Autoscaling Your Kubernetes Microservice with KEDA

Recently, I've been having a look around at autoscaling options for applications deployed onto Kubernetes. There are quite a few emerging options. I decided to give KEDA a spin. KEDA stands for Kubernetes Event-Driven Autoscaling, and that's exactly what it does.

Introducing KEDA

KEDA is a tool you can deploy into your Kubernetes cluster which will autoscale Pods based on an external event or trigger. Events are collected by a set of Scalers, which integrate with a range of applications like:

Posted on

Building AMQP-Based Messaging Framework on MongoDB

Introduction

In any integration scenarios, messaging needs are inevitable. There are several messaging frameworks /tools/technology available today to chose from. Starting from old MQ we have come a long way to the world of open source-based technologies like Kafka, RabbitMQ, ActiveMQ, etc. Every other messaging frameworks came due to certain needs. With the growing trends of microservices, engineers are looking for more lightweight, independently deployable, and less costly options in the market. Every messaging framework comes with the baggage of additional infrastructure and maintenance headache. In one of my projects there has been a proposal to use the capped collection feature of MongoDB along with its tailable cursor as an alternative option to deploy any real messaging infrastructure. Now the question arises,

  • Is this option suitable for all kind of messaging needs?
  • Can it be a replacement of proper messaging framework like Kafka, RabbitMQ, etc.?
  • What are the pitfalls?

Not to mention that this feature of MongoDB is quite old and well-known in the market and you will find a lot of articles around it. However, I believe those articles have just shown the basic way of enabling it without going deep into it. A real messaging framework has lots of challenges than just making an asynchronous way of delivering the messages. In this series of articles, we will try to address them and see if we can really build some messaging infrastructure using MongoDB by considering all the needs of a messaging framework.