Where we’re going, we don’t need servers!

One of the best soundbites I read during the week of re:Invent, was on the t-shirts of one of the vendors right there … (see the title of this section). I cannot recall which one it was and I must confess that I just put all my summer clothing in storage. Anyway, going serverless is one of the big trends and for me, as an integration consultant, this is the most natural fit for moving into the cloud,

Conference sessions

During re:Invent, I attended lots of sessions that were related to serverless technologies. When people from the AWS ecosystem talk about “serverless”, they do not merely mean AWS Lambda (augmented with AWS API Gateway), but rather mean to include other fully-managed services like their database offerings DynamoDB, RDS, but also services like AWS S3 (Simple Storage Service – AWS’ object store), AWS SQS/SNS and the like. Basically anything where you do not have to provision any servers for using the service, with a pay-as-you-go model. Fair enough.

Although I could not plan all sessions I wanted to attend due to them being fully booked, I was still very content with the sessions I could reserve a seat for … and the ‘refactoring’ I did on my schedule. Generally, the level of technical detail for the sessions I attended was very high. What I liked even more was the (almost) complete absence of all the marketing BS, sales pitches and safe harbor statements (so Oracle – this is how you do it! Just the technical stuff, not the fluff).
During the sessions I appear to have made 34 pages of notes that I will have to re-read the coming weeks, as a lot of the sessions contained some very useful pointers to additional material, eye openers and remarks.

One of the things I had not fully realized was that because the amount of memory and CPU power are directly related for your lambda function (doubling the memory  will also get you double the CPU power), allocating more memory may actually be cheaper. First, it seemed to be a paradoxical statement, but when they (ARC305 – Serverless Architectural Patters and Best Practices) explained that although your function may not be consuming all memory, it still might benefit from the additional CPU power it made sense. Also, he pointed us to the AWS repository of his fellow Amazonian Alex Casalboni that contains some scripts to demonstrate how to examine whether this also applies to your particular scenario.

Chris Munns (SRV401 – Optimizing Your Serverless Application) delivered a very interesting session on where to direct your efforts in pushing the performance for your serverless functions to the max, but also pointed out that memory sizes >= 1.8 GB offer multiple cores for execution … only to continue by stating that most code was not going to benefit from the multiple cores as it it single threaded.

Surprisingly, one of the most fun sessions was SEC316 (“Becoming an IAM Policy Master in 60 minutes or less”) by Brigid Johnson. Although the subject is very important, security does not spring to mind as a “fun” subject. However, Brigid did her utmost best to make it fun, which started by walking around pre-session chatting with the attendees and continued during the session with her examples and quizzes. Even though I attended this session as a 7pm session after a busy day, it was a lot of fun. Unfortunately, I do have to confess that I could not follow along until the end … so I will have to rewatch this session the coming weeks, as well as SEC301 she recommended. Fortunately, a lot of the videos have been posted to YouTube!

Serverless, the announcements

In my previous blog posts on re:Invent I have already mentioned some of the announcements/new releases for serverless, here I will collect some of the important announcements pertaining to FaaS (AWS Lambda/API Gateway) from re:Invent.

AWS Step Functions

AWS Step Functions is the AWS State Machine, used to build workflow process definitions for orchestrating miscellaneous services (and keeping the state out of the functions). As a former Oracle e-Business Suite consultant, I am well versed in building graphical workflow processes, at Oracle we used to have the graphical Oracle Workflow Builder for that purpose. Nowadays, as a Oracle Fusion Middleware Consultant, I still build orchestrations using BPEL Process Manager, or statelessly using Oracle Service Bus.

AWS Step Functions offers some basic functionalities for building processes and it has now expanded its reacht to support integrations with other Amazon Services like SQS, SNS, DynamoDB and AWS Batch (for the complete list: see AWS Step Functions’ product page).

Although AWS Step Functions seems like a really useful solution for orchestration and process state, what I currently miss is a nice GUI for defining processes … process definitions now need to be entered in the JSON based Amazon State Language which makes it tedious to define larger processes. After the process definition has been created, it does render as a graphical representation as well – but what really is missing is a two-way editing environment!

AWS Nested Applications

One of the new features for AWS Lambda is the announcement of the “nested application”. According to the AWS announcement “You can now assemble and deploy new serverless architectures using nested applications supported by the AWS Serverless Application Model (SAM) using the AWS Serverless Application Repository. Nested applications are loosely-coupled components of a serverless architecture“.
The outlook of being able to assemle architectures using nested applications seems to be quite useful, but I cannot exactly tell whether this is useful for my use cases, I’ll probably have to play around with this first. As I read the statement, it seems to tie you into the SAM ecosystem and I fear that this will limit your abilities to leverage other frameworks, e.g. Serverless.

AWS Lambda

For AWS Lambda, Lambda Layers and Custom Runtimes have been announced.

AWS Lambda Layers

From now on, AWS Lambda Layers offers the possibility to add five additional layers with dependencies that can be shared across functions. This way, you can add a set of shared concerns for your services as shared libraries by defining them in a single location (define a Lambda Layer) and reuse the same combination of libraries in differrent implementations. There were a lot of providers of monitoring and tracing tools present on the AWS Expo Grounds, some of them requiring you to install additional instrumentation libraries into your functions: defining these in a single location, or using Lambda Layers for standardizing your own logging frameworks seems to be a very good addition.

AWS Custom Runtimes

Currently, AWS Lambda supports Python, Node.js, Java, C# and Go – support for Ruby has also been announced. However, if you happen to be very well versed or have a special requirement for using another runtime, you can now roll your own runtime. Amazon has provided reference implementations for Rust and C++ and it is expected that the community will soon start adding onto these runtimes!

Finally …

One of my favourite services on display at the Expo at the Venetian was the AWS Simple Beer Service. As a lover of craft beers, I could see an very useful application for our company as we also brew our own beer – this could be a very nice use case of showing the integration of Cloud technologies (Alexa, pour me a  beer!) and our own SynTouch beer.

Auf Wiedersehen?

Concluding, I liked AWS re:Invent very much.In fact, this is one of my best liked conferences as it really is a conference for learning and gaining knowledge – and knowledge is in absolute abundance. Making an initial planning is already quite difficult, as the travelling distances between venues may cause your to not fill a slot with a presentation, but move to another location instead. Fortunately, I do not care about gambling … so I got to spend all my time on the ‘business’ part of the trip.

If I’d have the opportunity, I would sign-up for re:Invent 2019 right now – great experience, great content and great value!