This is a summary of the invited talk I gave at the first CloudCamb, the Cambridge Cloud Computing user group.
For context, Simone Brunozzi had just given a 30 minute presentation, presumably his standard spiel on Cloud computing: "It's great because it relieves you of the duty of managing your own computers, it lets you scale rapidly and quickly, etc etc". Perfectly valid, but old news I think, and more importantly, largely irrelevant to the world of the very-early-stage startup.
The original title was "Timetric and Amazon Web Services", but several people liked the phrase "Outsourcing worrying", which I coined halfway through speaking.
For those too bored to read the wholw thing, Jim Downing summed my talk up as "The point of EC2 for an early stage start-up isn't scalability, it's the complexity mgmt."
"Outsourcing worrying"
Inkling Software is a very early stage startup. There's only the three of us - I've been working on it fulltime for just coming up 5 months, and my two cofounders have been full-time a couple of months less.
This gives us a very different take on the use of AWS. Simone gave exampes talking about AWS's advantages compared to running data-centres of a couple of hundred computers - we have three laptops and one Linux server. Our cloud computing infrastructure currently amounts to at most 5 or 6 cloud-based servers. So. since essentially none of Simone's points apply to our situation, what do we gain from AWS?
Simone's advantages essentially boil down, in very hand-wavy terms to two points:
-
Cost
-
Ease of use.
I think there is a third, missed by him, which in my mind might be summarized as "Process".
Cost
In terms of cost, it's not obvious that AWS makes any sense for a small company. S3 is ridiculously cheap, but EC2 isn't - we never use more than 10 servers at any one point - and usually not more than four. This lands us with a monthly bill of several hundred dollars. Hardly breaking the bank, but at this stage in the game - very early startup, no actual customers or income yet - this is significant. After 5 months, it turns out it would have been cheaper to buy the computers outright.
On a larger scale there might be the issue of purchase granularity - buying physical servers requires speccing them out, obtaining quotes, etc, all of which makeas it unreasonable to buy less than a few tens/hundreds/thousands of servers (depending on your company size). That doesn't apply to us - we'll quite happily buy a single extra server when we need it.
Ease of use
S3, I have no complaints about - it's like a magic hard disk in the sky as big as I'll ever need - no worries about buying new disks and fitting them, no worrying about kernel version/disk controller incompatibilities, backups etc.
EC2 doesn't present as trivial an interface - and it's advantages are not obvious at our scale.
It's true that I don't have to worry about building my own servers (but I wouldn't anyway, I'd just buy some from Dell which I knew worked); I don't have to worry about routing power supplies to them, (but on the scale we're working at, that would just be some extension leads. In my last job, I was tangentially involved in fighting building contractors, trying to run additional power to a building, and I'm happy to be rid of that pain, but again, on our scale that's not relevant.)
It's also true that I don't have to worry about whether the pipe from my servers to the network is alive, which would be more of a worry if they were located in my office, but I could get much the same effect by co-locating a server. It wouldn't mean my servers were always accessible, but it would mean it was Somebody Else's Problem at which I can throw money - which is mostly what I'm after; I'd rather throw money (albeit limited sums) rather than time.
As for EC2's much vaunted scalability issues - well, we don't know how to scale our service to millions of users yet. When we do, then it'll important to worry about the underlying hardware, and EC2 will be the obvious choice. At the moment, we have bigger problems to solve, and I'm a great believer in solving the problems that are immediately to hand, not worrying about maybe's and what-if's later on.
So to be honest, if cost and ease of server management were all AWS offered, there'd be barely any point in it for companies on our scale.
Process
Actually, though, there is a huge advantage to us in using AWS, though it's not one we foresaw.
Firstly, I should mention that we need several varieties of server to run Timetric - we have the public-facing web-servers, and a few different backend servers performing different functions. All of these need different configurations, which are tweaked as we develop the service.
Secondly, I should point out that the AWS SLA very carefully states that EC2 servers don't have an infinite lifespan; Amazon reserve the right to terminate & restart them at any time. And when that is done, all local state is lost, the server is returned to its initial configuration. (This is not just a theoretical risk, it's happened to us a couple of times.)
In short, firstly, we need to manage server configurations, and secondly, if we simply tweaked configurations on the running server, those configurations would be lost eventually. However, all of these machines are virtualized, and Amazon provide tools and APIs for generating machine images and for doing instance-specific configuration tweaks.
So, Amazon are forcing us to address the issue of server configuration management, and at the same time presenting us with tools to help us do so.
This sort of configuration management is essential to any computer-based company. Any medium-to-large company worth its salt will have processes in place to manage this complexity, whether on physical or virtual servers. (I'm prepared to believe there are lots of companies out there not worth their salt!)
Managing this complexity successfully involves having processes with three properties:
-
Repeatability (so I can bring up new, identical, servers)
-
Testability (so I can run tests against my infrastructure to make sure its doing what I think it is)
-
Version Control (so I can roll back to known-good versions)
The suite of AWS tools and APIs lets us build such processes very cheaply, with much less developer time involved than otherwise.
Were we running on servers that we physically owned; whether they were in the same office as us, or whether colocated elsewhere, I can pretty much guarantee we'd not be doing this. It wouldn't be impossible - although it would certainly be more difficult, we could certainly manage to script much of a server installation, and it wouldn't be out of the question to come up with a testing regime. But I know how we work, and I know we wouldn't. With a server that sat there, and had apaprently persistent state, we'd be inclined to get it to a known-good state and tweak occasionally thereafter, sometimes remembering to write down what changes we'd made. The cost in time of proper process for server management is just too high otherwise.
And then we'd pay a higher price still, as soon as there was a failure on the server, or we needed a second one, or we needed to roll back a configuration change.
Moral obligations
I believe that running a software company involves a number of aspects to the work which are frankly not optional, and which amount essentially to moral obligations (though I know I have a moral sense which seems not entirely in accord with most people's). Using a proper test suite, using a good version control system, making sure you have off-site backups of all important data, and so on. These are not optional extras; a system without these is incomplete.
But as a small company you simply don't have time to do all of these things. They are not optional - but you have to miss some out, and desperately hope you won't be caught out before you have time to put them in place.
These are the sorts of things that keep me awake at night worrying; I like to minimize the number of risks to which we're exposed.
Configuration management of your servers is one of these things. What AWS does for is bring that process within reach of even the smallest companies. Having this process in place helps me sleep at night.