The BeeHive Architecture

Hello! Today I am going to propose a software architecture that supports unlimited number of plugable components. I am introducing the BeeHive architecture. Please feel free to provide your feedback and point out the problems. I would very much appreciate that.

Since I work mostly as a web application developer, I will describe the architecture pattern in terms of web application development, but the pattern can be well suited for desktop software development as well.

Motivation

I consider myself lucky, because within my short career span I have had the opportunity  to work with some great architects, had the opportunity to learn about some good architectures and also had the opportunity to design multiple small to medium scale systems from scratch.

The systems that I developed needed to be extensible and also needed to be maintainable and scalable at the same time. So, in almost all cases I used a hybrid architecture pattern.

  • For the extensibility I really liked Microkernel Architecture, which gives you the option to extend your solution and inject libraries at runtime.
  • For all the benefits it can provide, The Onion Architecture or The Clean Architecture.
  • And if the system becomes too big to manage it can adapt and effectively transform part of it to be a Microservice Architecture.

Funny though, I came to know the name of The Onion Architecture only recently.

So, eventually the pattern I used is a high level Microkernel with a low level Onion. It has a core components that loads one or more plugins while bootstraping and each of those component is built using onion architecture design principles.

Only now, I just came up with a fancy name 🙂 The BeeHive.

Where the name BeeHive comes from?

Even though it is a hybrid architecture, I prefer the name BeeHive because of how it behaves. Lets have a look a  Bee Hive at first –

  • A BeeHive is a swarm of bees, each of them has specific responsibilities.
  • Even though all of the bees are individuals, there is a clean work load distribution among them.
  • Some bees are more important than other bees.
  • A Queen Bee is the center for all and the hive cannot survive without her.
  • But being the center does not mean every communication has to go through the queen. Bees can communicate with each other with special signals. This reduces the everyday work load for the Queen itself.
  • If the Queen wants to banish an individual bee from the hive, the bee has nothing to do, but to leave.
  • If, one or many bees die, the hive still survives and continues to perform as if nothing happened and appoints new bees  to perform the same task. If, however, no suitable bee is found to take on the responsibility, the hive suffers.
  • If the hive, becomes too big, a new Queen bee arises and a new hive is formed somewhere else.

Well, there could be more, but you get the point. Now, we convert this to a feature of a software architectural pattern in the next section.

The BeeHive Architecture

Before we dive into details, I will summarize the targets that BeeHive tries to achieve –

This may sound like a marketing speech. I gotta sell it you know!

  • Development Friendly
    When I first tried to design my first ever system, the main focus point for me was always to be development friendly. A solution or system should be easy and small enough to kick it off within a few weeks but also will support ongoing development and be extensible in such a way that no matter what happens, it should be adaptive of future design decision. A architecture that is made to evolve over time.
  • Plug & Play
    Well, we did really hated the PS/2 mouse back in the old days, when we had to restart the whole machine, because we just plugged in a new mouse! Don’t we love the USB mouse and the point that it can be plugged in and works, just like that!Well, a large system should be like that, isn’t it?
    Why do we have to deploy the hole solution just to add a new feature to it? or just to add a new payment gateway?
    What it we want to turn off some features? I know, I know, micro-services. But what it we don’t have a big enough system or more importantly budget to support micro-services?
  • On Demand Micro-services
    Wouldn’t it be better to have a system that can be converted to micro-services as we scale out and support the business get big? BeeHive is built almost exclusively to support that.

These are the few of the benefits that we an achieve with BeeHive. If you are reading this, you are a programmer or someone who understands how things work. You will see the benefits.

Lets get into the design.

The Design

Well, here is how it looks like on a very simple diagram –

BeeHive 3

As you would have guessed, yes it looks like a bee hive. For easy understanding and explanation, instead off considering bee’s, I am going to use hexagon, similar to a beehive cell.

  1. The Gray Hexagon at the center, is the queen or for us the core. The core hexagon has the following characteristics –
    1. Does not implement any concrete service or classes unless that is absolutely necessary for the purpose of bootstrapping or is a common component shared by one or more standard cell (the green ones). i.e. plugins.
    2. Is responsible for loading all other plugable components (plugins)
    3. Provides a medium for communication between the plugins.
    4. Is capable of turning on or off – any component, anytime. We will call it The CORE.
  2. The Green Hexagons,
    1. Each of these Hexagons are a concrete implementation of services.
    2. Each itself is implemented using the Onion Architecture and has multiple layers of implementations.
    3. They are independent of one another and any single one does not even know about the existence of others. This is a very important constraint for BeeHive.

The Evolution

BeeHive is always ready to evolve, from the day it is created. If our monolith looks big enough we can easily break it down to multiple micro-services and it looks something like this –

Here, we have copied the core and move 2 individual modules together and formed a second hive which is completely separate from the first one. An now each individual hive can grow itself and again if we have too big, we can deconstruct again. Since, each concrete modules never knew about the existence of other modules, there is not need to change anything else. May be some proxies to connect these services and that is all. We will see them when we see an example.

In the following post we will see it in action.

Advertisements

I would like to say something ...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.