<div dir="ltr">Awesome! Thanks for sharing :)</div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-02 6:38 GMT+02:00 James Beedy <span dir="ltr"><<a href="mailto:jamesbeedy@gmail.com" target="_blank">jamesbeedy@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Team,<div><br></div><div>As some of you may know, I have taken on a new position as DevOps Engineer for a creative company -> <a href="http://creativedrive.com" target="_blank">CreativeDrive</a>. 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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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 :-)<br></div><div><br></div><div>Hope you enjoyed the update - more to come!</div><div><br></div><div>2.0 - so close!!!! SO EXCITED!!! WH00T!!!</div></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div>