This is a follow-up on a previous post that described how to run a really simple server-side WASM application with the Docker Desktop+WASM Tech Preview. This was your typical Hello, World! example. This time I'm going for a simple echoing TCP server.

For a customer we're managing a Cloud Foundry installation (actually Tanzu Application Service, TAS). I wanted to give the deployment of a simple Rust REST API a try and hit some issues which I'll describe in this blog post.

The title already says it all: I wanted to go through all the steps to run a server-side WASM app on the new Docker Desktop+WASM Tech Preview.

I recently passed the CKAD exam: Certified Kubernetes Application Developer, from the Cloud Native Computing Foundation. There are already lots of blog posts with tips on how to pass and how to train so I'll try not to repeat all of that. Here's some random advice that might help you.

This is part 4 in a series of posts about writing service brokers in .NET Core.

This is part 3 in a series of posts about writing service brokers in .NET Core.

This is part 2 in a series of posts about writing service brokers in .NET Core.

I'm experimenting with writing a service broker in .NET Core that conforms to the Open Service Broker API specification. This is part 1 of a series of posts that explores all service broker details from a .NET perspective.

Suppose you have a component (an API controller, for instance) that has a dependency on another component. And you have all of this nicely configured using your favorite IoC (Inversion of Control) library: SimpleInjector. In most applications you also have some cross-cutting concerns like logging, validation or caching. Ideally, you do not want these cross-cutting concerns to influence the way you write your business code.

Azure Resource Manager (ARM) provides you with the means to describe the infrastructure for your Azure applications. This includes storage accounts, virtual machines, Azure SQL databases and a lot more. On a project I'm working on we're using it to describe the layout of an Azure Service Fabric cluster but we decided to start using it for all resource groups.