As we enter into our 4th year, we've decided to get up close and personal with our team to share with you their passion, drivers, lessons learned and significant moments of the past year. We're a young company dedicated to adding value in all corners that we reach, so we hope you find the upcoming series useful! Hey Marek, so can you tell us how long you’ve been at Dashbird and where you were before? M: I’ve been at Dashbird for two years now.

Step Functions is a managed service by AWS that implements the Finite-state Machine (FSM) model. You coordinate multiple AWS services into serverless workflows so you can build and update apps quickly. Using Step Functions, you can design and run workflows that stitch together services such as AWS Lambda and Amazon ECS into feature-rich applications. You can read Wikipedia’s definition of a Finite-state Machine, but I think you’ll like the next section more. Keep on reading.

AWS Step Functions is a great service for orchestrating multi-step workflows with complex logic. It’s fast to implement, relatively easy to use and just works. The problem is its price. For relatively low-scale projects, it’s a feasible solution. But for large-scale, enterprise-grade orchestration with hundreds of millions of processes, each with dozens of steps, it can be cost prohibitive.

August 2020 marks 3 years of Dashbird and empowering serverless DevOps teams to fully understand their complex serverless infrastructures by enabling them to get full observability and insights into its performance. This birthday month, we have plenty of surprises, giveaways, and goodies in our sleeve over the next few weeks, so sign up for our newsletter to be the first one to know.

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.