/ Cloud, Machine Learning, Technology

Our Re:Invent 2017 Wish List

At the end of November, tens of thousands of avid cloud enthusiasts will gather again in Las Vegas for the AWS Re:Invent conference. In anticipation of the event, the Amazon Web Services have already begun rolling out new features and even more updates are expected during and after the event. AWS Re:Invent is bound to send shockwaves throughout the cloud development community, but while we are waiting for the official update releases, here is our product and upgrade wish list for the event:

AWS Lambda

AWS Lambda is already the beating heart of any modern cloud service built with the serverless paradigm. However, there is still room for improvement and in our opinion, the following additions would enhance the developer experience even further and lower the barrier to entry for the more traditional customers:

  • SQS event source for Lambda. This would ease decoupling of functions and remove the need to use e.g. SNS to signal Lambda about new items in the queue. For real-time scenarios, it would be required to have control on the maximum amount of parallel requests / maximum amount of requests during a given timeframe to ensure that the requests do not exceed processing/throttle limits of downstream services (e.g. REST APIs / databases).
  • Lambda “Publish” events in addition to “Subscribe” events. Currently, the developer needs to explicitly code database writes / message posts to SNS or SQS etc… It would ease to have the possibility to publish Lambda outputs onto other AWS Services (e.g. SNS, SQS, DynamoDB, Lambda, StepFunctions, …).
  • More Lambda runtimes. Add Node 8, Go, PHP support, please. And while we’re at it, having the capability to deploy your own docker container / build your own runtimes (incl. programming languages, 3rd party libraries, etc…) would also be cool (as in OpenWhisk).
  • Remove / Raise the 5min execution time limit. Sometimes (like when importing large database dumps to RDS) is just not enough.
  • Improved performance for VPC scenarios. When running Lambdas in VPCs, cold starts can be painfully slow (more than 10 second cold start times in some cases). Lambdas should have more consistent and acceptable performance for VPC scenarios.
  • Keep Lambda warm option. In many scenarios, you want consistent performance on at least some of your serverless API endpoints. An option to mark a function as “always warm” or “warm during a given time window” would work wonders in delivering better performance for the more demanding customers without having to shift to a more traditional container or IaaS architecture model.
  • Ability to define log group for Lambda function. Being able to define the log group would ease debugging and streaming of logs to 3rd party log analytics tools. For example, the logs off all Lambda functions related to a logical set or topic could be set to be written to one single log group.

API Gateway

Last month, we were happy to see AWS release API Gateway Regional Endpoints. This was a welcome addition and could signal a step away from the Cloudfront roots of the original API Gateway service. That would open doors for even more improvements. Here are some of the things we’d love to see:

  • Websocket / Async response support for API Gateway, or in short, keeping the HTTP connection alive and the ability to push results from Lambda to the open API Gateway connection. This would be useful for requests that cannot be handled synchronously or where the response is delivered in chunks (for example, when returning routing alternatives for a given route).
  • VPC support for API Gateway. As a follow-up to the regional endpoints, it would be useful to be able to deploy the endpoints inside the VPC. This would allow hiding the actual API endpoints from public access (and utilizing custom domains as a public entry point) and opening access for proxying services run inside a VPC (like in a setup where part of the services is implemented using serverless architectures and others use more traditional instance and container based architectures).
  • Lambda Proxy mapping for string parameters with multiple values. Currently the query string “?param=1&param=2&param=3” gives just “3” as the value for the parameter 3 when using Lambda Proxy. It should return the array of provided values (i.e. [1,2,3]). Alternatively, providing the full query string (path including parameters) would allow to implement your own parsing.

Databases

DynamoDB is the database of choice when a non-relational database is sufficient for the application, but sometimes, a relational database is needed (e.g. for transaction support, complex queries that involve table joins and so on). These upgrades would make the development of database-backed solutions easier:

  • DynamoDB support for burst traffic. The automatic provisioning of DynamoDB was introduced in 2017. It was a huge improvement for autoscaling the read and write capacity but due to the limitations in the amount of allowed scale-in events it does not work as such for burst traffic patterns. To better support for burst-like traffic, such as scheduled updates, there should be a way to have more frequent scale-ins, or the ability to queue DynamoDB updates.
  • Cursor support for DynamoDB. In many application scenarios, users need to page results over multiple pages. Supporting cursors in DynamoDB would ease the implementation of “next” and “prev” links.
  • Relational database as a truly managed service. RDS is a good start but leaves much of infrastructure planning and implementation to the developer (scaling, replicas, etc…). It would be neat to have a Dynamo-like relational database where developers just define schemas, indexes and the like and the servers are automatically provisioned and scaled in the background. Alternatively, add more powerful capabilities for transaction support and joins to DynamoDB.
  • CRUD UI for CloudDirectory. Something like the DynamoDB console would boost developer productivity with Cloud Directory.

AI / Analytics

Last year, we saw the release of new cognitive services such as AWS Polly, Rekognition, Lex. During the last month, an updated GPU-enabled instance type “P3” was released to support the most demanding deep learning problems. Additional improvements in the AI scope that we would be thrilled to see released:

  • More advanced Machine learning models. Besides the current linear / logical regression algorithms, support for the more advanced algorithms such as SVMs, Random Forests or custom (your own) neural networks would make the ML offering close in with its competitors.
  • Machine learning optimized Lambda runtimes. Deploying AI models to Python Lambda runtimes can be a pain due to issues with binary compatibility of the required libraries. It would be great to have the most common Machine Learning libraries (e.g MXNet, sklearn, scipy, numpy). And if these runtimes would be deployed in GPU-accelerated hardware, that would be close to perfect.
  • Image-to-text / OCR. You can now identify objects, persons, emotions on pictures using Rekognition. Text recognition for identifying text elements and their contents on images would be an obvious next step.
  • Generic NLP. Lex can be used to build conversational UIs, but there is no service to extract entities / emotions / etc.. from text. That would be a welcome addition to the service portfolio.
  • Reinforcement learning as-a-service. Reinforcement learning, i.e. learning from rewards of actions, has applications within advertising, content optimisation, dynamic pricing, and much more. Providing a managed reinforcement learning solutions based on common RL algorithms (Policy Gradients, Q-networks etc.) would really set AWS apart from the competition.
  • Building own specialised models on top of Rekognition. Currently as a developer, you are limited to the models built inside Rekognition for image recognition problems, which may require in many cases to set up your own image recognition solution. The addition of transfer learning, i.e. adding model detail information on top of Rekognition would dissolve that need (i.e. Rekognition recognises that the object is a car but your transfer learning model trains it further to identify different brands of cars)
  • MXNet / Tensorflow training and endpoint as a service. Set your data source (S3, RDS, Redshift, …), set your model parameters and get a model for use either in your own AI application or create a serverless REST endpoint for use by your apps.
  • Finnish language support for Lex & Polly.  This will just not fly in Finland before this is available.
  • Support for free text (AMAZON.LITERAL) in Lex. Sometimes the answer you need to capture cannot be captured in a list. Lex should support interpreting open ended intents (just like Alexa does) or at least have the option to record speech inputs to be interpreted by a human.

User Identity Management

Cognito User Pools streamline the development experience for building user management into web applications. Some additions could make the service even more powerful especially in the domain of compliance.

  • GDPR Compliance. Built in features to support the functionality defined in the GDPR “Rights of the User” (access, rectification, erasure) together with best practices and some formal statement of compliance would ease development of GDPR compliant solutions that manage personal user information using Cognito.
  • User pool import / export. Sometimes you need to rebuild your user database or e.g. transfer it to a new AWS region. The ability to export and import user pool databases (including hashed passwords) would ease in that task.
  • Facial recognition. In addition to the textual metadata that can be managed within Cognito User Pools, it would be awesome to have the ability to store the facial metadata of customers inside the Cognito pool and lookup for users using a picture (e.g. recognize a user at a physical service desk / cash registry).

Debugging

Cloudwatch collects metrics and logs for your AWS services, but especially in the scenario of serverless applications (a lot of log groups and streams) finding a specific error that has caused a Cloudwatch alert without any 3rd party logging solutions may feel like looking for a needle in a haystack. These small additions would improve the developer experience for basic developer scenarios:

  • Search CloudWatch logs. You know when your error happened but not exactly which function triggered the alarm (you do not want to set alarms for every single Lambda function). The ability to search for log entries in a given time range with some keywords (‘e.g. Error / TransactionId’) would ease the task.
  • Link from CloudWatch metrics to logs. … and remove the task of a developer needing to search for the error message based on the metric data. A direct link from the Cloudwatch metric to corresponding log events would just rock!

Meet us at Re:Invent

I’ll be participating Re:Invent with colleagues from Nordcloud. If you are also there and interested in a discussion about leveraging the AWS cloud for digital innovation and serverless technologies, send me an email (mikael.puittinen at sc5.io) or a Twitter message (at mpuittinen). Let’s meet up at Re:Invent!

 

 

Learn our ways of working.