
I see this too often with new teams which want to work with Serverless services to build their solution.  They focus on what services they want to use and how they will split up code into lambda functions to deliver their code.  All of this is great to be thinking about.  They are thinking about using managed Services, they feel like they have the Serverless mindset because they are going to write code for Lambda - but do they really have the Serverless mindset?  Are they really focused on the right thing?

## Writing Lambda Code is not thinking Serverless!
The enthusiasm is great but we need to be changing how we talk about Serverless,  we are not writing and delivering code to AWS Lambda - that is not being Serverless!  It may feel like it but we are limiting our viewpoint and being singleminded in our focus - this is dangerous and will get you in trouble at some point.  Just using Managed Services for everything is not the right solution all the time, it is a LOT of the time but we need to be mindful of what we are building and focus on the actual problem we are solving.

> Serverless is not a Silver Bullet

Just creating a system that is built with Managed Services is not going to create a Scalable solution without limits.  In the cloud there are always limits, and as cloud architects we need to be mindful of every managed service quota and limit which applies to our problem space.  This is additional thinking we need to take up when we want to **“Think Serverless”**.

## Think Event Driven
AWS Serverless DA’s have started to change the messaging for Serverless architecture to Event Driven Architecture (EDA).  This is a subtle change but is an important one, since it re-focuses us back to the fundamental architecture principles of Serverless which enable it to be so great:

1. Event driven
2. Asynchronous, stateless processing
3. Horizontally scalable 

These core principles enable any system to become hyper-scalable and are what make Serverless Systems so powerful.  Sure there is a lot more that goes into the hyper-scalability but the core, fundamental thinking from an architecture perspective boils down to these elements with **Event Driven** being the prime enabler.

If you want to get deeper into Event Driven thinking I recommend taking a look at the EDA Visuals from David Boyne and the AWS DA Team on [Serverlessland](https://serverlessland.com/event-driven-architecture).





Focus on Event Driven

When I start with new Serverless teams, the first thing I do is to start getting them to think differently about what they are building.  Most developers who have been around a while have worked on more monolithic code bases where software is built in structured layers.  This is all well and good and can translate to pushing code like this to the AWS Lambda service as a starting point.  This will likely work nicely for quite a while - AWS Lambda is super-resilient out of the box without doing any additional configuration so the code will probably run fine and won’t cause problems. This is a great way to get going especially if your expected volumes are not large.

> This is not “Thinking Serverless”

Thinking about Serverless processing is about being granular in your thinking.  Sheen Brisals, an AWS Serverless Hero, has some great articles along this theme which I recommend you go and check out.  Start with [Think Granular To Go Faster In Serverless! — Part 1: Individuality](~https://sbrisals.medium.com/think-granular-to-go-faster-in-serverless-part-1-individuality-25f52469de46~) and continue through the series.  

“Thinking Atomic” is where you need to be, don’t look to write code first up to do everything - break down your processing into singular steps which can be completed in a single action.  Everything must be singular and atomic - one input, one output.  As soon as you start having more than a single output or side effect (database update, notification) you create additional complexity and cause problems when the code is retried or re-run.  When you have multiple steps in code in one place and it fails at step 3 - what do you do with all the other steps?  Is it safe to re-run those again or will you cause duplication?

> The key to high scale, concurrent processing in a Serverless system is to “Think Atomic”.

A rule of thumb I like discuss with teams is limiting the number of outbound API calls to a minimum, any more than 3 outbound  API calls and developers need to consider refactoring their solution. in my experience with busy systems I find increased latency the main concern that nobody considers. Every interaction in the cloud will involve API calls which naturally means network latency, which is why I highlight this as a problem to be aware of.

When your thinking is atomic and your code is doing less latency will be less of a problem and your lambda duration will be shorter enabling higher throughput with lower concurrency which means your overall account health will be better.  Thinking atomically will also create a quicker pathway to refactoring to no code and using step functions which are powerful Serverless constructs.

So next time you start working on a new service, stop, and rethink the processing before you code and “Think Atomic”!

Think: Atomic

Serverless solutions are highly scalable, distributed systems and require a different approach to more traditional, monolithic systems which we noramlly build.  Explore here to find considerations for going all in on Serverless.