DEV Community: Gaurav

Transforming Engineering Culture in a 300-Person Company

Gaurav — Thu, 06 Nov 2025 18:15:17 +0000

🚀 Transforming Engineering Culture in a 300-Person Company

A few months ago, I worked with a small company (~300 people) that had reached a breaking point in its tech journey.

Here’s what I found when I joined:

No defined SDLC — ideas went straight to production.
Every client had a custom version of the product.
No documentation, no tests, no CI/CD.
Legacy code everywhere.
Engineers had been there 8–10 years, never exposed to new tech.

The result?
Tech silos.
Fear of change.
Zero innovation.
No shared vision of the future.

🧩 The Real Problem

The issue wasn’t people it was the way of working.
To fix that, we needed to reshape both culture and process without breaking the company’s rhythm.

So we used a blend of top-down clarity and bottom-up ownership.

🔝 Top-Down Changes (Leadership-Led)

Defined a simple product goal: move from per-client customizations to a single configurable platform.
Introduced lightweight engineering standards (code reviews, testing, CI/CD, README required).
Started a small Architecture Circle of 4 senior engineers for shared decision-making.
Modernized one critical service instead of rewriting everything.
Brought in 2 engineers from outside to spark new ideas.

⚙️ Bottom-Up Movement (Engineer-Led)

Picked one pilot team to adopt the new process → 30% faster release in 2 months.
Created Backend, DevOps, and QA Guilds — open to anyone who wanted to learn and share.
Made documentation part of “definition of done.”
Celebrated every small win company wide.
Paired legacy engineers with modern stack developers — building trust and skill transfer.

📈 The 12-Month Journey

Discovery – Understand what’s broken.
Pilot – Test the new process.
Foundation – Scale what works.
Culture – Build internal momentum.
Sustain – Make it habit.

By the end, the company wasn’t “perfect” — but it was healthier:

Releases were faster and stable.
Documentation became normal.
Knowledge silos started breaking.
People began suggesting improvements instead of resisting them.

💡 My Biggest Takeaway

You don’t need a big budget or 100 new hires to transform.
You need:

Clear direction (from leadership)
Empowered teams (from the ground)
Consistent small wins

Change doesn’t happen by mandate — it happens by momentum.

👉 Have you seen a similar cultural shift in your company?
What worked — top-down leadership, or bottom-up drive?

EngineeringCulture #Leadership #SoftwareDevelopment #Transformation #Agile #DevOps #ContinuousImprovement

Decode Bridge Pattern

Gaurav — Sun, 02 Jan 2022 06:51:49 +0000

When to use

When run-time binding of the implementation is required.
To support a proliferation of classes resulting from a coupled interface and numerous implementations,
To share an implementation among multiple objects and to map orthogonal class hierarchies.

Intent

Decouple an abstraction from its implementation so that the two can vary independently.

Structure

Implementation

The Bridge pattern is an application of the old advice, "prefer composition over inheritance". It becomes handy when you must subclass different times in ways that are orthogonal with one another. Say you must implement a hierarchy of colored shapes. You wouldn't want to subclass Shape with Rectangle and Circle and then subclass Rectangle with RedRectangle, BlueRectangle and GreenRectangle and the same for Circle. You would prefer to say that each Shape has a Color and to implement a hierarchy of colors, and that is the Bridge Pattern.

1 Design a color-oriented interface that is minimal, necessary, and sufficient. Its goal is to decouple the abstraction from the color. Define a derived class of that interface for each color.

package com.gaurav.dp.bridge;

public interface Color {

  void applyColor();

}

2 Define a derived class of that interface for each color.

package com.gaurav.dp.bridge;

public class Red implements Color {

  public void applyColor() {

    System.out.println("Red");

  }

}

package com.gaurav.dp.bridge;

public class Green implements Color {

  public void applyColor() {

    System.out.println("Green");

  }

}

3 Create the abstraction base class that "has a" color object and delegates the color-oriented functionality to it.

package com.gaurav.dp.bridge;

public abstract class Shape {

  protected Color color;

  public Shape(Color c) {
    color = c;
  }

  public abstract void draw();

}

4 Define specializations of the abstraction class.

package com.gaurav.dp.bridge;

public class Circle extends Shape {

  public Circle(Color color) {
    super(color);
  }

  public void draw() {
    System.out.print("Draw Circle in ");
    color.applyColor();
  }

}

package com.gaurav.dp.bridge;

public class Rectangle extends Shape {
  public Rectangle(Color color) {
      super(color);
  }

  public void draw() {
    System.out.print("Draw Rectangle in ");
    color.applyColor();
  }

}

package com.gaurav.dp.bridge;

public class Square extends Shape {

  public Square(Color color) {
      super(color);
  }

  public void draw() {
    System.out.print("Draw Square in ");
    color.applyColor();
  }

}

5 The Client code. The Bridge Pattern allows one to mix and match without needing to create a rigid hierarchy.

package com.gaurav.dp.client;

import com.gaurav.dp.bridge.Circle;
import com.gaurav.dp.bridge.Green;
import com.gaurav.dp.bridge.Rectangle;
import com.gaurav.dp.bridge.Red;
import com.gaurav.dp.bridge.Shape;
import com.gaurav.dp.bridge.Square;

public class BridgeClient {

  public static void main(String[] args) {

    Shape[] shapes = { 
        new Circle(new Red()), 
        new Square(new Red()),
        new Rectangle(new Green()) 
        };

    for (Shape shape : shapes) {
      shape.draw();
    }

  }

}

Output

[output]
Draw Circle in Red
Draw Square in Red
Draw Rectangle in Green

Benefits

Decoupling allows us to choose the implementations at runtime.
Compile-time dependencies on the implementation are eliminated.
Improved extensibility and flexibility.

Drawbacks

The delegation from the Entities to the Behaviors can degrade performance.

Real World Examples

The display of different image formats on different operating systems is a good example of the Bridge pattern. You might have different image abstractions for both jpeg and png images. The image structure is the same across all operating systems, but the how it's viewed (the implementation) is different on each OS. This is the type of decoupling that the Bridge pattern allows.

Software Examples

UnifiedPOS or UPOS that provides vendor-neutral APIs for numerous Point Of Sale peripherals.
OS specific Device Driver interfaces that define common standards for various devices.

Decode Adapter Pattern

Gaurav — Fri, 26 Nov 2021 18:37:59 +0000

When to use

To wrap an existing class with a new interface.
To perform impedance matching

Intent

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Components

Target - defines the domain-specific interface that Client uses.
Adapter - adapts the interface Adaptee to the Target interface.
Adaptee - defines an existing interface that needs adapting.
Client - collaborates with objects conforming to the Target interface.

Structure

Before
After

Implementation

Assume that you have an e-commerce application which is serving your customers for a long time. This e-commerce application is using a Legacy Order Management System (OMS). Due to the high maintenance cost and degraded performance of the legacy OMS software, you have decided to use a cheap and efficient OMS software which is readily available in the market. However, you realize that the interfaces are different in the new software and it requires a lot of code change in the existing e-commerce application.

Adapter design pattern can be very useful in these situations. Instead of modifying your e-commerce application to use the new interfaces, you can write a 'wrapper' class that acts as a bridge between your e-commerce application and the new OMS software. With this approach, the e-commerce application can still use the old interface.

Adapter design pattern can be implemented in two ways. One using the inheritance method (Class Adapter) and second using the composition (Object Adapter). The following example depicts the implementation of Object adapter.

1 Below is the code that uses the LegacyOMS.

package com.gaurav.adapter;

public class Item {
  private String name;
  private double price;

  public Item(String name, double price) {
    this.name = name;
    this.price = price;
  }

  public String getName() {
    return name;
  }

  public double getPrice() {
    return price;
  }
}

package com.gaurav.adapter;

public class Payment {

  public String type;
  public double amount;

  public Payment(String type, double amount) {
    super();
    this.type = type;
    this.amount = amount;
  }

  public void pay() {
    System.out.println(type + " " + amount + "$");
  }

}

package com.gaurav.adapter;

import java.util.ArrayList;
import java.util.List;

public class LegacyOMS {

  /* The Legacy OMS accepts input in XML format */

  List cart = new ArrayList();
  List payments = new ArrayList();

  public void addItem(Item itemXml) {
    cart.add(itemXml);
    System.out.println(itemXml.getName() + " " + itemXml.getPrice());
  }

  public void makePayment(Payment paymentXml) {
    payments.add(paymentXml);
    paymentXml.pay();
  }
}

2 The client code.

package com.gaurav.client;

import com.gaurav.adapter.Item;
import com.gaurav.adapter.OMSAdapter;
import com.gaurav.adapter.Payment;

public class AdapterClient {

  public static void main(String[] args) {

    /* Create an order and add items */

    LegacyOMS oms = new LegacyOMS();

    oms.addItem(new Item("Italian Pizza", 6.99));
    oms.addItem(new Item("Wine", 9.99));
    oms.addItem(new Item("Beer", 5.99));
    oms.addItem(new Item("Red Apple", 1.49));
    oms.addItem(new Item("Almonds", 11.99));

    System.out.println("---------------------------------");
    /* Create payment and make payment */
    oms.makePayment(new Payment("CASH", 20.00));
    oms.makePayment(new Payment("CREDIT", 10.00));
    oms.makePayment(new Payment("DEBIT", 10.00));
    System.out.println("---------------------------------");

  }
}

3 When the OMS needs to be swapped, you can simply create an Adapter class with same interface that the client uses. This adapter/wrapper class "maps" the client interface to the adaptee (New OMS) interface.

package com.gaurav.adapter;

import java.util.ArrayList;
import java.util.List;

public class NewOMS {

  /* The new OMS accepts input in JSON format */

  List cart = new ArrayList();
  List payments = new ArrayList();

  public void addToBasket(Item itemJson) {
    cart.add(itemJson);
    System.out.println(itemJson.getName() + " " + itemJson.getPrice());
  }

  public void pay(Payment paymentJson) {
    payments.add(paymentJson);
    paymentJson.pay();
  }
}

package com.gaurav.adapter;

public class OMSAdapter {

  /* Object Adapter uses composition */
  private NewOMS newOMS;

  public OMSAdapter() {
    newOMS = new NewOMS();
  }

  public void addItem(Item item) {
    convertXmlToJson(item);
    newOMS.addToBasket(item);
  }

  public void makePayment(Payment p) {
    convertXmlToJson(p);
    newOMS.pay(p);
  }

  /* The new OMS accepts only Json input.
   * Convert the client requests from XML to Json*/
  private void convertXmlToJson(Object o) {
    System.out.println("Converted from XML to JSON");
  }
}

4 The new client code. The client interacts in the same way as before.

package com.gaurav.client;

import com.gaurav.adapter.Item;
import com.gaurav.adapter.OMSAdapter;
import com.gaurav.adapter.Payment;

public class AdapterClient {

  public static void main(String[] args) {

    /* Create an order and add items */

    //LegacyOMS oms = new LegacyOMS();
    /* Use Adapter class with the same interface */
    OMSAdapter oms = new OMSAdapter();

    oms.addItem(new Item("Italian Pizza", 6.99));
    oms.addItem(new Item("Wine", 9.99));
    oms.addItem(new Item("Beer", 5.99));
    oms.addItem(new Item("Red Apple", 1.49));
    oms.addItem(new Item("Almonds", 11.99));

    System.out.println("---------------------------------");
    /* Create payment and make payment */
    oms.makePayment(new Payment("CASH", 20.00));
    oms.makePayment(new Payment("CREDIT", 10.00));
    oms.makePayment(new Payment("DEBIT", 10.00));
    System.out.println("---------------------------------");

  }
}

Output

[output]
Italian Pizza   6.99
Wine            9.99
Beer            5.99
Red Apple       1.49
Almonds        11.99
---------------------------------
CASH    20.0$
CREDIT  10.0$
DEBIT   10.0$
---------------------------------

Benefits

Class adapter can override adaptee's behavior.
Objects adapter allows a single adapter to work with many adaptees.
Helps achieve reusability and flexibility.
Client class is not complicated by having to use a different interface and can use polymorphism to swap between different implementations of adapters.

Drawbacks

Object adapter involves an extra level of indirection.

Real World Examples

Power adapters
Memory card adapters

Software Examples

Wrappers used to adopt 3rd parties libraries and frameworks.

Java SDK Examples

java.util.Arrays asList()
java.util.Collections list()
java.util.Collections enumeration()
java.io.InputStreamReader(InputStream) (returns a Reader)
java.io.OutputStreamWriter(OutputStream) (returns a Writer)

Want to discuss more
Lets have a Coffee

Decode Singleton Pattern

Gaurav — Sun, 14 Nov 2021 05:57:15 +0000

When to use

Application needs “only one instance” of a class.
To have complete control over the instance creation.

Intent

Ensure a class has only one instance, and provide a global point of access to it.

Components

Singleton Class

Structure

Implementation

Create a Singleton class with a static instance and a private constructor. Provide a static method to allow access to this 'only' instance.

1 Create a Singleton Class

package com.gaurav.singleton;

public class Singleton {

  /* the singleton obj */
  private static Singleton instance = null;

  /* private constructor to avoid
     external instantiation of this class */
  private Singleton() {
  }

  /* method to get the singleton obj */
  public static Singleton getInstance() {
    if (instance == null) {
      synchronized (Singleton.class) {
        /* double checked locking */
        if (instance == null) {
          instance = new Singleton();
        }
      }
    }
    return instance;
  }

  public void printObj() {
    System.out.println("Unique Id of the obj: "
    + System.identityHashCode(this));
  }

}

2 Access the singleton instance

class Demo {

  public static void main(String[] args) {
    Singleton obj1 = Singleton.getInstance();
    obj1.printObj();
    Singleton obj2 = Singleton.getInstance();
    obj2.printObj();
  }

}

Output

Unique Id of the obj: 1916222108
Unique Id of the obj: 1916222108

Benefits

Controlled instantiation
Supports both EAGER and LAZY initializations
Singletons can be converted to Multitons (to support limited number of instances identified by keys)

Drawbacks

Singleton is often seen as 'not-so-good' design as it resembles global variables
Special handling is required if the Singleton object needs to be deleted
Singletons that maintain global state may cause issues

Real World Examples

The Office of the President (there can be only one President at any given time)

Software Examples

Logger classes
Window Manager
Printer Spooler

Java SDK Examples

java.lang.Runtime.getRuntime( )
java.awt.Toolkit.getDefaultToolkit( )
java.awt.Desktop.getDesktop( )
java.util.logging.LogManager.getLogManager( )
java.lang.System#getSecurityManager( )

Want to discuss more
Lets have a Coffee

Select Right Aurora DB Instance 😎

Gaurav — Wed, 03 Nov 2021 12:39:04 +0000

The Factors

Back of envelope calculation for storage required (based on inputs from product requirements) . Aurora scales automatically so less of an issue.
Read scaling - Back of envelope no calculation for # of reads per sec - can be handled by adding read replicas.
Write scaling - In single-primary mode - there is a single writer DB . This can be the main factor for choosing the db instance.
Estimate the number of write connections needed per second . and pick the db instance based on the connection limits (keeping a factor for connection pooling) -
Also a guesstimate for the working set of data needed to be pulled into the memory for things like sorting/filtering etc will be a factor. The limits are mentioned in the above page.
This can only be a starting point . You should prioritise perf testing at a time your app is relatively stable to benchmark semi-realworld load. More often than not perf is constraint than storage.
(also benchmark reports in aws are highly optimistic, you mostly will not be able to achieve these results in your environment)
AWS

An example of how we approached (Simplified)

Back of the envelope calculation for storage

Assuming we will have total 10,00,000 users .
Each user record in DB will have - at max 10 fields.
Each field = max 1 kb (1000char) => Each User record = 10kb
So Total storage needed = 10,00,000 kb = 10 GB

Read/Write Ratio/concurrency

The DB will be read heavy database. A customer will change password may be once a month but login multiple times.

DocumentDB tops out at a maximum database size of 64TB and 4,500 concurrent connections per instance. DocumentDB supports a single primary node for writes and up to 15 replicas within a single Amazon region.That means with 15 replicas DocumentDB can handle 15 * 4500(max) = 67500 concurrent connection.That means some connections will be waiting in the connection pool.However , these limits may be adjusted - we need to check with AWS.

Decode Prototype Pattern

Gaurav — Wed, 03 Nov 2021 12:24:59 +0000

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

When to use

To improve the performance when object creation is costly and time consuming.
To simplify and optimize multiple objects creation that will have mostly the same data

Intent

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Components

A class that implements Cloneable interface (public)

Structure

Implementation

Most of the cloud platforms behave like Prototype pattern to create instances quickly upon requests. This is achieved with the help of pre-installed Machine Images. When a customer wants a Windows or Linux instance, the cloud software just loads the already created machine image on to a server hardware (rather than going through the complete installation process). This saves a lot of time.

1 Create a base machine image by installing the specified OS and antivirus software. Provide a 'clone' method so that client can create an object without using a time consuming 'new' operator every time.

package com.gaurav.prototype;

public class MachineImage implements Cloneable {

  StringBuilder image;

  public MachineImage(String os, String antivirusSW) {
    image = new StringBuilder();
    image.append(os)
         .append(" + " + antivirusSW);
  }

  private MachineImage(String sw) {
    image = new StringBuilder(sw);
  }

  public void install(String sw) {
    image.append(sw);
  }

  public void printSw() {
    System.out.println(image);
  }

  @Override
  public MachineImage clone()
      throws CloneNotSupportedException {
    return new MachineImage(this.image.toString());
  }
}

2 The client code. The client creates a base image and clones it to create other images.

package com.gaurav.client;

import com.gaurav.prototype.MachineImage;

public class PrototypeClient {
  public static void main(String [] args)
      throws CloneNotSupportedException {

    /* Create base Machine Images */
    MachineImage linuxVM= new MachineImage("Linux", "Symantec");
    MachineImage windowsVM = new MachineImage("Windows", "MaAfee");

    /* Clone Linux VM and Install Web Server */
    MachineImage webServer= linuxVM.clone();
    webServer.install(" + Web Server S/W");

    /* Create a copy of the Web Server and
     * install Application server on top of it */
    MachineImage webAppServer = webServer.clone();
    webAppServer.install(" + App Server S/W");

    /* Clone Linux VM and Install DB Server */
    MachineImage dbServer= linuxVM.clone();
    dbServer.install(" + Database Server S/W");

    /* Create a test machine from Windows Image */
    MachineImage testMachine= windowsVM.clone();

    System.out.print("Web Server Configuration: ");
    webServer.printSw();
    System.out.print("App Server Configuration: ");
    webAppServer.printSw();
    System.out.print("DB Server Configuration: ");
    dbServer.printSw();
    System.out.print("Test Machine Configuration: ");
    testMachine.printSw();
  }
}

Output

[output]
Web Server Configuration: Linux OS + Antivirus S/W + Web Server S/W
App Server Configuration: Linux OS + Antivirus S/W + Web Server S/W + App Server S/W
DB Server Configuration: Linux OS + Antivirus S/W + Database Server S/W
Test Machine Configuration: Linux OS + Antivirus S/W

Benefits

Performance: Cloning (using MemberwiseClone) is considerably less expensive than creating a new object afresh (with new operator).
Objects can be cloned very dynamically, without any insistence on up-front instantiation. The first created object can be created at any time in the application execution, and further duplication can take place at any time ahead.

Drawbacks

Deep copy has to be handled carefully.

Real World Examples

Biological Cell splitting

Software Examples

Virtual Machine Images - Have one image per OS which has all the required s/w installed.
DVD duplication - Duplication of the master dvd to create several copies.

Java SDK Examples

java.lang.Object clone()

Hope you like it. Would love to hear your thoughts on this design pattern.

Want to discuss more
Lets have a Coffee

Decode Factory Pattern

Gaurav — Sun, 24 Oct 2021 05:40:41 +0000

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

When to use

To avoid dealing with inconsistent object when the object needs to be created over several steps.
To avoid too many constructor arguments.
To construct an object that should be immutable.
To encapsulate the complete creation logic.

Intent

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Components

An Interface (or) Abstract class (public)
Set of implementation subclasses (private)
A Factory Method (public)

Structure

Implementation

1 Create an interface. Clients can code for this interface without worrying about the internal implementation..

package com.gaurav.factorymethod;

public interface Vehicle {
  void design();
  void manufacture();
}

2 Create a set of implementation subclasses. Constructors are protected to prohibit instantiations in clients modules using the 'new' operator.

package com.gaurav.factorymethod;

public class Car implements Vehicle {

  Car() {
    /* constructor is protected.
       clients need to use the factory method */
  }

  @Override
  public void design() {
    System.out.println("Designing Car");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Car");
  }

}

package com.gaurav.factorymethod;

public class Truck implements Vehicle {

  Truck() {
    /* constructor is protected.
       clients need to use the factory method */
  }

  @Override
  public void design() {
    System.out.println("Designing Truck");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Truck");
  }

}

package com.gaurav.factorymethod;

public class Motorcycle implements Vehicle {

  Motorcycle() {
    /* constructor is protected.
       clients need to use the factory method */
  }

  @Override
  public void design() {
    System.out.println("Designing Motorcycle");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Motorcycle");
  }

}

3 Create a class with method 'getVehicle()'. Clients can use this method to create an object instead of using 'new' operator.

package com.gaurav.factorymethod;

public class VehicleFactory {

  /* This is the factory method exposed to the client.
     Client requests for an object by passing the type.
     Client does not need to know about which & how object
     is created internally.
     */
  public Vehicle getVehicle(String vehicleType)
      throws VehicleTypeNotFoundException {

    if (vehicleType == null) {
      return null;
    }

    Vehicle vehicle = null;

    switch (vehicleType) {
      case "car":
        vehicle = new Car();
        break;
      case "truck":
        vehicle = new Truck();
        break;
      case "motorcycle":
        vehicle = new Motorcycle();
        break;
      default:
        throw new VehicleTypeNotFoundException();
    }

    return vehicle;
  }

}

4 The client code. Client knows only the factory method and the interface. Client code does not use 'new' hence decoupled from implementation.

package com.gaurav.client;

import java.util.Scanner;

import com.gaurav.factorymethod.Vehicle;
import com.gaurav.factorymethod.VehicleFactory;
import com.gaurav.factorymethod.VehicleTypeNotFoundException;

public class FactoryMethodClient {

  public static void main(String[] args) {

    Scanner in = new Scanner(System.in);
    String vehicleType = in.nextLine().toLowerCase();

    /* Create a factory instance */
    VehicleFactory factory = new VehicleFactory();

    try {

      /* Create an appropriate vehicle based on the input */
      Vehicle vehicle = factory.getVehicle(vehicleType);

      /* Design and manufacture the vehicle */
      vehicle.design();
      vehicle.manufacture();

    } catch (VehicleTypeNotFoundException e) {
      System.out.println("Invalid vehicle type entered!");
    }

    in.close();
  }

}

Output

[input1]
    MotorCycle
[output1]
    Designing Motorcycle
    Manufacturing Motorcycle

[input2]
    Car
[output2]
    Designing Car
    Manufacturing Car

[input3]
    Bus
[output3]
    Invalid vehicle type entered!

Benefits

Loose coupling allows changing the internals without impacting the customer code
Factory method provides a single point of control for multiple products
Number of instances and their reusability can be controlled with Singleton or Multiton

Drawbacks

An extra level of abstraction makes the code more difficult to read.

Real World Examples

Renting Vehicles. Customer needs to specify only the type of vehicle (car, truck, etc.) that is needed. Customer need not know about the internal details of the vehicle.

Software Example

Memcache
Filecache
Code for SQL standard without worrying about the underlying DB

Java SDK Examples

java.util.Calendar.getInstance()
java.util.ResourceBundle.getBundle()
java.text.NumberFormat.getInstance()
java.nio.charset.Charset.forName()
java.util.EnumSet.of()
javax.xml.bind.JAXBContext.createMarshaller()

Difference between Abstract factory and Factory pattern?

TS;MR:
The Abstract Factory is a set of Factory Methods.

TL;DR:
With the Factory pattern, you produce instances of implementations (Apple, Banana, Cherry, etc.) of a particular interface -- say, IFruit.

With the Abstract Factory pattern, you provide a way for anyone to provide their own factory. This allows your warehouse to be either an IFruitFactory or an IJuiceFactory, without requiring your warehouse to know anything about fruits or juices.

Hope you like it. Would love to hear your thoughts on this design pattern.

Want to discuss more
Lets have a Coffee

Disaster Recovery Maturity Model

Gaurav — Fri, 22 Oct 2021 20:01:21 +0000

Points to be consider while setting up DRMM.

Catalog your applications:

Make sure you are aware of all applications that exist in the ecosystem and that they have assigned owners along with their contact information. Also, make sure that the application owner is made aware of their responsibilities E.g. in case of an emergency, they or whoever they nominate on their behalf may be contacted for remediation.

Document standard recovery procedures:

For each application, make sure recovery procedures are documented and more importantly, well understood
Define a strategy: Make sure that the RPO and RTO for each application is defined i.e. a backup is defined.

Categorize applications into resilience categories:

Not all applications are created equal. Define resilience categories and slot each application into one of them. For e.g. the payments application for a credit card company may be more important to recover than a reporting application. Be aware of legal and compliance regulations for your domain. DR strategies come at a cost. An active-active deployment will likely cost more money than a cold standby. Make sure your business stakeholders are aware and participate actively in this categorisation process.

Practice!:

Ideally all the time as part of your automated deployment pipeline. Take your DR drills seriously.

Can you really recover if things start going south?

Automate!:

Infra as Code, automated configuration and secrets management, automated deployment, 'nuff said!
AWS' Well Architected Framework has a reliability pillar which talks about planning for disaster recovery that you may find useful.

Do maturity Assessment:

Areas to consider for maturity assessment (AWS context):

Applicable across all inventory -- application, network, infra, CI, storage, test-environments, etc. Any system that gets used today, needs a DR strategy -- including test systems, CI/CD, toggle/configuration stores, doc repos, etc.. because they ALL play an important role in keeping the Software running and Development process (machinery that creates software) running. (This is borrowed from Security thinking, where keeping non-Prod systems is very important too).
Are components in one AZ, multi-AZ, or cross Region (is cross region level complexity needed?)
For their business what are the RPO/RTO requirements? Each component then needs to be assessed against those goals -- to get a "heat map" for the whole inventory -- where are we today, vs where do we want to be, vs how will we get there, and what are the priorities? The RPO/RTO goals are usually not the same for all components, since some sub-systems are more critical than others.
What is the level of automation (to support the RPO/RTO objectives)?
How frequently is the automation tested?
Do they have automation/checks in place that can detect new features/configurations that are no longer meeting RPO/RTO objectives, because DR/Backup/Restore scripts have become out-of-date/obsolete? ("DR Automation obsolescence drift"). Think Poka-Yokes.

Decode Builder Design Pattern

Gaurav — Mon, 18 Oct 2021 18:45:34 +0000

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

When to use

To avoid dealing with inconsistent object when the object needs to be created over several steps.
To avoid too many constructor arguments.
To construct an object that should be immutable.
To encapsulate the complete creation logic.

Intent

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Components

The Builder class specifies an abstract interface for creating parts of a Product object.
The ConcreteBuilder constructs and puts together parts of the product by implementing the Builder interface. It defines and keeps track of the representation it creates and provides an interface for saving the product.
The Director class constructs the complex object using the Builder interface.
The Product represents the complex object that is being built.

Structure

Implementation

1 Define the Product (House) that gets assembled in the builder pattern.

package com.gaurav.builder;

/* The house is the object that gets assembled in the builder pattern. */
public class House {

  private String floorType;
  private String wallType;
  private String roofType;

  public String getFloorType() {
    return floorType;
  }

  public void setFloorType(String floorType) {
    this.floorType = floorType;
  }

  public String getWallType() {
    return wallType;
  }

  public void setWallType(String wallType) {
    this.wallType = wallType;
  }

  public String getRoofType() {
    return roofType;
  }

  public void setRoofType(String roofType) {
    this.roofType = roofType;
  }

  public String toString() {
    return new String("\nConstructing House \n FloorType: " + floorType
        + "\n WallType:  " + wallType + "\n RoofType:  " + roofType );
  }
}

2 Define the Builder interface (or abstract class) along with Concrete Builders. The Builder interface contains methods for the step by step construction of the product. It also has a build method for retrieving the product object.

package com.gaurav.builder;

public interface HouseBuilder {

  public HouseBuilder buildFloor();
  public HouseBuilder buildWall();
  public HouseBuilder buildRoof();
  public House build();

}

3 Concrete Builders implement the Builder interface. A Concrete Builder is responsible for creating and assembling a Product object. Different Concrete Builders create and assemble Product objects differently.

package com.gaurav.builder;

public class ConcreteHouseBuilder implements HouseBuilder {

  private House house;

  public ConcreteHouseBuilder() {
    house = new House();
  }

  public HouseBuilder buildFloor() {
    house.setFloorType("concrete");
    return this;
  }

  public HouseBuilder buildWall() {
    house.setWallType("concrete");
    return this;
  }

  public HouseBuilder buildRoof() {
    house.setRoofType("concrete");
    return this;
  }

  public House build() {
    return house;
  }

}


package com.gaurav.builder;

public class WoodenHouseBuilder implements HouseBuilder {

  private House house;

  public WoodenHouseBuilder() {
    house = new House();
  }

  public HouseBuilder buildFloor() {
    house.setFloorType("wood");
    return this;
  }

  public HouseBuilder buildWall() {
    house.setWallType("wood");
    return this;
  }

  public HouseBuilder buildRoof() {
    house.setRoofType("wood");
    return this;
  }

  public House build() {
    return house;
  }

}

4 A Director object is responsible for constructing a Product. It does this via the Builder interface to a Concrete Builder. It constructs a Product via the various Builder methods. The director class ensures that all the required operations are performed before the object is returned to the client in a 'consistent' state.

package com.gaurav.builder;

public class HouseBuildDirector {
  private HouseBuilder builder;

  public HouseBuildDirector(final HouseBuilder builder) {
    this.builder = builder;
  }

  public House construct() {
    /* call the necessary methods and return the consistent object*/
    return builder.buildFloor().buildWall().buildRoof().build();
  }

}

5 The client code. The Client uses different builder objects to create different types of products. However, the construction process is same.

package com.gaurav.client;

import com.gaurav.builder.ConcreteHouseBuilder;
import com.gaurav.builder.HouseBuildDirector;
import com.gaurav.builder.HouseBuilder;
import com.gaurav.builder.WoodenHouseBuilder;

public class BuilderClient {

  public static void main(final String[] arguments) {

    /* Construct a concrete house */
    HouseBuilder builder = new ConcreteHouseBuilder();
    HouseBuildDirector carBuildDirector = new HouseBuildDirector(builder);
    System.out.println(carBuildDirector.construct());

    /* Construct a wooden house */
    builder = new WoodenHouseBuilder();
    carBuildDirector = new HouseBuildDirector(builder);
    System.out.println(carBuildDirector.construct());
  }
}

Output
Constructing House 
 FloorType: concrete
 WallType:  concrete
 RoofType:  concrete

Constructing House 
 FloorType: wood
 WallType:  wood
 RoofType:  wood

Benefits

Construction process can be controlled by the director.
Useful when many operations have to be done to build an object.
Avoids Telescoping Constructor Pattern.

Drawbacks

Not suitable if a mutable object is required.

Real World Examples

Building a house - We need to tell the architect what all we want as part of the building. The Architect then designs and constructs the building. It will be handed over only when everything is implemented. We do not get a 'partially' built house (which is unsafe).

Java SDK Examples

java.lang.StringBuilder append()
java.lang.StringBuffer append()
java.nio.ByteBuffer put()
javax.swing.GroupLayout.Group addComponent()
java.lang.Appendable implementations

Hope you like it. Would love to hear your thoughts on this design pattern.

Decode Abstract Factory Design Pattern

Gaurav — Sun, 17 Oct 2021 19:38:03 +0000

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

When to use

To support families of related or dependent objects.
To encapsulate platform dependencies to make an application portable.
To prevent client code from using the 'new' operator.
To easily swap the underlying platform with minimal changes.

Intent

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Components

An Abstract Factory class (public)
Factory Implementations for various familes (protected)
Interfaces for various products (public)
Set of product implementations for various families (protected)

Structure

Implementation

1 Define interfaces for different types products/objects. Each family will have all these parts.

package com.gaurav.abstractfactory;

public interface Engine {

  public void design();
  public void manufacture();
  public void test();

}

package com.gaurav.abstractfactory;

public interface Tyre {

  public void design();
  public void manufacture();

}

2 Create sets of implementation subclasses for the above interfaces. Classes are access protected to prohibit instantiations in client modules using the 'new' operator.

package com.gaurav.abstractfactory;

class CarEngine implements Engine {

  @Override
  public void design() {
    System.out.println("Designing Car Engine");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Car Engine");
  }

  @Override
  public void test() {
    System.out.println("Testing Car Engine");
  }

}

package com.gaurav.abstractfactory;

class TruckEngine implements Engine {

  @Override
  public void design() {
    System.out.println("Designing Truck Engine");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Truck Engine");
  }

  @Override
  public void test() {
    System.out.println("Testing Truck Engine");
  }

}

package com.gaurav.abstractfactory;

class CarTyre implements Tyre {

  @Override
  public void design() {
    System.out.println("Designing Car Tyre");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Car Tyre");
  }

}


package com.gaurav.abstractfactory;

class TruckTyre implements Tyre {

  @Override
  public void design() {
    System.out.println("Designing Truck Tyre");
  }

  @Override
  public void manufacture() {
    System.out.println("Manufacturing Truck Tyre");
  }

}

3 Create a Abstract Factory class with factory method 'getFactory()'. Clients can use this method to get an object the required factory. This example uses both Singleton and Factory Method patterns for better design.

package com.gaurav.abstractfactory;

public abstract class Factory {

  /* Singleton Factory objects */
  private static Factory carFactory = null;
  private static Factory truckFactory = null;

  public abstract Engine getEngine();
  public abstract Tyre getTyre();

  /*
   * This is the factory method exposed to the client.
   * Client requests for a factory instance by passing the type.
   * Client does not need to know about which & how
   * object is created internally.
   */
  public static Factory getFactory(String vehicleType)
      throws UnknownVehicleException {

    if (vehicleType == null) {
      return null;
    }

    Factory factory = null;
    switch (vehicleType) {
      case "car":
        if (carFactory == null)
          carFactory = new CarFactory();
        factory = carFactory;
        break;
      case "truck":
        if (truckFactory == null)
          truckFactory = new TruckFactory();
        factory = truckFactory;
        break;
      default:
        throw new UnknownVehicleException();
    }

    return factory;
  }
}

4 Create Factory implementations. Classes are protected to prohibit direct access in client modules.

package com.gaurav.abstractfactory;

class CarFactory extends Factory {

  @Override
  public Engine getEngine() {
    return new CarEngine();
  }

  @Override
  public Tyre getTyre() {
    return new CarTyre();
  }

}


package com.gaurav.abstractfactory;

public class TruckFactory extends Factory {

  TruckFactory() {}

  @Override
  public Engine getEngine() {
    return new TruckEngine();
  }

  @Override
  public Tyre getTyre() {
    return new TruckTyre();
  }

}

5 The client code. Client is exposed to only the Abstract Factory class and the interfaces.

package com.gaurav.client;

import java.util.Scanner;

import com.gaurav.abstractfactory.Engine;
import com.gaurav.abstractfactory.Factory;
import com.gaurav.abstractfactory.Tyre;
import com.gaurav.abstractfactory.UnknownVehicleException;

public class AbstractFactoryClient {

  public static void main(String[] args) {

    Scanner in = new Scanner(System.in);
    String vehicleType = in.nextLine().toLowerCase();

    /* Get the factory instance */
    Factory factory;
    try {
      factory = Factory.getFactory(vehicleType);

      /* Get the Engine from the factory */
      Engine engine = factory.getEngine();
      engine.design();
      engine.manufacture();
      engine.test();

      /* Get the Tyre from the factory */
      Tyre tyre = factory.getTyre();
      tyre.design();
      tyre.manufacture();

    } catch (UnknownVehicleException e) {
      System.out.println("Invalid vehicle type entered!");
    }

    in.close();
  }

}

Output

[input1]
    Car
[output1]
    Designing Car Engine
    Manufacturing Car Engine
    Testing Car Engine
    Designing Car Tyre
    Manufacturing Car Tyre

[input2]
    Bus
[output2]
    Invalid vehicle type entered!

Benefits

Loosely coupled code.
Abstract Factory provides a single point of access for all products in a family.
New product family can be easily supported.

Drawbacks

More layers of abstraction increases complexity.
If there are any changes to any underlying detail of one factory, the interface might need to be modified for all the factories.

Real World Examples

Providing data access to two different data sources (e.g. a SQL Database and a XML file). You have two different data access classes (a gateway to the datastore). Both inherit from a base class that defines the common methods to be implemented (e.g. Load, Save, Delete). Which data source shall be used shouldn't change the way client code retrieves it's data access class. Your Abstract Factory knows which data source shall be used and returns an appropriate instance on request. The factory returns this instance as the base class type.

Software Examples

Dependency Injection

Java SDK Examples

javax.xml.parsers.DocumentBuilderFactory newInstance()
javax.xml.transform.TransformerFactory newInstance()
javax.xml.xpath.XPathFactory newInstance()

Hope you like it. Would love to hear your thoughts on this design pattern.

Lets have a Coffee

Future Of Lombok

Gaurav — Thu, 25 Mar 2021 07:06:54 +0000

Following the general release of JDK 16: https://jdk.java.net/16/ and
specially https://openjdk.java.net/jeps/396 Lombok has severe build
issues due to its reliance on the JDK internals which 16 has closed off,
discussion here:
https://github.com/rzwitserloot/lombok/issues/2681

Given the fact that Java 16 brings Records out of preview and libs like
Lombok (over)relying on internal JDK functions, does it make sense to
use Lombok in our code anymore?

Java Records don't require any additional dependency, so it's better to use them instead of Lombok I think.

If your project supports Java 14 you can already use them in Eclipse.
There's a plugin in the marketplace for it:

https://marketplace.eclipse.org/content/java-14-support-eclipse-2020-03-415

Lombok way
Add lombok annotations on top of the class:

import lombok.AllArgsConstructor;
import lombok.Getter;

@AllArgsConstructor
@Getter
public class TransactionLombok {
    private final String from;
    private final String to;
    private final int amount;
}

A constructor with all arguments and getters are generated by lombok.

TransactionLombok transactionLombok = new TransactionLombok("you", "me", 100);
assertThat(transactionLombok.getFrom()).isEqualTo("you");
assertThat(transactionLombok.getTo()).isEqualTo("me");
assertThat(transactionLombok.getAmount()).isEqualTo(100);

Records way
Define a record:

record TransactionRecord(String from, String to, int amount) {
}

You get constructor and getters by default in a record:

TransactionRecord transactionRecord = new TransactionRecord("you", "me", 100);
assertThat(transactionRecord.from()).isEqualTo("you");
assertThat(transactionRecord.to()).isEqualTo("me");
assertThat(transactionRecord.amount()).isEqualTo(100);

As we can see the new record keyword does the same job in a much neater way.
Anything more?
Yes, records can do more than that. It also provides the equals, hashCode and toString automatically for you. So this works as well.

assertThat(transactionRecord.equals(anotherTransactionRecord)).isTrue();
assertThat(transactionRecord.hashCode()).isEqualTo(anotherTransactionRecord.hashCode());
assertThat(transactionRecord.toString()).isEqualTo("TransactionRecord[from=you, to=me, amount=100]");

While in lombok you have to achieve the same thing by adding a few more annotations like this:

@ToString
@EqualsAndHashCode
@AllArgsConstructor
@Getter
public class TransactionLombok {

Or just make it a value:

@Value
public class TransactionLombok {

So the record keyword can be considered as an equivalent to lombok’s @Value annotation.
Customized constructor
In addition, records also supports customized constructors like this:

public TransactionRecord(String from, String to) {
    this(from, to, 0);
}

And if you want to validate the arguments, it’s also possible:

public TransactionRecord {
    Objects.requireNonNull(from);
    Objects.requireNonNull(to);
}

Can records replace lombok?
No.
Even though records provides a lot of nice features and is neat in code, lombok still has way more features than records. For example:

@Builder
@With
public class TransactionLombok {

Records just don’t provide builder and clone functions. Therefore lombok will most probably coexist with records for long time.

What's inside a container?

Gaurav — Mon, 08 Jun 2020 10:15:45 +0000

Hi People
This is my first post on Dev.to
Nowadays everyone is using containerized solution for CI/CD.
I always wonder what makes a container to run in a host machine as a separate process/CPU/memory all along.

So here are some of my findings:

Processes

Containers are just normal Linux Processes with additional configuration applied. Launch the following Redis container so we can see what is happening under the covers.

 docker run -d --name=db redis:alpine

The Docker container launches a process called redis-server. From the host, we can view all the processes running, including those started by Docker.

ps aux | grep redis-server

Docker can help us identify information about the process including the PID (Process ID) and PPID (Parent Process ID) via

docker top db

Who is the PPID? Use

ps aux | grep <ppid>

to find the parent process. Likely to be Containerd.

The command pstree will list all of the sub processes. See the Docker process tree using

pstree -c -p -A $(pgrep dockerd)

As you can see, from the viewpoint of Linux, these are standard processes and have the same properties as other processes on our system.

Process Directory

Linux is just a series of magic files and contents, this makes it fun to explore and navigate to see what is happening under the covers, and in some cases, change the contents to see the results.

The configuration for each process is defined within the /proc directory. If you know the process ID, then you can identify the configuration directory.

The command below will list all the contents of /proc, and store the Redis PID for future use.

DBPID=$(pgrep redis-server)
echo Redis is $DBPID
ls /proc

Each process has it's own configuration and security settings defined within different files.

ls /proc/$DBPID

For example, you can view and update the environment variables defined to that process.

cat /proc/$DBPID/environ

docker exec -it db env

Namespaces

One of the fundamental parts of a container is namespaces. The concept of namespaces is to limit what processes can see and access certain parts of the system, such as other network interfaces or processes.

When a container is started, the container runtime, such as Docker, will create new namespaces to sandbox the process. By running a process in it's own Pid namespace, it will look like it's the only process on the system.

The available namespaces are:

Mount (mnt)
Process ID (pid)
Network (net)
Interprocess Communication (ipc)
UTS (hostnames)
User ID (user)
Control group (cgroup)

More information at https://en.wikipedia.org/wiki/Linux_namespaces

Unshare can launch "contained" processes.
Without using a runtime such as Docker, a process can still operate within it's own namespace. One tool to help is unshare.

unshare --help

With unshare it's possible to launch a process and have it create a new namespace, such as Pid. By unsharing the Pid namespace from the host, it looks like the bash prompt is the only process running on the machine.

sudo unshare --fork --pid --mount-proc bash
ps
exit

What happens when we share a namespace?
Under the covers, Namespaces are inode locations on disk. This allows for processes to shared/reused the same namespace, allowing them to view and interact.

List all the namespaces with

ls -lha /proc/$DBPID/ns/

Another tool, NSEnter is used to attach processes to existing Namespaces. Useful for debugging purposes.

nsenter --help

nsenter --target $DBPID --mount --uts --ipc --net --pid ps aux

With Docker, these namespaces can be shared using the syntax container:. For example, the command below will connect nginx to the DB namespace.

docker run -d --name=web --net=container:db nginx:alpine
WEBPID=$(pgrep nginx | tail -n1)
echo nginx is $WEBPID
cat /proc/$WEBPID/cgroup

While the net has been shared, it will still be listed as a namespace.

ls -lha /proc/$WEBPID/ns/

However, the net namespace for both processes points to the same location.

ls -lha /proc/$WEBPID/ns/ | grep net

ls -lha /proc/$DBPID/ns/ | grep net

Chroot

An important part of a container process is the ability to have different files that are independent of the host. This is how we can have different Docker Images based on different operating systems running on our system.

Chroot provides the ability for a process to start with a different root directory to the parent OS. This allows different files to appear in the root.

Cgroups (Control Groups)

CGroups limit the amount of resources a process can consume. These cgroups are values defined in particular files within the /proc directory.

To see the mappings, run the command:

cat /proc/$DBPID/cgroup

These are mapped to other cgroup directories on disk at:

ls /sys/fs/cgroup/

What are the CPU stats for a process?
The CPU stats and usage is stored within a file too!

cat /sys/fs/cgroup/cpu,cpuacct/docker/$DBID/cpuacct.stat

The CPU shares limit is also defined here.

cat /sys/fs/cgroup/cpu,cpuacct/docker/$DBID/cpu.shares

All the Docker cgroups for the container's memory configuration are stored within:

ls /sys/fs/cgroup/memory/docker/

Each of the directory is grouped based on the container ID assigned by Docker.

DBID=$(docker ps --no-trunc | grep 'db' | awk '{print $1}')
WEBID=$(docker ps --no-trunc | grep 'nginx' | awk '{print $1}')
ls /sys/fs/cgroup/memory/docker/$DBID

How to configure cgroups?
One of the properties of Docker is the ability to control memory limits. This is done via a cgroup setting.

By default, containers have no limit on the memory. We can view this via docker stats command.

docker stats db --no-stream

The memory quotes are stored in a file called memory.limit_in_bytes.

By writing to the file, we can change the limit limits of a process.

echo 8000000 >/sys/fs/cgroup/memory/docker/$DBID/memory.limit_in_bytes

If you read the file back, you'll notice it's been converted to 7999488.

cat /sys/fs/cgroup/memory/docker/$DBID/memory.limit_in_bytes

When checking Docker Stats again, the memory limit of the process is now 7.629M -

docker stats db --no-stream

Seccomp / AppArmor

All actions with Linux is done via syscalls. The kernel has 330 system calls that perform operations such as read files, close handles and check access rights. All applications use a combination of these system calls to perform the required operations.

AppArmor is a application defined profile that describes which parts of the system a process can access.

It's possible to view the current AppArmor profile assigned to a process via

cat /proc/$DBPID/attr/current

The default AppArmor profile for Docker is docker-default (enforce).

Prior to Docker 1.13, it stored the AppArmor Profile in /etc/apparmor.d/docker-default (which was overwritten when Docker started, so users couldn't modify it. After v1.13, Docker now generates docker-default in tmpfs, uses apparmor_parser to load it into kernel, then deletes the file

The template can be found at https://github.com/moby/moby/blob/a575b0b1384b2ba89b79cbd7e770fbeb616758b3/profiles/apparmor/template.go

Seccomp provides the ability to limit which system calls can be made, blocking aspects such as installing Kernel Modules or changing the file permissions.

The default allowed calls with Docker can be found at https://github.com/moby/moby/blob/a575b0b1384b2ba89b79cbd7e770fbeb616758b3/profiles/seccomp/default.json

When assigned to a process it means the process will be limited to a subset of the ability system calls. If it attempts to call a blocked system call is will recieve the error "Operation Not Allowed".

The status of SecComp is also defined within a file.

cat /proc/$DBPID/status

cat /proc/$DBPID/status | grep Seccomp

The flag meaning are: 0: disabled 1: strict 2: filtering

Capabilities

Capabilities are groupings about what a process or user has permission to do. These Capabilities might cover multiple system calls or actions, such as changing the system time or hostname.

The status file also containers the Capabilities flag. A process can drop as many Capabilities as possible to ensure it's secure.

cat /proc/$DBPID/status | grep ^Cap

The flags are stored as a bitmask that can be decoded with capsh

capsh --decode=00000000a80425fb

Hope you found this article worth reading!