To me personally, when I think programming languages I think JavaScript and while 67% of the developers out there might think the same (at first) that does not imply it’s the most efficient language to use with AWS Lambda. So without further ado, here we go.

To put it simply, serverless computing is a cloud computing execution model meaning that the cloud provider is dynamically managing the distribution of computer’s resources. What’s taking up valuable computing resources is the function execution. Both AWS and Azure charge more if you have a combination of allocated memory and the function execution elapse time which is rounded up to 100ms.

We discuss quite a bit about going serverless for SMEs and startups, however it’s often those with an already huge infrastructure, such as enterprises, that can find the move and change daunting. We see many companies from the likes of Coca-Cola to Netflix managing it but what does it look like in action? In this article, we share some best practices and insights on the serverless designs that can scale massively and represent enterprise models.

This is part of a series of articles discussing strategies to implement serverless architectural design patterns. We continue to follow this literature review. Although we use AWS serverless services to illustrate concepts, they can be applied in different cloud providers. In the previous article (Part 1) we covered the Aggregator and Data Lake patterns. In today’s article, we’ll continue in the Orchestration & Aggregation category covering the Fan-in/Fan-out and Queue-based load leveling.

Serverless has been around for a minute now but it’s safe to say that it’s still in its infancy in 2020 and definitely has a long way to go. But serverless architecture is a major step away from to dependence on humans and towards reliance on machines. Are the machines already talking over? Not literally the “Terminator” movie scenario quite yet but is this the beginning of the end of an era in the world as we know it?

Since 2014 when AWS launched AWS Lambda and kickstarted the serverless movement, going serverless has grown exponentially for organizations of all sizes from one-man start-ups to huge listed global enterprises. While there are some challenges to this new architecture, the ways moving to serverless can transform a business often far outweigh these.

This is a hands-on course on how to deploy a fully Serverless web app using the AWS CDK. You can use the resources declared in this demo application as a starting point to mix and adapt to your own architectures later, which should save you quite some time.

A while back I talked about how big companies have started using serverless in production and how this is a clear sign that we will see more implementation of the serverless infrastructure in the near future. I’d like to take some time today and talk about one of the companies that are using serverless in production: Coca-cola.

When first looking into serverless migration and its architecture, it can feel like you’re staring down an endless shopping aisle of critical serverless tools that all need to be put into your basket straight away. Some services seem to offer the same function, while others can feel wildly different - both, as a result, can instill some doubts as to what is really necessary for your business and serverless application.

A while ago, we covered the invocation (trigger) methods supported by Lambda and the integrations available with the AWS catalog. Now we’re launching a series of articles to correlate these integration possibilities with common serverless architectural patterns (covered by this literature review). In Part I, we will cover the Orchestration & Aggregation category. Subscribe to our newsletter and stay tuned for the next parts of the series.

While we know the many benefits of going serverless - reduced costs via pay-per-use pricing models, less operational burden/overhead, instant scalability, increased automation - the challenges are often not addressed as comprehensively. The understandable concerns over migrating can stop any architectural decisions and actions being made for fear of getting it wrong and not having the right resources.