Simple introduction to NServiceBus
 

What is NServiceBus

NServiceBus is a Microsoft .Net based framework for implementing the Enterprise Service Bus pattern. Its a framework for implementing reliable messaging through various transports without having to write boilerplate code. NServiceBus also provides facilities for pub/sub, retries, format abstraction, encryption, workflow orchestration, and scalability.  Below are few highlights of the system.

  • Seamlessly work with various messaging systems (Transport)
  • Automatic Serialisation & De-serialisation
  • Enforcing a Bus architecture
  • Transaction Scope (Unit of Work)
  • Simple model to handle long running transactions (Sagas)

Building a simple Unicast bus using NServiceBus

Let’s use .Net core 2.0 for building a simple bus. Everything in NServicebus can be configured using a simple class called “EndpointConfiguration”. An endpoint is a service which uses NServicebus framework for handling messages.

var endpointConfiguration = new EndpointConfiguration("UnicastBus");

NServiceBus uses persistence to store all the configuration and temporary data so that the data is not lost while there is a failure (fallacies of Network). We can configure NServiceBus persistence using the below code. We are using an In-memory persistence for the sample app. But in real applications, other reliable persistence like SQL, Raven, Azure Service fabric etc. will be used.

endpointConfiguration.UsePersistence<InMemoryPersistence>();

NserviceBus is a framework and is not a message queues on its own. However, it uses an Adapter pattern to fit any open source & commercial queuing systems. In our case, we are wiring it up with RabbitMQ (an open source message queuing system written in Erlang).

var tranportExtensions = endpointConfiguration.UseTransport<RabbitMQTransport>();

tranportExtensions.ConnectionString("host=localhost;username=guest;password=guest");

RabbitMQ also has a concept of routing topology where a user can configure how data is passed between exchanges & queues. In our case, we are going to use ‘direct routing’ topology.

tranportExtensions.UseDirectRoutingTopology();

var routing = tranportExtensions.Routing();
routing.RouteToEndpoint(assembly: typeof(Order).Assembly,destination: "Sales");

Through this configuration, we are pushing all messages coming to “Unicast Bus” exchange to “Sales” exchange. That’s it, we are good to start the Unicast bus.

var endpointInstance = await Endpoint.Start(endpointConfiguration).ConfigureAwait(false);

Now, sending messages using the bus that we just created is simple.

endpointInstance..Send(“My First Message using NServiceBus”);

To see the result, we should run the program and look for messages in the ‘Sales’ queue in RabbitMQ management tool.

Conclusion:

NServiceBus is one of the frameworks for doing reliable messaging for handling the fallacies of distributed computing. This is just a gentle introduction to NServiceBus. We shall see more advanced concepts in the future posts.

Docker – Basics and Benefits
 

Docker

How many times have you encountered a situation where the software built on one platform doesn’t work on another platform? It is a very expensive affair to ensure that your software works on all the platforms (Mobile, Tablets, PC and so on). This is one of the crucial problems which Docker helps you to resolve but this is not it. There is much more to Docker which we will explore as we move in my upcoming blogs.

Docker is a container management service or a tool which is designed to help developers to deploy and run applications by using containers.  It ensures that the code will behave the same regardless of environment/platform.

Key components of a Docker

  1. Docker File – A dockerfile is a text document that contains series of all the commands a user a make use of to create a Docker Image. The Docker images are automatically built by reading the instructions from a dockerfile.
  2. Docker Image – It’s a lightweight snapshot of a virtual machine. It is essentially an application with all its requirements and dependencies (read-only copy of OS libraries, application libraries etc.). When you run a Docker image, you get a Docker container. Once a Docker image is created, it guarantees to run on any Docker platform. These can be retrieved to create a container in any environment.
  3. Docker Registry – A Docker image can also be stored at online repository called Docker hub.  You can also store your image in this cloud repository (https://hub.docker.com/). You can also save these images to your version control system.
  4. Docker Container – A Docker container is nothing but a Runtime instances of Docker images.

Benefits of a Docker

  1. Build your application once and use it in multiple environments without the need of building or configuring once again. The application built on dev environment guaranteed to work in prod environment.
  2. Centralized Docker repository makes it very easy to store and retrieve. Moreover, you don’t need to build the image from scratch.  You can always leverage existing image and go from there.  The sharing of an image becomes very simple as well.
  3. Version Control – You can always create next image and version control them.
  4. Isolation – Every application works inside its own container and never interfere with other containers.  If you no longer need an application, you can delete its container. Every container has it’s own resources hence there is going to be no challenge.
  5. Security – The isolation ensures that the applications that are running on containers are completely segregated. The container cannot look into or have a provision to control processes running on other containers. This greatly enhances security.
  6. Multi-cloud platforms/Portability – The image built on Amazon EC2 would very well be ported to Microsoft Azure.
  7. Productivity – This is an implicit benefit of using Docker. The speed of development is much faster as the main focus is writing code and business over worrying extensively about deployment/testing.
Why choose Couch DB over Relational Database?
 

Why choose Couch DB over Rational Database?

Choosing a correct database is very important in software development.

The relational database maintains ACID rules. Relational model requires relational database engine to manage writes in a special way. It locks the rows and table to maintain atomicity and consistency. Protecting referential integrity across the tables and rows increase locking time. Increase locking time means higher latency and slower application. Developers face some problems with the Relational database such as:

Object Relational Impedance Mismatch: When RDBMS is being served by an application program written in an object-oriented programming language, objects or class definitions need to be mapped to database tables defined by a relational schema. Misalignment layer of application objects to tables and rows is called Impedance mismatch.

As an example, below are the schema definitions:

Below is the application code:

Class Foo
{
int Id;
string[] colours;
}

In this example, object foo contains field Id and colours (which is a bunch of strings). To store this into the database we need to create 3 tables.

  • Main object
  • Colour information
  • Relation between color and main object

These forces the developer to write a mapping layer such as Entity Framework or ado.net to translate the objects in memory and what is saved in the database.

Many of the developers use object-oriented languages in development. Objects are not rows and tables. All objects are not uniform. Mapping those objects into rows can be painful.

Couch DB is schema-less. There is no relation between a collection of objects. A developer can store any type of document. The documents can be flat and simple or as complex as the application requires.

Couch DB document for “Foo”:

{

ID:1,

Colours:[“red”,”yellow”]

}

Scalability Issues: Scaling out and replicating data to other servers need to increase the lock. Relational database tries to be consistent and increase the locking time and as result application gets slower.

Replication is one of the features in couch DB. Replication takes advantage of clustering to achieve scalability. We just need to mention the source and destination database. Couch Db will handle to replicate the data into a destination. This can also be achieved through a REST call. It should be a POST request to the endpoint “_replicate” with the source and destination servers specified in the body of the request.

RDBMS With MS SQL SERVER NO SQL WITH COUCHDB
Define table No schema
Rows and Columns Document
Dynamic Query Predefined query
Join/Relations Not required
T-SQL Map Reduce
OLEDB/ODBC/EF/ADO.NET REST API
Management Studio Futon
Constraints, Triggers, SPS Validations, show & List Functions

 

Couch Db stores JSON for documents, JAVASCRIPT as MAPREDUCE queries and HTTP for an API. Couch DB can be considered as a b-tree manager with an HTTP interface. It uses a data structure called a B- tree to index its documents and views. It maintains optimistic concurrency via MVCC (Multi-version concurrency control). Previous versions of a document are available till the database is compacted.

B-trees append data only to the database file that keeps the B-tree on disk and grows at the end. B-tree delivers fast searches, inserts, and deletes.

Couch DB features on the server-side document validation and on the fly document transformation. Although a document is stored in JSON, the document can be served as XML or CSV.

Architecture OF Couch DB:

The lowest tier is simple JSON based file store. The storage engine is responsible to accept the JSON documents and serialize them into the disc. Storage engine can access the JSON store. The query engine does fast access to the stored in JSON store. The query definitions are JAVASCRIPT functions stored in the database. B-tree structured index is built on every query and stored in a database. This helps the query engine to read the data fast. Replication engine provides capabilities in master-master bidirectional replication. Through Rest API we can access any of the three capabilities.

 

 

 

 

Service Oriented Architecture – Basics
 

The Service Oriented Architecture (SOA) is not a technology instead it is a collection of Services. Precisely it is an architectural style for building business applications using loosely coupled services which communicates with each other.

SOA      =    Messages + Services

Services – Self-contained business functionality and communicate using messages.

Messages – It is a discrete unit of communication.  It should be cross-platform, secure, asynchronous, reliable, follow industry standard and able to describe and discovery service.

The SOA shifts your thinking from classes and objects to messages.

The webservice is nothing but a service available over the web (Or method of communication between two devices over a network) while API (Application Programming Interface) acts as an interface between two different applications so that they can communicate with each other. The API may or may not be web-based.  Having said that all the all the web services are APIs but all APIs are not web services. The webservice always needs a network while for API it may/may not be needed.

WebServices are mainly of two types

  1. SOAP
  2. RESTFul

Let’s understand the differences between SOAP and REST

  1. SOAP stands for Simple Object Access Protocol. REST stands for Representation State transfer.
  2. SOAP is an XML based protocol which uses WSDL for communication between source and recipient. REST is an architecture style protocol which uses XML and JSON to communicate between consumer and provider.
  3. SOAP uses RPC while REST directly uses URL.
  4. The transfer is over HTTP, FTP, SMTP and other protocol for SOAP while for REST it is HTTP only.
  5. SOAP is hard to implement over REST.
  6. The performance is slower compared to REST.
  7. SOAP is more secure since it does define its own security. The REST is less secure. The transport defines the security. (Smart consumer and provide while dumb pipe).

The SOAP message is large.  The core element of SOAP message is a SOAP envelope. The SOAP envelope defines the start and end of the message. It has two parts 1. SOAP HEADER 2. SOAP BODY

WSDL – Web Service Description Language

The WSDL is an XML based interface that is used to describe the functionalities of the webservices .

Microservices to Micro-Frontends
 

Microservices

Microservices is one of the newer concepts and a variant of a Service Oriented Architecture (SOA). Although SOA has been there for almost two decades while the Microservices came into existence in 2012.

Microfrontends

The idea is to have small autonomous services to work together to build the large complex application. The approach focuses on individual business sub-domains and building small services making them easier to maintain, and promotes independently deployable pieces thus ensuring that internal changes in one service do not affect or require the redeployment of other services. In today’s software development landscape, most applications are monolithic and one of the drawbacks of this approach is that business owners get to take a very limited number of decisions in a year (slower response times because of dependencies). For instance upgrading product, adding newer functionality which is significant in size etc within a set of related services requires a concerted effort of all concerned parties to deliver changes in a synchronized manner. Microservices allow you take more far-reaching business decisions more spontaneously as each microservice works independently and an individual team who is managing that has a good control over the changes. This is also helped by the fact that well-implemented microservices attempt to steer clear of the ‘shared database’ model of development (mentioned later in this post).

The microservices architecture allows each team to decide the technology and infrastructure that works best for them, which may be completely different from other microservices that it interacts with for the very same product. Another aspect of choice is seen when attempting to scale a Monolith application, where you need to scale every component as all components under one product typically run under the same process. This usually reduces flexibility that may require only a small subset of the features to be scaled (eg. performance bottleneck in one piece of a payment processing pipeline). Given such circumstances, scaling a monolithic application as a whole may soon turn into an expensive affair. On the other hand, each set of microservices can (potentially) be scaled independently of the others, thus helping focus resources on areas where the problem truly lies.

I have been reading building microservices by Sam Newman and really liked the 8 keys principles explained by him. In this post, I am attempting to provide a high-level overview of those principles and I highly encourage you to read his book to get a more detailed understanding of these concepts.

The eight key principles are

1. Modelled around business domain 

Focus on your business domain and identify individual subdomains and build services. A good way to start would be to follow the principles of Domain Driven Design.

2. Culture of automation

Infrastructure automation is what smart companies are focusing on today.  Provisioning a new machine, operating system and service should be automated.

Automation testing and continuous delivery are critical as well so as to deploy/release your software frequently and reliably.

3. Hide implementation details.

Hide your database, and hide your functionality. Each service should have its own database and if shared information is needed from other services, leverage service endpoints designed for the specific subdomain to extract what is expected. While migrating a monolithic application to a microservice(ish) structure, it is often considered easiest to tease apart application level code while leaving the (shared) underlying database as is. There is often a variety of rationale provided for doing this ranging from a lack of confidence in the success of this migration to potential issues faced for data analysis and report aggregation purposes. However, this shared database continues to serve as a source of coupling between the independent services far greater than the decoupling achieved by spinning off the application level services.

4. Decentralise all the things

Focusing on autonomy (giving people as much freedom as possible to do the job in hand), self-service (do you have to create a ticket to provision a machine or you can do it all by your self), shared governance (making architecture work) and avoiding complex messaging is important.

5. Deploy independently

If you have 4 services and all of them have to be deployed together due to dependency then fix that before you create 5th service. Having one service per host make life very easy for everyone. Docker is getting a lot of traction for such isolation of operating environments.

In such an environment of independent deployments, consumers drive contracts where when you make a change, the consumer service has expectations about not facing challenges when you deploy changes.

When there are co-existing endpoints, for instance in an upgrade scenario, the consumer service would switch to a newer version while the provider continues supporting existing version for a limited time period this providing some time for other services to migrate without holding the entire system hostage to its changes.

6. Consumer First

As the creator of an API, it is very important that you make your service easy to consume. The documentation plays an important role here.

7. Isolate Failures

Microservice architecture doesn’t automatically make your systems more stable. To the contrary, it makes the overall system more vulnerable to certain types of network and hardware related issues (more points of failure). You should have ways to isolate failures and look for ways to recover such as failover caching and retry logic.

8. Highly observable

It is very important to know what is happening in your system with so many moving parts. Each service may depend on multiple services and vice versa.  There needs to be constant observation and monitoring to ensure the whole integration is smooth.

Microservices often communicate via HTTP/REST (Synchronous) or utilizes Asynchronous protocols like JMS, RabbitMQ etc.  It is perfectly fine and acceptable to use Synchronous protocols for public APIs while when dealing with microservices internal communications, you should go with Asynchronous protocols.

In a typical monolith application when you want to fetch the data to show in search functionality, all you have to do is join multiple tables and present it to a user. If you want to achieve the same using microservices, there is going to be a big performance hit as you need to retrieve it from each and every microservices which may not be a good idea.   In this situation, I would recommend you to go with Elasticsearch. You can display the high-level data coming from one table. When a user clicks on an individual item, you can always go to all microservices. Moreover, you can run them all in parallel on top of it. This can significantly reduce the pain of performance bottlenecks in homegrown solutions.  There are multiple scenarios like this which entice teams and organizations to avoid going with microservices while an easier way out exists. I would be discussing some of the very common challenges and their resolution in details in my upcoming blogs

Micro-Frontends

The microservices architecture gives you enormous benefits when done right. When implementing a microservices architecture, you certainly want to keep your services small.  Most of the companies and teams I have come in contact with having a tendency to do so with the backend, primarily for two reasons.

  1. It is expensive in terms time and money.
  2. Knowledge gap

Although you are better off going with monolith application while you would not gain most of the benefits as you cant deploy your backend services independently without the front end.  In such scenarios, not only is application scaling a challenge,  you also need to update the front end whenever an API is deployed with breaking changes.

 

The idea with a Micro-Frontend is to decompose your application into smaller units based on screens representing domain-specific functionality instead of writing large monolithic front-end application. The front-ends are self-contained and can be deployed independently. SPAs (single page applications) are the best way identified so far to go this route and domain driven architecture helps achieve this to a great extent. You can have backend, frontend, data access layer, and database, everything required for a subdomain in one service. Every piece of the service should be worked by an independent team. Collaboration and communication play an important role here and as long as you adhere to best practices and principles of microservices, you are most likely to get successful and gain maximum out of your product/software.

Benefits of Micro-Frontends

  1. The individual development team can choose their own technology.
  2. The development and deployment are very quick.
  3. The benefit of microservices can be leveraged in a much better way. The dependency is drastically reduced.
  4. Helps in continuous deployment.
  5. The maintenance and support are very easy as the individual team owns the specific area.
  6. The testing becomes simple as well as for every small change, you don’t have to go and touch entire application.

Challenges

  1. The UX consistency is an important aspect. The user experience may become a challenge if the individual team go with their own direction hence there should be some common medium to ensure UX is not compromised.
  2. The dependency needs to be managed properly. The collaboration becomes a challenge at a time. The multiple teams working on one product should be aligned and have a common understanding.

You can also read :

Micro-Services, Eventual Consistency and Event sourcing patterns

 

DAR – How to find a better option when you have multiple solution for a given problem?
 

“You must choose … but choose wisely”   Your decisions play a critical to make or break your future. The company you choose, the girl or guy you marry, the house you buy, the career option you choose. Isn’t it a great idea to have a tool or intelligent mechanism to make the life easy which would help you to choose the best possible decision based on some real facts rather than some random decision?

DAR

DAR is a process to make key decisions in your organization and even in personal life more objectively and wisely. Just to add more clarity, what do you do when you have multiple solutions for a given problem? How do you decide to pick one that most suited and obviously wise?

Human psychology plays an important role while using this technique. We have a lot of information which we don’t really process rather we just go by Halo effect which is nothing but taking a decision based on what you have in your mind at that moment instead of considering all the inputs

Let’s take some examples

Business Decisions

Should I outsource or not.

Is it a good idea to start an XYZ office in Pune or Mumbai?

Technical Decision – Which technology to choose – C++, Java or .NET

Which technology to choose – C++, Java or .NET

Architecture decisions.

Alright, seems boring. Let me get on to more personal stuff.

Which car do you want to buy?

The DAR – Decision analysis and resolution is an answer for above situations. It is one of the process area defined by CMMI but practically used everywhere. The reason DAR works most times

  • You think about every possible solution and list them out. Hence you consider everything before taking a decision over just thinking about limited core items.
  • You rank individual items based on comparison hence you have more clarity.
  • The template would give you amazing results.
  • You do consider Risk and constraints.

Essentially writing down everything and coming to conclusion. There is no guarantee that your solution would be perfect while you are increasing the chances of getting it right significantly.  It takes almost no time to use this process once you acquainted with it.

Please leverage attached DAR template. I have created it to have the better clarity.

Dar Template

Try few times and trust me you would fall in love with it.

The most basic Java Script Interview Questions
 

JavaScript developed by Netscape. JS is a client side as well as a server-side scripting language. It is interpreted programming language as well with object orientated capabilities.

1. How do you create a class in JavaScript?

Answer – There are multiple ways you can create a class in JS. For example

Method 1 – Using functions

// This is a class name

function Flat(aptName, location){

// You can define object properties

this.aptName = aptName;

this.location = location;

this.getLocation = getLocationInfo

}

// The method can be defined as

function getLocationInfo{

return “The location is “ + this.location;

}I

// You can even define function of a class like this

Flat.prototype.getFlatInfo = function() {

alert (“The apartment name is” +   this.aptName + “ and the location is “ + this.location = location);

// Instantiate new object of Flat class

var myFlat = new Flat(“Manjeera”, “Kukatpally”);

// Invoke methods like this

alert myFlat.getLocationInfo();

Method 2 – Using object literals

Var Flat = {

this.aptName = “manjeera”;

this.location = “kukatpally”;

this.getLocation = function() {

return “The location is “ + this.location;

}

}

Apart from using functions, and object literals, you can use object constructor as well to create JavaScript class.

2. What is the difference between ‘==’ and ‘===’?

Answer –       ‘==’ checks for equality only

‘===’ checks for equality and type

For example

false == 0 returns TRUE

false === 0 returns FALSE

3. What is isNan? Give example?

Answer – This would return true of the argument is not a number. For example

isNaN(23) returns false

isNaN(“2/3/2017”) returns true

4. What are the difference comments available in JavaScript?

Answer – There are two types of comments available in JavaScript

A. Single line comments

// This is a single line comment

B. Block comments

/*

This can be used

For block comments

..

*/

5. What are the types used by JavaScript?

Answer – There are six types used in Java Script

Boolean (True and False)

Null (null)

Undefined (undefined)

Number (Integers, floating etc.)

String

Object (Objects, Array, Functions etc.)

6. Is JavaScript a case sensitive?

Answer – Yes, JavaScript is case-sensitive.

7. How can you create an object in JavaScript

Answer – You can use object literal as shown below

var student  = {

name: “Sandeep”,

age: 36

};

Alternatively, you can use below (As explained in question number 1)

var myFlat = new Flat(“Manjeera”, “Kukatpally”);

8. Does JavaScript support exception handling?

Answer – Yes, it does support exception handling by means of try and catch. It supports try, catch, finally, throw etc. keywords to handle exceptions.

9. What is the difference between break and continue?

Answer – Break statement causes program control to exit from the loop.

The continue statement causes program control to continue with next statement.

10. What is the primary difference between ViewState and SessionState?

Answer – ViewState represents a page in session while SessionState is specific to user specific data which can be accessed all across in the web application.

 

 

 

 

 

 

 

 

The five dysfunctions of a team – Book Review
 

I got an opportunity to drive ‘team book reading’ with my highly competent team for one of the very critical facets of team building i.e. “What it takes to be successful as a Team”. The book name is “The five dysfunctions of a team – A leadership fable” which I personally found very interesting hence thought of sharing the summary with you all. Precisely the book talks about the five dysfunctions of a team which restricts the team to be successful. It is very important to understand and overcome them in order to be more effective as a team. The dysfunctions are

Absence of trust
Trust & respect are the foundation stones of any relationship be it a home or office. If the members of the team do not trust each other then they cannot be completely honest with each other.

Hence “Create Trust” by following but not limited to:

  • 360-degree feedback
  • Spend time together
  • Understand each other personal history
  • Believe in each other
  • Be honest

Fear of conflict – Without trust, team members will not have the healthy debates that are necessary to arrive at better thought through decisions.
It’s very important to have open lines of communication (so that everyone is clear & aligned). Always remember

  • Open discussions. Debate leads to a better solution
  • Focus on the issue, not the individual.

Hence “Value Conflict” (It has to be in a healthy way!) by following but not limited to:

  • Straight talk
  • Calling people on behavior traits that demonstrate fear of conflict
  • Identify how we respond
  • Leader leads in behavior

Lack of commitment – If the team has not aligned to a decision then the individual members who did not agree with the final decision will ultimately be less committed to that decision. It is important to know that the “Alignment” is more important than agreement

Hence “Encourage commitment” by following but not limited to:

  • Summaries decisions made in group discussions or meetings
  • Come to consensus — Any decision is better than no decision – Timeboxing decisions.
  • Clarify all scenarios including worst-case ones.
  • Talk it loud, hear everyone’s opinion.

Avoidance of accountability – If they are not committed to the course of action, then they are less likely to feel accountable (or hold other people accountable). Lack of clarity of roles & responsibilities and not holding individuals accountable leads to “Avoidance of accountability”
Hence “Promote Accountability” by following but not limited to

  • Open disclosure of goals, standards, and metrics
  • Continuous progress reviews
  • Reward for a team not individual

Inattention to results – If the individuals are not accountable, they are less likely to care about the group results (Instead they would focus on achieving their individual goals).
Hence “Celebrate Results” by following but not limited to:

  • Group declaration of results
  • The reviews to be based on results.
  • The leader should lead in behavior.

Disclaimer “This is a just summary of the book we read – In order to have more details, you are required to read the complete book”.