Posted on

Manage Azure Event Hubs With Azure Service Operator on Kubernetes

Azure Service Operator is an open source project to help you provision and manage Azure services using Kubernetes. Developers can use it to provision Azure services from any environment, be it Azure, any other cloud provider, or on-premises — Kubernetes is the only common denominator!

It can also be included as a part of CI/CD pipelines to create, use and tear down Azure resources on-demand. Behind the scenes, all the heavy lifting is taken care of by a combination of Custom Resource Definitions which define Azure resources and the corresponding Kubernetes Operator(s) which ensure that the state defined by the Custom Resource Definition is reflected in Azure as well.

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.

Posted on

EnMasse: Basic Setup and Usage on Kubernetes

In this article, we are are going to learn and take a deep dive into EnMasse basics.

EnMasse is an open-source project for managed, self-service messaging on Kubernetes and Openshift. EnMasse can run on your own infrastructure or in the cloud and simplifies running a messaging infrastructure for your organization.

Posted on

Architectures for Distributed, Hybrid, Edge, and Global Apache Kafka

Multi-cluster and cross-data center deployments of Apache Kafka have become the norm rather than an exception. Learn about several scenarios that may require multi-cluster solutions and see real-world examples with their specific requirements and trade-offs, including disaster recovery, aggregation for analytics, cloud migration, mission-critical stretched deployments and global Kafka.

Key Takeaways for Multi Data Center Kafka Architectures

  • In many scenarios, one Kafka cluster is not enough. Understand different architectures and alternatives for multi-cluster deployments.
  • Zero data loss and high availability are two key requirements. Understand how to realize this, including trade-offs.
  • Learn about features and limitations of Kafka for multi-cluster deployments- Global Kafka and mission-critical multi-cluster deployments with zero data loss and high availability became the normal, not an exception.
  • Learn about architectures like stretched cluster, hybrid integration and fully-managed serverless Kafka in the cloud (using Confluent Cloud), and tools like MirrorMaker 2, Confluent Replicator, Multi-Region Clusters (MRP), Global Kafka, and more.

Slide Deck

 

Posted on

How to Implement Producer/Consumer With System.Threading.Channels

What’s this “Producer/Consumer” thing? It’s around us, everywhere. Every time you see some kind of workflow with multiple serial steps, that’s an example. A production line in a car factory, a fast-food kitchen, even the postal service.

So why do we care about it? Well, that’s easy: in almost every piece of software we write, there’s a pipeline to fulfill. And as every pipeline, once a step is completed the output is redirected to the next one in line, freeing up space for another execution.

Posted on

Turn Alexa into Your Personal Messaging Assistant

Learn more about your Alexa devices!

Do you want to have an assistant to check for unread SMS messages, read them aloud and let you reply to the sender without the need of using your phone or touching a single button on a device? If yes, go on to read this article as we will discuss developing an application to perform such a task.

Posted on

Apache Kafka In Action

Challenges and Limitations in Messaging

Messaging is a fairly simple paradigm for the transfer of data between applications and data stores. However, there are multiple challenges that are associated with it:

  1. Limited scalability due to a broker becoming a bottleneck.
  2. Strained message brokers due to bigger message size.
  3. Consumers being in a position to consume the messages at a reasonable rate.
  4. Consumers exhibiting non-fault tolerance by making sure that messages consumed are not gone forever.

Messaging Limitations Due to:

High Volume

Messaging applications are hosted on a single host or a node. As a result, there is a possibility of the broker becoming the bottleneck due to a single host or local storage.

Posted on

A Covert Channel Over the Telegram

We used to think of Telegram as a reliable and secure transmission medium for messages of any sort. But under the hood, it has a rather common combination of a- and symmetric encryptions. Where’s fun in that? And why would anyone trust their messages to the third-party anyway?

Covert Channels

There are many workarounds to transmit data between two users avoiding direct contact. You can use middlemen, crypto-, and steganography methods, broadcasting relay networks, and other extensions of existing protocols. But sometimes, it’s useful being able to establish secure contact using only officially documented features. Or, as one should say, set up a covert channel.

Posted on

How to Set up CodeReady Studio 12 (Integration)

The release of the latest Red Hat developer suite version 12 brings with it a name change from Red Hat JBoss Developer Studio to Red Hat CodeReady Studio.

The focus here is not on the Red Hat CodeReady Workspaces, a cloud and container development experience, but on the locally installed developers studio. The new release brings with it the questions around how to get started with the various Red Hat integration, data, and process automation product toolsets that are not installed out of the box.

Posted on

An Overview of the Team Messaging App Security, Increasing Concerns and Emerging Solutions

Team messaging apps are no longer confined to small teams but have to facilitate global enterprise level adoption with multiple teams collaborating real time. Globally distributed teams transferring considerable size of data has widened the threat landscape considerably and many experts are also expressing significant concerns over it. Nemertes report indicated clearly that security concerns are one of the major constraints that are prohibiting many enterprises to adopt team collaboration, especially the ones dealing with private and mission-critical data.

Plenty of team messaging apps or team collaboration platforms are available in the market, such as Slack, Microsoft Teams, and Cisco Webex Teams, and each has its own strengths and weaknesses when it comes to security. The key to defending the enterprise’s collaborative environment and mission-critical data lies in the choice of the collaborative platform or the tool. First, we have to ask which them is the most suitable candidate capable of supporting the inherent workflow of your organization and has the most competent and fitting security system to match your enterprise’s operational style.

Posted on

The What, Why, and How of Unified Endpoint Management

IT management has become a department that exists in every business ecosystem, irrespective of verticals. Those who are responsible for taking care of IT management need to work around the clock to secure and maintain servers, computers, smartphones, tablets, iPads, IoT devices, virtual machines, and more. The technician alone is like a modern puppeteer controlling and manipulating all these devices from one central location in a unified way. This is why a unified endpoint management (UEM) ecosystem is crucial.

What Is Unified Endpoint Management?

Unified endpoint management is a process of managing and securing all of an organization's servers and devices from a unified console. Unified endpoint management is an evolution and combination of enterprise mobility management (EMM), mobile device management (MDM), and client management. UEM considers different devices and platforms to bring cross-platform security and management to IT departments, thus enhancing the scope of device administration and data security.