SOA

Client Side Load Balancing Vs Server Side Load Balancing: How Client Side Load Balancing works?

Udara Wijeratna Leave a comment

Firstly let’s see what is load balancing;

It’s mainly distributing work of a computer to two or more similar computers. This ensures reliability and increases the responsiveness of the system.

 

 

Load balancer generally group in to two categories.

Layer 4: Act in network and transport layer protocols (IP, TCP, FTP, and UDP)

Layer 7: Distribute requests based upon data found in application layer protocols such as HTTP

 

Also Load Balancer (LB) reside in two types, (more information)

Hardware LB: F5 BIG-IP, Cisco, Citrix

Software LB: NGINX, HAProxy, LoadMaster

 

All these different load balancers uses different algorithms to distribute the load among the application pool. Some of the industry standard Load Balancing algorithms are:

  • Round robin: This method continuously rotates a list of services that are attached to it. When the virtual server receives a request, it assigns the connection to the first service in the list, and then moves that service to the bottom of the list.
  • Least connections: The default method, when a virtual server is configured to use the least connection, it selects the service with the fewest active connections.
  • Least response time: This method selects the service with the fewest active connections and the lowest average response time.

Now that’s all about the very basic theory in Load balancing. Now let’s see how Server side load balancing works in the real world.

 

Server Side Load Balancing

A Server side load balancer sits between the client and the server farm accepting incoming network and application traffic and distributing the traffic across multiple backend servers using various methods. Mostly load balancer will check the health of the server pool underneath and use the algorithm which we discussed earlier to distribute the load.  This was the most common mechanism we used in the past to manage our application load. However the upswing of Client Side Load Balancing is now on the peak. Let’s dig deep on that context.

 

Client Side Load Balancing

As we discussed, in the server side load balancing, a middle component is responsible for the distributing the client requests to the server. However that middle component is moving out on the decision making in the load distribution. Client itself will decide on the server it need to forward the request. How it work is very simple: Client holds the list of server IPs that It can deliver the requests. Client select an IP from the list randomly and forward the request to the server.

With the microservice architecture, Client side load balancing plays a major role. Services like Netflix Ribbon and Eureka components helps client side load balancing have similar features to server side load balancing like fault tolerance, caching and batching.

Let’s see how Eureka and Ribbon work together to achieve the client side load balancing in microservice architecture.

 

As per the above diagram, let’s assume Microservice B wants to communicate with Microservice C. So Microservice B is the client and now it will use the Eureka client and get what nodes (server list) are available in Microservice C. Then using ribbon client in the Microservice B, it will call the Microservice C using default round robin algorithm. So the method which Microservice B used to call Microservice C is known as client side load balancing. Which illustrates that client is the one decide on the server which need to call not a middle component like in Server side load balancing.

 

All the links are provided as references to get more inside on the topic we have covered. Especially how you can use Netflix OSS to achieve client side load balancing in microservice solutions.

 

References

 

Read More

How Microservices fitting in Enterprise SOA Solutions

Udara Wijeratna Leave a comment

In previous posts we discussed on different topics of Service Oriented Architecture and Microservices. In this post we will discuss how Microservices moving in to the traditional SOA solutions.

In software engineering, SDLC (System Development Life Cycle) is a well know process. Similarly when we want to develop SOA solutions, there is similar process which is illustrated in the below diagram.

In the Service Oriented Analysis and Design stages, microservices comes in to the picture.  Before we proceed let’s get a quick introduction to microservices. In SOA world microservice represent a specific performance / reliability requirement (business process) in a SOA solution. Its holds a distinct implementation environment optimized to support special processing demands that required for performance and reliability needs. Microservice is an independent service, however when a microservice needs to access other resources (services), those resources can either be replicated or redundantly implemented so that they remain part of the microservice’s local processing scope. Therefore, when it is decided that a microservice needs to compose another service, the composed service may be redundantly implemented and deployed together with the microservice.

 

Service Analysis and Modeling Process

Now let’s check how microservices are produced in a SOA solution on a given Business Process.

 

Step 1 | Analysis of the Business Process:

Main goal of this step is to decompose the business process to smaller processors. To achieve this we can follow the below steps

  • Identify main processors in the business process
  • Breakdown each main process in to small processes
  • Draw the detail business process flow diagram
  • Identify small processes which cannot be automated or should not be automated. Those processes should only handle through a manual process. So remove them from the list of process which are candidates for service implementation

 

Step 2 | Define Entity Services:

From the list of processes which are candidates’ service implementation, find out reusable agnostic services candidates and its capabilities.  Those services can be categorized as entity services.

 

Step 3 | Define Task Services:

These are the services which has process specific logic (non-agnostic). After identifying the entity services, the remaining can be categorized under task service. Normally we can find business rules, conditional logic which is specific to a process in this kind of services.

 

Step 4 | Apply Service Orientation:

Revisit the services which we have categorized and try to apply service orientation principles on them. Service loose coupling, Service abstraction and Service autonomy to those services.

 

Step 5 | Identify Service Composition Candidates:

In this step, we will look at the entity and task services that we captured during earlier stages and check whether those are candidates for service compositions.

 

Step 6 | Analyze the processing requirements:

For each process / sub process we need to follow the following steps to identify special requirements

  • What are the processing logic required in each service
  • Did we identified them earlier or do we need to redevelop them
  • What are the external resources we need to access via our services (DB, Message Brokers, Legacy systems)
  • Any logic critical for performance and reliability
    • This is the point where need of microservices comes in to picture in SOA solution
    • By producing performance and reliability critical services as microservices, we can ensure other services won’t have any impact from those performance critical services. Since those are run independently

 

Step 7 | Define Utility Services:

From the agnostic processing logic which we identified earlier, check if there are any reusable utility services. For example logging services and notification services.

 

Step 8 | Define microservices candidates:

Revisit the non-agnostic process logic which we identified earlier and determine any of the logic can be represent as microservices. Ideal candidate for a microservice would be

  • Volatile requirement
  • Performance requirement
  • Runtime reliability and failover requirement
  • Service visioning and deployment requirement

 

Step 9 | Apply service orientation:

As we did in the step four, repeat the same process to utility and microservices which we identified earlier

 

Step 10 | Revisit the service composition candidates:

Check whether we can use the microservices and utility services for other service requirements

 

That’s pretty much it, on the process of analysis and design stage of services in a SOA solution. So we can clearly see where the microservices coming in to play in the SOA solution development process.

 

References

Read More

Is Microservices Architecture a sub set of SOA? (Understanding Microservices Architecture by wearing the Developers Thinking Hat)

Udara Wijeratna Leave a comment

In the previous posts we looked in to the basic concepts of SOA. Thought of moving to a new term in the technology world called Microservices Architecture. Actually the term is the only thing which is new to SOA world. The concepts behind the microservices architecture came with SOA. However if you’re not familiar with SOA and compare the microservices architecture with Monolithic applications development then this would be a new concept for you. Assuming you have the knowledge in SOA, we will justify the above argument which is Microservices Architecture is a sub set of SOA.

What is Microservices Architecture?

Microservices architectural style is an approach of developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. – “Martin, Fowler”

Let us concentrate on the definition of microservices architecture and discuss about each special characteristics.

The concept “small services which build around business capabilities”, is a concept we discussed under SOA. Which is Agnostic Logic and Entity Service concept in SOA. Those services are reusable, also concentrate on single small business problem.

The statement “Developing single application as a suite of small services” is yet another well establish concept in SOA known as “Service Composition”. There we have a Service Inventory which is a collection of reusable small services which will help to compose large services / applications.

The newly introduce concept on microservices architecture when compare to SOA is; microservices is individually deployable services which make them very easy to apply continuous integration and deployment. Where in SOA we deploy our services in shared resources. Microservices architecture is more driven by DevOps practices. Mostly deployed in cloud infrastructure, each service has the capability to auto scaling in built. With the immerging container technologies like Docker and surrounding technologies like Mesos and Kubernates will ensure the deploying micro services will be more unwind than ever. This concept will maximize the decoupling of logic and in addition the platform they are deployed. In the long run microservices architecture will minimize the change management cost compare to traditional SOA.

However if you have properly deign and implemented your SOA solution then you should be able to easily deploy your services independently in Tomcat / Nginx application servers across the nodes in your cluster too. Which will cover the key feature in micro services architecture.
In SOA, ESB and BPEL orchestration software plays a major role in building communication structures between different systems enterprise applications. Let’s see how microservices architecture replaces those tools.

 

ESB / BPEL Tools vs Smart Endpoints and dump pipes

Enterprise Service Bus (ESB) main capabilities are message routing, choreography, transformation, and applying business rules. In the microservices architecture ESB capabilities are covered through smart end points and dump pipes. REST protocol with different end points (smart endpoints) which has appropriate logic behind it will ensure the covering of ESB and BPEL orchestration capabilities we see in SOA. Application of a lightweight message bus act as the dump pipes in microservices architecture. It can be simply implemented using tools like RabbitMQ. The key added feature from dump pipes is reliable asynchronous messaging between services which is also common in SOA.

Below diagram illustrate the how microservices architecture differentiate from SOA.

Conclusion

So we can clearly see microservices architecture does not have much difference compare to SOA other than the deployment platform. Further as many articles express; “Microservices architecture is a design pattern of SOA” and Microservices architecture is a new term introduced to latch a new look to very old concept called SOA.

 

References

Read More

Building the Service Oriented Solution

Udara Wijeratna Leave a comment

Previous Blog Posts

As we learned from the previous posts, the main strategic goal of Service Orientation is that service must be inherently composable.

As you can see in the above diagram we can reuse services and compose service compositions which will provide a comprehensive solution for a complex problems in the business domain.

So as the time progress developers will get new requirements and as the first step they will check the service inventory.

Then do a proper design for the new business problem on what identifying what are the services they can reuse and what are the services they have to write from scratch.

The new services must be compliance with the set of rules we defined in the earlier posts, and must be placed in the service inventory with intention of future reuse and composition.

Domain Service Inventory

In a large organization which has multiple business domains it’s hard to maintain a single service inventory. So to ensure quick service discovery and easy maintenance, there we introduce a concept called Domain Service Inventory.

Each of the domain inventory is standardized and governed independently. For example, Finance, Shipping, Cargo, HR like domains can be exist in a large organization which has multiple subsidiaries. So having inventory for each domain will be a more organized inventory.

 

Now we completed the design of a Service Oriented Solution. In the coming posts lets investigate on how we can implement those using JAVA and many other systems in the global market.

 

References

Read More

Modeling the Service Oriented Solution by Breaking down the Business Problem

Udara Wijeratna Leave a comment

Previous Blog Posts

In this post we will work on how to model the Service Oriented Solution for a particular business problem.

Firstly what is a Business Problem?

It’s a business process which required automated solution. After implementing the business solution business will achieve the following goal.

  • Increased intrinsic interoperability
  • Increased federation
  • Increased vendor diversification options
  • Increased business & technology domain alignment
  • Increased ROI
  • Increased organization agility
  • Reduce IT burden

 

Let’s start the real work by organizing the business process actions into two primary categories which we identified in the earlier post, Agnostic & Non-Agnostic.  To do so we need to do the following steps

  • Functional decomposition : Identify the large problem and then create small collection of problems which will represent the large problem. Then find the solutions for each of the small problems. This method is also known as “Separation of concern theory”

  • Service encapsulation : In this step we need to identify what subset of logic needs to encapsulation within a service

 

Agnostic Context (Reusing the solutions)

  • Reusing the agnostic services : Now we have reusable solution logic units with proper encapsulation. Identification of solution logics which can reuse to solve different problems will take place in this step.

 

  • Utility abstraction : Separate the common, cross cutting functionality that neither specific to a business process nor a business entity . In the service inventory we will have a utility service layer, which can be used in services.
  • Entity abstraction : Similar to utility abstraction, we will identify services which are related to business entities and have them in the entity service layer of the service inventory.

 

Non-Agnostic Context

  • After identifying the all the above solutions related to agnostic context, remaining solutions will be specific to business processes.

 

Now we have organized the solution properly from the above process. So let’s build the Service Oriented solution in the next post.

 

References

Read More

Service Oriented Enterprise Architecture

Udara Wijeratna Leave a comment

Previous Blog Posts

Previous blog post, we had an introduction to SOA. In this post let’s find out how we can apply SOA in our enterprise solution.

In theory we have Eight Deign Principles which we need to follow in Service Oriented Design Model.

 

When we apply SOA with the above design principles we can observe the below characteristics in our enterprise solution

 

In-addition our SOA solution can be one from the following types;

Service Architecture: Architecture of a single service

Service Inventory Architecture: Architecture that supports a collection of related services that are independently standardized and governed

Service Composition Architecture: Architecture of a set of services assembled in to service composition

Service Oriented Enterprise Architecture: Final outcome which is the Architecture of an Enterprise

High level positing of those types are shown in the below diagram

 

Now we have a clear idea about the design principles, SOA characteristics and four types. In the next post let’s further discuss about Service , Service Inventory and Service Composition.

 

References

Read More

Introduction to Service Oriented Architecture (SOA)

Udara Wijeratna Leave a comment

SOA is a concept which was introduced in late 1996 and now it’s a fully-fledged concept in enterprise application development.  However this blog post is mainly focus on technical people who are new to Service Oriented Architecture. Firstly let’s start as a beginner and then discuss about more advance topics in the coming posts.

Will start our discussion by concentrating on the three words which makeup the SOA; Service, Service Orientation and Service Oriented Architecture.

 

Service

In software application world service is small to large scale unit which contains a solution for a business problem. In SOA, web services are the main component that we relate as a service. However we need to keep in mind that web service is not the only service we consider in SOA. As explained above it can be in any form.

In SOA we can describe service as a collection of capabilities. Service will expose functionality of an application without a user interface, so it can be utilized by other applications / components.

 

Service Orientation

The word Orientation means coordination or positioning. So when we take the service orientation, it’s a design model that derived from establish design practices and technology platforms which coordinate / position services to provide solutions for large business problems. Service orientation is a vendor and technology natural model.

 

Service Oriented Architecture

We have services which have some set of capabilities that can be used by applications. Also we have a well define design model that define on how those services can be coordinate with each service / application. Hence SOA is the architecture that result from the applying service orientation.

 

Now we know how SOA is derived. Therefore, let’s discuss on how we can adopt to Service Orientation design model in the next post.

 

References

Read More