AWS Executive Briefing 20.06.18
The AWS Executive Briefing is a quarterly event that gives folks an opportunity to say how they’re using or supporting others’ use of Amazon’s services. It’s not “down in the weeds” technical, as you’d expect from anything with the word “executive” in the title. This quarter’s presentation was sponsored by Rackspace who made up 2/3 of the presentation (James Morris and Tom Ellis). Clearly industry in general, and fintech in particular, is very excited right now, and AWS are not hanging around in their efforts to capitalise on the opportunity.
Jonathan Allen is one of their “Evangelists” (which still sounds weird as a job title) and represented AWS with the kick-off talk then joined the Q&A panel later. Clearly he’s now passed Amazon’s Corporate Messaging test since he was allowed to field questions freely rather than having to exit quickly as was the case last time I saw him speak at an event.
Allen pointed out that in the last year they’ve launched over 1400 new services, which seems like a lot, but it remains to be seen how useful each is. In his previous role as CTO at Capital One bank he moved more or less the entire firm to AWS, quite an achievement in anyone’s book. He explained how previously at Capital One, and now, in his new role he espoused the benefits of Scrum, Kanban, Pair programming, Agile and dev ops in their “2-pizza” teams of 6 to 12 members. Each team owns a few of these (micro)services. Now many of us have been doing all these development-oriented processes for years having learned the hard way that getting people to write great code is best achieved if they have to fix their own screw-ups, having someone to bounce ideas off and check your code is A Good Thing, and so on. These truisms now have proper nouns associated with them. It’s good to have it spelled out literally though.
One interesting approach AWS use is to get the dev team to write the press release before anyone writes a line of code. They also put the questions into the FAQ, and define the user interaction upfront. Anything that focuses on the deliverable while preventing the inevitable scope creep is worth investigation, and this approach seems like it would deliver. We’ve all had that often iterative conversation with a client that starts with “Could you just add/change this one thing…?” followed some time later by the conversation with the same client that starts with “How can it possibly have taken so long to…?” when you’ve repeatedly re-engineered the application to reflect their flip-flopping specification. Many lengthy explanations to Management then ensue, distracting everyone from the real delivery, blowing milestones killing team morale and ruining the relationship with the client.
The next thing we heard was a proposal for driving adoption, namely the creation of a Cloud Tiger Team. This should be made up of one or more people from each of the following backgrounds:
• Infrastructure Engineer
• Product Manager/Lead Architect
• Security Engineer
• Operations Engineer
• Application Engineer
This team should be seated together, grown until it can be bifurcated or replicated as the team members adopt the skills necessary to form a new standalone team without breaking the original one. Again this seems common sense when you read it. We’ve run up cloud projects with fewer but have ended up with a less-rounded development that risks missing full coverage of an important element.
Rackspace are positioning themselves as service providers – they help get your applications into the cloud then run additional metrics to keep it safe and sound. Given that the large hyperscalers (AWS/Microsoft/Google) are likely to get the most benefit by running their own datacenters rather than relying on existing datacenter providers this seems astute. Rackspace have their own toolkit product “Compass” which layers on a collection of best practice checks focussing on security, cost management, utilisation and inventory. This makes sure you didn’t do anything dumb like leaving an S3 bucket open to the internet and gives a deep breakdown of your usage profile so you can ensure you’re getting the best bang for your buck. Their intention is to make sure you get a “Well Architected Framework” to make sure you are able to deliver a solution based on best practices. This ensures you to nail all the annoying questions people will ask you around security such as:
• How are you capturing and analysing logs?
• How are you leveraging AWS security features?
• How are you encrypting data on the wire/at rest?
• How do you ensure the appropriate incident response, ie "Limit the blast-radius"?
The benefits of cloud are now a dead discussion. Allen claimed that customers typically see 25-30% saving on cloud instances (servers). This seems high since my experience on Azure showed a cost-benefit tipping point at, initially 5-6 hours daily usage edging up to 8 hours per day 18 months ago (ie the last time we did the analysis). These numbers incorporated the support and hosting costs for an on-premise server. So anything that’s required for more than 8 hours per day is cheaper on-premise, and is therefore not going to be cloud-efficient. Or is it? The cost/benefit measure doesn’t stop with the per-core-hour commerciality, and this explains AWS’ interest in extending the functionality they offer beyond the simple IaaS and PaaS offering. The AWS ecosystem “add-ons”, combined with the ability to “fail fast” or at least “fail with minimal cost” because you’ve not had to buy a bunch of expensive on-premise servers, plus the ability to scale up and down at speed have to be the main attractions and drivers of adoption. This is most likely true, at least in those organisations that have already successfully spun up their first cloud project. Clearly there will be challenges explaining to a CFO why buying cloud instances will be more expensive than an on-premise server purchase but the following checklist may help:
1. Maintenance – AWS engineers do the support so you don’t have to. Racking, building and patching is their task.
2. Add-ons – the ecosystem is growing rapidly and while the additional services may not benefit your legacy application suite new applications and future enhancement work has lots of potential.
3. Scale – you can scale up and down on demand.
4. Security – AWS handle the security of the cloud, you just have to look after the application level details, ie security within the cloud. We can also include compliance here since standards are heavily security-related – the hyperscalers are busily getting compliant so you don’t have to, and it doesn’t stop with ISO27001 security, Allen had a slide full of certifications. Your application will still need to be made compliant, but having the platform already compliant is half the battle.
5. Accessibility- you can provision online anywhere you have an internet connection to your device of choice.
6. Cost – typically there are cost savings versus on-premise server provision.
7. Resilience – Spreading across 3 AZs (AWS’ Availability Zones are bunches of distinct datacenters) is going to give 6-9s reliability, or about 30 seconds downtime per year in real terms.
8. Edge points – There are 119 PoPs: 108 edge locations and 11 regional edge caches across 58 cities in 26 countries. The access is near you and your clients.
So there you have it.
M.A.S.S.A.C.R.E.
As a closing thought, Morris noted that 88% of respondents from the Financial Services had stated that they considered a significant part of their business was at risk from new entrants to the marketplace. Given the enormous legacy technology stacks that the incumbent banks have to maintain and the arrival of PSD2 the challenger banks have no such legacy costs to burden themselves with. Although there are many groups attempting the journey to getting their banking licence I’m yet to hear a compelling argument that will persuade a significant portion of the populace to give up on the high street and switch to the new providers. However, with a low, scalable, in-cloud architecture the entry bar is low and the running costs will be commensurately marginal. So it is hard to see a scenario where the challengers won’t be able to offer better rates than the dinosaurs. Compare Monzo’s headcount (sub 300 in one block in Shoreditch) with any of the familiar names.