All you need is love ❤️ and data 🤖
Tags: aws, lambda, serverless, architecture
Published: 2021-06-10 13:08:12

Alexa...set a timer for 15 minutes. ⏳

A few days ago I had a chat with a former colleague that inspired me to write my first official lighning post article about this. He asked me via WhatsApp:

Hey Christian, how are you? You must be very familiar with Lambda as an AWS solution architect? I have a question. 

The question was targeted towards a service quota of lambda for the maximum number of parallel executions. Giving the answer on the exact question was very easy. I said:

**Yeah there is a default quota of 1000 concurrent executions. But you can increase it if you need to via a support ticket.**

Well that could be the end of the story but I was interested to know more about why they hit those limits and we got in a very interesting conversation. 

## What about data 🤖 ?

The conversation reveals a lot of what I spend my professional day with.

My job as an AWS Solution Architect at DFL Digital Sports is to help teams find an optimal solution to a (business) problem. Or as Maria Ane Dias (Solution Architect at AWS) describes it very aptly on [Instagram](https://www.instagram.com/p/CPbMGkojzC0/?utm_source=ig_web_copy_link):

> I help customers understand how they can innovate by working backwards from their challenges, drawing and reviewing architectures, and being a strong support and advisory to them.

Bam 💥

And one of the most exciting challenges in my work: for every problem there are many possible solutions.

To make an informed decision about possible solutions, I need a lot of background information. I have to put myself in the shoes of others and ask a lot of questions to understand things and contexts.

The reason why my buddy was actually evaluating AWS Lambda was because they have troubles to handle traffic peaks after they send out push notifications to users. And my buddy seems to be kind of disappointed that a serverless approach using AWS Lambda did not solve the problem out of the box. 

So our discussion afterwards was a lot about topics apart from AWS Lambda. I asked a lot of questions like:

* Do you have enough data to predict peak loads?
* Can the response somehow be cached?
* What percentage of users are logged in on average?
* Is it possible to segment users and send the notification in bulks?

So, in order to be able to show solution options 
a) I have to have a good technical understanding
b) but more importantly, understand exactly how the problem is structured.

In the end, the discussion was less about AWS Lambda. It was more about the context of the application. About background information on the problem. 

I asked myself 🤔:

* Maybe AWS Lambda is a less than optimal choice of technology here?
* Are there other approaches in terms of integrating the systems in charge?
* How deep is the data base to make informed decisions here?
* Is the problem a general one or does it only occur sporadically?
* What influences that the problem occurs?

Data and knowledge helps me in my daily work to support my colleagues in the best possible way. To make data-driven decisions and reduce the amount of hypothesis. Technology must never be an end in itself. 

In my eyes, the choice of technology must always be based on supporting a specific problem. If we've achieved that, we've done everything right. 💡

Coming back to the problem of my former colleague, I recommended to look, if the new released capability of [EC2 warm-pools](https://aws.amazon.com/de/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/) could potentially help better before refactoring towards AWS Lambda. Or if they can somehow reduce the pressure by caching responses at edge locations. Or if something like [predictive scaling](https://aws.amazon.com/de/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) of EC2 could also work for them. Maybe it is "shooting at sparrows with cannons", but in this short time it was not possible for me to dig deeper in the status quo of his current architecture and future plans. 

## And what about love ❤️ ?
I love what I do. I believe that is another important factor to inspire people. I am a passionate software developer, software architect and fan of technology. I don't care if the software is written in JavaScript, TypeScript, Java or PHP. Likewise whether it runs serverless, container-based or on premise. 

I am constantly trying to broaden my horizon. This is the only way I can neutrally look at a wide range of options and then come to an informed decision. 

Passion for what you do is everything! 

Alexa says, time is over...see you next time. Happy to get your feedback and thoughts in the comments. 👋