Abhishek Soti

Hello. Yes. So, I'm Abhishek Soti. I have more than 9 years of experience with back-end technology, and my tech stack includes Java, Spring Boot, microservices, REST APIs, SQL databases, NoSQL databases, Docker, and Kubernetes. These are the technologies I have worked with, and I am open to learning any new technology required for the job. Regarding my experience, I have worked in different domains. For example, my first company was a finance company. Then, I worked at a startup that I founded, which was an EdTech-based company. After that, I worked in investment management and mutual funds at Fidelity International, where I was a Java developer. Currently, I'm working with Accenture on the Vodafone UK project. I'm building an ecommerce-based web application, and I'm currently working on the back-end side of it. It's based on Java, Spring Boot, microservices, REST APIs, and I have also managed the CICD of this application using Amazon CodeBuild and CodePipeline. It's deployed on ECS using Fargate, and the Docker images are pushed into the Elastic Container Registry. So, that's pretty much about me.

To implement a Python-based script to automate health checks across a network of Spring Boot microservices, we would need to have the actuator enabled in our application. And we would also need to have some sort of logging and monitoring system, which can be comprised of Prometheus, Grafana, or an ELK stack, through which we can monitor the health of our Spring Boot microservices. We can also have Dynatrace. On AWS, we can write few scripts which can keep track of whether our application is up and running or not. It will keep triggering the Python-based script, which will keep triggering the actuator endpoints, actuator health endpoints. And through that, we will be able to determine if the endpoint is not working. We will also write the logic to send an email notification to the respective owners of the microservices or whoever is looking into the support of that application.

So to introduce a new microservice into an existing ecosystem, I would. If the current architecture is based on Eureka servers and Eureka discovery, I would need to have this new service also registered in the Eureka server. If I'm not going ahead with the Eureka server, new communication between this application will be based on a REST API through a REST template or web client call. If this microservice needs to be based on an event-driven architecture, I would also implement 1 Kafka queue between this new service and the calling application, which will act as a consumer in that case. I will be consuming these app messages from my partition. That's how I will be doing it. For a deployment, I'll be using a Docker-based, containerized system. I will create the Docker images, and I will use ECR and ECS or an EKS on Amazon to deploy and containerize this application. I will also have log monitoring through AWS CloudWatch or Prometheus, Grafana, Dynatrace, ELK Stack, or any other new tool that's available in the market. That's how I will be managing this application.

The strategy to ensure zero downtime deployments in microservices using Spring Boot would be based on the green blue green blue deployment. What happens is there will be two servers which keep a copy of my microservice. First, the deployment would be done on the green server. And after proper health checks are done on this artifact on the green server, then we will initiate deployment on the blue server. This will all be managed through a Python script, and we have also written an automation suite, which will take care of testing the green deployment, whether it is done correctly or not, and whether we have everything in place or not. So after that is done, we will do the blue deployment. And that's how the deployment would be done to make sure there is zero downtime for my microservice. First, in my load balancer, when I will be deploying on the green server, I will switch off incoming requests from the external network so that I am not making any calls, so that my green server is not taking any calls. All calls will be routed to the blue server. And once the green server is up and running, I will redirect traffic from the blue server to the green server. Now the deployment will start happening on the blue one. And once the blue deployment is also done, the load balancer will again come into play and will distribute the load between these two blue and green servers.

So, yeah, so Python can be integrated with Java-based microservices, and the potential is, basically, when we are trying to manage deployments in the cloud environment. That's when Python scripts can come very handy, and everything from image creation to actual deployment can be managed through Python. The potential pitfalls of such an integration is, basically, if the developer is not aware of how to do it in Python, how to write such code in Python, so there will be a learning curve involved. And that could hamper the actual downtime. So, there will be a learning curve in that case, which might slow down the actual deployment. That's what I think. That's the major pitfall while doing such an integration through Python. Also, if the automated script is not correctly written and if the test cases are not correctly defined, there will be challenges with this approach. We would have to be very sure of whatever we are writing and that it is correct and of the highest quality.

So, these steps of integrating Python-based AI models into an existing Java microservices architecture. The steps for this integration would be to place the Python model for deployment and automation checks. If the microservice is healthy enough for health checks to be done correctly. That's where I think the AI models can come into picture, and the Python-based AI model can streamline the entire testing and deployment of our Java-based microservices.

So, the problem with this code snippet is that in a multi-threaded environment, this could lead to multiple instances of the singleton getting created, which we do not want. And so to take to make sure that this does not happen, we will be implementing a double-checked locking mechanism for creating this instance. So when we are writing this get inside this get instance method, we will be putting in a synchronized block when the if block. So if instance is double equals to null. After this, we will be writing a synchronized of and making a lock in the singleton dot class. Inside that synchronized block, we will be creating the instance is equals to new singleton line so that we are completely sure of that only one singleton instance is getting created in a multi-threaded environment. So, yeah, that's how it will be done.

Yeah. So the problem with this code is that it intends to lazily initialize an instance of a service. The problem with this approach is when a single thread is trying to access this get service instance method, another thread can also come in and while trying to create a new service instance, there can be two threads that can be doing the same thing, and it will eventually have two service instances, which is not correct for a multithreaded environment. So instead of that, we should be implementing some locking mechanism for the service instance so that only a single instance of this service factory is getting created. Single instance of this service instance is getting created. So that's how it should be done.

To develop a comprehensive backup strategy for a microservices ecosystem that spans multiple data sources, we should first have these data stores in different availability zones, so that if there is a mishap at one of the availability zones, another data store is keeping a copy of the entire database, safe. And we should implement a master-slave architecture for multiple data stores to maintain consistency across all the data sources. We can have multiple slaves and only one master, with the multiple slaves responsible for reading operations and that one master responsible for write operations. So write is only happening on one data store, one copy of the data store. And in case, we should regularly back up all the data that is there in my master. We should regularly update the data amongst the slaves so that in case the master goes down for some time, any of the slaves can take the place of that master and act as a master copy for the entire data store, multi-data store architecture. That's how the backup strategy should be working. We could have multiple availability zones where these data stores are kept, and that will ensure we have a 0 data loss policy.