Cloud – TechSpark

Background

It always helps to know the background of a word, and how it made it into a software design pattern. Like most of the patterns, the bulkhead design pattern is also inspired from other more established engineering disciplines.

The ship you see above, with vertical lines dividing it, those are called bulkheads. These are some of the reasons ships are built that way (from Wikipedia)…

Increase the structural rigidity of the vessel
Divide functional areas into rooms
Create watertight compartments that can contain water in case of a hull breach or other leak.
Some bulkheads and decks are fire-resistant to achieve compartmentalization, a passive fire protection measure

Usage in Software

I believe that background makes it easier to understand Bulkhead design pattern in software.

With modern microservices architecture many applications/services are broken into different domains. This makes adopting to this pattern easier. Look at the following example, how different instances of the same API are provisioned for different clients.

Failure in Client 1 instance has not affected the other clients.

Another example where different processes are consuming messages from different instances of queues. Failure in one is not cascading and bringing down the whole system

Some would say this makes more sense in multi-tenant applications, where a tenant is using dedicated services in isolation. The whole concept comes down to the basic principle of isolation for resiliency. How you isolate resources varies based on the domain.

Using software, there are so many different ways to solve a problem. Varying acronyms and technical terms to confuse you, specially when you need to discuss it with a non-technical stakeholder.

Confused Season 3 GIF by The Simpsons - Find & Share on GIPHY

Let’s break it down and see if an analogy makes it any easier.

The requirement is to travel from point A to point B.

On-Premise is like building and maintaining your own car, you get the greatest control but it comes with total ownership cost as well.

IaaS (Infrastructure as a Service) you buy a car from a dealer and they offer you to maintain it with regular capped priced servicing.

PaaS (Platform as a Service) in this case you are leasing a car and making monthly payments, you don’t own the car but some responsibility of the car is still with you.

Serverless, you just rent a car, you do it when you need it and return it when you are done. If you end-up using it a lot, it might actually cost you more than PaaS

SaaS(Software as a Service) this case you don’t even want to drive, just call an Uber/Lyft whenever you need it, no ownership cost involved. Maybe this one doesn’t fit quite right, because thats not how most of the SaaS offerings work. Another way to think of it is like having a monthly bus pass.

But if you go into details of each of the analogies it might not align perfectly, which is ok.

The point is to use this for meaningful discussions with someone, where you cannot go into technical details.