BDX <-> Juju

[James Beedy]

Team,

As some of you may know, I have taken on a new position as DevOps Engineer
for a creative company -> CreativeDrive <http://creativedrive.com>.
CreativeDrive is the parent company of 5 child creative companies which it
acquired over the last year. Being as CreativeDrive itself is just over a
year old, and with the acquisition of the 5 child companies; we have a
large need, and a lot of room for Juju in our application/dev-ops stack. In
short, I/we have 100s (not joking) of applications that could benefit from
being charmed up and deployed (to a private openstack if I can forge my
will) back to aws.

I have immediately (in my first week) charmed up 3 big apps, and
demonstrated the power of Juju internally throughout the company with a lot
of success in the acceptance of its uptake. Minus a small hiccup with an
aws vpc (operator error) (also huge thanks @lazyPower for pulling through
with the assist in diagnosing the performance of the cluster on the spot),
I was also able to flawlessly save a demo of an application whose
elasticsearch cluster had been compromised, by spinning up a new Juju
deployed elasticsearch cluster immediately, and getting it re-indexed
within a few hours - this was overseen by our VP of technology and made a
huge impression with our higher ups (first day on the job). I have since
created an infrastructure plan for how we might use Juju to facilitate our
many needs throughout the company, and shown how simple reactive patterns
can be a charm template for every next application.

One piece of the puzzle I wanted to get squared away before the rest is our
secrets lifecycle management. Following too many (high level yet technical)
discussions with upper management concerning the concept of "secrets" in
general, we have decided to procure an implementation of vault + consul for
encrypted key/value store. I think this is a great choice for us, seeing as
we have many separate apps, app envs, and app developers; the use of vault
will allow me (as an admin) to interface to the application developers with
the respective vault api for their application language(s), and in a sense
create an tooling/platform/application/language agnostic interface for
secrets that can be entirely decoupled from other tooling and easily
consumed by any application.

Hypothetically, with the vault + consul stack in place, the app devs will
interface to it, and use a similar "get secrets in our app" template for
each language/framework/app, leaving me free to charm up our applications.
In the eyes of the company I have incurred two primary efficiencies: a
template for new applications need be charmed - few custom modifications
needed for each next/new app to become "charmed" or deployable, and a
secrets interface to the app devs through vault - tightening down our
secrets visibility, whilst opening them up for consumption, and templating
of their provisioning in the application code.

All this to say, I will be making heavy use of aws and rackspace providers
over the next amount of time, and want to say thank you in advance for your
support :-)

Hope you enjoyed the update - more to come!

2.0 - so close!!!! SO EXCITED!!! WH00T!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160801/0ba0d32d/attachment.html>