Merge pull request #41 from mishmash-io/publish-druid

Update README

README.md

@@ -23,13 +23,54 @@ Here you can also find implementations of such data sources for a few popular op
 
 ***Contents:***
 
+- [How OpenTelemetry compares to other telemetry software](#why-you-should-switch-to-opentelemetry)
 - [Introduction to OpenTelemetry for Developers, Data Engineers and Data Scientists](#opentelemetry-for-developers-data-engineers-and-data-scientists)
 - [Software artifacts to:](#artifacts)
   - [Embed OTLP collectors in Java systems](#embeddable-collectors)
   - [Save OpenTelemetry to Apache Parquet files](#apache-parquet-stand-alone-server)
   - [Ingest OpenTelemetry into Apache Druid](#apache-druid-otlp-input-format)
 - [More about OpenTelemetry at mishmash io](#opentelemetry-at-mishmash-io)
 
+# Why you should switch to OpenTelemetry
+
+If you are new to OpenTelemetry you might be thinking how is it better than the multitude of
+existing telemetry implementations, many of which are already available or well established within
+popular runtimes like Kubernetes, for example.
+
+There are a number of advantages that OpenTelemetry offers compared to earlier telemetries:
+
+- All signal types (`logs`, `metrics`, `traces` and `profiles`) are ***correlatable:***
+
+  For exmpale - you can explore ***only*** the `logs` emitted inside a given (potentially failing) `span`.
+
+  To see how `telemetry signal correlation` works - refer to the [OpenTelemetry for Developers, Data Engineers and Data Scientists](#opentelemetry-for-developers-data-engineers-and-data-scientists) examples section below.
+- More precise timing:
+
+  Unlike other telemetries, OpenTelemetry does not `pull` data, it `pushes` it. By avoiding the
+  extra request needed to pull data - OpenTelemetry reports much more accurate timestamps of
+  when `logs` or `spans` and other events where emitted, or `metrics` values were updated.
+- Zero-code telemetry:
+
+  You can add telemetry to your existing apps without any code modifications. If you're using
+  popular frameworks - they already have OpenTelemetry instrumentation that will just work out
+  of the box. See the [OpenTelemetry docs for your programming language.](https://opentelemetry.io/docs/languages/)
+
+  Also, you do not need to implement special endpoints and request handlers to supply telemetry.
+- No CPU overhead if telemetry is not emitted:
+
+  When code instrumented with OpenTelemetry runs ***without*** a configured signals exporter
+  (basically when it is disabled) - all OpenTelemetry API methods are basically empty.
+
+  They do not perform any operations, thus not requiring any CPU. 
+- Major companies already support OpenTelemetry:
+
+  Large infrastructure providers - public clouds like Azure, AWS and GCP already seamlessly integrate their monitoring and observability services with OpenTelemetry.
+
+  Instrumenting your code with OpenTelemetry means it can be monitored on any of them, without
+  code changes.
+
+If the above sounds convincing - keep reading through this document and explore the links in it.
+
 # OpenTelemetry for Developers, Data Engineers and Data Scientists
 
 We have prepared a few Jupyter notebooks that visually explore OpenTelemetry data that we collected from [a demo Astronomy webshop app](https://github.com/mishmash-io/opentelemetry-demo-to-parquet)