AWS re:Invent 2020 is coming to us this time. With hundreds of sessions and talks to attend, choosing the right ones can be a challenge!
Here, I am adding here a list of sessions that I identified that I thought would benefit a serverless engineer. Not all sessions are on serverless. I have reasons why I have included non serverless sessions as well. You will understand as you read through the short description I have added for each.
You can see my complete list under the AWS Hero’s pick in Cloud Pegboard’s AWS re:Invent 2020 agenda. …
I had a humble beginning with Amazon DynamoDB. I heard that DynamoDB was the place to store the sessions in a serverless environment. So I created a table.
Many recommended the session identifier (ID) as the Partition Key (PK) and a timestamp attribute to store the creation time. I thought it was so simple.
Soon, the sessions were flourishing in millions. Adding a session, reading a session took just a few milliseconds. I was happy!
One day, I asked myself, how would I block someone from using an old session? Easy! Fetch the session, check the timestamp. If old, then delete it from the table. …
An event is something of importance that happens at a certain point in time. It is unique. It is singular. In technical speak, an event carries information that has the potential to influence one or more applications.
Here are a few sample events.
A typical application can emit numerous events during its operation.
When we think of an event, we mainly relate it to having a simple data structure that carries one message. …
I once worked for a corporation that had its offices close to a river. It was a beautiful location with great views. Lunch-hour walks became the most satisfying part of my workday.
Something I witnessed along my walking path one day, completely changed how I had perceived and practiced my talks up until that day.
On a dry summer day, as I was walking, I heard a distant but faint voice. I stopped and listened. It sounded more like a one-way talk than a conversation.
As I walked closer, I saw a man standing at the edge of the riverbank, facing the river and talking. He was talking with a full voice. His animated hand gestures and occasional shake and nod of his head were very visible. …
In the previous article “Think and Develop Serverless Applications as Set-Pieces”, we saw how a serverless application can be thought of as a collection of set-pieces and developed as independent smaller services. In this article, we will see how to apply the set-pieces concept in practice. For this, we will look at Back-in-stock Email Notification feature as a case study.
As I walk you through the requirements and the architecture, I will try and follow a simple narration. I believe simple messages do not require expansive modeling artifacts!
Here is the one-liner requirement for the Back-in-stock Email Notification feature.
“In a given country, customers register their interest to get notified via email, when an out-of-stock product becomes available to…
In my previous articles on serverless, I used themes such as cooking, growing, fishing, and hiring. In this, I talk about football, movies, and music. “What do they have to do with serverless?”, you might ask. Well, there isn’t anything directly common between these themes and serverless. However, with some imagination and story-telling, we can easily build the connections ourselves.
It was a warm March afternoon of 1991. I was five months into my first job as a software engineer. I must admit I had a smooth start to my career. However, on that particular day, I was very nervous. I was going to demonstrate the first application that I developed to my boss. Though I did a couple of utilities for other departments, this was the first application that I developed and I was so proud.
Let me introduce my manager. Mr.Y was one of the most senior engineers in that department. He was a Chief Engineer. He had multiple engineering degrees from top universities and had several awards and accolades. He was part of a core team involved in the design of power plants, oil refineries, space antennas, and other complex structures for companies around the world. He understood software very well and wanted to cultivate the software culture in his department. Even with all his knowledge, power, and influence, Mr.Y led a very simple life. …
In my recent article “Serverless is for everyone!”, I talked about why serverless is suitable for both the start-ups and the enterprises alike. In that, I highlighted a few attitude challenges that often hinder an enterprise’s serverless adoption. One common theme that I have observed from people in the industry is that, organisations with no in-house serverless expertise often struggle to make a start. In this blog, I am discussing a way to overcome such starting hurdles, and a few tips to make the serverless adoption a rewarding experience!
“The swiftest way to grow a company is to grow its people” — I once read in a book. People are the most valuable commodity of an organisation. There are standards, training and accreditation that help a company to invest and grow its people. Many successful organisations are proud of their achievements in growing their people. …
A typical busy day at the office. Home office, that is. I was due to join a serverless webinar at 12 noon. It’s now 20 minutes past. I continued my conversation with my colleagues, Russ and Fabi. We wrapped up in the next 5 minutes and I then joined the webinar.
The talk that I wanted to attend was about comparing serverless with a particular container technology. The good, the bad, the ugly, the strength, the weakness and the fitness of those two different technologies. The talk was concluding as I joined and caught the last few words of encouragement from the speaker on serverless. A mundane, off-the-shelf recommendation that we’ve been hearing since the birth of the term serverless. “Serverless is good for start-ups. Serverless is fit for background processing. Serverless is ideal for batch jobs”. …
Part 1 started off the Serverless Casserole series with a brief about the payments capture functionality and its architecture. It then focused on a client facing API and its implementation as a functionless integration of API Gateway and S3. If you haven’t read Part 1, then it is recommended to go through it first to gain a better understanding of the context.
Part 2, this post, as part of the main course, focuses on the failure handling of async lambda invocations. It looks at the different options and argues why is one better than the other.
Here is the architecture we saw in Part 1 that forms the base for this series. …