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.

We have all been at a point where you get stuck with a serverless application issue and can see no possible solutions because the problem isn’t clearly presenting itself. The distributed and asynchronous nature of serverless systems present a unique set of problems due to its inherent complexity, so one must adopt a different troubleshooting approach when it comes to serverless applications compared to traditional monolithic systems.

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.

The pay-per-use economy of serverless is pushing computing into the commodity space in Wardley Maps slowly but consistently. Unsurprisingly (to me at least), this movement is not pushed solely by cloud vendors, but also by tech giants such as Twilio and Atlassian as they re-package FaaS for the needs of their customers and charge them with the pay-per-use scheme. The last prominent move in this approach came by Salesforce last week, when they introduced serverless functions on their platform.

At Lumigo, we recently ran into some issues with a service we built on top of our Nodejs AWS Lambda handler. These issues were the result of lambda execution leaks from within our serverless code. In this article, I’ll explain about node.js lambda execution leaks and how to avoid them.

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.

Any enterprise working on the cloud is likely to use Infrastructure as Code as it simplifies the deployment process and makes iterative serverless applications easier to manage. There are several open source tools out there that work with most cloud providers, each of them with their own implementation processes. In this article we are going to dive into the workings of one particular tool, Pulumi.

Information security (infosec) is a broad field. Its practitioners behave more like artists than engineers. After all, the mandate for security is not “do X”, but instead “ensure no one can do X, Y, Z, ɑ, β, ɣ, etc.”. The array of possibilities leading to infosec failure are vast. It’s like trying to prove a negative, thus making the task near impossible. On one hand we have an impossible task, on the other we have the affordance of time.

At Epsagon, we pride ourselves on having a platform that is security-first and enables our users to feel confident in the privacy of their data. With this in mind, we are excited to announce that we’ve now achieved Privacy Shield Framework certification, adding to our existing certifications of SOC2 Type 2, ISO27001, HIPAA, and GDPR.

Applications have traditionally been run on servers, which have to be closely monitored to ensure there are no hindrances in production. In the case of serverless computing, you no longer have to manage servers, as the onus falls on cloud service providers. Read along to discover more about serverless computing, including some of its advantages and disadvantages. So what actually is serverless computing?