<p>Let me answer each your question in parts.</p>

<h1>What the point is?</h1>

<p>As per <a href="https://circleci.com/docs/2.0/orb-intro/" rel="nofollow noreferrer">Orbs Introduction</a>:</p>

<blockquote>
  <p>orbs are shareable packages of configuration elements, including jobs, commands, and executors. 
  CircleCI provides certified orbs, along with 3rd-party orbs authored by CircleCI partners</p>
</blockquote>

<p>The advantages of this approach are that an <strong>authorized</strong> package of <strong>jobs</strong>, <strong>commands</strong>, and <strong>executors</strong> is offered.</p>

<p>Assuming <a href="https://circleci.com/orbs/registry/" rel="nofollow noreferrer">hundreds of <code>orbs</code></a>, it looks like a community-approved plugin/addon ecosystem. E.g. <code>Ansible roles</code> or <code>Jenkins plugins</code> or <code>Wordpress plugins</code></p>

<h1><code>orbs</code> vs shell functions/script</h1>

<p>Since <code>orb</code> packages:</p>

<ul>
<li><a href="https://circleci.com/docs/2.0/jobs-steps/#jobs-overview" rel="nofollow noreferrer"><code>jobs</code></a>, </li>
<li><code>commands</code>,</li>
<li>and <a href="https://circleci.com/docs/2.0/using-orbs/#executors" rel="nofollow noreferrer"><code>executors</code></a>, </li>
</ul>

<p>then it can hardly be replaced by a simple combinations of shell commands/functions. </p>

<h1>Seems like unnecessary lockin?</h1>

<p>As for lock-in concerns: you are right. </p>

<p>It looks like lock-in. And it <strong>is</strong> lock-in. </p>

<p>But as I know, there isn't any portable solution than can be easily migrated from one <code>CI/CD</code> system to another. E.g. try to convert <code>.gitlab-ci.yml</code> to <code>travis.yml</code>.</p>

<p>But lock-in's, as usual, tend to give you an advantage in speed or ease of deployment.</p>

<h1>Portability</h1>

<p>Since there are four <a href="https://circleci.com/docs/2.0/executor-types/" rel="nofollow noreferrer">executor types</a> (<code>docker</code>, <code>machine</code>, <code>windows</code> and <code>macos</code>), it gives you more portable and cross-platform approach.</p>

CC BY-SA 4.0
2020-04-29T09:19:45.517Z
Seems like still a majority of 'orbs' could be instead using bash functions - and only use orbs where needed. Also I don't think the "authorized" is an advantage here - could easily just be a git repo in which case you get the same set of  advantage, in fact I think this is a disadvantage as it's _centralized_.
Chris Stryczynski
CC BY-SA 4.0
2020-04-30T08:25:59.103Z
You are right. I suppose, importance of "authorizing" depends on CTO's opinions.
Yasen
CC BY-SA 4.0
2020-04-24T13:03:06.257Z
2020-04-28T06:52:45.133Z
2020-04-28T06:52:45.133Z
Yasen
<p>orbs can help you saving a lot of time and from lots of configurations hassles in circle ci configuration. orbs provides extra functionality in your build pipeline with its pre-configured properties.</p>
<p>suppose, you want to copy your build artifact to s3 bucket from circle build environment. to achieve that goal without orbs, you need to install awscli and then set environment variables for iam access key id, secret access key, region. but with orbs you can import the s3 copy functionality in build pipeline and provide iam key pairs and region value into that orb function. thus it helps you to use pre-existing templates with certain functionalities in build environment. same goes to k8s deployment by using kubectl from k8s orb without installing kubectl in circle pipeline.</p>

CC BY-SA 4.0
2020-06-19T10:16:22.627Z
You have made no mention of the comparison to using bash for this.
Chris Stryczynski
CC BY-SA 4.0
2020-06-19T14:10:58.890Z
using of bash was meant to install and configure awscli comparing to s3 orb. using various combination of certified orbs can also save time by not requiring bash functions.
chaks
CC BY-SA 4.0
2020-06-19T08:32:04.330Z
2020-06-19T08:32:04.330Z
chaks
<p>I'm looking at: <a href="https://circleci.com/orbs/registry/orb/circleci/kubernetes" rel="nofollow noreferrer"><code>CircleCI</code> <code>Orb</code> for <code>kubernetes</code></a></p>

<p>Whats the point of this? Whats the benefit of an <code>orb</code> which is a <code>CircleCI</code>  specific feature rather than say a <code>bash</code> function/script (which is more interoperable/common)?</p>

<p>Seems like unnecessary lockin, but maybe I'm just being naive here?</p>

<kubernetes><circleci>
Whats the point of circleci orbs?
Chris Stryczynski
# Whats the point of circleci orbs?

(Asked by: username_0 on 2020-04-23)

I'm looking at: [`CircleCI` `Orb` for `kubernetes`](https://circleci.com/orbs/registry/orb/circleci/kubernetes)

Whats the point of this? Whats the benefit of an `orb` which is a `CircleCI` specific feature rather than say a `bash` function/script (which is more interoperable/common)?

Seems like unnecessary lockin, but maybe I'm just being naive here?

**Tags:** kubernetes, circleci


---

## 2 answers

### Answer by username_1 on 2020-04-24. Score: 1 | Accepted answer

Let me answer each your question in parts.

# What the point is?

As per [Orbs Introduction](https://circleci.com/docs/2.0/orb-intro/):

> orbs are shareable packages of configuration elements, including jobs, commands, and executors.
> CircleCI provides certified orbs, along with 3rd-party orbs authored by CircleCI partners

The advantages of this approach are that an **authorized** package of **jobs**, **commands**, and **executors** is offered.

Assuming [hundreds of `orbs`](https://circleci.com/orbs/registry/), it looks like a community-approved plugin/addon ecosystem. E.g. `Ansible roles` or `Jenkins plugins` or `Wordpress plugins`

# `orbs` vs shell functions/script

Since `orb` packages:

* [`jobs`](https://circleci.com/docs/2.0/jobs-steps/#jobs-overview),
* `commands`,
* and [`executors`](https://circleci.com/docs/2.0/using-orbs/#executors),

then it can hardly be replaced by a simple combinations of shell commands/functions.

# Seems like unnecessary lockin?

As for lock-in concerns: you are right.

It looks like lock-in. And it **is** lock-in.

But as I know, there isn't any portable solution than can be easily migrated from one `CI/CD` system to another. E.g. try to convert `.gitlab-ci.yml` to `travis.yml`.

But lock-in's, as usual, tend to give you an advantage in speed or ease of deployment.

# Portability

Since there are four [executor types](https://circleci.com/docs/2.0/executor-types/) (`docker`, `machine`, `windows` and `macos`), it gives you more portable and cross-platform approach.

> **Comments:**
> **username_0**: Seems like still a majority of 'orbs' could be instead using bash functions - and only use orbs where needed. Also I don't think the "authorized" is an advantage here - could easily just be a git repo in which case you get the same set of  advantage, in fact I think this is a disadvantage as it's _centralized_.  
> **username_1**: You are right. I suppose, importance of "authorizing" depends on CTO's opinions.  

---

### Answer by username_2 on 2020-06-19. Score: 0

orbs can help you saving a lot of time and from lots of configurations hassles in circle ci configuration. orbs provides extra functionality in your build pipeline with its pre-configured properties.

suppose, you want to copy your build artifact to s3 bucket from circle build environment. to achieve that goal without orbs, you need to install awscli and then set environment variables for iam access key id, secret access key, region. but with orbs you can import the s3 copy functionality in build pipeline and provide iam key pairs and region value into that orb function. thus it helps you to use pre-existing templates with certain functionalities in build environment. same goes to k8s deployment by using kubectl from k8s orb without installing kubectl in circle pipeline.

> **Comments:**
> **username_0**: You have made no mention of the comparison to using bash for this.  
> **username_2**: using of bash was meant to install and configure awscli comparing to s3 orb. using various combination of certified orbs can also save time by not requiring bash functions.  

---

