Microservices

Improve application resilience with chaos testing by deliberately introducing faults that simulate real-world outages. Azure Chaos Studio Preview / AWS Fault Injection Simulator is a fully managed chaos engineering experimentation platform for accelerating discovery of hard-to-find problems, from late-stage development through production. Disrupt your apps intentionally to identify gaps and plan mitigations before your customers are impacted by a problem.

Communication between entities has been a long lasting topic in Software engineering. IPC, Message brokers, Queues are only few of the main actors in this drama. In this episode, Chris is joined by Francesco who will cover a couple of Microservices communication patterns and give a deep dive into the Saga pattern to resolve multi-step transaction flows.

In a previous blog post, I provided an overview of the Distributed Application Runtime (dapr) and explained how it is a useful framework when building microservices. In this blog post, I will show you how to use dapr to enqueue and dequeue messages locally with Azure Service Bus and Azure Storage Queues.

In this post, we’re going to explore the Open Source project known as Dapr (The Distributed Application Runtime). This post is primarily aimed at those who already have an understanding of Containers, Kubernetes and Microservices. However, if you’re not familiar with these topics - I’ll do my best to set the right context and background without making the blog too lengthy!

In this talk, Asanka will introduce the ‘cell-based’ reference architecture, which is decentralized, API-centric, cloud-native and microservices friendly. He will explain the role of APIs in the cell-based approach, as well as examine how real applications are built as cells. Asanka will explore the metrics and approaches that can be used to measure the effectiveness of the architecture and explore how organizations can implement the cell approach.

Following hot off the heels of my recent blog post introducing Logic Apps and how I use the technology on cloudwithchris.com, I thought it made sense for the second post to continue the Logic Apps theme. This time, we’ll be focusing on Logic Apps preview (sometimes referred to as Logic Apps v2) - the evolution of Logic Apps. Typically when you deploy Logic Apps, you deploy it as a multi-tenanted service. There are some benefits to that, including the serverless capability, so being able to pay per execution rather than an overall infrastructure cost. But what if cost is less of a requirement for you? What if you care more about portability, greater performance, and ultimately control over your environment? If those are more along the lines of your requirements, then you may want to investigate the Logic Apps previewhttps://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview-preview. The Logic Apps preview builds upon the Azure Functions extensibility model. Yes, you read that right - Azure Logic Apps is effectively building on top of Azure Functions. Why should you care? Anywhere that Azure Functions can run, then Logic Apps can run.

Recently, I’ve been doing a bit of work with GitHub Actions as well as Terraform for a pet project I’ve been working on. I’ve been building a multi-tenanted inventory app for my Yu-Gi-Oh card collection. In this session, we’ll explore some of the GitHub actions that I have used to deploy the application content and various Microservices.

Let’s introduce the next episode -We have another guest! We’re starting to bring a few of those previous topics together in this episode. We touch upon requirements, DevOps, and building applications - or rather APIs - in the cloud. In this episode, I talk with a colleague and friend, Peter Piper, on factors that relate and impact API design. So, without further ado… here we go!

In my spare time, I work on a pet project called Theatreers. The aim of this is a microservice based platform focused on Theatre / Musical Theatre (bringing a few of my passion areas together). I’ve recently re-architected the project to align to a multi-region serverless technology stack.