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.
AWS API Gateway is a great service but can be quite expensive, and even cost-prohibitive in some cases. An Application Load Balancer is a viable alternative since it integrates seamlessly with Lambda functions and is also highly scalable and reliable. For very small traffic, API Gateway will probably be the winner, but in high-throughput cases, ALB is capable of providing up to 90% savings.
One of the benefits of Serverless architectures is the possibility of scaling applications without worrying about load balancers and clusters of servers. While services like AWS Lambda hold their promises on this area, there are usually misconceptions about how they work. It is common for developers to assume that Lambda functions can scale infinitely, at any speed, in any circumstances. Reality is quite different from that.
Technology touches almost every corner of the world economy. Even when it’s an indirect relation, in many cases tech is an essential, vital part of our societies. It just can’t fail without causing too much distress and losses. Not only financially, but especially to the human aspect.
As we all know, the on-demand capacity mode of DynamoDB is great but can be cost-prohibitive in some cases (up to seven times more expensive than the Provisioned Capacity mode). The Provisioned mode, on the other hand, shifts to the development team the burden of predicting what level of capacity will be required by the application. And it’s not quite as straightforward to achieve the same level of scalability in the Provisioned mode as we enjoy in the On-demand one.
This post was originally published in JAXenter.com. Serverless is a relatively novel concept and cloud architectural model but has been advancing very quickly over the past 5 years. In this article, we’ve compiled a list of recent changes that are likely to shape how development teams use Serverless in practice. In this article, we’ll be heavily focussing on AWS serverless services. The cloud provider has been investing heavily in the advancement of Serverless.
As a Serverless computing service, Lambda already saves hundreds of thousands of dollars for many companies out there. While traditional server-based infrastructures usually lead to overprovisioning and waste, the Serverless pay-per-use model enables cost-effective cloud spending. Nevertheless, there are still more cost-saving opportunities that many development teams miss on AWS Lambda. Optimizing Lambda functions can be time-consuming, though.
