The Top Three AWS re:Invent Serverless Announcements

Last week was AWS re:Invent which is the most busy time of the year for those of us a part of the AWS ecosystem and arguably the most important. Every year Amazon inundates us with a large number of announcements and it can be overwhelming to keep track of them all. This year amazon announced new EC2 instance types, a time series database, and a slew of machine learning offerings... They also announced a service to retrieve data from orbiting satellites, a rack you can install in your data center with AWS services, an R/C car, and a blockchain service.

It's easy to miss things in all of that so we're going to recap what we see as the biggest announcements. Plus we'll also briefly cover the fun we had with our "appearance" at Stackery's re:Invent booth.

Top Three Serverless Announcements

Let's run through what see as the most important things that came out of last week. These were the ones that stuck out most to me and I spent the most time thinking about. Here they are in no particular order.

DynamoDB On Demand Pricing

AWS uses four characteristics to identify something that is serverless. These characteristics apply to both the services they offer and the applications we build. These four characteristics are:

• No servers to provision or manage
• Per-per use / Never pay for idle
• Scales with usage
• Availability and fault tolerance built in

The "never pay for idle" characteristic always feels off with the data layer of serverless applications. That is, storage and database services. Paul Jonston's explainer of serverless calls this out specifically. In a way you're always using storage whether you're actively interacting with data or not. But this feels like an excuse we use for the "serverless still uses servers" crowd when we try explain what serverless is and they point to our databases and storage.

That's why on-demand pricing for DynamoDB is such an important announcement. DynamoDB finally conforms to the four AWS characteristics of what makes something serverless! Will we see more pricing changes in AWS services? Could we see a change in S3 pricing in the future? Or better yet, could we finally see Kinesis change its pricing model so we pay for messages instead of shards. This isn't far off from DynamoDB's recent pricing change.

Nested Applications Using the AWS Serverless Application Repo

I'm a very large fan of AWS Serverless Application Repository (SAR). While it doesn't attract a lot of attention, even in the serverless space, it's a sleeper important service for serverless and computing in general. The announcement of nested application support brings us a big step forward in building application tomorrow.

Even before SAR was announced I had been wondering what new development patterns serverless might enable us. The coupling of infrastructure with tightly focused code made we wonder not only if we might achieve reusable infrastructure across different organizations but even reusable code that we could use to quickly construct applications. I called these serverless nanoservices. They're deployable, reusable, and useful services for constructing serverless applications.

What was needed was a library to collect these serverless bits so people could consume them and SAR achieved that this year. But have you ever tried to construct an application this way? I have and even simple applications can be hard. You had to deploy each nanoservice individually and connect them all together properly. More than once I crossed services and and had a nanoservice sending events to a nanoservice in a different application.

The ability to create SAM templates that consume applications from SAR has me excited. I can build reusable nanoservices and create a SAM template to connect them all and form a usable application to be deployed. I can treat SAR just like NPM or PyPi, or like my organization's Artifactory. We may be seeing a low-code approach to application development in the making.

Lambda Custom Runtimes And Layers

Want Ruby support for AWS Lambda? What about PHP? AWS released support for custom runtimes via a new featured called Lambda Layers. Layers allow you to provide your own custom runtime to meet needs not currently satisfied by AWS. This feature is important for serverless adoption because it leaves organizations no longer at the mercy of what runtimes AWS supports. I've worked in organizations where Ruby is the interpreted language of choice over Python or JavaScript. It doesn't make sense to force engineers to adopt a different language just so they can go serverless.

Lambda Layers also provides a new way for companies to connect your Lambda functions to their product more easily. Want to try out a new product? Just add a layer. The mean time to value for the potential customer drops significantly.

But the value of this functionality doesn't end there. I'm wondering how I can apply myself as an operations person using these new layers. Can I create blessed versions of certain libraries? Can I aide developers in debugging an application by providing a debugging layer? I'm still not certain where I could take this but I know we'll see unique and innovative patterns emerge.

Not Mentioned: AWS Firecracker

The open source release of AWS Firecracker, which powers the Lambda platform, gained significant attention. Their micro-VM technology really is innovative and releasing it open source is a major indicator of the value AWS sees in embracing the open source model. But while Firecracker is interesting and innovative, it doesn't belong as a major serverless announcement.

The reason it doesn't belong has nothing to do with the technology and the team behind it deserves a lot of praise for what they have built. But in the end our focus should always be on the serverless applications we're building and not the underlying platform. How Firecracker works doesn't make a difference to me. I'm not building my own serverless platform. While Firecracker is interesting from a purely technical standpoint, it makes no more difference to me than the new class of EC2 ARM based instances.

Fun Times at re:Invent

Though we couldn't be at re:Invent physically we teamed up with Stackery to have a presence. If you attended, I hope you got a chance to see this!

Great catching up with @tmclaughbos and the @stackeryio crew ! Quite the crowd :) pic.twitter.com/Dtlgx21jG9

— Ajay Nair @ Re:Invent (@ajaynairthinks) November 27, 2018

Stackery offered up our Serverless DevOps ebook to attendees. This was a wonderful match because I see ServerlessOps and Stackery so well aligned. I started ServerlessOps because I saw the potential hardships for operations engineers making the leap to serverless infrastructure and I decided to build a company to make these people successful.

I've admired Stackery's product for awhile because I see it as the perfect tool for operations engineers being thrust into an unfamiliar role of having to code more - or - being expected to deal with YAML and DSLs for the first time. We have to remember, much of the operations world is still just beginning their DevOps and cloud journeys. What seems natural to us six or eight years in is still new to many people.

Just as ServerlessOps wants to be the people who make more operations engineers successful, I see Stackery as a tool to make those same people successful.

Haven't had a chance to read our ebook? Well then check it out here!