Programming in The New World
I move to Nashville Tennessee, I move to AWS, I become infinitely more metal
First of all, hello to all the people who subscribe to me on Medium; the few and the proud.
I’ve been quiet for a while. It’s been about 5 months since I last posted, in fact. And there’s been a reason for that…
… I’ve changed jobs, and I’ve moved to another country!
I’m Australian, and I’ve lived in Australia all my life up to now. The last 7 years or so were working as CTO for a tiny startup in the Adelaide Hills, building a lot of software in Python on Google App Engine, and writing about my ideas around that, particularly in my Medium publication The Infinite Machine.
Then suddenly, BAM, I’ve moved to the US, to Nashville, with my darling wife Jodie O’Regan. I’m working in a new job in a proper grown-up company, with a fancy title that includes words like “Director” and “Architecture” and such.
Now those of you who’ve kept reading until now will be thinking, yes, blah blah, what does this have to do with the code my good man? And to you I will respond with three letters…
… AWS.
My focus has switched away from Google’s cloud, and toward Amazon Web Services, which I’m hugely excited about!
Google’s cloud, in particular App Engine, has been a professional focus of mine since maybe 2011, 2012? And it’s been an amazing thing to work with.
But this is tech, and time marches forward. In 2012, App Engine was like a kind of magic obelisk from the future. But in 2018, it’s beginning to feel dated, particularly as we watch the emergence of Serverless Computing.
The further from the metal you get, the more metal you become.
In the cloud computing world (that is, the massive scale commercial distributed computing world), Serverless Computing is about as far from the metal as you can get.
Serverless is an idea that’s a little woolly around the edges, especially when the marketing folks really get up a head of steam (our yogurt is Serverless, and Gluten Free!), but you can boil it down to any computing done on cloud services where you only pay for usage; you don’t deal with (and pay for) provisioning capacity.
The work I’ve been doing on Google App Engine with the concept of The Infinite Machine always wanted to run on Serverless infrastructure. And App Engine itself was an early shot at Serverless, that just fell a little short. In particular, you still have to think about Instances (even though they can be automatically provisioned), and, crucially, you pay a 15 minute minimum penalty every time a new one is spun up.
That’s something that hurt me when using adaptive sharding and similar algorithms, where I would kick off a lot of tasks all at once, and they’d all finish quickly; a spiky workload. If you run a huge load of very short tasks (which might cause hundreds of instances to spin up over a couple of minutes) and they all complete in a minute or so, you pay for those minutes + a 15 minute startup cost per instance; roughly a factor of ten penalty for having a spiky rather than smooth load. If you do that a lot, you’re going to hear from some angry baboons in the accounts department.
Now, Google’s refreshing App Engine with “Second Generation Runtimes”, but checking the docs, the 15 minute startup cost still applies. So that’s still a bummer.
Serverless Computing meanwhile revolves around Cloud Functions. Variants of these are available from Google, Microsoft, and Amazon, although Google’s offering only supports Javascript, while Microsoft and Amazon support many languages. That’s lame, Google!
This focus on AWS means I get to really dig into AWS Lambda, which is a really solid cloud function offering. Lambdas seem to be really cheap to run, there’s a per lambda flagfall charge but it’s very low, and they support Python, which is important for my functional distributed programming work.
So, expect to hear a lot from me about Lambdas in the near future.
Also, I’ve decided to discontinue The Infinite Machine. Its focus was on Google App Engine + Python Standard Environment, First Gen Runtime, and it can be a time capsule of that work.
As I move on to an AWS focus, I want to drop the Medium Publication idea (it seems a bit pointless honestly, everyone follows me, few people follow the publication), and I want to give this practical functional distributed computing technique a new name… Infinite Programming.
I’ll be developing the concept of Infinite Programming on AWS over time. It’ll include the concepts I began on Google App Engine, and extend them as far as I can push them. The core idea is to take distributed programming, add practical functional techniques and a sprinkle of proper magic, and end up with a new style of programming which is simple, elegant, and ridiculously productive.
I’ll begin with a focus on Python, partly because of its mystical ability to serialize first class functions and send them over the wire, and partly because I just like it. I do expect to branch out into other languages over time.
My first impressions of AWS are that there’s a lot of interesting stuff there (too much really), and that it’s terrifically complicated compared to the simplicity of App Engine. So my first efforts will go towards identifying the most promising services for Infinite Programming (stuff that’s serverless but also has some extra necessary qualities), and putting together the basics in Python.
These basics might include
- An equivalent of the @task decorator for throwing functions into another distributed process; maybe @lambda?
- Some work on Adaptive Sharding using Lambdas and various data stores
- The @lambda decorator should get me to a place where I can pass first class functions around and run them in separate lambdas, so I should be able to construct a variety of distributed map functions, which can map over data sources and apply a mapping function to elements.
- I’ll need to be able to debounce and cache these distributed functions using variants of @lambda.
- And if I can manage it, I might be able to get to distributed futures in the manner of @future.
I expect the building blocks of all of this to include a lot of use of SQS Queues paired with Lambdas (to add in the robust retry semantics that App Engine has with Tasks).
AWS seems to conspicuously miss a serverless data store comparable to Google Cloud Datastore. That is, something that
- only charges you for usage (storage and access),
- scales massively, and
- has transactional capability.
Dynamo DB almost fits the bill, but it doesn’t have transactions. The Java Client Library for Dynamo DB does have transactions, however, so I may be able to wrap that into a set of lambdas and call it from Python, and have the service I need. Or I could go read the Java code and make a Python version? There is a problem in that Dynamo DB makes you provision capacity (and pay for that provisioned capacity). This can auto scale, but I think it’ll make it possibly expensive, and also the cost of spiky scaling may be strange and bad. That needs some digging. On the plus side, it seems to be crazy fast (compared to Datastore’s plodding).
Aurora Serverless may work; it’s got transactions and it’s I think it’s properly serverless. It’s a relational database though (MySQL compatible) and I’m worried about its ability to really scale. Will access slow down as a table gets big? Will transactions slow down or become less reliable? Will cost stay under control? Again it needs some investigation.
A dark horse is Amazon Cloud Directory. This seems to be a quirky hierarchical database that scales and has transactions. I don’t understand the pricing yet, that could kill the idea.
And with all of these options, the devil is in the details. This is always true of cloud services; what looks good on paper can fall apart in practice because of one unfortunate constraint listed somewhere in the fine print.
Anyway, at this point I’m rambling. There’s stuff to do. This’ll be fun! Stick around.
