Press "Enter" to skip to content

Category: Architecture

Azure ML Well-Architected Framework Review

Published 2022-03-28 by Kevin Feasel

Ben Brauer has good news:

Microsoft offers prescriptive guidance called the Well-Architected Framework that optimizes workloads implemented and deployed on Azure. This guidance has been generalized for most workloads and creates a basis for reliable and secure applications that are cost optimized.

We have begun to build on this base content set to include more precise guidance for specific workload types, such as machine learning, data services and analytics, IoT, SAP, mission critical apps, and web apps. Machine Learning was the first branch from the base content, which came into fruition in the Fall of 2021.

In case you have never used the Azure Well-Architected Review assessment tool, it’s really useful. It can take hours (or days) to go through the review but if you take it seriously and have the right people in the room giving answers, you’ll get concrete guidance on how to optimize your Azure-based solutions.

Comments closed

Understanding Data Mesh

Published 2022-03-15 by Kevin Feasel

Rick Spurgeon has a video series:

Decentralized architectures continue to flourish as engineering teams look to unlock the potential of their people and systems. From Git, to microservices, to cryptocurrencies, these designs look to decentralization as a method of breaking apart centralized bottlenecks. Data mesh is an approach to data and organizational management centered around decentralizing control of data itself. In this post, we’ll look at a Confluent Developer video-led course that tackles the big concepts and walks you through creating your own data mesh using event streams and Confluent Cloud.

Click through for a 9-part video series.

Comments closed

Summarizing Data Mesh in Azure

Published 2022-03-09 by Kevin Feasel

Paul Andrew wraps up a series:

When we consider this in the context of what I’ve already established in part 1 of the series, I focused on our data products and ownership. Now I want to re-introduce our data domains as a level above our data products. We can even consider this a hierarchy.

– Data Domains

– Data Products

Why?

Read on for that answer.

Comments closed

From Access to SQL Server

Published 2022-03-08 by Kevin Feasel

Tom Collins has some tips to make an Access to SQL Server migration more successful:

-Access has a size limit of 2 GB

-Access has a concurrent users limit of 255 users

-Require increased capacity 

The SQL Server Migration Assistant for Access (SSMA) is a very useful tool  offered by Microsoft . 

The main objective of these notes is to supplement the Microsoft documentation and to assist in Access to SQL Server journey.      

Read on for those notes.

Comments closed

Mission-Critical Azure Architectures

Published 2022-02-23 by Kevin Feasel

Ben Brauer has some reference guidelines:

The AlwaysOn project strives to address the challenges of building mission-critical applications by providing organizations with a prescriptive architectural approach for the Microsoft Cloud.

It leverages lessons from numerous customer applications and first-party solutions, and applies Well-Architected best practices to provide actionable and authoritative guidance for building and operating a highly reliable solutions on Azure at-scale.

I guess marketing is calling it “AlwaysOn” again. Until they call it Always On. Or AlWaYsOn.

Comments closed

What Comes after the Well-Architected Framework Review

Published 2022-02-18 by Kevin Feasel

Ben Brauer takes us through the next step:

Congratulations! You’ve finished your Well-Architected Review of a workload, giving you a better understanding of where it could be fortified along the five pillars: Security, Reliability, Operational Excellence, Performance Efficiency and Cost Optimization. You have received Microsoft’s best practices as recommendations based on your answers to questions specific to each pillar.

The report (example below) shows a Well-Architected score for each pillar, as well as prioritized recommendations that allows for you to focus on biggest areas of impact. A great example is virtual machine right sizing. You can significantly lower your costs if you know which VM is best suited for your workload type.

By the way, if you have Azure resources, I highly recommend checking out the Well-Architected Framework assessment link there. It can take a very long time to go through because of just how many questions there are; that said, the results are also pretty specific and can be immediately helpful.

Comments closed

Database Schema Types

Published 2022-02-11 by Kevin Feasel

Steve Jones explains schema types:

OLTP/Relational

The type of schema that many of us work with is the standard OLTP or relational model. We have lots of transaction tables, most should have a PK, some of which have PKs. The schema expands to meet different needs and can have lots of entities.

It may just be the time of morning but “Galaxy schema” sounds dumb specifically because the Kimball style of star schema implicitly includes what the galaxy schema shows. Dimensions are conformed, which means they apply across facts, which implies that there may be multiple facts in the schema design. This means that galaxy schemas necessarily star schemas. For the sake of education, we tend to focus on one fact table but a star schema with two fact tables is still a star schema.

Anyhow, that’s my minor rant of the day. It’s not Steve’s fault somebody misunderstood the concept of star schemas and began promulgating this unnecessary term.

Comments closed

Lakehouse, Mesh, and Fabric

Published 2022-02-09 by Kevin Feasel

James Serra is back in blue:

(NOTE: I have returned to Microsoft and am working as a Solution Architect in Microsoft Industry Solutions, formally known as Microsoft Consulting Services (MCS), where I help customers build solutions on Azure. Contact your Microsoft account executive for more info. That being said: the views and opinions in this blog are mine and not that of Microsoft).

There certainly has been a lot of discussion lately on the topic of Data Lakehouse, Data Mesh, and Data Fabric, and how they compare to the Modern Data Warehouse. There is no clear definition of all these data architectures, and I have created a presentation using my own take that I have been presenting frequently internally at Microsoft and externally to customers and at conferences. Hopefully these presentations, blog posts, and videos can help clarify all these data architectures for you:

Click through for several useful resources to help differentiate these topics.

Comments closed

Data Mesh in Azure: Self-Service Infrastructure

Published 2022-02-02 by Kevin Feasel

Paul Andrew continues a series on applying data mesh principles in Azure:

This principal is very broad, so I want to break down the theory vs practice as before. The idea of self-service is always a goal in any data platform and the normal thing for analytics is to focus on this within the context of our data consumption. Whereby a semantic layer technology can be used in a friendly business orientated, drag-drop type environment to create dashboards or whatever.

However, my interpretation of ‘self-serve’ for a data mesh architecture goes further than just the dashboard creation use case. This should not just apply at the data consumption layer, but all layers within the solution and for clarify, not just related to the data itself. Hence the term in this principal ‘data infrastructure as a platform’. This then unlocks the deeper implication of this serving for a data product, all abstracts of the platform can be consumed in a self-service manner from a series of predefined assets. Let’s think about this serving more like an internal marketplace or catalogue of assets for delivering everything the data product needs to enable a new node within the wider data mesh.

Read on for some deep thoughts on the topic.

Comments closed

Defining Technical Debt

Published 2022-01-28 by Kevin Feasel

Paul Andrew has thoughts on technical debt:

A few times now I’ve been asked to define technical debt. It can be an ugly term if your role is a project manager or scrum master. But, for me, as a more technically minded person I see this debt as a very normal thing that in an agile delivery team can be managed. However, before we can manage it, I’d like to use this blog post to define it (and get my own thoughts in order).

Read the whole thing. If you want a bit more on the topic, I have a post sharing my thoughts. Reading Paul’s post, I think there’s a lot of common ground in our ways of thought on this.

Comments closed