DEV Community: Shitij Bhatnagar

Meaningful and humor books in IT

Shitij Bhatnagar — Sat, 14 Feb 2026 16:30:33 +0000

I always used to think that a book that will be meaningful could not be funny or, one that could be funny, would not have much meaning, till I got introduced to humor literature. And, the one that stayed with me the most was humor that was related to my own job/industry i.e. IT.

Around 10 years ago, I came across the book called 'The Phoenix Project' - A Novel about IT, DevOps, and Helping your Business Win. By Gene Kim, Kevin Behr, George Spafford link that talks about IT operations, Dev Ops, repeatable/predictable project delivery, managing business expectations, scaling of work and a lot more. Even though it was published many years ago, I still end up referring to it; while it has lot of meaning and lessons, the humor is amazing too and makes for a compelling read. It does not talk about core software development, but the end to end processes, critical dependencies, tight coupling / hard dependencies and solutions that one can relate to surely.

For anyone with IT experience (any level or aspiring to), the events mentioned in the book could seem relatable or bring up a memory and even smiles. And who knows, you might end up even comparing yourself to some of the characters in the book :-)

I hence would like to recommend this book to anyone who works in IT, irrespective whether you are in technical or functional or managerial role. Having said that, I would love to hear any similar book recommendations from anyone.

How multi-tenancy forced removal of caching in a critical API

Shitij Bhatnagar — Fri, 30 Jan 2026 14:10:46 +0000

When we think about data caching in an API, we automatically think about faster response time, less database calls, better overall performance - everything positive. The more critical the API (e.g. financial), the more benefits an optimization technique like caching can bring. However, in one specific scenario, data caching became a bottleneck. Yes, that is right.

This was the case when an on-premises API (note - API is REST end point, back-end Spring Boot and many other integrations and libraries combined) that is working well in production however to be more scalable, made more stable, needed to be run in high availability / multi-instance mode.

When faced with a situation like this, there is generally a good amount of opinions within a development team and option analysis, like let's use Redis/distributed caching, let's synchronize Spring cache between instances and more similar options plus another unusual option - remove data caching. And after a lot of deliberation, the last option was chosen i.e. remove caching altogether from the API. There were few reasons for this:

Synchronizing cache across multiple service instances is error prone if done through custom mechanisms (heard of the cache invalidation problem in computer science? :-))
Using a new distributed cache like Redis would involve additional components, maintenance and possibly infrastructure (and skills too)
The API was write heavy, more data is written or sent downstream vs being read, removing caching removed additional look ups within the boundary of the application
The API heart beat checks are periodic (e.g. every 30 seconds), besides that, the read traffic is not in significant/high use
The API volume is growing gradually, not exponentially (in short to medium term)
We need to move the API to cloud in 12+ months and that will eventually need some re-design
High availability is a design principle that needs to be adhered to (by design, not by accident)

The trade off? a miniature hit to performance in leu of high availability benefits & stability (that is proven through load testing, tangibly).

Given the above, a decision was made to remove caching from the API. This was not an easy decision as every developer feels emotional about the code they write :-), however in this case, this clearly was the pragmatic option, while also an example where caching seemed like an existing unnecessary over engineering in an API.

Lesson: a best practice like caching also needs to be considered for fitment before applying it - whether the service is on-premises or on the cloud, considering data load, consumer size, non functional requirements, long term impacts and more.

The outcome was a leaner API service which can be run in multiple instance mode and we do not need to worry about whether the data being saved/retrieved is latest or stale.

Thanks for reading thus far, if anyone has any similar experience or other experiences with design choices, would love to hear and learn from that.

A Critical Gap in the Technical path, and AI cannot solve this

Shitij Bhatnagar — Sun, 25 Jan 2026 16:42:54 +0000

We have always learnt about the multiple career paths in IT, especially in software engineering/development. But did we ever imagine in a dynamic industry like this, what gaps could/would creep in silently and impact the very culture of teams, departments and firms? Let's look at the career paths first and then will quickly talk about the gaps.

Management path involves people development, line management, coaching, performance management, project management, budgeting and a lot more; this path typically starts after one has spent a few years in junior/senior roles, have an understanding of how teams deliver work and then a professional makes a choice (or is forced due to circumstances or under influence) to pursue management.

Technical path involves growing into senior engineer, technical lead, staff engineer, architect and similar roles over time.

And then of course the new path i.e. Hybrid - that has roles like Engineering manager, Technical manager every since IT companies starting asking managerial roles to be more hands-on (without thinking about its impact or success rate).

Let me talk about the gaps that I am seeing as critical (or becoming worrisome) for past few years. This relates to some behaviors that I have noticed in past few years in multiple organizations and relates to technical path, the following are only few examples or behaviors:

Engineers only focused on their individual contribution, not sharing anything much in teams or outside team (this might appear like a behavior that has always been there, but I feel it is a bit compounded in past few years)
Engineers who are high headed and tend to shrug off others (there are always a few in every team, at least one - in my experience :-))
Senior Engineers / Tech leads (at least 10 years+ experienced) being immature in their oral and written communications e.g. not considering what impact their words or gestures may have
Engineers at all levels (juniors, seniors, leaders) not joining meetings on time :-), yes, this happens more often than we think it does; including engineers not opening their meeting codes on time while interviewing candidates (i.e. making candidates wait)
Engineers growing into tech leads/engineering managers with line management however not having an eye for observing individual or team behaviors and too focused on just the technical stuff (guess who loses out - everyone)
Engineering leaders (managers, VPs & more) losing touch of technical reality due to not being hands-on for some time but make up by being good people leaders OR in some cases, being forced to be hands-on/coding, so not able to properly focus on people aspects (basically, a mix up)

I can go on, but I would take a pause here, because these are just my observations and not necessarily what anyone else may have seen in the technical paths. These observations made me ponder about why this is happening (in pockets or in plenty), because this neither looks healthy nor it is something that I would want the next generation to follow.

In my humble view, I felt the following could be some of the reasons (and I am not talking of generation gap here), there would surely be a lot more to it:

Engineers not receiving adequate direction in their careers that it is not just producing software (the 'what' part of work), but also behaviors and maturity (the 'how' part of work) that matters
A culture of not troubling 'technically strong engineers', worrying they will leave :-) (and letting work environment get toxic)
Performance assessments that emphasize that only technical delivery matters, behaviors do not matter 'as much' comparatively
Lack of gut in line managers and leaders to take 'tough calls', to coach others, even if it's difficult

Again, I would take a pause here, but one thing that clearly stands out to me in this assessment is that while technical delivery happens, individual contributors do their work, teams deliver.. but people don't grow in stature, team's don't gain emotional intelligence.

Does all of this come down to just the leader of the team / project / department (stuff like this does not happen in a day, it builds over time)?. May be I am wrong, but if the leader is not focusing enough on the soft aspects (not just technical aspects), how would a correction happen? And if leaders/managers are thrown into coding left right center, who will take care of the softer issues, AI?

I would appreciate if anyone could share their experiences, suggestions or any comments.

Thanks for reading.

Do we need junior developers? - https://dev.to/shitij_bhatnagar_b6d1be72/do-we-need-junior-developers-2k2l

Shitij Bhatnagar — Sat, 17 Jan 2026 13:15:46 +0000

Do we need Junior developers?

Shitij Bhatnagar ・ Jan 17

#programming #career #ai #automation

Do we need Junior developers?

Shitij Bhatnagar — Sat, 17 Jan 2026 13:11:01 +0000

Do we need junior developers, freshers, early aspirants in Software Industry (and any other industry)? my take - Yes.

Doesn't the above take seem contrary to the prevalent news about AI taking over junior or senior jobs, why so much narrative about every day work going away to robots (like shown in the movie 'I Robot' released in 2005) - when retail/daily Robotics is at least a decade away and Artificial Intelligence (particularly Agentic AI) is still shaping up?

There is some truth (early strides like use of chatbots for IT support), but lot of hype to aid capitalism, regrettably; still the news circulates on and professionals get effected because taking this narrative path helps justify role reductions or reorgs or strategizing, which leads to cost savings, then leads to higher share prices or opportunity budget that can be deployed elsewhere - just an inference.

However, even if there is some truth, does it mean the industry does not require junior engineers/professionals? This has never been true, nor would it ever be, in my humble opinion.

Entry level / junior professionals - you are the next generation, the next force that pushes the economic pedestal forward for your country and industry, you have the energy and perspective, you have the internet and lot of free resources to upskill and you can understand industry trends well (or learn).. simply said, you are smart, vocal, capable and well armed.

First some historical reference:

During the economic downturn events (2000 dot com burst, 2008-09 financial crisis, Covid-19), for freshers/juniors (even seniors), I cannot deny that struggle was there, I am aware of many technologists to moved to marketing/data processing/front office/other roles to keep the house running; due to lay offs many professionals had to stay out of job for few months, but then eventually (even after an year), people got the relevant jobs - may not be in big companies, but in small ones, midsized ones, working as interns/trainees, faculties, part-time engineers and then eventually landing the kind of jobs they wanted or aspired to. It took time, but it happened; career toll? it took some months or year out of a career trajectory, but few months or year out of a 35-40 year career, can be caught up - looking at the long term.

Note: majority of working people I have known over the past 25 years are still employed, but they did need to pick up new skills or move into different roles

To the point about AI/automation impacting need for junior engineers:

Before AI, let's talk about previous automation spikes and what they did to IT jobs and need for juniors. Innovations like software test automation, robotic process automation (RPA), AI chatbots in support/customer facing phases forced professionals to pick new skills rather than eliminate their jobs - for majority of the roles (but some were effected e.g. reduction in IT support personnel head count or manual software testers asked to become test engineers etc.); again, only the professionals who did not adapt to new skills or aligned with new realities (incl. to increased productivity or performance expectations) were effected - and that too not on day one, but over a tenure. The need for entry level / juniors did not go away, junior hiring got delayed or recruitment numbers got reduced temporarily but definitely picked up later - let's call this the 'delay' effect.

AI is another form of automation that is much smarter than its predecessors. The first impact or theme, at least at this stage with Generative AI (Chat GPT, Gemini, Claude and others) is that with these chat tools at hand, people need to be a lot more productive and should be multipliers. So, if you see, the business demands are what? -> 'increased productivity or performance expectations'. I find this as a common theme repeated over and over again irrespective of the automation spike at play.

Another theme that AI has actually expedited (it was already growing) is a shift towards leaner organization hierarchy, increasing technical skills, currently trending as the need for more engineering skills and reduction in facilitation oriented roles. Whether we like this or not, this is happening and we must prepare/adapt. So, what could juniors/entry level staff do? Do more side / live projects to be job ready.

Yet another theme that will start taking shape is when Agentic AI becomes production ready, it could further impact facilitator roles in companies if the privacy and security concerns of Agentic AI are taken care of. But who would configure Agentic AI? of course, developers. And what could facilitator oriented roles do? Mesh more business or other skills relevant to the job or industry

AI will impact different IT companies in different ways, depending on their business models, segregation of roles, customer profiles, funding and more. But some things are less likely to change, in my humble opinion, like:

Need for engineers who are productive and multipliers (right attitude)
Need for engineers to oversee output of AI tools, this would be a technical function
Need for project managers to manage projects and programmes
Need for production support staff to man IT systems and tackle incidents/problems (if I were an IT production manager, I would not trust a solution from AI - at least at this point, I need to talk to a man)
Need for engineers to mentor other engineers, otherwise, the human connect will vanish
Need for Engineering leaders, not just talkers but, those who can walk the talk
Need for multiple skills - degrees would matter less, skills would matter more. And, this is not a new theme, its been there since a few decades at least in IT

What I would have done if I were a junior developer or fresher today

Being an entry level / junior is never easy in an unsettling economic or industry stage, like in IT. Yet, if I were there today, this is what I would have done:

1) Talked to experienced engineers (find on LinkedIn, Medium, dev.to etc.), taken their guidance for realistic projects and done practice
2) Checked college/university alumni and sought support (kept ego side)
3) Volunteered for freelance projects
4) Got into any IT role if possible (trainee, intern, tester, engineer, support) in any IT organization / get foot in the door
5) Created a smart CV covering projects, skills, volunteering, education
6) Done Network Network Network - one of the lifelines of career
7) Focused on learning and professional certification
8) Taken career guidance from experienced IT folks

At the end

I hope the articles resonates with someone, I would be more than happy to hear any criticism or views that would widen my own and everyone's understanding and to help each other. And if you ask me about AI impact, I believe the senior IT professionals are at a much higher risk than juniors.

Simplified: Spring Boot with Docker (Part 3)

Shitij Bhatnagar — Sun, 23 Feb 2025 10:00:11 +0000

We covered the 'Multiple Services Instances' angle of Spring Boot and Docker in the Part 2 article of this series.

In this Part 3 article, we shall see how to manage dependencies between services, recovering from start failures, following a start up sequence through Docker Compose in an application that has multiple services. There are numerous examples of such an arrangement:

Microservice that talks to a database (another service)
Single Page application (SPA) that talks to microservice in background
Necessary service bindings (e.g. distributed logging)

Pre-requisites:

To experience the journey as outlined in the article, it is recommended to have the pre-requisites in place before getting on with the technical steps.

Reading: Basic awareness about Containerization & Docker
Tool: Installed Docker Desktop – contains multiple Docker services
Tool: Familiarity with Java (preferably 8 onwards), Spring Boot 3.4.x
Tool: Installed JDK 17 & Maven (build tool)
Hardware: Recommended to have at least 08 GB RAM (more the merrier)
Reading: Understood the Part 1 & Part 2 articles (Basics & Docker Compose)
Code: We shall use the 'Referral' Spring Boot application available at this Github Repo and Docker setup used in Part 1 & 2 article

Context:

We have a Spring Boot microservice called 'Referral'. This service helps persist & retrieve referral (any person) information in a back-end database - H2 (in memory) or external (PostgreSQL on-prem or container) and each of these 03 storage options can be enabled by choosing the active spring profile i.e. local (H2), dev (PostgreSQL on-prem) or dockerize (PostgreSQL on Docker container). Note that the default spring profile is local.

Let's look at the operations we can perform with the Referral application:

GET /referrals/status to get the status of the service (alternative is Actuator but that is not enabled right now)
GET /referrals to retrieve all the referrals
POST /referrals to add a referral [JSON request like { "givenName": "Marty" }]

Objectives we want to accomplish:

Deploy the Referral application to Docker (think service)
Keep multiple instances of the API / service (think replicas)
Have request distribution to the Referral application instances (think another service i.e NGINX)
Referral application to connect with PostgreSQL running in container (think another service i.e. PostgreSQL)

When using 'dockerize' spring profile, the database connectivity information & schema setups are not provided in the application properties but are defined externally in the Docker Compose YML (we shall touch on this later in the article)

Steps:

In order to meet the objectives, let's move one step at a time as there is a lot to accomplish here.

Understand Services & inter-dependencies

The traffic to 'Referral' application instances will channeled though the web server NGINX (similar approach to Part 2 article). The 'Referral' application instances shall integrate with PostgreSQL running in another container. So, we see at least 03 entities with their inter-dependencies as below:

NGINX (depends on Referral)
Referral (depends on PostgreSQL)
PostgreSQL (with necessary database schema)

What does 'Referral Controller' do?

Let's look at the below code:

package com.sb.mybatis.postgre.web;

import com.sb.mybatis.postgre.dto.ReferralDTO;
import com.sb.mybatis.postgre.service.ReferralService;
import jakarta.validation.Valid;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;
import java.util.List;

@Slf4j
@RestController
@RequestMapping("/referrals")
public class ReferralController {

    @Autowired
    private ReferralService referralService;

    @GetMapping("/status")
    public String getStatus() {
        log.info("ReferralController.getStatus() is invoked");
        return "Referral Service is Up";
    }

    @GetMapping
    public List<ReferralDTO> getTransactions() throws Exception {
        log.info("ReferralController.getTransactions() is invoked");
        return referralService.findAllReferralRecords();
    }

    @PostMapping
    public ReferralDTO createTransaction(@Valid @RequestBody ReferralDTO referralDTO) throws Exception {
        log.info("ReferralController.createTransactions() is invoked");
        if(referralService.insertReferral(referralDTO) == 1) {
            //Success
            return referralDTO;
        }
        else throw new Exception("Error in creating new Referral record");
    }
}

The ReferralController allows us to create/retrieve Referral records, provide service status and at the same time also add a simple message in the application logs that can be verified (would be referred later in the article).

Create Referral Executable Jar

First and foremost, please clone the Referral spring boot application locally and run the command mvn clean install to have the executable jar file ready (name like Referral-0.0.1-SNAPSHOT.jar).

Create Dockerfile

In order to create a Docker image for the Referral application, we first need to create a Dockerfile.

FROM openjdk:17
EXPOSE 8081
ARG JAR_FILE=Referral-0.0.1-SNAPSHOT.jar
COPY ${JAR_FILE} Referral-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java","-Dspring.profiles.active=dockerize","-jar","/Referral-0.0.1-SNAPSHOT.jar"]

Provision of the spring profile 'dockerize' in the ENTRYPOINT ensures this profile is picked up in the eventual image creation

Create 'Referral' Docker image

Using the Docker image, let's execute the command docker build -t sb-referral-service:V1 . to create the docker image for the Referral application.

A successful execution should look like below, indicating that the Docker image 'sb-referral-service:V1' is built.

Create NGINX.conf (web server configuration)

Similar to the Part 2 article, let's create a NGINX configuration file which should indicate that all requests to sb-referral-service should be channeled through the NGINX service.

user  nginx;

events {
    worker_connections   10;
}
http {
        server {
              listen 8000;
              location / {
                proxy_pass http://sb-referral-service:8081;
              }
        }
}

Create PostgreSQL DB Schema creation script

As mentioned previously in the Step 'Understand Services & inter-dependencies', we would like to ensure that the PostgreSQL DB in Docker should have the necessary database schema. If this is not the case, the Referral application will not work because Spring Boot is not instructed to initiate schema creation in 'dockerize' mode/profile.

Let's create an SQL script by the name 'create-db.sql' with content as below:

create table if not exists T_REFERRAL
(
    id varchar(255) primary key,
    name varchar(255) NOT NULL
);

'create-db.sql' needs to be part of the PostgreSQL configuration in Docker Compose YML file

Define Service Orchestration via Docker Compose

Once we have the Referral image, database schema creation SQL script and the NGINX configuration files in place, the next step is to define how the different services will be associated, sequenced (in start up) and recover (in case of any dependent service failure). Let's have a look at the Docker Compose YML below:

services:
  nginx:
    image: nginx:latest
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - sb-referral-service
    ports:
      - '8000:8000'

  sb-referral-service:
    image: 'sb-referral-service:V1'
    restart: on-failure
    expose:
      - '8081'
    build:
      context: .
    deploy:
      replicas : 2
    depends_on:
      - db
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/test
      - SPRING_DATASOURCE_USERNAME=test
      - SPRING_DATASOURCE_PASSWORD=test
      - SPRING_JPA_HIBERNATE_DDL_AUTO=none

  db:
    image: 'postgres:13.1-alpine'
    container_name: db
    environment:
      - POSTGRES_USER=test
      - POSTGRES_PASSWORD=test
    volumes:
      - ./db:/var/lib/postgresql/data
      - ./create-db.sql:/docker-entrypoint-initdb.d/create_database.sql

Looking at the YML file closely, we find 03 services:

NGINX: the web server, that will be setup by Docker by utilizing the NGINX.conf file and that has dependency on 'sb-referral-service'
sb-referral-service: the Referral application, that will have 02 instances (replicas), will be restarted by Docker if it's previous attempt was unsuccessful (restart: on-failure) and is dependent on 'db'
db: the PostgreSQL server, that will use the create-db.sql script and use the provided credentials for 'test' database

Notice the provision of the Spring Boot to database connectivity information in the 'environment' section under 'sb-referral-service' and the atypical spring datasource url as jdbc:postgresql://db:5432/test - that is because the database is running in a container

Starting the Services in Docker

To initiate creation of the services in Docker, we need to execute the command docker compose up (please ensure create-db.sql and nginx.conf files are also present in the same folder) and we should see a message like below:

Once the services are started successfully, we should be able to see them in Docker Desktop like below:

Pre-Checks before consuming the services

Sometimes re-starts can be noticed in the upstream services (in this case, sb-referral-service) if the downstream services (in this case, db) are still getting setup while the upstream is trying to connect to the downstream. So, instead of rushing to consume the Referral application after seeing 05 containers visible in the Docker Desktop Dashboard, we can do some pre-checks also.

So, before we attempt to start using the API/end points of Referral application at the URL http://localhost:8000/referrals (note the port 8000 is of NGINX), we can additionally verify the following messages from the command prompt / log messages displayed by 'docker compose up' command:

Successful PostgreSQL setup:

Successful Referral application setup:

Because the 'depends on' (in Docker Compose YML) only waits for the other container to be up (and not for its contained application to be fully running), it is advisable to additionally verify the applications/services before consuming them.

Consuming the 'Referral' application

Now that the services are running in Docker, let's try consuming them, this time from Postman.

When we execute GET http://localhost:8000/referrals/status, we should get a successful message about service status, like below.

When we execute GET http://localhost:8000/referrals, we should receive zero Referral records, because none exist, like below.

When we execute POST http://localhost:8000/referrals, we should see a success message with the Referral information, like below.

Now, again when we execute GET http://localhost:8000/referrals to see if we see the newly created Referral in the fetch operation, we receive the Referral record(s), like below.

In addition to the above, let's also verify the Referral application logs. For the same, we can go to the individual sb-referral-service instances/containers and go to Logs option, we should see below (based on the above success).

Note that as per the above two logs, Referral services instances received different requests (from Postman), which also proves that NGINX is rotating the requests between the instances successfully

Destroy the containers / services

As our work finishes, we can finish the containers using the command docker compose down and we should see a confirmation, like below.

Summary

In this article, we saw how Docker (and Docker Compose) allowed us to comfortably build a service orchestration that is typically only possible in a test environment - on our development machine and how we can use it - covering multiple services (including database), service to service communication, service start up sequencing and recovery.

Would appreciate any feedback for improvement on the approach and content.

References:

https://stackoverflow.com/questions/52699899/depends-on-doesnt-wait-for-another-service-in-docker-compose-1-22-0

Simplified: Spring Boot with Docker (Part 2)

Shitij Bhatnagar — Fri, 14 Feb 2025 17:11:01 +0000

We covered the 'Getting Started' angle of Spring Boot and Docker in the Part 1 article of this series.

In this Part 2 article, we shall see how to span up multiple instances of a Spring Boot REST service using containers on a developer machine itself. The need to have multiple service instances can arise due to a number of reasons:

Observe REST service behavior in multi-instance setup
Simulate a test environment setup locally
Experimentation / Getting hands dirty before moving to more complicated scenarios (like proving service to service connectivity, orchestration expansion & more)

In the Part 3 article of the series, we shall bring in more details around inter-service hard dependencies, orchestration methods (& more) however here, we shall cover multi-instance possibilities in Docker.

Pre-requisites:
To experience the journey as outlined in the article, it is recommended to have the pre-requisites in place before getting on with the technical steps.

Reading: Basic awareness about Containerization & Docker
Tool: Installed Docker Desktop – contains multiple Docker services
Tool: Familiarity with Java (preferably 8 onwards), Spring Boot 3.4.x
Tool: Installed JDK 17 & Maven (build tool)
Hardware: Recommended to have at least 08 GB RAM (more the merrier)
Reading: Understood the Part 1 article (Basics)
Reuse: We shall re-use the 'Tower' Spring Boot service and Docker setup used in Part 1 article

So, in Part 1, we saw how to deploy the 'tower' service in Docker and consume it through the application URL http://localhost:8085/tower

Now, if we want to have multiple instances of the 'tower' service aka run 'tower' service in multiple containers, what are the different options to do so in Docker, let's explore the same below.

Objective: We should have multiple instances of the 'tower' service, each ready to serve clients

Option A: Execute multiple 'docker run' commands

For creating multiple containers, we can first try to run the 'docker run' command (same as in Part 1 article) multiple times - this might seem like first no-brainer option to exercise. Let's have a look-

Command 1: docker run -p 8085:8085 sb-tower-service:V1
Command 2: docker run -p 8085:8085 sb-tower-service:V1

When the first command is executed, the 'tower' service comes up successfully (accessible at http://localhost:8085/tower) and we can verify the service (image below).

However when we execute the second command, instead of a new container getting setup, we see an error message like below. This is because the host port 8085 is already occupied by the first 'tower' service and cannot be re-used.

So, we realize that we cannot plainly apply the Part 1 article approach here for creating multiple containers for the same service and need to look for a different option.

Option B: Execute multiple 'docker run' commands but with different host port

Command 1: docker run -p 8085:8085 sb-tower-service:V1
Command 2: docker run -p 8086:8085 sb-tower-service:V1 (notice the different port 8086)

When the first command is executed, the 'tower' service comes up successfully (accessible at http://localhost:8085/tower) and we can verify the service (image below).

When the second command is executed, the second 'tower' service also gets started successfully (accessible at http://localhost:8086/tower) and we are able to verify the service (image below)

So, while we are able to have multiple instances of the 'tower' service running in Docker, we have a problem :) i.e. we have two URLs for the same service. This approach is not extensible (i.e. if we create 05 instances, we shall have 05 application URLs) and we cannot have tests written for multiple URLs every time except for specific scenarios like A/B testing but again, we would typically not do this kind of testing on local machine - generally.

Before moving to further options, we need to understand another tool called Docker Compose.

Docker Compose is a docker utility that allows us to describe service(s) run configuration in an YML file (in addition to Dockerfile) and then instead of using 'docker run' command to create a container, we can use command 'docker compose up' to execute the run configuration to create the container(s). Likewise we can use 'docker compose down' to dismantle the running containers that were created previously. One point to note is that Docker Compose does not create an image of a service automatically, so to use the 'tower' service in Docker Compose, we need to have an existing image (like we created in Part 1 already) named sb-tower-service:V1.

The real benefit of Docker Compose is that we can execute a number of scenarios like creating multiple service instances, creating dependency between services etc. quite easily without going into multi node and network setups explicitly.

For a better understanding, let's experience the Option B again using docker compose tool. For the same, we need to create a docker-compose.yml file with the following content:

docker-compose.yml

services:
  tower-services: 
    image: sb-tower-service:V1
    ports:
    - "8085-8086:8085" 
    deploy:
      replicas : 2

Let's break down the docker compose content below-

tower-services - this is the service name 'tower-services'
sb-tower-service:V1 - this is the docker image name
8085-8086:8085 - instructs Docker to use a host port range (8085-8086)
replicas : 2 - instructs Docker to create 02 service instances

Then, we execute the command docker compose up and the 02 'tower' instances come up using port 8085 & 8086 (image below). The services are verifiable in the same way as done earlier in Option B.

Finally, we can exit the docker compose by executing the command docker compose down and the 'tower' instances are removed (image below).

Note: Docker also creates/destroys a Docker network by the name 'tower_default' automatically for supporting network/communication

Option C: Setup multiple service instances on same host port (using Docker Compose & front-proxy)

Now that we have understood Docker Compose, let's try to accomplish
our objective using a simple arrangement. This arrangement would have an additional service, NGINX web server (open source) to front-end the client calls, while in the background it would send the client requests to multiple 'tower' service instances (using round robin allocation). This way, the client only gets a single application URL (e.g. http://localhost:8000/tower) to access even though there are multiple service instances.

The configuration for Option C consists of additional artefacts-
1) docker-compose.yml - provides the 'tower' & NGINX services info
2) nginx.conf - NGINX server config file including association with the tower services/instances

docker-compose.yml

services:
  tower-services:
    image: sb-tower-service:V1
    expose:
      - '8085'
    deploy:
      replicas : 2

  nginx:
      image: nginx:latest
      volumes:
         - ./nginx.conf:/etc/nginx/nginx.conf:ro
      depends_on:
         - tower-services
      ports:
         - '8000:8000'

Let's break down the docker compose content below-

tower-services - this is the service name 'tower-services'
sb-tower-service:V1 - this is the docker image name
expose 8085 - instructs Docker to use the port 8085 in REST service
replicas : 2 - instructs Docker to create 02 REST service instances
nginx _ - this is the NGINX web server & service name
depends_on - instructs that the NGINX depends on 'tower-services'
volumes & nginx.conf - instructs a volume and NGINX config to refer
ports '8000:8000' - instructs docker to ensure port 8000 for NGINX

nginx.conf

user  nginx;
events {
    worker_connections   10;
}
http {
        server {
              listen 8000;
              location / {
                proxy_pass http://tower-services:8085;
              }
        }
}

Let's break down the nginx.conf content below-

worker_connections 10 - instructs NGINX to use up to 10 worker connections when talking to the 'tower' instances
server listen 8000 - instructs NGINX to use 8000 as the listening port; note the same port number is mapped in docker compose yml also
proxy_pass http://tower-services:8085 - instructs NGINX to pass on the requests received on port 8000 to the service 'tower-services' listening on port 8085.

So now our expectation is that when the above configurations are executed, the clients would should be able to hit the application URL http://localhost:8000/tower (external URL) and this should internally talk to http://localhost:8085/tower (internal URL) however the internal URL will not be accessible to clients.

Now it's time to let Docker to the above setup for us. When the command docker compose up is executed, the NGINX server and the 02 'tower' service instances get successfully created.

We are also able to verify the service through a CURL command hitting http://localhost:8000/tower.

We can also see the application log in one of the 'tower' service instances.

Finally with this proving complete, we close the Docker compose service by running the command docker compose down.

Additional Note

1) Scaling possibility in Option C: We can over-ride the replica count 2 mentioned in the docker compose yml by providing that value in the docker compose up command e.g. 'docker-compose up --scale tower-services=5'. This would end up creating 05 instances of the Spring Boot service instead of 2.

2) Other aspects of Option C for multi-instance service setup

Benefits:

all configuration stays in docker compose yml & NGINX conf files
possible to scale the no of instances above the 'replica' count mentioned in the docker compose yml

Drawbacks:

Docker compose file becomes more complicated with NGINX added (but still is one-time effort)
cannot scale dynamically / additionally after services have started (e.g. cannot add more instances post start up)

Summary

We saw how multiple instances of same Spring Boot REST application can be setup using Docker to service client requests while utilizing additional services like NGINX. In the Part 3 of the article series, we shall try to cover additional use cases like hard dependencies between services (e.g. web dependent on database), start up sequencing (& known issues), more orchestration scenarios (like Docker Swarm or K8s) & more.

Would appreciate any feedback for improvement on the approach and content.

References:

https://www.nutrient.io/blog/how-to-use-docker-compose-to-run-multiple-instances-of-a-service-in-development/

https://stackoverflow.com/questions/64819934/running-multiple-services-on-same-port-in-docker-compose

Simplified: Spring Boot with Docker (Part 1)

Shitij Bhatnagar — Tue, 11 Feb 2025 11:33:11 +0000

Spring Boot is a popular framework for building microservices in Java. Spring Boot helps make building REST services faster because of a lot of auto configurations and in-build dev tools. Even the simplest Spring Boot REST application comes with an inbuilt Tomcat server to host the service, which implies faster local testing and validation.

However, sometimes, there is a need to test a containerized (or multi-instance) arrangement for a REST service for specific use cases early in the development life cycle e.g. before pushing the service to higher test environments. Also, while a test environment could support containerization (e.g. in PaaS), the same may not be easily possible on a developer’s machine – whether for technical proving (single container, multiple containers) or for replicating more complicated scenarios on local (e.g. service talking to a real database that’s generally only possible in an integration test environment).

That is where a containerization tool can come handy to provide a similar experience to a developer, e.g. by allowing the REST service to run in a container on the developer machine, without the overhead of additional hardware, operating system etc. Once a REST service runs in a container platform locally, it is possible to load additional services (like other REST services or DB etc.) in additional containers like an ecosystem. Docker is one of the containerization platforms that makes this possible.

This article intents to share a simple use case of running a Spring Boot REST service with Docker on a developer’s machine, which should be easily replicable. This is the Part 1 of this article series. Next parts shall bring in more details around multiple-container scenarios however to start with here, we shall cover a single container use case.

Pre-requisites:
To experience the journey as outlined in the article, it is recommended to have the pre-requisites in place before getting on with the technical steps.

Reading: Basic awareness about Containerization & Docker
Tool: Installed Docker Desktop – contains multiple Docker services
Tool: Familiarity with Java (preferably 8 onwards), Spring Boot 3.4.x
Tool: Installed JDK 17 & Maven (build tool)
Hardware: Recommended to have at least 08 GB RAM (more the merrier)

Steps:

Create Service
We need to have a REST service that spans up fast and can be verified quickly. To do so, the first step is to create a new skeleton Spring boot service (using Spring Initializer) or as an even faster alternative, please download an already prepared Spring Boot REST service from https://github.com/shitijbhatnagar/tower/tree/learner_1 (unusual name ‘tower’, I know).

As we download and setup the code (e.g. using IntelliJ), let’s have a look at the main Rest Controller (TowerController.java) and note that all it does is to provide a happy path response to the HTTP GET call and log a message (by default goes to console).

Build and Execute Service (on local)
We need to build/compile the service first, using the command mvn clean install. Once successfully through, the Spring Boot executable jar file should be created in the ‘target’ folder. The next step is to run the service using the command mvn spring-boot:run post which, the REST service should start successfully and we should see an output as below.

Verify Service (on local)
The REST service should be accessible (via curl/Postman/browser) by hitting the application URL http://localhost:8085/tower

Also, note that when the application URL is accessed, a new log message should be visible in the Spring boot application log (aka console) as below:

Thus far, we have setup the simple REST service and proven that it works on developer machine, so the next step is to focus on Docker. In preparation, let us create a new folder/directory (we can call it ‘tower’ folder) and copy the Spring Boot executable jar file there. Additional files and artefacts will also be kept in the same folder for easy reference.

Prepare Dockerfile (for a Docker image)
A docker image is a blueprint (via metadata) of what component or service a Docker container will execute. This meta data is captured inside a file called the ‘Dockerfile’ and the docker image is later created using this Dockerfile.

Below are the contents of a Dockerfile that mentions the specific JDK to be used, which port the service will be exposed on, the executable Spring Boot JAR (aka REST service) and how it will be executed inside the container. Please create/save the Dockerfile in the tower folder.

Prepare Docker image
Once the Dockerfile is ready, it can be used to create a docker image using the following command on the command prompt:

docker build -t sb-tower-service:V1 .

Let’s break down the command below

docker build -t is the command to build a new docker/container image with a name:tag
sb-tower-service is the name of the docker image
V1 is the tag associated with the docker image

Please ensure the Docker Desktop tool/service is running prior to building a docker image, otherwise, the image creation will not succeed. Now, once the previous command is executed, an output similar to below should be seen on the command prompt/console.

The newly created docker should also be visible in the Docker Desktop tool (Dashboard -> Images).

An alternative method to check about docker image creation is to execute the command ‘docker images’ on command prompt and it should show the newly created image (i.e. ‘sb-tower-service’) along with other images.

Start Docker container
Once the docker image is created (built and available), it can be used to then create a container (that hosts a running instance of the ‘tower’ REST service). Execute the following command on the command prompt:
docker run -p 8085:8085 sb-tower-service:V1

Let’s break down the command below
docker run – this instructs docker to run a new container with an indicated image
-p indicates port mapping (host port to container port)
8085:8085 - indicates that requests on the host port 8085 (where you can traffic) should be sent to the container’s port 8085 (where container is listening) for servicing
sb-tower-service:V1 – this is the docker image with its tag that was created previously

After executing the command, we should see an output similar to below:

The container (provided a random name by Docker) should be visible in Docker Desktop also, similar to below:

Verify the REST service (running in Docker)
Try hitting the application URL again via CURL/Postman/browser (http://localhost:8085/tower) and we should see an output like below; the only difference is that this time, the service response is coming from the service instance inside Docker container.

Additionally, let’s observe the logs generated by the application by clicking on the container name (in Docker Desktop) and go to Logs tab:

We should be able to see the message “Tower Service is Up” in the container logs.

Summary

We saw how a simple Spring Boot REST service can be containerized using Docker on a developer desktop – no super heavy hardware requirements, no new equipment - with minimum setup. In the Part 2 of the article series, we shall try to cover additional use cases like multi-instances (of same service) and more.

It is also worth nothing that this article focussed more on ‘running commands’ for a closer understanding/experience while there are plug-ins and utilities that can automate some of this.

Would appreciate any feedback for improvement on the approach and content.