Hazelcast Integration With SpringBoot

Target Audience

Developers who are familiar with Java and Spring Boot [with maven]

We all are building various applications in Spring Boot. Spring boot is a simple lightweight spring application with the integrated server. We can run java[spring] application without any hassle, with most of the things are driven by application properties.  We run single Spring Boot application in the single JVM. Many times we have to run more than one instance of the same application, to manage a large number of requests. We put these instances behind the load balancer, and load balancer will decide which instance should handle the current request.

Simple Pictorial Design

Screen Shot 2018-04-09 at 4.20.39 PM

So our request comes to the load balancer. The load balancer is the entry point of the request. Here we have App 1, which have 3 instances.

Instance: Same Application running in the different server [or in there scope].

So, whenever request goes to any of the instances of App 1, it should behave in the same manner. We create multiple instances so that we can handle more requests. Consider these 3 green regions as separate JVM [seperate tomcat sever].

As we all know two JVMs does not tall to each other, We can consider JVM as an isolated boundary to run a Java application.

Problem Statement

Now suppose you want to somehow share data between these 3 different instances running on different JVM. Assume you need to count of the total number of request server by App 1. If we create a single variable in App1, which will be auto incremented each time request comes to application, it will not solve our problem. Lets name variable requestCounter. Now suppose the total number of request come to load balancer be 3.

Flow Of Request

  • Request 1 goes to instance 1
  • Request 2 goes to instance 2
  • Request 3 goes to instance 1

If We request for the total number of requests server by App 1

  • Instance 1 will return 2
  • Instance 2 will return 1
  • Instance 3 will return 0

Though App 1 serves total number 3 request, all instance provide the wrong result. This is because  we are saving the requestCounter variable at an individual instance, thus every instance is giving the response of its state. We can either get the count from all the instance and sum it, but assume if you have hundred of instance of the same application, how you will do that.Even if we are ready to call each instance, we need to maintain the IP address of all the instances which can be very difficult.

For the same, we will you Hazelcast. What Hazelcast  will do, it will share the state of variable among different instances [JVM].  So in this blog, we will create a simple Spring Boot Application with HazelCast support. And try to share a single long variable among the different instances of Application.

Spring-boot  Setup With Hazelcast

Create Spring Boot Application[Sample Application on Git]

Go to Start Spring IO to create a vanilla Spring-boot Application with Java, Maven and Spring Web as the dependency.

Add HazelCast dependency in the pom.xml


 com.hazelcast
 hazelcast-spring 

Create a class HazelcastConfig inside config package [create package also]

@Configuration
public class HazelcastConfig {

@Bean
public Config hazelConfig(){

Config config = new Config();
config.setInstanceName("hazel-test");
config.getGroupConfig().setName("dev").setPassword("pass");
return config;
}
}

 

  • Line 8 represents the instance name, it should  be different for each instance, in our case Instance 1, Instance 2 and Instance 3
  • Line 9 represents the group. in our case it will be App 1, Since there can be much application you are running, you want to share hazelcast cluster among instances of the same app. In the code above we have used dev [App1]. On the same line, we have set the password also, as to avoid adding the cluster of different instance among the same group.

Now add the TestController, which will use the shared variable.

@RestController
@RequestMapping(value = "/api")
public class TestController {

@Autowired
private HazelcastInstance instance;

@RequestMapping(value = "test")
public String appName(){

return "App1" + instance.getAtomicLong("long-test").incrementAndGet();
}


}
  • Line 6, we have bound the hazelcast instance.
  • Line 11, we are taking Atomic long [“long-test”] variable and simultaneously increasing its value.

Now your code is ready, start this spring boot application twice on the different port. Let’s assume we have started two instances on port 8080, 8081.

 

This is a very simple POC for haze-cast integration with spring boot, it has enormous usecase, We will see some the use cases.

Other Use Cases

  • To maintain the session amoung distributed application.
  • Have distributed cache, [If we maintain cache at the instance level, then cache created at instance 1 will not benefit the instance 2]
  • Distributed in-memory data storage.[Hazelcast contain replica also in case some instance goes down]

 

 

 

 

Advertisements

How to fail with MicroServices

microservices

 

As we all know, microservices is the new god in the tech industry. Yes, we always have old gods and new gods. Surely microservices have been accepted by the many of the companies, without even understanding how the business will be aligned with it.

Let’s not discuss what is microservices, but we should surely discuss what not to do if you don’t want fire on your ass.Today will try to discuss few of the shortcoming which I have felt after I have[NOT]proudly redesigned the system from monolith to microservices.

  • Domain is Important, But not the same Domain For every one

We all know the domain is very important for every application.Let’s make our code closer to the real-world entity. But does the sharing of domain make sense?Often people debate about how come we can have a different domain for the same entity.For example, let’s have a Flight domain, Flight will be flight, no matter it is in search service or booking service. Flight can have different attributes in both the context.And you will never replicate these attributes.Never create a single jar of domains to share it among different services. If you have to just kill other your services.

  • How services are talking to each other

Often developers create many microservices, they all the talking to each other in exactly the same way, it has been doing if they were a monolith.Direct interaction with microservice can be dangerous, can create a bottleneck for a process. Try to design a system in such a way that one service should not be waiting because of the action from another service. Utilize the power of asynchronous request using the messaging queue or any other design.Blocking request can be a hassle. Don’t just create distributed monolith

  • Complete System Design is Important, Microservice alone cannot do anything

When you are designing the microservice, you are not designing it for fun. It will eventually be plugged in the system to complete the bigger task. So know your system design. All the constraints against which your service will be run should be known. Development of microservice can be done in the isolation, but the birth of any microservice should always be an outcome of whole system design.

  • Be Ready before you start, DevOps if your key

devops.png

You can ask yourself, why the concept of microservice in a boom these days. This is because now we have such a capability which can handle such a massive complexity. So DevOps is too important. If your DevOps is not ready to support the proper microservice architecture, never ever think to go towards microservices.You can never create a home if your basic structure is not setup first.

  • Don’t try to clean the mess of other

144158-145685

Your service is not designed to clean the work of any other service. If any service is not doing its task completely, it’s not your duty to do it, ask that service to do it. There was a very simple example which I want to share, I was consuming one of the services whose owner was sitting beside me. Few of the attributes were missing from the result of that service, so I asked the owner to provide me the missing data, but the conversation finally went in a disappointed way. The owner asks me to fill the data by myself as getting those data points were very difficult for that service. And eventually, my service ends up doing a task which was not in the context of its boundary.

  • Learn from others, but don’t ever replicate their mistakes

We often share code, when a business is trying to solve the same kind of problems they often end up using the same type of approach/code for the different problem statement. There may be a chance good chance you will solve a problem very quickly by just simple copy paste, but you never know the constraints under which that code was written. With the power of that code, your are also copying the weakness of it. Learn from others, but never accept its solution for granted.

  • Let the services to micro, not the knowledge pool 

 

shareLogo

In the last point, I have discussed how dangerous the code replication. But This point doesn’t say we should blindly learn from other services. What I want to point out here is share the knowledge of other services, either the technical findings or the business constraints. Because in the end every micro service a broken piece of a giant puzzle

  • Let the code be agile, not just the process

Often people make the process agile but forget that if your code is not agile you cannot achieve agility. Make your services loosely coupled.Each service should be independent, and there should be minimum effort even if we have to rewrite the entire service.

  • Monolith business with microservices is as bad as Monolith

“This is the way things are done here”. One of the very old statements from old timers or from the business guys. But this will never help a project. If your system is going toward microservice, itis very important your business should also reflect the same, or honor it.At the end business thinking will be reflected on your system.

  • Common decision for every service is a hazard

Since every service is designed for its own purpose, a single and common solution can be dangerous for the lifecycle of services. It is very similar to the problem of selling shoes in the two very different geographic area.

  • Frameworks as awesome, but maybe not awesome for every service

Frameworks are awesome, it will hide the complexity from the developers, and magically do a lot of the stuff. But in-house framework can be a risk to the ongoing project. If you add the in-house framework to each and every service of your, you are binding the bugs associated with the framework to every service. It even often delays the release cycles.

  • Event Sourcing, I will be another Netflix

Don’t just use any of the modern design just for the sake of using it. Understand the business requirement first. Analyse the scope of your problem in terms of the traffic and availability of the system. What I have seen people often used event sourcing even to solve the simple problem stating the reason “We will be next Netflix”.

  • Different shops, with the same warehouse

Lest assume we have 5 different shops, but all the shops using the resource from a common pool. We have 10 resources in the pool and 5 services.Ideally 2 resources for each service, but if one of the services goes greedy/faulty and consumed 8 resources.Certainly there is a resource crunch for other services. even though other services are related to service one, but it got affected because of it. Same conditions are very common whenever we are using the same Database for the different microservices.Even in normal conditions, we know that database will be the choking point in the high traffic situation. Should implement the seperate database for separate services.

  • Pool of PolyGlot can be a pool of death

This point is more in the concern of the company.But not just company is affected, even the developers are affected, as it often increases the effort in maintenance. Choosing entirely different tech stack for each service can increase the project cost, as you need the tech specialist for each tech. Sharing of tech knowledge will be limited. And often the company cannot afford many tech specialists for tech, so eventually, it can let to the dependencies on few of the forks.

  • Anonymous service is a ghost

One of the common design we can see these days is, if few of the task which is not a good fit any of the existing services, developer eventually put all these tasks in the anonymous service, where no one knows what is happing. Service with no boundary, no exact reason. I call these kinds of services as a ghost. Ghost services are dangerous, and they are often the result of poor design or to support existing business for the time being. But remember you can never get rid of the ghost, and they will haunt you from time to time.

 

All these are the points which are the concern for me, maybe true or not true for you. These can be avoided or can be tackled with different designs, but do consider them before it late for your service.