{"id":3108,"date":"2022-04-01T15:31:21","date_gmt":"2022-04-01T20:31:21","guid":{"rendered":"https:\/\/www.northone.com\/blog\/?p=3108"},"modified":"2022-12-08T07:40:18","modified_gmt":"2022-12-08T12:40:18","slug":"serverless-architecture","status":"publish","type":"post","link":"https:\/\/www.northone.com\/blog\/northone\/serverless-architecture","title":{"rendered":"Building North One: What Is Serverless Architecture and How Do We Use It"},"content":{"rendered":"\n

<\/span>The Serverless Journey at North One<\/span><\/h2>\n\n\n\n

While many companies today are experimenting with serverless architecture in various forms, North One has the distinction of being (almost!) entirely serverless. From a developer perspective, that\u2019s a pretty special thing. Serverless architecture is the near-total abstraction of the server layer from the application layer. There are a lot of fun problems to solve in traditional server architecture, but every \u201cgood\u201d problem is inevitably countered by ten \u201cbad\u201d ones, typically solved in obscurity with a lot of effort and low gain. For North One to embrace serverless development as we have, the biggest gains are in the things we don\u2019t think about, the services we don\u2019t have to manage, and the layer of complexity that is already solved.

It\u2019s easy to imagine developers writing lines of code to solve a problem, but in a more traditional server-based stack, a lot of work goes into the foundational architecture on which that code runs. For even a single server, you have to answer a staggering number of questions, like: What performance-based hardware requirements do you have? What kind of operating system fits best? How do keep changes or request volume from slowing down (or taking down!) the server? With server-based stacks, everything also needs to be provisioned for worst-case scenarios, ultimately costing time and money for unused processing (but hey, better safe than sorry, right?).

Serverless, on the other hand, takes away all that complexity, and leaves you with a baseline of performance and reliability so that your code is just your code! What kind of hardware? What kind of operating system? Don\u2019t know, don\u2019t care. AWS Serverless takes care of all that for us, enabling us to focus on the code that actually makes a difference for our business. Much like building with LEGO pieces, our architectural development becomes a highly composable yet systematic process: we write code to handle the input, execution, and output for a given request. Scale is still considered, but the vast AWS ecosystem allows us to leverage easily configurable services that are most appropriate for our use-case.

There are a lot of great services to solve interesting problems in the AWS Serverless catalog, and far too many to cover in just one post, so I\u2019m going to focus on just three of my favorites: SQS, Lambda, and DynamoDB.<\/p>\n\n\n\n

<\/span>Our Favorite Pieces<\/span><\/h2>\n\n\n\n

<\/span>SQS<\/span><\/h4>\n\n\n\n

SQS, or Simple Queue Service, is the original AWS service, and one of the core services for scalability. It\u2019s a queue, yes, but from a development perspective, it\u2019s an ideal store for transient data. If you think of data flowing through our systems as water flowing downwards, SQS is like a massive funnel. We can collect any amount of messages from any number of sources, and we run code to \u201cdrain\u201d messages at the bottom of that funnel. As the volume of messages going into the queue dips or spikes, we define the rate we pull those messages to drain that funnel, providing message output at a consistent rate for variable input. We open, close, or limit the tap with the click of a button!

SQS also facilitates a number of healthy practices for failure scenarios. The dream is that all the code we write works the first time all the time, but in practice, that\u2019s never quite true. Any code can fail for a number of reasons, including:<\/p>\n\n\n\n