<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Passing Curiosity: Posts tagged cloud</title>
    <link href="https://passingcuriosity.com/tags/cloud/cloud.xml" rel="self" />
    <link href="https://passingcuriosity.com" />
    <id>https://passingcuriosity.com/tags/cloud/cloud.xml</id>
    <author>
        <name>Thomas Sutton</name>
        
        <email>me@thomas-sutton.id.au</email>
        
    </author>
    <updated>2014-02-11T00:00:00Z</updated>
    <entry>
    <title>Puppet Camp Sydney 2014</title>
    <link href="https://passingcuriosity.com/2014/puppet-camp-sydney/" />
    <id>https://passingcuriosity.com/2014/puppet-camp-sydney/</id>
    <published>2014-02-11T00:00:00Z</published>
    <updated>2014-02-11T00:00:00Z</updated>
    <summary type="html"><![CDATA[<p><a href="http://puppetlabs.com/community/puppet-camp">Puppet Camps</a> are regular, regional events for the Puppet community and
this is the second or third time I’ve attended one. They can feel a <em>tiny</em> bit
vendor-y (this should be unsurprising) but the quality of the talks and the
attendees is pretty good, in my experience.</p>
<p><strong>Nigel Kersten</strong>’s keynote talk was aimed at a pretty broad audience (a bit of
Puppet, what’s driving uptake, etc.) but also described some of the new
features in components included in the next release (IIRC) of Puppet
Enterprise. I was particularly interested to learn about <a href="http://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html#policy-based-autosigning">policy based
auto-signing</a> and <a href="http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#trusted-node-data">trusted node data</a> in Puppet 3.4+, <a href="http://docs.puppetlabs.com/guides/custom_facts.html#external-facts">external facts</a>
in Factor 1.7+, more readable ouput from Hiera 1.3+, and the news that
Puppet Labs will be supporting some of their modules from the <a href="http://forge.puppetlabs.com/">forge</a>.</p>
<p><strong>Peter Leschev</strong> from Atlassian described the process of introducing and
developing “infrastructure as code” in the Atlassian build engineering team. He
describe their introduction of a number of tools and measures and the impact on
confidence in infrastructure changes being made. It was interesting to see the
journey of adding code reviews, Puppet, Vagrant-based development (with
Veewee), behaviour based testing (with Cucumber), continuous integration
(Bamboo and Vagrant), profiling (Puppet’s <code>--evaltrace</code> flag), automated
deployment (to staging) and notification (in HipChat). Later on I wished I’d
asked if the graphs of confidence in his slides were from measurements, or for
illustrative purposes only.</p>
<p><strong>Lindsay Holmwood</strong> from Bulletproof described the <a href="http://puppetlabs.com/community/puppet-camp#previous">Flapjack</a> monitoring
system – which seems pretty cool – and how you’ll be able to configure it
with Puppet (when he releases the Puppet module). The architecture of Flapjack
looked pretty interesting and I plan to have a play with it this weekend.</p>
<p><strong>Rene Medellin</strong> spoke about NAB’s move to push some of their workloads into
“the cloud” (AWS). They used Puppet as part of their SEO machine image building
process <em>and</em> in deployment as one of their monitoring and compliance tools.
Lots of Jenkins and automated building of AMIs and CloudFoundry templates and
such.</p>
<p><strong>Aaron Hicks</strong> from Landcare Research NZ spoke about the way he uses Puppet in
a scientific research environment. Particularly interesting was the use of
Puppet to formalise the configuration of the many, many precious snowflake
machines used in the various research projects his organisation supports. The
idea of supplying Puppet manifests to help in the replication of scientific
computing sounds great.</p>
<p><strong>James Dymond</strong> and <strong>John Painter</strong> from Sourced Group described a series of
“Puppet in the AWS cloud” architectures they’d developed for clients in their
consulting engagements. Most interesting was their fourth (I think) solution,
where they implemented a “gateway” between AWS autoscaling notifications and
Puppet, allowing the master to sign certificates, delete node reports, etc. as
the AWS autoscaling system adds and removes nodes.</p>
<p><strong>Matt Moor</strong> from Atlassian described the way they use Puppet to manage their
SaaS offering. Each SaaS client has their own VM which, now, is managed using
Puppet. This allows them to manage service and version dependencies much more
reliably than their previous approach of building massive WAR files using Maven
and managing them with hack-y shell scripts.</p>
<p>The last talk was by <strong>Chris Barker</strong> from Puppet Labs who gave a product
demonstration of Puppet Enterprise. I’d already used most of the features
demoed but some of the newer stuff – especially the <a href="http://puppetlabs.com/presentations/introducing-puppet-enterprises-event-inspector">event inspector</a> –
looked pretty cool.</p>
<p>Puppet Camp Sydney 2014 was a great event and brought to mind again just how
much fun operations work (what little I’ve done) can be. In time, I expect the
slides and videos of the presentations will be available from the Puppet Labs
web-site on the <a href="http://puppetlabs.com/community/puppet-camp#previous">Previous Puppet Camps</a> page.</p>]]></summary>
</entry>
<entry>
    <title>PyconAU 2012: Implementing a cloud service in Python</title>
    <link href="https://passingcuriosity.com/2012/cloud-services/" />
    <id>https://passingcuriosity.com/2012/cloud-services/</id>
    <published>2012-08-18T00:00:00Z</published>
    <updated>2012-08-18T00:00:00Z</updated>
    <summary type="html"><![CDATA[<p>John Barham from SlickDNS.com.</p>
<p>A bit of blurb about “the cloud”.</p>
<p>Using</p>
<ul>
<li><p>Using ECS and RDS for “main server”.</p></li>
<li><p>DNS servers on linode.</p></li>
<li><p>Postmark for email.</p></li>
<li><p><code>fabric</code></p></li>
<li><p><code>daemontools</code></p></li>
<li><p><code>celery</code> on RabbitMQ. Decoupling form submission from processing to improve
user experience; event logging (gathering metrics).</p></li>
<li><p><code>memcached</code> for caching with Django’s built-in support; cache anonymous
pages.</p></li>
<li><p>Browser caching: embed timestamps in the static media URLs, resources can be
cached forever as the URL will change (http://gist.github.com/3375913).</p></li>
<li><p>API. Good old REST vs SOAP and JSON vs XML blah. HTTP authentication: basic
over HTTPS.</p></li>
<li><p>Logging: CloudWatch to monitor EC2, is pretty heavyweight; StatHat for
statistics and event logging.</p></li>
</ul>
<p>See “The S Stands for Simple”</p>]]></summary>
</entry>

</feed>
