Getting to Know Containers

Containers have sparked genuine interest over the last few years. As a developer, I’ve had my fair share of “It Works on My Machine” days, where I spent an interesting amount of my time trying to identify why my code doesn’t run in a given environment. Did I make a mistake? Did someone else make a mistake? Uncertainty, risk and the Human Factor definitely make for adrenaline packed all-nighters.

What’s this all about?

In the old days, R&D was about features, marketing was about promoting products to prospective decision makers, sales were about getting big deals, and service was about implementing and fixing things. Today, it’s all about growing end-user consumption and selling microtransactions to consumers.

The risk is on us, and our reward only happens if our end-users are successful.

Success doesn’t magically happen… Product marketing must design for it, development must build for it, services must contribute heavily to consumption research, marketing must translate the findings into offers, offer management technology must deliver it, services must access it during every service transaction…

In short, consumption is everything. If end-users underutilize our software, chances are that at some point the company we code for, won’t be able to pay for our services. We are all responsible for crafting successful software. From developers to sellers, everyone is liable to provide feedback, insights and value to the end-users. This is a team effort and can be supported through practices like DevOps, Business Intelligence and Artificial Intelligence. This requires communication and collaboration. It’s time to forget about silos and to move from a one-time sale to a pay-per-use model.

Quick Thoughts

Businesses need to be agile to compete in today’s global economy. Programmers use various tools and techniques in order to meet this business requirement. The challenge is great and quite complex. Going too fast without the right approach can lead to ephemeral success.

I believe that Microservices give us the agility and architectural patterns that empower us to scale and create value at a far greater pace for the business compared to using a traditional tiered architectures approach.

Forget about 3-tier architectures, they just doesn’t scale. Stateless services need to rebuild their internal state for every call, and they can generate tremendous pressure on data stores. Consequently, this generates back pressure that bubbles up through the layers of our solution and reaches out to the edge. Back pressure then translates into unavailable services. The key is Data Locality and Stateful Services.

Happiness is DevOps’ Cornerstone

DevOps is definitely a culture. I think it’s the new Agile in many ways, and that’s OK. So we’re tech-savvy and we usually delve in tools and processes when we talk about DevOps. But we often forget the most important part, the people.

Why Service Fabric?

There are definitely a lot of reasons to consider Service Fabric. Surprisingly, they originate from multiple perspectives because Service Fabric is beneficial to IT Pros, Developers and above all else the business.

The 95th Percentile

Imagine a reality, where you can detect and fix issues without your users noticing that something went wrong.

We all aspire to measure performance in some way, and choosing what to measure can be a challenge in itself. By default, we think about averages, and we forget that there are many other possible measurements.

Share this:

Microsoft Azure has a lot of options when it comes to provisioning environments and resources. In my last post about troubleshooting Virtual Machine allocations, I enumerated a few of these options and briefly mentioned that I favored destroying environments to shutting them down. In this post, I will try to give more context around my preference.

Saving Microsoft ARM Templates as JSON files on disk

If you are creating a brand new environment on Azure, you should be using Windows PowerShell and Resource Manager. Instead of creating and managing individual resources, use a template (resource model) to create a resource group that has the resources need to support your service. You can create your own templates or pick a template from the gallery.

If you’re starting off with the Azure Resource Manager (ARM), I recommend taking a look at what others have published. Then modify them to create a resource model that represents your service.

The Greenfield to Brownfield Transition

There’s a special moment in every project where it transitions from a Greenfield (new) project to a Brownfield (legacy) project. This moment usually occurs close to the second release.

As developers, we love Greenfield projects. It’s a new adventure where creativity runs wild and free.

The transition of a project from Greenfield to a Brownfield is an event that we can all appreciate. It’s delicate and requires attention from everyone on the team.

Semantic Logging Application Block (SLAB) – Out-of-process Service is not Logging to #Azure Table Storage?

With the latest update of the Semantic Logging Application Block – Out-of-process Service NuGet Package, the user under which the Windows Service is executed has changed. In hopes to save you countless hours of debugging I am sharing the configurations that should be used on Azure Cloud Services.

When you start the Out-of-Process service be sure to specify the LocalSystem account.

SemanticLogging-svc.exe -s -a=LocalSystem

Failure to execute under the right account will prevent the Out-of-Process service from logging Events to Azure Table Storage.

• Semantic Logging Application Block – Out-of-process Service
• Semantic Logging Application Block – Source Code & Samples

What is SLAB?

The Semantic Logging Application Block (SLAB) provides a set of destinations (sinks) to persist application events published using a subclass of the EventSource class from the System.Diagnostics.Tracing namespace. Sinks include Azure table storage, SQL Server databases, file, console and rolling files with several formats and you can extend the block by creating your own custom formatters and sinks. The console sink is part of this nuget package. Other Sinks mentioned above are available as separate nuget packages. For the sinks that can store structured data, the block preserves the full structure of the event payload in order to facilitate analysing or processing the logged data.