Posts

What are we running - API changes expressed as versions

Image
What API version is out there and how do we know it? The software world is continually moving along the path to more API-driven solutions in an attempt to break down monolithic software systems into more manageable size pieces.  We stitch together business processes with a collection of synchronous API endpoints, asynchronous messages, and massive event streams.  Every one of these connection points is a data and behavior contract that can be changed every time one of these endpoints is updated or upgraded.  Today's agile means that the individual services change often and at a rate decoupled from the API consumers.  We need to apply software engineering discipline to capture the changes and make it possible for our consumers to know which version they are talking to. Video Part 1 Change Types and Scale, Synchronous/Asynchronous APIs, Design Time vs Run time Considerations Part 2 Run Time versioning options for consumers and operations All APIs: Syn

What are we running - Tagging infrastructure in Azure

Image
Asset Tagging is one of the best ways for providing run-time compliance and versioning information in cloud-based resources.  All of the major cloud providers provide the ability to annotate cloud resources with custom tags.  We reliably version/tag cloud resources if we follow the  Infrastructure as Code philosophy.  All our infrastructure is created using scripts that call cloud APIs, or resource templates that can be loaded by cloud APIs. Infrastructure versioning has both design time and run time components. The design-time pieces come into play at build and packaging time and when deploying.  The run time component is what lets us interrogate the component or the cloud metadata around that component.  Video Design-time infrastructure versions with IaC IaC uses code or configuration files to drive provisioning. Those files can be checked into source code management systems where they can be branched and versioned like any other code. We can always query the VCS for the various b

Make Azure learning credits visible in the coffee shop domain

Image
The Microsoft Accounts mess can make it hard to use your Azure credits that come bundled with MSDN/VSOL. You  can end up with two accounts with the same name, one work/school in your corporate domain and one personal  Microsoft ID outside the corporate domain.  Enterprise users run into this when they want to learn in Azure using their Corporate MSDN Azure credits. Both accounts have the same email domain which means they both have corporate accessibility zone restrictions even though the two accounts are not connected in any way and have no way of seeing each other's resources. We can share this subscription with your personal, non-corp domain, account or create an ID that only exists in the ID that is tied to the subscription.  This lets you learn Azure  while sitting at home or the coffee shop.  This blog assumes you are allowed to use your Azure credits for your education from personal gear.  If not, then stop here. Video Discussion Initial State We usually start with

Azure Active Directory - Tenant basics I never knew

Image
Azure Active Directory has always been sort of  just there .  I've never paid any attention to the concept of Azure Active Directory tenants until last week. Azure AD was just an idea when we first started our Azure work 8 years ago. There were all kinds of "you can't do that in Azure AD" wrappers around it back then. Azure AD has grown in flexibility. Now it is time to look at the multi-tenancy aspects of Azure AD. You can spend years in Azure without running across the tenancy.   Got a personal Azure account?  One tenant is plenty.   Got an MSDN Azure subscription tied to your account? One tenant is plenty.   Working in a corporate environment where some other group manages AD and provides your subscriptions?  One tenant might be all you ever use. We can walk through an example account to get a better understanding of Azure AD tenants why we might use them. Video Azure AD Tenant Basics <speaker notes to be

Four faces of software reuse - Greatest strength is its greatest weakness

Image
We have four major patterns for reusing software and code. They each have their own advantages and disadvantages. This will be another demonstration of how an approach's greatest strength can also be a weakness of that approach. We will cover copy/paste, shared library, mono-repo internal library, and shared services. Today's pattern is tomorrow's anti-pattern.

Log! Don't Print! Use the Python logging library

Image
Python has become one of the most popular application languages in IT, shadow-IT, and data science. Python developers continually improve their systems by iterating from example patterns to best practices.   The Python logging package should be used wherever print() statements were in the past. The logging package makes it possible to classify output at different severities.  logging has the ability to enable and disable the generation of output at those different levels. This means you can create debug-level  statements that are useful to programmers without letting those statements bleed into a production application. The referenced GitHub project shows how to load logging configurations, and how to change where logging goes based on those configurations.  Classify output by severity Filter output generation by severity Send data to different sinks based on the program module and the severity Logging Design Logging is routed through loggers  that are instantiated in each python modul

A Software Architecture's Greatest Strength is Its' Greatest Weakness

Image
An approach's greatest strength is also often its greatest weakness.  You see this in Software Designs or Software Architecture.  We design something to be optimized around a set of needs, business functionality, ease of development, ease of maintenance, data integrity, performance.  Those decisions create their own problem.  We design and build systems optimizing our design around delivery capability, technology, NFRs, and business functions. Those designs and systems architectures take into account the best practices at that time . Those best practices sometimes come from other companies with different priorities and skillsets. The great strengths of your present-day designs will make up a good percentage of the future weaknesses. This should not be a surprise. We design around what we know now and around the technology available at that time.   Your successors will toss your design in the future when the strengths of the current approach become the things holding back forward

No-meeting blocks - defending a policy that enables people to get stuff done

Image
Meetings have their place, especially in collaborative, consensus, or creative organizations. We need to manage the number of meetings to ensure that you have "heads down" time. I have seen at least three different ways of tackling the problem. Create a corporate or department policy. Create a daily multi-hour team meeting. Block out multi-hour blocks on your calendar. There are other ways that I've never tried. Ban all meetings Decline all meetings where you are optional. An average  calendar with some protection This calendar partially successfully guarded 4 ways.  There is a " no meetings before 9:00"  policy.  There is a daily " lunch block " . There is a " no meetings Friday afternoon"  policy and there is " team time"  blocked out for two hours every afternoon. Video Video speaker notes <to be added> Create a corporate or departmenta