[CS-FSLUG] Cloud applications and missions

[Josiah Ritchie]

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.

So,  yes, I'm interested in learning more, but not available for
employment.

JSR /
On Apr 5, 2013 7:57 PM, "Micah Yoder" <micah at yoderdev.com> wrote:

> Hello again,
>
> 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.
>
> 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.
>
> 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:
>  -- 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.
>  -- Use the API, not the control panel, to set up servers and related
> cloud products.
>  -- 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!)
>  -- Put different services on different sets of cloud servers
>  -- Design security in at every layer
>
> 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!
>
> 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.
>
>
> * 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!
>
>
> ______________________________**_________________
> ChristianSource FSLUG mailing list
> Christiansource at ofb.biz
> http://cs.uninetsolutions.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ofb.biz/pipermail/christiansource_ofb.biz/attachments/20130406/9d3df806/attachment.htm>