2. Disclaimer
• I am jonasbn - like almost everywhere
• Long time Perl and web developer
• Open Source/CPAN contributor and
previously freelance developer in logicLAB
• Currently employed with DK Hostmaster
• I have no affiliation with ActiveState
3. (My) Developer Needs
• Easy access to platform, runtimes and
frameworks
• The least possible gap between
development, test and production
• Minimal differences between deployed
code and the code in the editor
• reproducibility for transparency
4. What do we have?
• Unit-tests
• Mocked objects and classes, stubs a.s.o
• Local servers / emulators
• Virtualization
• Dedicated environments (dev/test/prod)
• Code - lots of code...
9. Dr. Matt Wood (@mtz)
• Technology Evangelist with Amazon,
working with Amazon Web Services (AWS)
• http://youtu.be/NT-ccnFMBWA
• from Internetdagarna 2011 in Stockholm/
Sweden
12. Points from Dr. Matt Wood
• 30-70% divide
• IT infrastructure friction
• Focus on your core competences
• Focus on delivering value
• http://www.slideshare.net/FDIHdk/ahead-in-
the-cloud-matt-wood-amazon
13. Amazon EC2
• Amazon EC2 however does not get us
there - no matter how much elasticity it
provides
• http://aws.amazon.com/
14. Ruby/Perl in the cloud?
• @ActiveState introduces #stackato
based on phenona and Cloud
Foundry
• http://www.activestate.com/stackato
• http://www.cloudfoundry.com/
15. Stackato
• A micro-cloud
• current version 1.0.6
• out of beta, released 2012.02.29
• Platform as a Service (PaaS) private and
public
• Supporting several languages, their
frameworks and commonly-used services
21. operating
• start, start a service
• stop, stop a service
• restart, restart a service
• this is about it, for what I can provide for
now, I have no experience with long time
operation of a Stackato deployed service
• Oh there is one more thing...
25. updating
• update, when an application has been
pushed (deployed) this is the command you
will use
26. All the little things
• binding DNS, going beyond mDNS
• binding services (databases et al.)
• resource allocation, memory, instances etc.
• logging (more on this later...)
• now for some architecture...
27.
28. Support
• @ActiveState fora
• #stackato on irc://irc.freenode.org with
users and ActiveState staff
• Webcasts
• White papers
• ActiveState are incredibly open and
cooperative
29. Open Source Examples
• @ActiveState examples on Github
• my own fork is on Github
• Github is nice!
30. Stackato is not
• Open Source? - it is closed and proprietary
• @ActiveState is however dedicated to
keeping the micro-cloud solution free
32. Targets!
• Multiple targets
• development / test / production
• Targets make sense in SCM context
• trunk / branches / tags (releases)
• You could just go for the micro-cloud, but
you would loose some of the benefits
36. My Current Road Map
• Oracle as a service (Perl driver DBD::Oracle and Oracle
driver distribution issue)
• Cryptographic components (export of PPMs, Perl packages)
• Deployment of custom components
• Service integration (PostgreSQL)
• Full blown examples (Mojolicious over Mojolicious::Lite etc.)
• mDNS and dynamic DNS (might be .local)
• Central logging (syslog)
37. Conclusion
• The Stackato cloud is awesome
• @ActiveState mean serious business
• I am going to present and propose Stackato
as a part of our future infrastructure
38. Benefits
• Easy and controlled access to platform,
runtimes and frameworks
• The least possible gap between development,
test and production and minimal differences
between deployed code and the code in the
editor depending on your cloud deployment
• reproducibility for transparency since the
amount of magic is kept at a minimum