Khan's Blog

Opening Keynote

I was lucky enough to attend the two day Amazon Web Services summit here in Sydney this year, along side my team at Qantas. Boy, you really have to be a morning person to survive the keynote. With DJ Kanban (apparently a JIRA plugin) setting the mood with some bizarre mashups including this Eminem/Lorde Gem, before being treated to a light and sound extravaganza featuring strobe lights, a giant, rotating, luminescent cube and possibly the most dramatic video about IT ever made. All this was followed by a keynote speech including a young T-shirt clad multi-billionaire, co-founder of Atlassian, Scott Farquhar. The whole spectacular was reminiscent of the opening scene of Marvel’s Iron Man 2 (The actual opening can be found here). And just incase you hadn’t had enough, the whole shebang was repeated for the opening of day 2.

But aside from all the glitz and glamour, we had not insignificant amounts of content. Each day had a series of breakout presentations. With each talk attended, one had to endure the compulsory broadside of corporate chestbeating and thinly-veiled sales pitch. But if you looked past all this, there was a great deal to take away from the AWS summit, and I would encourage anyone regardless of technical background to attend given the opportunity.

The takeaway

So what was it that I took away from the summit? Although a great number of topics were covered, from AI, covering Amazon’s Lex, Polly and Rekognition services, to big data, security and IOT, I feel as though the AWS Summit had two major themes. First, being lean, and the second being serverless. These two themes really went hand in hand, but we’ll get to that.

Feeling Lean

I was captivated by quite a few talks aimed at enterprises. Many spoke, on high levels, on how to drive the pace of innovation, and how innovation, at speed, was a key driver for the ability to adapt.

Much was said about the ability to adapt. Indeed, in the opening keynote speeches, Westpac, a company which as of this year is 200 years old, making it one of Australia’s longest running companies. Much was spoken of how its survival was due to the ability to adapt and change with the environment, drawing attention to its historical firsts, such as first female bank teller, first female CEO in Australia, and first in Australia to embrace online banking. The theme here was not getting to the finish line first, but rather the willingness to embrace change. This was reiterated by Scott Farquhar, saying the intention behind founding Atlassian was not to build a profitable company, instead to build a company which will outlast its founders. Being able to adapt was key to fulfilling this goal for Scott, and indeed was a general theme of the rest of the keynote speeches. Adaptation, it seems, was a way to avoid becoming so highly specialized that one might bow at the slightest breeze, at the cost of some efficiency.

And how was this ‘ability to adapt’ driven? Through cultural change, implementing agile work practices which were far more conducive to adaptive development and by driving innovation from all levels, from the top down, by dedicating resources and time to proof of concepts and exploratory ideas.

Going Serverless

At several different breakout sessions, The trope Servers as cattle, not pets, was constantly used. It was used to describe the transistion away from dedicated server hardware, instead moving toward infrastructure as code, or Platform as a Service. But these talks were all about going one step further and taking any aspect of the server out of the question for the end user, and moving instead to Function as a Service (FaaS). Instead of having to run and maintain a virtual server, that continually runs, all the while paying for this uptime, FaaS enables developers to concentrate only on functionality while the provider (in this case Amazon) handles the rest. That means you don’t have to worry about scaling for load or maintenance of any form. The talks I went to really pushed this concept from the buisiness case of reducing ost by only ever paying for exactly what you use, and from the development side where the developer is only ever concentrating on code which provides value, and none of the glue in between.

AWS provide this ability through Lambda, and almost every single breakout session I went to had mentioned Lambda in some way, shape or form. It seemed that there were very few situations where you couldn't, or wouldn't use it, Time will tell if this is truly the next step, and if its here to stay, but for the time being consider me convinced. The idea of FaaS very plainly fits in a shift in architecture, from monolithic code blocks, to a collection of dedicated and tightly coupled services to a loose collection of stateless, reusable microservices (In this case, as they were pushing, the microservies were a collection of Lambdas). This little diagram was another very frequently reused trope, thrown at us in presentation after presentation.

But the migration to microservices is another way of increasing reusability and reliability. Encapsulating functionality in Small services with a single purpose increase reliability. As it is a service, it allows for reuse in other projects. Being serverless means that every microservice can scale to meet the demands of each application using them.

Putting it all together

Why do I say these went hand in hand? One of the final talks that I went to was a completely unapologetic sales pitch from the fine folk at AWS entitled imaginatively as Deliver Desktop Applications with Amazon AppStream and Workspaces. This talk would have been entirely uninteresting and a poor choice if it hadn’t been for the guest speaker from the VP of IT & S/CIO at Clough, an engineering firm, Emma Whitty. She spoke about the transition the company made when she joined, including how she had reduced her IT department from over 40 dedicated employees to just 2, all the while producing more innovation and giving better results for the company. How had she achieved this? This is where our two themes converged. On one hand, through the use of AWS services, a platform which required no maintenance and was accessible 24 hours a day world wide was created. This was a great enabler, removing the need to maintain expensive physical hardware and dedicated people to maintain it, but also enabling development and innovation at a breakneck pace by allowing developers to concentrate their time developing functionality.

Whilst this change was focussed on technology, the other side of this was people and culture. Whitty had cut her dedicated IT staff down to absolute bare minimum, moving all development externally. To perform development work, she created short lived startups which had a sole focus of the project for Clough, leveraging the AWS infrastructure and resources already being used in the company. I see this movement of human resources as a sort of analogue of the technology side. Instead of having a large number of expensive, permanent developers, Whitty had spun up her human resources when and only when she needed them. Developers as Cattle, Not Pets, should have been a trope of this particular presentation.

Final Thoughts

Are we moving toward a future where we break down large, monolithic companies and move toward loosely coupled startup style companies? Can we see a future where innovation can be turned on like a tap, providing infrastructure of both people and technology for short, intense bursts to fulfill a need and have them dissipate as soon as there is no need for them? Perhaps this is where we will need to go if we want to keep innovating in the future, but I am not sure if this is a future I would like to see.