Disclosure - I work for a vendor (NetApp) that develops and sells both large filesystem and object storage platforms, I'll try to keep this as implementation neutral as I can, but my cognitive biases may unconciously influence my answer.
There are many differences from both an access, programmability and implementation point of view, however given this is likely to be read primarily by programmers rather than infrastructure or storage people, I’ll focus on that aspect here.
The main difference from an external / programming point of view, is that an object in an object store is created or deleted or updated as a complete unit, you can't append data to an object and you can't update a portion of an object "in place", you can however replace it while still keeping the same object ID. Creating, Reading, Updating and Deleting objects is typically done via relatively straightforward APIs, which are almost always REST-ful or REST based and encourages a mindset that the store is a programmable resource or perhaps as multi-tenant remote service. While most of the object stores I'm aware of support byte-range reads within an object, in general objects stores were initially designed to work with whole objects . Good examples of object storage API’s are those used by Amazon S3 (the default standard for object storage access), OpenStack Swift, and Azure Blob Service REST API. Describing the back end implementations behind these APIs would be a book all by itself.
On the other hand files in a filesystem have a broader set of functions that can be applied to them, including appending data, and updating data in place. The programming model is more complex than an object store and is now almost always accessed programatically via a "POSIX" style of interface and generally tries to make the most efficient use of CPU and memory and encourages a mindset that the filesystem is a private local resource. NFS and SMB does allow for a filesystem to be made available as a multi-tenanted resource, however these are often treated with suspicion by programmers as they sometimes have subtle differences in how they react compared to "local" filesystems despite their full support for POSIX semantics. To update files in a local filesystem, you will probably use API’s such as https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html or https://msdn.microsoft.com/en-us/library/mt794711(v=vs.85).aspx. Talking about the relative merits of filesystem implementations e.g. NTFS vs BTRFS vs XFS vs WAFL vs ZFS has a tendency to result in a religious war that is rarely worth anyones time, though if you buy me a beer I’ll happily share my opinions with you.
From a use-case point of view, if you wanted to keep a large number of photo’s, or videos, or binary build artefacts, then an object store is often a good choice. If on the other hand you wanted to persistently store data in a binary tree and update that data in place on the storage media then an object store simply wouldn’t work, and you’d be much better off with a filesystem (you could also use raw block devices for that, but I haven’t seen anybody do that since the early 90s)
The other big differences are that filesystems a designed to be strongly consistent, and are usually accessed over low to moderate latency (50 microseconds - 50 milliseconds) networks whereas object stores are often eventually consistent, and distributed over a shared nothing infrastructure connected together over low bandwidth high latency wide area networks and their time to first byte can sometimes be measured in multiples of whole seconds. Performing lots of small (4K - 16K) random reads from an object store is likely to cause frustration and performance problems.
The other main benefit of an object store vs a filesystem is that you can be reasonably sure that anything you put in an object store will remain there until you ask for it again and that it will never run out of space so long as you keep paying for the monthly charges. These resources are generally run at large scale with built in replication, version control, automated recovery etc etc and nothing short of Hurricane Harvey style disaster will make the data disappear (even then, you have easy options to make another copy in another location). With a filesystem, especially one that you are expecting you or your local operations people to manage, you have to hope that everything is getting backed up and that it doesnt fill up accidentally and cause everything to melt down when you cant update your data anymore.
I've tried to be conscise, but to add to the confusion the words "filesystem" and "object store” get applied to things which are nothing like the descriptions I’ve used above, e.g. NFS the Network file system isn’t actually a filesystem, its a way of implementing the posix storage API’s via remote procedure calls, and VMware’s VSAN stores its data in something they refer to as an "object store" which allows high speed in place updates of the virtual machine images.
