Archives For Best Practices

thoqlo0jwq

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. Continue Reading…

blue-abstract-balls-spheres-large

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.

statemonolithic-vs-micro

Continue Reading…

2016-07-09

Speaking at DevTeach 2016

Years ago, I attended the DevTeach conference and was fortunate to participate in conversations that helped me overcome many challenges over the years that followed. This week I had the opportunity to speak at DevTeach in Montreal. For this event, I chose a topic that I’m really passionate about and needed to cover a lot of ground in a short amount of time.

The talk had a progression from a public cloud, to an architectural pattern, to a hyper-scale microservice platform and finally about a programming model.

My goal with this talk is primarily to introduce Actors and Service Fabric. Then provide attendees with additional information in the downloadable slides about the patterns that I feel are important to consider when building microservices.

Caught by surprise, I had a full room and a lot of great questions. Thanks everyone for making this a success. Continue Reading…

man-person-people-emotions-large

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. Continue Reading…

startup-photos

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. Continue Reading…

pexels-photo-52910-large.jpeg

Big Compute or Big Data?

This question comes up on a fairly regular basis. So I thought it would be interesting to share my understanding in hopes to help you make the right decision.

Both are enablers, and they create opportunities through various approaches. When the problem is understood, and the algorithms vary by parameter, then Big Compute is definitely an approach to consider. When we know our input data, and are experimenting with various algorithms, Big Data is a clear winner.

This being said, let’s try to materialize this into something more concrete.

Big Compute shines at large scales. Easily parallelizable workloads are the best use cases, because they allow us to break the workload into independent tasks. This is where we can gain the most from large numbers of compute cores. Big Compute is all about executing any software package, written in any language by passing in variables. This creates an amazing opportunity for developers to optimize their code to be extremely efficient. Optimizations range from concurrency management, memory management, limiting IOPS and other aspects like network communication optimization. Possible scenarios are well known algorithms like Monte Carlo simulations, rendering and work flows.

Big Data is all about empowering us to experiment with our data by providing us with tools, query languages and scripting capabilities that are geared at giving us a lot of agility. Tinkering with algorithms, is the perfect use case. We know our data, and want to extract insights from it. This means that we’re going to clean it, shape it and question it. Big Data is built for this; it makes it possible to iterate through multiple versions of our algorithms in a way that’s difficult with Big Compute.

So now that we’ve nailed this down, which is right for your workload?

Share your thoughts in the comments below


Keeping ARM CMDLETs Fresh

Open a PowerShell Console as an Administrator and used the following commands. It usually takes about 15 minutes to complete, so don’t do this if you’re in a hurry =)

Install-Module AzureRM -AllowClobber -Force

Installing AzureRM modules.
AzureRM.Profile 1.0.5 updated [1/29]...
Azure.Storage 1.0.5 updated [2/29]...
AzureRM.Backup 1.0.5 updated [3/29]...
AzureRM.RedisCache 1.1.3 updated [4/29]...
AzureRM.Tags 1.0.5 updated [5/29]...
AzureRM.SiteRecovery 1.1.4 updated [6/29]...
AzureRM.Insights 1.0.5 updated [7/29]...
AzureRM.OperationalInsights 1.0.5 updated [8/29]...
AzureRM.DataLakeAnalytics 1.0.5 updated [9/29]...
AzureRM.Dns 1.0.5 updated [10/29]...
AzureRM.Storage 1.0.5 updated [11/29]...
AzureRM.UsageAggregates 1.0.5 updated [12/29]...
AzureRM.HDInsight 1.0.6 updated [13/29]...
AzureRM.RecoveryServices 1.0.6 updated [14/29]...
AzureRM.Network 1.0.5 updated [15/29]...
AzureRM.Compute 1.2.4 updated [16/29]...
AzureRM.TrafficManager 1.0.5 updated [17/29]...
AzureRM.Websites 1.0.5 updated [18/29]...
AzureRM.LogicApp 1.0.1 updated [19/29]...
AzureRM.DataFactories 1.0.5 updated [20/29]...
AzureRM.DataLakeStore 1.0.5 updated [21/29]...
AzureRM.Sql 1.0.5 updated [22/29]...
AzureRM.Automation 1.0.5 updated [23/29]...
AzureRM.ApiManagement 1.0.5 updated [24/29]...
AzureRM.StreamAnalytics 1.0.5 updated [25/29]...
AzureRM.Batch 1.0.5 updated [26/29]...
AzureRM.Resources 1.0.5 updated [27/29]...
AzureRM.NotificationHubs 1.0.5 updated [28/29]...
AzureRM.KeyVault 1.1.4 updated [29/29]...
pexels-photo

Has Something Gone Wrong?

Generally, we choose to leverage Read-Access Geo-Redundant Azure Storage Accounts (RA-GRS) because we can use it as part of our disaster recovery (DR) plan. And sometimes, we forget that our devil is in the details. Disaster recovery (DR) plans are rarely tested and can cause headaches when they are. So let’s relieve some of those headaches.

Headache…

“Geo Replication Lag” for GRS and RA-GRS Accounts is the time it takes for data stored in the Primary Region of the storage account to replicate to the Secondary Region of the storage account. Because GRS and RA-GRS Accounts are replicated asynchronously to the Secondary Region, data written to the Primary Region of the storage account will not be immediately available in the Secondary Region. Customers can query the Geo Replication Lag for a storage account, but Microsoft does not provide any guarantees as to the length of any Geo Replication Lag under this SLA.

The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the first items that come up in DR discussions. When we use RA-GRS we control the RTO because we decide when to read from the secondary location. The RPO is a bit different because that can vary due to physics and load. The best way get current Recovery Point (RP) is to get the last sync time for the RA-GRS in question. This post is all about getting the right information, when we need it, because we need facts to make the right decisions. Continue Reading…

mind-the-gap

Based on the current builds, compared to Server, Nano Server has 93 percent lower VHD size, 92 percent fewer critical bulletins and 80 percent fewer reboots!

Deploying Nano Server to Azure

I’ve been curious about Nano Server for a while now. And I recently noticed that it was available on Microsoft Azure. This post is definitely from a developers point-of-view. It goes through the steps required to create a functional Nano Server Virtual Machines (VM) on Microsoft Azure.

Nano Server is ideal for many scenarios:

  • As a “compute” host for Hyper-V virtual machines, either in clusters or not
  • As a storage host for Scale-Out File Server.
  • As a DNS server
  • As a web server running Internet Information Services (IIS)
  • As a host for applications that are developed using cloud application patterns and run in a container or virtual machine guest operating system.

The Adventure

Nano Server is a remotely administered server operating system (OS). Wait. Let me repeat this because it’s important… Nano Server is a remotely administered server operating system (OS). Developers, Nano Server is a server OS optimized for clouds and data centers. It’s designed to take up far less disk space, to setup significantly faster, and to require far fewer restarts than Windows Server. So why does this matter? Well it means more resources, more availability and stability for our Apps. And it also means that it’s time to learn new skills, because there is no local logon capability at all, nor does it support Terminal Services. However, we have a wide variety of options for managing Nano Server remotely, including Windows PowerShell, Windows Management Instrumentation (WMI), Windows Remote Management, and Emergency Management Services (EMS). Continue Reading…