AWS releases new services and features year-round, but the anticipation of re:Invent each year always gets us thinking about what we would be most excited to see announced. Here are just a few of the ways we think our time in the cloud could be made even better.
A New Abstraction for Applications
AWS Accounts are still the best option for creating logical and functional boundaries between AWS resources, but what if we had a way to create those boundaries without requiring multiple accounts?
The introduction of an “application” or “project” abstraction to AWS could do just that. This could exist between the account-level and the AWS CloudFormation stack-level, so multiple projects could be created within an account, and each project could contain multiple stacks. In addition to being a way to logically organize related resources, projects could be used to enable:
- setting service quotas per-project
- creating spending limits to keep POC projects cheap or free
- isolating projects from each other with IAM (especially useful for limiting the privileges of CICD deployment identities)
- deleting all resources within a project, even those not deployed with IaC
Account-level separation would still be the best practice for separating resources that belong to different environments, like development and production. But this new abstraction would allow for more sophisticated separation of resources within a given account.
Serverless Compute with Unlimited Runtime
Ever since AWS increased the maximum execution time for AWS Lambda functions to 15 minutes, people have been asking for the cap to be increased further. While they wait for such an announcement, many developers have created impressive workarounds with Lambdas that re-invoke themselves near the timeout. Or they may have turned to AWS Fargate, which introduces complexity that is unnecessary for certain architectures.
The best solution for this problem may actually be to introduce an entirely new service. Lambda’s feature set is focused around short-lived compute that responds quickly to events. Removing the 15 minute limit would make the service offering more confusing. A new serverless compute service should still be easy to provision and scale to zero like Lambda, but AWS could build it from the ground up to best serve the unique needs of long-running workloads.
A Better Free Tier
If you spend much time in AWS communities, you will likely see first-time AWS users who accidentally ring up a bill that they can’t afford to pay. Billing alarms are commonly recommended as a mitigation for these billing surprises. Unfortunately, users must manually create them, and given that AWS only calculates estimated charges a few times per day, users can quickly spend over their threshold before the alarm sounds. Many users don’t know that AWS support has a reputation of forgiving these accidental charges, so they assume they’re stuck with the bill.
A better free tier would remove the conditions that make these surprises possible. My preferred form of a free tier is one in which an account could not be charged until a switch is flipped. Some services would likely be excluded from this tier completely, or would have features disabled, but that would allow plenty of freedom for learners to get familiar with AWS without spending a dime.
A Better DevOps Experience
The current suite of AWS tools for building and delivering software is overly complex when compared to tools like GitHub Actions and GitLab CI. Pipelines can be managed in code with AWS CloudFormation, but defining them quickly grows complex, and special attention must be paid to allow pipelines to update themselves. Deploying feature branches requires dynamically creating and deleting pipelines, or sharing a pipeline between branches. And AWS CodePipelines are difficult to define with reusable components.
A proper AWS DevOps toolset would support modern features such as composable pipelines that are easily modified without redeploying, and complex rules for running pipelines based on repo activity like pull requests or the creation of new branches. Since these tools would be running in AWS, pipelines could use standard IAM authentication without crossing cloud boundaries or using long-lived credentials. AWS could also support native integrations with other services like Amazon EventBridge, and could offer a marketplace for custom integrations made by vendors or developers.
More Development Tools for EventBridge
Trek10 uses Amazon EventBridge regularly to develop event-driven solutions, and some additional tools would make the development process easier. We would love to see a console UI that assists the user in creating rules for custom events, where one could select specific elements of their events and have the UI automatically create a filter, with suggestions for which matching functions to use.
The development process could also be improved with richer monitoring for event buses and rules. AWS could have the console UI display recent events on an event bus without the need for a “catch-all” consumer. Also, the console could show the user how each event rule evaluates a given event, so they could see which elements of the rule match an event and which elements do not. These tools would help engineers develop rules and event consumers with more confidence.
We’re excited to see if any of these features will be announced at this year’s re:Invent! Be sure to follow the AWS news page for the latest details.
