Since AWS Lambda was launched in 2014, serverless has transformed the way applications are built, deployed, and managed. By abstracting away the underlying infrastructure, developers are able to shift operational responsibilities to the cloud provider and focus on solving customer problems.

Recently, I had a scenario in which it was necessary to access the content of the source JSON message and extract a property that contains a date-time. That property was in the last object (a repeating object) for control purposes, and my first idea was to get it done with Azure Function and that’s it. But then I was thinking, if I need to use Function for all these simple tasks, what’s the point?

The infrastructure that runs your applications can be nearly as complex as the applications it supports. This complexity generally scales with the resilience of the architecture of your application, the scaling needs, and any security concerns. Thus, successful infrastructure for traditional applications often relies on a comprehensive tooling suite that allows the infrastructure engineers to iterate upon and improve your application’s resources.

Orchestrating and composing multiple services in a distributed architecture is not easy. Before we move along with the great solution offered by vending-machines to our distributed architectures, we need to understand what solutions and values we’re looking for. In a serverless environment, there are at least three desired properties of any distributed services implementation.

Azure Functions is a serverless compute service that lets you run event-triggered code without having to explicitly provision or manage infrastructure, in other words, Microsoft’s Azure Functions is a modern serverless architecture, offering event-driven cloud computing that is easy for developers to use. This blog is about Azure Functions triggers and bindings.

In our latest article on the Amazon Builders’ Library, Yan Cui highlights the main takeaways from the article, Implementing health checks, by AWS Principal Engineer David Yanacek.

Come January, pretty much any current tech keyword you type into Google News will result in hundreds of prediction op-eds and roundups. The fact that it’s an entirely new decade has amplified this phenomenon and serverless is no exception. As the CEO of a company dedicated to helping software teams build, manage, and deliver serverless applications, it’s a joy to read these posts by some of the brightest minds in the industry.

Serverless development opens lots of new opportunities, and if you’re invested in serverless (or you’ve been following the hype) you’ll know that cost efficiency is principal among those benefits. Simply put, we can save money by choosing the right tool for the right task. Since a distributed microservices architecture is made up of many managed services it’s a simple task to change out the building blocks of a particular application flow.

You may know my series of blog posts about BizTalk Server Tips and Tricks that I normally write in the BizTalk360 blog. Well, the goal of this Logic Apps Tips and Tricks series will be the same; to provide simple tips or tricks that may improve your performance on developing Logic Apps workflows, avoiding issues, apply best practices and so on. But you may think, “What a strange way to start this topic, deprecated actions? Why should I use deprecated actions?”.

Local prototyping has become de rigueur for most web stack developers in the last few years. Even complex web backends are generally assumed to be emulatable from a developer’s laptop. But this assumption breaks down a bit as we explore the AWS platform in general. More specifically, serverless architecture challenges the system of local prototyping.