<p dir="ltr">These days I'm exploring OpenStack in the hope of moving my org from a VMWare foundation, but we have a lot of clients who are just doing the typical vm thing so I need to explore more of how to support a VMWare hypervisor in openstack and wrangling things like exchange and AD servers. I'm actually standing up an openstack install at the local hackerspace to share the learning experience. I started loading up the controller Thursday. We're still looking for parts. </p>

<p dir="ltr">So,  yes, I'm interested in learning more, but not available for employment. </p>
<p dir="ltr">JSR /</p>
<div class="gmail_quote">On Apr 5, 2013 7:57 PM, "Micah Yoder" <<a href="mailto:micah@yoderdev.com">micah@yoderdev.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello again,<br>
<br>
So as I've mentioned a long time ago I work for Rackspace, who is now of course a major cloud provider*.  As of a couple months I am certified Cloud Savvy, which is supposed to mean I have a clue about how to design applications in the cloud.<br>

<br>
Many people who come from a dedicated hosting platform will spin up a cloud server and install stuff on it just like they did on their dedicated server, install their web application on it, and let it go.  If something acts up they troubleshoot it.  It is expected to last a long time.  They might take advantage of virtualization features like snapshots, but that's as "cloudy" as they get.<br>

<br>
To properly take full advantage of the cloud and use it as intended, you need to get a completely different mindset when you're designing applications.  Some principles involve:<br>
 -- Everything should be set up via automation, using something like Chef or Puppet. You should *never* manually install things or edit the configuration settings on production (or even staging) servers.<br>
 -- Use the API, not the control panel, to set up servers and related cloud products.<br>
 -- Design for failure. Stuff breaks. If the application can't access some database, it should if possible fail over to the replica. If that's not possible, fudge something so that the user doesn't notice, if at all possible. And do that quickly so the user isn't waiting a long time.  Also, use load balancers and take out flaky nodes.  If some cloud server goes weird in some way, you don't nurse it back to health, you kill it and fire up another one (with automation).  All automatically.  (One analogy is that cloud servers should be treated like cattle, not like pets!)<br>

 -- Put different services on different sets of cloud servers<br>
 -- Design security in at every layer<br>
<br>
Just wanted to throw this out and ask if anyone is working with a missions organization that is designing a cloud application.  If so, and you want to run something by me, let me know!<br>
<br>
Also wonder if it might make sense for me to go to ICCM.  If I could be of significant help, I'd consider it.  With any luck I might even be able to get Rackspace to sponsor me going there.<br>
<br>
<br>
* If you're a great Linux or network device guy and want to live in San Antonio or Austin, please let me know. We're having a very hard time filling our positions!<br>
<br>
<br>
______________________________<u></u>_________________<br>
ChristianSource FSLUG mailing list<br>
<a href="mailto:Christiansource@ofb.biz" target="_blank">Christiansource@ofb.biz</a><br>
<a href="http://cs.uninetsolutions.com" target="_blank">http://cs.uninetsolutions.com</a><br>
</blockquote></div>