A shorter answer (compared to westfw's) is that the timer is a physical piece of hardware somewhere on the chip. You tell it what to do by writing some bytes to configuration registers (Described in the datasheet) and after that it just keeps on doing what it is configured to do. It can count the CPU cycles (with or without a prescaler) or it can count external events on an I/O pin. Timers have options to generate interrupts when certain events happen (overflow, capture / compare, etc) but those are optional, an usually have to be enabled explicitly. For an interrupt to function properly, you have to write code for it, and you have to enable the interrupt in the configuration register for that peripheral (A global interrpt en/dis -able bit is also common, and more details...)
The same mechanism is also behind all other microcontroller peripherals, such as UsART's, SPI and I2C, I/O registers, etc.
You first configure a UsART (baudrate, number of bits, which interrupts to generate) and after that as soon as you write a byte to it's data register it starts doing it's thing: It sends a start bit to an output pin, then shifts out the data bits and also adds a stop bit, and it does this all in hardware. It can also generate interrupts, but those are also optional.
Such concepts maybe easier to grasp if you have a look at old computers such as the Z80. (which is still popular in the "retro computing" communities) In such old systems the processor and it's peripherals are all different things in separate IC's and connected to each other with many wires in a bus system.
On microcontrollers this bus system is also present, but it is not accessible from the outside world. probably there is a block schematic near the beginning of your microcontroller with a block schematic. Each block is a separate piece of hardware, and the bus system that connects all these pieces is also drawn on it.