Amazon Web Services’ re:Invent is a massive and fast-growing event. Estimates for this year’s attendance range between 40,000 and 50,000 people, and it was sold out nearly two weeks before the first day. This year there are over 1000 breakout sessions covering a dozen or more tracks, as well as workshops, certification classes, hands-on labs, and social events galore.
Besides the steady rollout of new products and features, the biggest trends I’m observing this week are the expanding role of serverless computing, and the ability to rapidly integrate the huge variety of services for custom solutions.
Managed cloud computing offered the ability to quickly provision and deploy traditional N-tier architectures that are managed by Amazon, scale elastically, and offer high availability. This is being augmented and supplanted by lambdas and ephemeral functions-as-a-service, with an emphasis on per-use transaction costs (as measured by individual API calls and invocation times) as opposed to capacity averaged over time. I’ve seen TensorFlow in Lambda, Aurora in Lambda. The impact on us as solution architects is a need to reconsider how we structure and cost solutions — instead of focusing on capacity that fits the problem, and provisioning-in-advance, there will be increased emphasis on frequency and size oftransactions between services, and decomposing problems into lambda-sized models. For example, having a million customers whose devices send one message a day to the IoT back end for storage is very different from a thousand client devices that send a message every five seconds. And, if that message is bounced out to third party or other internal integrations for reprocessing and triggering, then those transaction costs need to be understood and accounted for in the total solution cost as well.
This also illustrates the other trend — mix and match capabilities. The AWS toolset has become so diverse and rich that even internal teams are finding ways to use existing services “off-label” — for example, I saw a cool presentation where the Amazon Music team used AWS IoT as a general purpose publish-subscribe message broker to enable them to push information like football (soccer) game scores, status, etc. to millions of devices with less than one minute latency. This is not an IoT problem space, but the tool fits and provided a cost-effective and technically appealing solution for their business need.
Odds are that there is more than one way to solve any given problem. Our job here at Cardinal Peak is to find not just “a” solution, but the”right” solution for our clients, in terms of both cost and capabilities, in the constantly changing landscape of the AWS cloud.