This month’s ACUG meeting was cooler than usual – instead of having one speaker talk on a cloud-related topic, we had multiple group members do short presentation on what they’re actually doing in the cloud. I love talks like that, it’s where you get real rubber meets the road takeaways.
I thought I’d share my notes on the presentations. I’ll write up the one we did separately, but I got a lot out of these:
- OData to the Cloud, by Craig Vyal from Pervasive Software
- Moving your SaaS from Colo to Cloud, by Josh Arnold from Arnold Marziani (previously of PeopleAdmin)
- DevOps and the Cloud, by Chris Hilton from Thoughtworks
- Moving Software from On Premise to SaaS, by John Mikula from Pervasive Software
- The Programmable Infrastructure Environment, by Peco Karayanev and Ernest Mueller from National Instruments (see next post!)
My editorial comments are in italics. Slides are linked into the headers where available.
OData was started by Microsoft (“but don’t hold that against it”) under the Open Specification Promise. Craig did an implementation of it at Pervasive.
It’s a RESTful protocol for CRUDdy GET/POST/DELETE of data. Uses AtomPub-based feeds and returns XML or JSON. You get the schema and the data in the result.
You can create an OData producer of a data source, consume OData from places that support it, and view it via stuff like iPhone/Android apps.
Current producers – Sharepoint, SQL Azure, Netflix, eBay, twitpic, Open Gov’t Data Initiative, Stack Overflow
Current consumers – PowerPivot in Excel, Sesame, Tableau. Libraries for Java (OData4J), .NET 4.0/Silverlight 4, OData SDK for PHP
It is easier for “business user” to consume than SOAP or REST. Craig used OData4J to create a producer for the Pervasive product.
Questions from the crowd:
Compression/caching? Nothing built in. Though normal HTTP level compression would work I’d think. It does “page” long lists of results and can send a section of n results at a time.
Auth? Your problem. Some people use Oauth. He wrote a custom glassfish basic HTTP auth portal.
Competition? Gdata is kinda like this.
Seems to me it’s one part REST, one part “making you have a DTD for your XML”. Which is good! We’re very interested in OData for our data centric services coming up.
Moving your SaaS from Colo to Cloud
Josh Arnold was from PeopleAdmin, now he’s a tech recruiter, but can speak to what they did before he left. PeopleAdmin was a Sungard type colo setup. Had a “rotting” out of country DR site.
They were rewriting their stack from java/mssql to ruby/linux.
At the time they were spending $15k/mo on the colo (not including the cost of their HW). Amazon estimated cost was 1/3 that but really they found out after moving it’s 1/2. What was the surprise cost? Lower than expected perf (disk io) forced more instances than physical boxes of equivalent “size.”
Flexible provisioning and autoscaling was great, the colo couldn’t scale fast enough. How do you scale?
The cloud made having an out of country DR site easy, and not have it rot and get old.
Question: What did you lose in the move? We were prepared for mental “control issues” so didn’t have those. There’s definitely advanced functionality (e.g. with firewalls) and native hardware performance you lose, but that wasn’t much.
They evalled Rackspace and Amazon (cursory eval). They had some F5s they wanted to use and the ability to mix in real hardware was tempting but they mainly went straight to Amazon. Drivers were the community around it and their leadership in the space.
Timeline was 2 years (rewrite app, slowly migrate customers). It’ll be more like 3-4 before it’s done. There were issues where they were glad they didn’t mass migrate everyone at once.
Technical challenges:
Performance was a little lax (disk performance, they think) and they ended up needing more servers. Used tricks like RAIDed EBSes to try to get the most io they could (mainly for the databases).
Every customer had a SSL cert, and they had 600 of them to mess with. That was a problem because of the 5 Elastic IP limit. Went to certs that allow subsidiary domains – Digicert allowed 100 per cert (other CAs limit to much less) so they could get 100 per IP.
App servers did outbound LDAP conns to customer premise for auth integration and they usually tried to allow those in via IP rules in their corporate firewalls, but now on Amazon outbound IPs are dynamic. They set up a proxy with a static (elastic) Ip to route all that through.
Rightscale – they used it. They like it.
They used nginx for the load balancing, SSL termination. Was a single point of failure though.
Remember that many of the implementations you are hearing about now were started back before Rackspace had an API, before Amazon had load balancers, etc.
In discussion about hybrid clouds, the point was brought up a lot of providers talk about it – gogrid, opsource, rackspace – but often there are gotchas.
Chris Hilton from Thoughtworks is all about the DevOps, and works on stuff like continuous deployment for a living.
DevOps is:
- collaboration between devs and operations staff
- agile sysadmin, using agile dev tools
- dev/ops/qa integration to achieve business goals
Why DevOps?
Silos. agile dev broke down the wall between dev/qa (and biz).
devs are usually incentivized for change, and ops are incentivized for stability, which creates an innate conflict.
but if both are incentivized to deliver business value instead…
DevOps Practices
- version control!
- automated provisioning and deployment (Puppet/chef/rPath)
- self healing
- monitoring infra and apps
- identical environments dev/test/prod
- automated db mgmt
Why DevOps In The Cloud?
cloud requires automation, devops provides automation
References
- “Continuous Delivery” Humble and Farley
- Rapid and Reliable Releases InfoQ
- Refactoring Databases by Ambler and Sadalage
Another tidbit: they’re writing puppet lite in powershell to fill the tool gap – some tool suppliers are starting, but the general degree of tool support for people who use both Windows and Linux is shameful.
Moving Software from On Premise to SaaS
John Mikula of Pervasive tells us about the Pervasive Data Cloud. They wanted to take their on premise “Data Integrator” product, basically a command line tool ($, devs needed to implement), to a wider audience.
Started 4 years ago. They realized that the data sources they’re connecting to and pumping to, like Quickbooks Online, Salesforce, etc are all SaaS from the get go. “Well, let’s make our middle part the same!”
They wrote a Java EE wrapper, put it on Rackspace colo initally.
It gets a customer’s metadata, puts it on a queue, another system takes it off and process it. A very scaling-friendly architecture. And Rackspace (colo) wasn’t scaling fast enough, so they moved it to Amazon.
Their initial system had 2 glassfish front ends, 25 workers
For queuing, they tried Amazon SQS but it was limited, then went to Apache Zookeeper
First effort was about “deploy a single app” – namely salesforce/quickbooks integration. Then they made a domain specific model and refactored and made an API to manage the domain specific entities so new apps could be created easily.
Recommended approach – solve easy problems and work from there. That’s more than enough for people to buy in.
Their core engine’s not designed for multitenancy – have batches of workers for one guy’s code – so their code can be unsafe but it’s in its own bucket and doesn’t mess up anyone else.
Changing internal business processes in a mature company was a challenge – moving from perm license model to per month just with accounting and whatnot was a big long hairy deal.
Making the API was rough. His estimate of a couple months grew to 6. Requirements gathering was a problem, very iterative. They weren’t agile enough – they only had one interim release and it wasn’t really usable; if they did it again they’d do the agile ‘right thing’ of putting out usable milestones more frequently to see what worked and what people really needed.
In Closing
Whew! I found all the presentations really engaging and thank everyone for sharing the nuts and bolts of how they did it!
the agile admin 