Updating our readme adding info about our components (#65)

* Improve our README to add info about the Oryx components

* fix links

* rewording

README.md

@@ -94,6 +94,50 @@ docker run --detach --rm \
     sh -c 'oryx -appPath /app && /run.sh'
 ```
 
+# Components
+
+Oryx is a collection of the following components:
+
+
+## Build script generator
+
+The build script generator is a command line tool (and .NET Core library) that can generate and execute build
+scripts for a given source repo.
+
+## Build image
+
+We have a single build image which supports all of the SDKs and their versions. This allows developers to use multiple
+languages in their build, e.g. run a Python setup script when building their .NET Core app, or have a TypeScript 
+frontend for their Python app. You can take a look at its [Dockerfile](./images/build/Dockerfile) to better understand
+its contents.
+
+Note that some layers of this build image come from yet another set of images, which we build independently for
+modularization and for faster build times. You can see what are those images and how they are built in their
+[build script](./build/build-buildimage-bases.sh).
+
+To help the user select which version they want for each platform, they can use the `benv` script pre-installed
+in the build image. For example, `source benv python=3.6 node=8` will make Python 3.6 and the latest supported
+version of Node 8 the default ones.
+
+The build image also contains the build script generator, which can be accessed by its alias, `oryx`.
+
+## Startup script generators
+
+These are command line tools, one for each platform, that inspect the output directory of an application and
+write a script that can start it. They are written in Go, and are located in
+[src/startupscriptgenerator](./src/startupscriptgenerator/).
+
+## Runtime images
+
+We have a set of runtime images, and their Dockerfiles are located in [images/runtime](./images/runtime). Some of the Dockerfiles are generated from a template, also located in this folder, with a corresponding script to turn those
+scripts into actual Dockerfiles. Having templates helps us maintain consistency across the Dockerfiles.
+
+There are some exceptions that are not templates, where we have to customize the image. A typical need for
+such customization is security, where we have to patch a tool or rely on a different base image than the
+official images released for a given platform.
+
+Each runtime image contains the startup script generator for its platform.
+
 # Contributing
 
 See [CONTRIBUTING.md](./CONTRIBUTING.md).