Freelancer.com is an online outsourcing marketplace. Almost from its founding in 2009, the company has relied on Amazon's public cloud to deliver infrastructure-as-a-service.
David Harrison, the company's vice-president of engineering, says that shifting a business from its own hardware to the cloud can offer significant benefits. However, the cloud model should shape how companies architect their online systems.
They've got virtualization, great; they've got lots of different instance sizes, great. But they've got a way of actually programming for the platform, and that's the really amazing part
"If you want to think of Amazon as a turnkey solution, you really only have to learn what product you want and it's just a question of shoving the data in there and having it work," Harrison says.
"I think the underpinning architecture for a lot of what you do is still just Linux or Windows or whatever," he explains.
"I think it's not a question of whether you know Amazon or not. The APIs are clean they're well documented. It's easy enough to use, they've got the Web interface – you can point-and-click etc. – they've got all the command line tools, they've got binding libraries. They've got everything you need."
Amazon launches local cloud support operation
Dead database walking: MySQL's creator on why the future belongs to MariaDB
From zero to hero: Suncorp's Drupal 'leap of faith'
Trisquel GNU/Linux flies the flag for software freedom
"In that respect it's a question of understanding how your use case is going to fit within the cloud context and part of that comes down to experimentation," Harrison adds.
"Early, early on we ran a number of tests in terms of what our process was going to be for the data migration: how many hosts we were going to need to spin up, what the load profile was going to look like, how we were going to split that out.
"We tried to keep the original migration architecture to what we were previously running, so that when we made the migration it wasn't a massive leap, and we were small enough to do that."
He says the lessons are about understanding "the bounds and the nature of the new environment".
"So in a physical, dedicated hosting environment, you could have SSDs, you can really high-performance disks, you can have SANs. And [when Freelancer.com started using AWS] EBS was a younger technology: There weren't committed IOPS [on AWS] as there is now and that kind of thing. What you found [was] you wanted to flex and sort of bend your architecture a bit, so it would more directly match what you needed to get out of it.
"If you've got a disk-heavy read profile for your database, you really want to look at that and try to understand – 'Right, how can we get more of that up into RAM? How can we optimise our queries? How can we optimise our use patterns? Can we use more caching?'"
Understanding how your cloud infrastructure will scale is also important, Harrison says.
"How do I run a scalable version of my application stack. And that comes down something that we learned very early on: You've got to be able to silo your application stack, so that at any given time if you do have a failure – as you would in any environment – you can still continue to function beyond that failure."
If an instance dies, then you need to have enough additional capacity and supporting infrastructure, such as load balancers, to keep things going. "That's something that you've really got to engage with early on," Harrison says.
APIs are really Amazon's cloud's "killer feature," he adds. "They've got virtualization, great; they've got lots of different instance sizes, great. But they've got a way of actually programming for the platform, and that's the really amazing part."
"You can then tie that into how you do your scalable architecture," he explains. "So once you've established what your silos look like – once you've thought about your caching architecture and whether you want to shard or whether you want to cluster or whether you just want to use a really, really big instance – once you've established that, then you can actually start to automate. And that's where it really, really gets interesting. And a lot of fun."
Architecting for failure is nothing new for software engineers, Harrison says. If you're running your own physical hosts, you still have to deal with hardware failure. "The difference is, you also had to care about the power supplies, and disk failures, and the racking, and the cabling, and data centres," he says.
"You'd still have to think about what happens when that disk dies and you've got to worry about your EOLs on your hardware. And you've got to talk to your data centre guys and make sure they've got an extra diesel generator."
The difference with cloud is that although you need to design for resilience, "you don't have to worry about all that underlying stuff."
Instead you can spend more time working on the infrastructure itself, "without having to worry about the guts of it in terms of 'Ah okay, so we need to put in another order of Xeon processors' or whatever.
"If you take that out of the equation, what you actually get is the ability to spend more time on the patterns and shape of your infrastructure. And those patterns are really what let you scale."
Follow Rohan on Twitter: @rohan_p