faq.md updated (#1679)

* faq @ porter registry

Signed-off-by: Sonu Kumar Kushwaha <[email protected]>

* remaing 3 faq added

Signed-off-by: Sonu Kumar Kushwaha <[email protected]>

* fromatting done

Signed-off-by: Sonu Kumar Kushwaha <[email protected]>

* Update faq.md

required mark down added

Signed-off-by: Sonu Kumar Kushwaha <[email protected]>

* Update faq.md

final fromatting done!!

Signed-off-by: Sonu Kumar Kushwaha <[email protected]>

Co-authored-by: Carolyn Van Slyck <[email protected]>

docs/content/faq.md

@@ -144,5 +144,40 @@ The Azure mixins are going to be full fledged tools that communicate with the
 Azure APIs, and provide an improved user experience. It all depends on how much
 time you want to invest, and what you are starting from.
 
+## Does the Porter has its own registry?
+
+ No, Porter does not have a dedicated registry for hosting bundles. You can use any OCI registry, such as DockerHub, with Porter. We have compiled a [list of compatible registries](https://porter.sh/compatible-registries/) that have been tested with Porter.
+
+## What do mixins do?
+
+Mixins provide the following features:
+ * Install a tool into the bundle. It handles editing your dockerfile for you.
+ * Mixins can adapt imperative command line tools to work with desired state. 
+
+    For example, the uninstall command should be re-runnable. I should be able to re-run porter uninstall if there was an error and it should pick up where it left off. Most command line tools are imperative though, and don’t handle errors in a way that works well with that (e.g. returning a failure when you attempt to delete something that   is already deleted).
+ * Mixins provide rich metadata that end-users can use to both understand what a bundle will do, and companies can limit what bundles they allow based on both the mixins present and what functionality of the mi   xin is used.
+ * Mixins help collect outputs from steps, and reuse those as arguments to subsequent steps. 
+    For example, the helm mixin can create a database and generate an output with the connection string. The terraform mixin can then use that connection string as an input variable, or even expose that output to the end-user when the bundle finishes running.
+
+You never have to use mixins, other than the built-in exec. You could write a custom dockerfile and then call a bash script. But most people find that working with mixins is easier.
+
+## What is the different between Porter and existing DevOps tools?
+
+Porter is never a replacement for an existing tool. Think of it as doing extra nice things on top of what those great tools already do!
+ * Packages everything you use to deploy in a single artifact that can be easily distributed over registries and across air gapped networks.
+ * Bundles can be signed and the signature verified before installing the bundle to improve supply chain security.
+ * Makes for more reliable deployments because it has the exact version of a CLI that goes with the deployment. End users don’t need to install the right versions of tools locally (sometimes different apps require different versions).
+ * Provides metadata about a deployment that you can use in many ways. End users can run porter explain to quickly see how to customize an installation with parameters, what credentials are needed by the bundle. No need to read separate installation docs to figure out how to deploy an app.
+ * Reduces the operational knowledge required to manage an application. Often a deployment uses multiple tools, for example terraform, AND helm, AND kubectl and they are glued together with bash scripts. When those are put inside a bundle, it simplifies how much the end user needs to know. It’s always a single command, porter upgrade . In many cases the end user doesn’t even need to know what tools are used, or how to use those tools.
+ * Makes it easier for a team to manage an application securely. Porter remembers the actions performed previously on the bundle, the parameter values used previously, the current version of the bundle, etc. 
+ * You can put together the necessary parameters and credentials so your teammates don’t need to each hunt down the proper values themselves, or even worse copy sensitive credentials into local environment variables on every machine that does the deployment. Secrets stay in a secret store and aren’t copied around.
+Those are just some of the reasons why working with bundles with the tools embedded inside is helpful vs using the same tools standalone.
+
+## Do you have suggestions for bundles that I could make?
+
+ * Create a bundle for a side project. It handles setting up any infrastructure, such as creating a VM or other cloud resources, and it then also deploys your app. Maybe pushing your serverless function as one example, or running a helm chart. 
+   This is useful because often we figure out how to do these things while working on the project and then after not having time for the project most people forget how to deploy their project. That makes it super hard to start back up on the project! So using bundles helps make the best use of your limited side project time
+* Create a bundle for an open source project. Pick a project that you like, maybe wordpress, mysql or discourse, and then write a bundle that will deploy the software to a cloud provider. This is a fun one because other people can use your bundle!
+
 [CNAB Core Spec]: https://github.com/cnabio/cnab-spec/blob/main/100-CNAB.md
 [CNAB Dependencies Spec]: https://github.com/cnabio/cnab-spec/blob/main/500-CNAB-dependencies.md