Why we need to create instance for interface not for implementation?

Programming to an Interfaces Not Concrete it's a good concept.
In MSDN about interface says
An interface contains definitions for a group of related functionalities that a class or a struct can implement.
It's Ok..But people's are not fully understandable about Why interfaces , Where and when we use interfaces why recommending Programming to an interface not concrete..a lot of questions in our mind.

Why we use Interfaces?
1.Extensibility
2.Maintainability
3.Testabilty

I am not telling this about detail..But l would like to share something about Extensibility.It's one of the best thing about interfaces.

Suppose In my application i am using Sqlserver for storing and retrieving the data.So i am going to create one class for saving Customer information.
Business Logic

public class CustomerRepository{

public void Save(){//logic for saving data}
public void Update{}
//some other operations here
} 

Application Layer
In my application layer if i want to save a Customer information we should create an instance of a class and call the save method like below

CustomerRepository objCustomer=new CustomerRepository();
objCustomer.Save();

Ok fine..We done all of the functionalities. After some days our client says i don't want to pull the data from Database i have some file system or some services.Hmmm..

How to handle this situation?
We have to modify our application layer as well as the business logic. Here Interfaces come in to the picture.

Modifying our existing application based on interfaces

public interface ICustomerRepository{
void Save();
void Update();
}

public class CustomerRepository:ICustomerRepository{

public void Save(){//logic for saving data}
public void Update{}
//some other operations here
} 

Modifying our Application Layer

public class SomeApplicationLevelClass{
private ICustomerRepository _customerRepository;
public SomeApplicationLevelClass(){
//manual dependency injection.
_customerRepository=new CustomerRepository();
}
public void SaveCustomer(){
_customerRepository.Save();
}
}

Now my data access change from DB to File.
Note: keep the existing CustomerRepository class. It's working functionality. If we modify it will make error prone. In future client need db access also.We can't trust
So i am going to create one more class CustomerFileRepository and implement the same interfaces we have created before

public class CustomerFileRepostory:ICustomerRepository{
public void Save(){//logic for saving data to file}
public void Update{}
}

Modifying application Layer.
Previously we should change all concrete implementation directly in all places. here i am manually injecting dependencies in our constructor.So we only modify the constructor.You can also inject dependencies via configuration by using Dependency Injection API's.For microsoft technologies we can use Ninject,Unity,StructureMap dependency containers.

Modified Code

public class SomeApplicationLevelClass{
private ICustomerRepository _customerRepository;
public SomeApplicationLevelClass(){
//manual dependency injection.
//changes in constructor only
_customerRepository=new CustomerFileRepository();
}
public void SaveCustomer(){
_customerRepository.Save();
}
}

After applying the Dependency Injection Design Pattern your code will look like below

public class SomeApplicationLevelClass{
private ICustomerRepository _customerRepository;
public SomeApplicationLevelClass(ICustomerRepository customerRepository){
//manual dependency injection.
//changes in constructor only
_customerRepository=customerRepository;
}
public void SaveCustomer(){
_customerRepository.Save();
}
}

we no need to mention our concrete implementation in application layer. Everything about concrete class can configure in dependency injection configuration section.If you want to change again to db.you only modify in the configuration or constructor.

Now our application in an Extensible way.I Hope you are got little bit idea about why interfaces and Programming to an interface not concrete concept
If you know more about interfaces you should know the following things deeply. It will take some time to grasp those things but you will get more gradually.

http://stackoverflow.com/questions/130794/what-is-dependency-injection[^]
Dependency Injection for Loose Coupling[^]

SOLID architecture principles using simple C# examples[^]

http://www.oodesign.com/factory-pattern.html[^]
Repository pattern, done right[^]

Hope this information helps you

Do keep in mind that an Interface never has an 'instance: Classes, or Structs inherit from Interface(s). Note that an Interface can inherit from another Interface, and may extend it by adding additional objects' signatures.

Those Classes, or Structs, that inherit from Interface(s) must implement each Method, Property, Event, or Indexer, defined in the Interface so the implementation matches the signatures the Interface specifies.

Instances of Classes, or Structs, are created by program execution, either when the application loads ... or, at run-time, by programming.

I'm not sure what you mean by "concrete class:" perhaps you are thinking of an Abstract Class, which is like an Interface in that it may contain signatures, and can never be instantiated, but, it can provide a default implementation of methods.

Note that a Class or Struct, can only inherit from one Abstract Class.

I suggest you read: [^], [^], [^].