.NET Core AWS Lambda Lifetime After Uncontrolled Exception

I am writing my first AWS Lambda function. It maintains some state in a static variable and I wanted to know whether that static variable sticks around if an uncontrolled exception occurs.

In a console application for example, an uncontrolled exception results in the ending of that process. Any state is lost. In an ASP.NET application, only the request dies, but the application continues. So not knowing the details of the hosting environment of a function, I wasn't sure what would happen.

Event-Driven Architectures - Queue vs Log - A Case Study

In the previous post we looked at relative event ordering and the decoupling of publishers and consumers among other things. In this post we'll take those concepts and look at an example architecture. We'll look at the various modelling possibilities we have with RabbitMQ representing a queue based system, and Kafka representing a log based system.

Event-Driven Architectures - The Queue vs The Log

A messaging system is at the heart of most event-driven architectures and there are a plethora of different technologies in the space and they can be classified as either queue based or log based.

Queue based: RabbitMQ, ActiveMQ, MSMQ, AWS SQS, JMQ and many more.

Log based: Apache Kakfa, Apache Pulsar, AWS Kinesis, Azure Event Hubs and many more.

Each messaging system has different features but at the heart are their data structures: queue or log. In this post we'll take a look at how the underlying data structure affects your event-driven architecture.

SQL Server CDC to Redshift Pipeline

In this post we'll take a look at what Change Data Capture (CDC) is and how we can use it to get data from SQL Server into Redshift in either a near real-time streaming fashion or more of a batched approach.

CDC is a SQL Server Enterprise feature and so not available to everyone. Also there are vendors that sell automated change data capture extraction and load into Redshift, such as Attunity and that may be your best option. But if you can't or don't want to pay for another tool on top of your SQL Server Enterprise license then this post may help you.

Processing Pipelines Series - Reactive Extensions (Rx.NET)

Whereas TPL Dataflow is all about passing messages between blocks, Reactive Extensions is about sequences. With sequences we can create projections, transformations and filters. We can combine multiple sequences into a single one. It is a very flexible and powerful paradigm but with such power comes extra complexity. I find TPL Dataflow easier to reason about due to its simple model. Reactive Extensions can get pretty complex and is not always intuitive, but you can create some elegant solutions with it. It will require some investment in time and tinkering to get a reasonable understanding of it.

Processing Pipelines Series - TPL Dataflow - Alternate Scenario

In the last post we built a TPL Dataflow pipeline based on the scenario from our first post in the series. Today we'll build another pipeline very similar to the first but with different requirements around latency and data loss.

In the first scenario we could not slow down the producer as slowing it down would cause data loss (it read from a bus that would not wait if you weren't there to consume the data). We also cared a lot about ensuring the first stage kept up with the producer and successfully wrote every message to disk. The rest was best effort, and we performed load-shedding so as not to slow down the producer.

Processing Pipelines Series - Concepts

In this series we'll look at few different .NET technologies we can use to process streams of data in processing pipelines and directed acyclic graphs (DAGs). This is not about distributed data platforms for big data but real-time processing and computation running on a single machine. We'll take a single scenario and build it out multiple times, each with a different technology. Each application will be built as a console application with .NET Core.

AgileTM vs Real Agility - The Constant Rush

Being in a rush is counter-productive. It is stressful for the people doing the work and the quality of the work suffers. In software development that translates into an ever increasing amount of spaghetti code and an architecture of quick fixes which then leads to a slow down. This slow down then leads to greater time pressure, and the rush gets worse.

Real deadlines do exist, and sometimes out of necessity a team has to pull out all the stops and make a short-lived dash. The big problem arises when this mad dash is the normal state of affairs.