Each company treats the Solution Architect role with a different set of responsibilities. In all the companies I worked in or clients I worked for, the roles and responsibilities of Solution Architects have differed significantly, except for the core responsibility: Answering the question "How?".

In a consultancy, I was responsible for:

• Understanding the requirements
• Designing the solution
• Preparing the High-Level Design document
• Roughly breaking it down to delivery items
• Roughly estimating the work, the team profile, and quoting the price
• Guiding the delivery teams as an active part of the delivery team

In a bank, I was responsible for:

• Understanding the requirements
• Designing the solution
• Preparing the High-Level Design document
• Explaining the design to the delivery teams answer questions if needed

In an automotive company:

• Understanding the requirements
• Designing the solution
• Preparing the High-Level Design document
• Implementing the proof of concept or the walking skeleton of the solution
• Guiding the delivery teams as an active part of the delivery team

I can give many more examples, even weird ones, but you get the gist. The typical tasks for each role are the same, though:

• Understanding the requirements
• Designing the solution
• Preparing the High-Level Design document

These three items answer the question "How can we solve this particular problem with the requirements and constraints we've been given?". 

The core responsibility of the SA role is to come up with the most suitable solution to the problem. Mind you, not the "best" or the "perfect" solution. The "most suitable" solution. We're not crusaders on a quest to find perfection. That path is dangerous; only a Sith deals in absolutes.

However, in some teams, especially agile teams, the boundaries between roles get blurred. Scrum Guide only has three roles: Developers, Scrum Master, and Product Owner. SA falls into the category of Developers, which is defined as below:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Scrum Guide | Scrum Guides

Navigate to Home Page

Because Scrum Guide is deliberate in its vagueness, it creates a question in the minds of the SAs: What the hell am I supposed to do?

You're not alone in thinking this. I also struggle quite a lot with this.

I don't have a straightforward answer for you, but instead of running around to answer any question, keep calm and focus on "How?". That's the most important one.

A typical Scrum Coach would tell you that the following questions are answered by the roles next to them:

• What: Answered by the Product Owner, explaining the requirements in the form of a Product Backlog.
• Why: Answered by the Product Owner.
• When: Answered by the Product Owner and the team during Sprint Planning.
• Who: Answered by the team during Sprint Planning or the Sprint.
• How: Answered by the team during the Sprint Planning.

However, as the SA, you'll notice you can (and unfortunately, will) answer most of these questions if the necessary roles aren't pulling their weight. That's taxing and blurs your responsibilities.

If you don't know your responsibilities, focus on "How?" instead of stretching yourself thin. Understand the problem, find the most suitable solution, and convey that to the team in the best possible way.

Don't worry about who implements it and when it gets implemented. Let the PM and SM decide on those. Ask PM what you should work on and pull that into the Sprint. Then, what you do best: Analyse, design, document, and guide.

Let the chips fall where they may. It's not your responsibility to solve everything.

You probably know the saying, “About 70% of the software development projects fail, and about 55% go over budget.” The numbers may change every year, but I’ve been hearing this since my first day as a developer. After 20 years in the industry, I think I can safely state my opinion here: Projects don’t fail or go over budget because building software is difficult; they do because people are.

These statistics are mainly gathered by companies like Gartner and regurgitated countless times by numerous consultants and project managers because they want to sell you something: Their services. They cover the software development with a shroud of mystery and tell you scary stories around the campfire, which looks too much like a meeting room: Half the people who go into software development projects don’t return. The others that came back are never the same.

(I have to say, I’m very proud of this campfire analogy that I came up with.)

But hear me out: Ultimately, the root of your problems isn’t how you execute the project. It’s just how well you’re communicating with. If your team members are incapable of asking for help when they’re about to be mauled by bears, it doesn’t matter if you do Agile or have a PMP-certified PM from Deloitte or McKinsey. You will fail.

And sadly, most of the software developers are terrible at communication. Not because they are bright engineers who think it’s a waste of time. There are plenty of engineers in other industries that build things just fine. I mean, NASA landed on the moon with computers less powerful than my Apple Watch, for fuck’s sake.

Let’s roast each role in a software development project. Why? Because I want to.

Hi, I’m Harun, and Welcome to Jackass

The whole thing happens because software engineers think software development is all about writing code. They think it’s an art, and you just aren’t at their level. Their magnificent minds are on a level that your mere mortal minds can’t comprehend. They are the Illuminated, and all that matters is their work.

And if you’re a PM, BA, or Agile Coach who’s laughing at me roasting the devs above, yeah, bad news. You’re next.

Business Analysts mostly think the developers are idiots and just don’t understand what needs to be done. In their minds, because they talk to the users, they know best. Their brilliant minds see the intricacies of the cogs that make the business work. Hell, most of the time, they know it better than the business units themselves! They explain it all to you in an endless stream of documents. Still, instead of reading and appreciating their masterpieces, you ask dumb questions!

Project Managers are the most blameless and underappreciated of them all—at least, they think of themselves that way. In their minds, the team always fails to deliver despite the PMs’ unrelenting effort to turn them towards the Path of Light, which is another name for the long-ass Gantt chart they prepared in Excel or Microsoft Project. If everyone else would do the tasks by the deadline for each of them!

Testers are the most gullible of them all. They have no idea what the actual fuck is going on and how everything works. In their mind, they are tasked with one thing: Pretend they understand the box of black magic the developers left for them and pray that nothing blows up when they give it to the customers. If it does, it’s the developers’ fault. If it doesn’t, it’s the developers’ fault.

And finally, for our grand finale, the Agile Coaches. They can recite every one of the principles of the Agile religion and all the lines of the manifesto that their 12 monks left for them by memory; they would also preach to you about your sins and try to guide them towards the light. You have to pray in small but not too detailed prayers, do it every two weeks, plan your prayers with your church on the first day of your two-weekly period, estimate how much time each of them will take, and make sure you pray them all before you go back to church and kneel before the gods. Then do it again. Then again. Then again. The gods might change their expectations and ask for your firstborn, and you should do it because it’s written in their manifesto!

Good Grief

Why did we do that? Because it was fun. And also to make a point: The problem is not the software you’re building; it’s your people.

Put 10 people in the same room, and in half an hour, they would find 10 things they would despise about each other. But you’re paying them to get along, so they won’t say anything. They would nod and play nice. But it wouldn’t work well. They still despise each other. They would form groups, probably based on their roles, and they gossip about the other groups. Developers would talk shit about PMs, BAs about devs, PMs about QAs, and QAs about everyone else.

Ultimately, it doesn’t matter if you choose the best methodology on the market for your team. Because the team members won’t communicate well with each other, it won’t work well.

I’m not saying it won’t work at all. It will. I mean, people used to deliver big projects using waterfalls. It just won’t work well.

You don’t need the perfect project management system. You need people to talk to each other.

There isn't a day passes that I'm not involved in a Twitter feud. This time it was about the front-end development ecosystem. I'm not trying to be provacative or anything, but sometimes it’s unavoidable to step onto some toes.

One thing I learned early on in my career: Most important thing you can do in software business is to learn what you’re doing and what you’re using, thoroughly. Learn the basics. Learn what’s making it ticking (insert Sylar gif here). Learn if you’re doing something right.

But of course, that’s not always the case with the majority of the industry. They just love the Hype Train.

I know, it’s a fun experience. You get to use the cutting edge things, fancy things. And you get to tell your friends:

• Hey, we’re doing microservices! There are 5 of them and it’s a pain in the ass to deploy, but we’re doing it!
• Hey, we’re using Kubernetes! That 5-app microservices I mentioned, yeah, we deploy it to a Kubernetes cluster we manage. It’s painful but fancy!
• Hey, I’m using React Server Components! Sure, we don’t need to, and it looks like ASP.NET Web Forms, but hey, it’s new!
• Hey, we’re doing Agile! We fail every sprint that we take, and we use 1 story point for 1 day of work, but we are not doing waterfall anymore - that’s so old school.
• Hey, I’m driving a Cybertruck! It’s ugly as hell and a proof of poor craftsmanship, but it makes my dick feel bigger!

You see my problem with it, right? A lot of people just think a newer tool means it’ll be faster and easier. If you previously were riding a horse driven cart and you learned of dinosaur-powered loud transport machines, yeah, it’s probably better. That’s a good leap.

But unless you’re a frog, leaping from one new thing to the other isn’t necessarily a good thing. Especially if you don’t know what you’re doing.

An Example: The Front-End Development

Let’s take the front-end development ecosystem as an example. There are hundreds of Javascript frameworks you can use, and probably tens of different build tools & engines you can compile your code. Each one thinks they are doing it better than the others. 

• Angular thinks if they add new things every year they can take you to the moon, eventually.
• React thinks that server components should make a come back, because everyone loved Asp.NET Web Forms and the ViewState so much.
• Vue thinks they are reinventing the web development with every release.
• Svelte thinks they are much much cooler than the other boys.
• HTMX is written by 9GAG when it became sentient.

I can talk about this six ways till Sunday and it still wouldn’t be finished.

The same people that couldn’t manage a simple KnockoutJS application from leaking memory think that using Angular or React would make it much better and painless. Then they think those are unsustainable, and go write their own tooling and frameworks.

If you know what you’re doing, you can write an app even with sticks and stones. Don’t forget:

• Gmail used to write code in Java and compile it to Javascript, just because they could. They didn’t even need fancy JS frameworks to make it work.
• Yahoo did their first version of SPA app of Yahoo Mail when there wasn’t even jQuery. I remember it because it took me an hour to close my mouth when I first saw the code.
• Amazon still works with a server page system. And makes billions.

You just need to know what you’re doing. That’s it. There’s no magic to it. There’s no need for a new JS framework that’ll be released in 2024. 

You certainly don’t need AI to write the code for you.

If you don’t know how to fish, an aircraft carrier isn’t going to help your dinner plans.

After working on it for about a month, I finally opened my new project to the public: That Blue Cloud. It’s a website that will be the go-to place for new features on Azure and Microsoft Fabric, how to use them, when to use them or avoid them, and how to design better solutions.

It’s starting as a blog, with a mix of feature announcements and some guides, but I’m planning to make it so much more. I’d like to share some example designs and discuss them in detail, share best practices and offer guidance. The most emphasis will be on using the right technology at the right time and place.

That Blue Cloud

No-nonsense, quality content on building data platforms & apps on Microsoft Azure.

That Blue CloudHarun Legoz

There are numerous tools and features available on Azure, and I’d like to show them in action and discuss the alternatives and variations in the design. As an example, people immediately go for Cosmos DB on Azure for database, thinking that it being a No-SQL database, makes it a better choice than Azure SQL. That’s not always the case.

The design decisions should be made based on the requirements and the context. If your primary objective is to store the data and query it, but not heavily aggregate it, Cosmos might work well for you. However, if your data is very much relational, and you would like to utilise aggregations heavily, Azure SQL might be best. Furthermore, in certain scenarios, Cosmos might be the most expensive data storage you encounter on Azure.

Eventually, there will be premium and subscriber content on the website as well. Some designs might be behind a paywall, some might be open to the public. But I haven’t made up my mind on that part yet. I need to see how the website will fare, first.

There will be, however, a newsletter pretty soon. I’d like to curate some developments in the industry and share with the newsletter with the subscribers.

Feel free to visit the page and subscribe to be notified of the latest content.

That Blue Cloud

No-nonsense, quality content on building data platforms & apps on Microsoft Azure.

That Blue CloudHarun Legoz

After an eventful week in the dotnet open-source ecosystem about, how can it be more sustainable and OSS-developer friendly, I thought I should contribute meaningly to the discussions besides criticisms. So I started thinking about an idea that could help with that. There are many alternative package stores that help developers sell their packages, similar to Gumroad’s model. I did not want it to become another of these stores, as I wanted to target the middle-ground between paid licensing and sponsorships accurately.

What I wanted to achieve is for companies or individuals to purchase a monthly or yearly subscription through an app and provide them with a service: Sponsorship-as-a-Service. It would act like a combination of GitHub Sponsors and NuGet store, but package that into a subscription fee that would be distributed on behalf of the subscriber. Think of how SetApp works: You purchase a subscription and you can download all the apps participated to SetApp. Now think of a donation-powered version of this: Instead of purchasing, the system determine which developer receives a part of your subscription fee, based on your usage.

I know what you're thinking. You think I'm reinventing GitHub Sponsors. I'm not, I'm bridging the idea behind it with NuGet feed. Ideally, this should be implemented by NuGet and become part of the ecosystem, but I don't know what their priorities are and what held them up this long. I also have to admit I haven't looked into Java world or other ecosystems to see if there's already a similar idea implemented or not.)

Enter SponsorFeed

Meet SponsorFeed: A subscription based NuGet-proxy feed for companies to support OSS developers, without compromising their security and their purchase model.

The idea is very straightforward: The OSS developers who already publish their packages to NuGet link both their package feed and Stripe account to SponsorFeed. The customers who want to support OSS but can’t donate directly purchase a monthly or yearly subscription from SponsorFeed and receive a private feed URL which is a proxy for the packages linked to SponsorFeed by their developers. Every month, based on the download statistics calculated by the platform, the amount is split across the linked packages and the money is deposited to the developers’ accounts, through their linked Stripe accounts.

From The Consumer / Subscriber Perspective

From consumers’ perspective, consider SponsorFeed like a donation-based SetApp. You buy the subscription for, let’s say $10, and you receive a private feed URL. You link that feed to all your developers’ machines, your CI builds, anywhere you want within your company or personal use. Let’s say you only used 4 packages that month through the feed, and the usage is like below:

• Package A: 100 times
• Package B: 30 times
• Package C: 60 times
• Package D: 10 times
• Total downloads: 200 times

Based on this monthly usage and your $10 monthly subscription fee, the developers or each receive the following amount at the end of the month:

• Package A: $5 (100 times download / 200 total)
• Package B: $1.5 (30 times download / 200 total)
• Package C: $3 (60 times download / 200 total)
• Package D: $0.5 (10 times download / 200 total)

SponsorFeed is a proxy for NuGet and compatible feeds; it doesn’t keep the packages on the platform, doesn’t alter them in any way. The feeds are also available through their origin NuGet store, so at any time you can cancel your subscription and revert to the original NuGet feed.

The Subscriber Portal would be straightforward: Current subscription and payment history, monthly breakdown of usage, payouts calculated per package based on your subscription fee.

For clients that would consume the packages, it wouldn’t change anything apart from the feed URL. If you make the SponsorFeed your primary feed, your client would try to resolve the packages from it first, then the NuGet feed if failed. This would ensure your donation goes to the developers.

From The Developer / Contributor Perspective

From the OSS developers’ perspective, it’s similar to GitHub Sponsors: You reference your package feed and link your Stripe account. At the end of the month, based on the usage of each subscriber and their fee, your payout is calculated and sent to your Stripe account.

The payout amount for each package is calculated per subscriber, not globally. The idea behind SponsorFeed is not to make it a competition and calculate a monthly leaderboard. It’s based on the usage of each subscriber. If a subscriber pays $10 and only downloads Package A through SponsorFeed, then the Stripe account of Package A receives the $10. If the subscriber downloads 100 packages through SponsorFeed in equal numbers, each package developer receives 10 cents.

The Developer Portal would be simple: A page to see your package registrations, then details on the daily, monthly, yearly statistics. Another page about payment methods, payout history, statistics, etc.

Benefits

As mentioned, SponsorFeed would act as a proxy feed between the NuGet Store and the subscriber. Its whole purpose is to calculate the payouts, nothing fancy or sinister. It wouldn’t modify the packages or wouldn’t store them anywhere, even for caching.

It would also not need to employ any package scanning or feed security, as it would only authenticate the subscriber key to calculate the usage.

I know that some companies use third-party tooling to cache the NuGet store and scan the packages individually for malicious content. That’s fine and compatible with SponsorFeed. Rather than using NuGet Store’s feed URL, you can use SponsorFeed’s URL.

Drawbacks

If the subscriber caches the packages in a company-wide store, that would mean the clients wouldn’t hit SponsorFeed again after the first hit. That could be a problem for developers who don’t release new packages frequently, or if the clients wouldn’t update packages frequently.

Gaps & Questions

• Although this sounds like a nice idea, I have to say I don’t know about anything about how donations and taxes work in each country, even the UK. My knowledge of taxes is limited to my own limited-company experience, so this idea may need some legal help.
• Should SponsorFeed only act as a proxy for developer-registered packages, or the entire NuGet feed?
• Would NuGet store employ any throttling to SponsorFeed?
• How would the taxes work?
• Would SponsorFeed need to be a non-profit company? How would that be managed?
• How would the fee be distributed if the subscriber doesn’t download any packages that month? Same as last month? Yearly average?

Closing Words

Remember, this is not something I already built. This is just an idea, to start some discussions in the right way. I don’t think the whole Moq and SponsorLink shenanigan was the correct way of implementing it, so I thought I should at least throw an idea into the arena, so it would be only fair.

What do you think? Feel free to reach out to me on Twitter/X using my handle @hylegoz to kick off the discussion.

.NET OSS ecosystem had a lot of drama, but I haven’t seen anything like what happened in Moq’s repo. And I participated in it. I normally don’t get into this type of discussion in the software world, but this was an awful implementation of a bad idea, followed by potential security concerns and an unauthorised email scraping from the user machines.

I’m not going to talk about what SponsorLink is in detail, you can check Daniel’s own explanation and Sean Killeen’s blog post. But briefly recapping: A NuGet package that automatically checks if you’re a GitHub Sponsor for the OSS library you’re using, and “nags” you to be one.

The original implementation of SponsorLink was very problematic; it was closed-source, and it included scraping the current user’s email, sending it to a third-party endpoint and storing it there. According to Daniel, it’s being reworked, and an offline operating model will be introduced. But it won’t change what SponsorLink is: A bad idea.

SponsorLink Rediscovered America, erm, Licensing

There are many ways to earn money from software. True, it’s not as rich as the new content creator economy, which Daniel is aiming for (and missing it by a great margin). And I understand people to earn money from their public efforts, especially when big corporate giants are benefitting from those same efforts like crazy. I really get that.

But like it or not, BSD-3 is a contracting agreement you’re entering with your users. You’re telling them, “you can use this for free”.

If you wanted to earn money from your effort, you would first start by creating your financial model around it. You could make a paid version of your free product. You could offer services, consultancy, training, etc. You could sell swag. Or, you could change the licence of your free library. Make it dual-licensed: Companies with over 1M$ income could pay for their licences. But no, Daniel didn’t want to do that. From his blog post on SponsorLink:

I don’t want to have to deal with setting up licenses on a server, provisioning test agents or whatever.

Then, he went ahead and implemented it thing anyway, just by piggybacking GitHub’s Sponsor infrastructure. Because he wanted the money, but not the hassle.

Don’t get confused, Moq is now a paid product. You just pay it with coffee, or your patience. The model of SponsorLink powered-libraries is now a paid-licensing model disguised as “FOSS”, and it’s called “Nagged Until Paid”.

The Concept Of “Nagged Until Paid” Is Passive-Aggressive

Moq was always a free software, as numerous others, released under the BSD-3 licence. You have the permission to use it, free of charge, either personally or commercially. As of today, that’s still the promise. You don’t need to pay or sponsor Daniel or any other contributor if you don’t want to.

But Daniel’s approach was to create build warnings to coerce you into paying by constantly nagging you and slowing your builds between 0 and 4 seconds. He says he’s planning to change it, but the promise of SponsorLink is the same: “Nag you until you pay”. By the way, I’m not using the term “nag” myself; it is something said by Daniel, openly, and like something to be proud of doing.

It isn’t. It is a very, VERY passive-aggressive form of communication, and he’s showing it down the throats of Moq users and asking other OSS contributors to do the same. SponsorLink is built onto the promise of guilt-shaming you because you didn’t tip $1 to the contributor. And it does it on your machine, on your codebase, within your IDE. Let me give an example of the situation with a metaphor, which I already used in Moq’s GH issue:

Imagine a musician, playing by the river. They are playing it for free, just with a tip box. You see them, stay for a few minutes, enjoy the music, maybe make an instagram story, then move on without tipping. Then you come back home, finding the musician sitting in your living room, butt-naked, asking you to pay, or they would follow you around the house. What would you do?

I understand that Daniel wanted to create a better and sustainable licensing for OSS developers, similar to a subscription model like Spotify (his own words from Twitter here and here). Does SponsorLink sound like a platform that would achieve that? He could build a platform like SetApp for developers to bring their tools under a shared subscription model that would be distributed between them. It could’ve worked as a NuGet proxy feed, for people to opt in and use. That would at least resemble Spotify in a sense.

But no. He decided to remind you that you didn’t tip, every time you play his song, even though it was freely given. He wanted to “nag” you.

See the problem?

As a big believer in automation, I certainly can say I’ve gone both ways on the spectrum: I’ve executed things manually, and I’ve automated the system so well, it had more code in the automation scripts than the app itself. Both have been dear mistakes. And I see that I’m not the only one making them.

Automation is a powerful tool, especially if you can achieve end-to-end automation on your software development pipeline. You get the requirement, and you develop the feature, then from the first commit you kick off a chain reaction until your feature ends up in the production system. In your automation, your code is built, tested and even deployed automatically. It’s no small treat to achieve that, and it’s admirable. But it’s also a hell to maintain that state.

In some teams, you’ll find a tendency to over-automate everything. Literally, every single thing. Occasionally, they would spend more time on automation than delivering features. They may even automate their automation processes (once, I saw someone generating deployment scripts and executing them within the same deployment pipeline).

These teams may receive a bug in production, which would require them to run a script to fix some data. But those automation zealots in them would take that script, and put that behind an admin page, an API, or a command-line tool that can be called if needed again.

The problem is, you’ll be spending so much time making that automation, you’ll be losing the value of doing it. There’s even a xkcd cartoon on the topic called “Is it worth the time?”:

Keep in mind that this chart is over a five-year period, not a single year. So, when it says, “if you’re spending 1 hour every day on a task, you would save 2 months by automating it”, it’s over 5 years. You would only save 12 days a year.

Before you jump the gun and make up your mind, you need to remember that time saving is not the only benefit of automation:

• There’s the cost of training when a new team member joins and adapts to that mundane task.
• There’s the cost of human error while doing that task.
• A manual process can also bring down the team’s morale over time.

All of these should be taken into consideration when choosing to automate or not.

Now, make a calculated decision: Is it really worth spending time to automate that mundane task? How much real pain this manual process causes us? What else can we benefit from, besides the saved time & cost? What are the downsides?

I saw two separate tweets today that were examples of the same issue in software these days: Choosing the solution first, then retrofitting the problem to it.

We’ll go over both examples now. Buckle up.

Choosing Kubernetes Because Everyone Else Does

Kubernetes solves a very specific problem in a very specific way: You want to add a separate abstraction on top of the servers to orchestrate your containerised apps. Rather than maintaining their servers, the devs maintain their container images. It solves the complexity of shipping software by adding another complexity: The abstracted infrastructure. The need to maintain an infrastructure doesn’t go away, it just draws a curtain between the apps and the infra. You still have to maintain the infrastructure, now you have to maintain the Kubernetes cluster as well.

If your app isn’t big and complicated enough to warrant that complexity, or you don’t have the resources to maintain a cluster, you’re in trouble. You’ve just added another layer that needs maintaining without solving your problem.

If your app can live on serverless and doesn’t have a vendor limitation or a specific cluster requirement, why bother? Most cloud vendors allow you to run a containerised app without Kubernetes (e.g. Azure App Service can run containerised web apps and API apps). Or if you don’t even need a container because your app is so small, why not run it on AWS Lambda or Azure Functions? Why not take on the cost of moving to somewhere specific one day, instead of the cost of possibly moving anywhere?

Choose a solution that would fit your problem. If you don’t have multiple teams working on your CRUD-based app, go with a monolith. Take on the cost of conflicting changes over the cost of over-architecture. Pick real value over a virtual one.

Over-complicating Your Solution From The Get-Go

The Clean & Onion Architecture models are great, but there’s nothing new there. For many years, a lot of the apps were haunted by the “Three-Tier Architecture” and created one-liner service Facade layers over Repositories to serve the API or UI layers. It’s the same shit all over again: Defining your layers before defining your problem will only cause you more problems.

Any new layer of abstraction is a layer that needs to be maintained. SOLID means nothing if you also don’t implement KISS (Keep It Stupid-Simple). You don’t need to make everything extendable for the sake of complying with the Open-Closed Principle.

Let your application requirements drive the layers. If your requirements are complicated enough to use the Clean Architecture, by all means, use it. But don't start with it just because "you may need those layers someday". Your guide is your requirement list, not your architecture.

I like the tweet below from David Whitney (@david_whitney):

The complexity of your software should be less than the complexity of your problem space, and never greater.
If it is? You caused more problems than you solved.

Conclusion

There’s a reason we have a list of Anti-Patterns. Choosing a predefined solution before understanding the problem is the perfect definition of the Golden Hammer. There’s a saying in Turkish: Don’t order pants for your unborn baby.

Remember: Your job is to solve problems, not cause them. Be mindful that your actions can also contribute to the problems, even though your intentions aren’t to do so.

Truth be told, I’ve never been a fan of Google Analytics. Or any analytics tool, for that matter. For me, other than seeing how many people have visited my website and where, I don’t see the value of it for my blog. For other projects, it’s complicated. I see the value up to a point, but the means of achieving that value is making me uncomfortable.

Anyway, I’ve always used multiple content blockers and also deployed a Pi-Hole to my home network to reduce ads, so I wasn’t happy to use GA just to keep track of some visitor numbers. I’m not interested in knowing what are my audience’s interests are, where they come from, who they are, etc. but GA collects this information even if I don’t want it to. It was hypocritical of me to disable tracking on my browsers (so even my website couldn’t track me) but asked my website to track people.

So I ditched it. I now host my own Matomo instance, and it’s set to be cookie-less. It also has anonymisation enabled, so I don’t collect any personal information or share it with a gigantic company that lives in a grey area. I also got to remove my cookie banner, which was a massive win for me. Which idiot thought it was a good idea anyway? (And which idiot thought to legalise it?)

So, no PII, no cookies. I only see visitor numbers, which may be a bit off, but I can live with it. You are welcome to check my Privacy Policy.

Be the change you want to see in the world.

UPDATE 21/06/2023: Scratch that, I'm using Plausible Analytics. I self-hosted Plausible, which keeps no cookies, records no IP addresses or any other personal data about the visitors. It works better than Matomo for this purpose, and I've also updated my Privacy Policy reflecting the tool.

For the sake of transparency, here's what I see on Plausible:

I liked Plausible Analytics so much that I may actually write a separate post about it.

There seems to be a popular desire to use Microservices to build anything and everything. While Microservices are great and scalable solutions, they address a very specific requirement: A need to decouple teams and solutions from each other when build a loosely-coupled polyglot environment whilst keeping things cohesive. You use it when you have multiple teams are working on a single and complicated product environment, and you want to keep each team in charge of autonomous product features. Yes, it’s a broad solution style that can be applied to anything, but let me remind you one of the golden rules of life: Just because you can, doesn’t mean you should.

Anything you can solve with Microservices can also be solved in some other way. What should have you lean towards it is the need to scale the dev teams. It’s a specific organisational requirement as part of non-functional requirements. This particular requirement should drive you to have independent teams that work together to create a cohesive product whilst keeping their products (or same product’s parts) separate. Each team should have the ability to build and ship their own features and manage their own product backlog, whilst work in tandem and make sure their products/features are integrated well enough to create a cohesive big picture.

If you’re choosing Microservices without having this particular requirement, I have bad news for you: You’re making a mistake. It’s difficult to maintain a Microservices environment and it’s damn difficult to develop in one. Oh, it’s fancy, I’ll give you that. It’s a white whale that everyone chases, just to build something with it at least once in their career. But because that’s not the requirement, you’ll be doing it the wrong way. You’ll be choosing the solution first and then will try to retrofit the requirements to make it work. That will certainly hurt everyone, especially your business.

A Microservices app that’s messaging based can be done with a single app that subscribes to multiple queues. You can scale it very well, too. API based Microservices can also be done with a few good API apps with an API Management layer in front of it. You won’t need containers, Kubernetes, or sidecars to build any of it. You don’t need to use Event Sourcing, Materialised Views, or CQRS to start building something. Believe me, the majority of the effort you’ll be spending will go to keeping the system upright instead of adding new features to it.

That’s because distributed systems, especially the ones that doesn’t need to be distributed, require a lot of manpower to maintain. If you don’t have the resources maintain one, stay away from Microservices.

Last week, I challenged myself to get four Azure certifications (Administrator, Security, Developer and DevOps Expert). I got my only certificate, Azure Solutions Architect Expert, last July, so [I wanted to get a few others]({% post_url Software/2020/2020-04-11-my-azure-exam-marathon %}) while being locked up because of COVID-19 stuff.

And I did it, I got all four of them. It's been quite a challenge, studying while working and under lockdown, the mental strength can stretch a bit. But thanks to my previous role at M&G Investments, I have learned a lot on many Azure resources. We were the team that would find out the best technologies available on Azure for a specific task or project, and then deep dive into it, make it operational and train the development teams. It worked quite well and although having a spearhead team like this is a luxury, it pays off.

Anyways, the certification exams weren't that difficult. Microsoft has been criticised about the quality of their exams, and these actually didn't feel like they were testing me on how good I can can do something. They were testing if I know how to do it. They're not the best way to evaluate someone's capabilities, but they're what we have at the moment. Sometimes you get a lab or two, which didn't come up with these exams. I'm not sure if these exams didn't have it before or the rumour going around (Microsoft cutting back on labs because of Azure resource usage peaks since COVID-19) took part in it.

Will try to write briefly on each exam (preferably without comprimising the NDAs I signed) and what would be best way to prepare them, in a few days.

There're many applications I pay for regularly, especially since I started using a Macbook Pro. The big ones are Office 365 and McAfee, but there are many small ones as well. But none of them make me feel being milked like Parallels Desktop does (apart from Apple).

I mean, I get it, as a software guy I like the versioning system. In a specific version, you make certain promises under certain conditions, like Parallels does in each version: Let you run VMs in your MacOS. It has many nice features and once you pay for a version, you own it, you can continue to use it. Or at least, you should be able to use it.

I haven't opened up my Windows VM for some time now and I thought it would be good to let it boot up and have it's rush of updates. It did, apparently there are many updates and versions I missed. Once the turmoil went calm, I tried a few things on the machine, since I know each version of Windows can affect Parallels' performance and it needs to be tested. I was right: When I used it in full screen instead of Coherence, this was the result:

What the hell? This only happens when it's full screen and it's using Radeon discrete GPU. Travel mode, which forces Parallels to use Intel video adapter, is fine apparently. But the moment I plug my laptop's power cord in, things go crazy. Crazy, right?

Guess what's the solution that Parallels give: Parallels Desktop 13 (the version I had) doesn't support MacOS Catalina, so you have to upgrade to Parallels Desktop 15. And guess what (again)? It worked! Even without the Parallels Tools update in the VM! The moment the VM was booted, it worked. How convenient.

Now, again, I get it. It's a huge thing to do, supporting both Windows' and MacOS' weird and constantly changing features. But honestly, why each Parallels version is locked to MacOS? Can't you support at least 2-3 versions of MacOS with each Parallels version? So, if Apple to say, and by say I mean force you, to upgrade year (which is free), why do I have to pay £39 each year to Parallels? Is it that hard to do it? From a developer to developers, come on! Being on an Apple platform, we're used to be milked. But if every company does that, we'll be just using vending machines, not computers.

But I pay it, I have to pay it, because I'm a Visual Studio and a Macbook Pro user, and my work depends on it. In order to continue my work seamlessly, Parallels Desktop is the best tool that I can use. I've tried others, including VirtualBox and VMWare Fusion, but none of them can match the performance of Parallels Desktop. And I don't want to boot my machine into Windows every time with bootcamp.

But still, we pay to own these softwares, right? Parallels Desktop doesn't have a subscription model, so it should at least work on my machine for a couple of years, until I need more features and I feel the need to upgrade. It should be up to us, not the provider, to decide when. Even though it's a great tool, it still feels wrong.

Don't even get me started on the subscription model, that's another and a wider discussion.

Looks like I've discovered it halfway through, but Microsoft has been creating some quality content for almost six months. They've been having webinar sessions on various perks of Azure AD, such as Multi Factor Authentication (MFA), Conditional Access, Hybrid Identity, etc. They also keep the recordings on YouTube and also provide the presentations, so they're easy to find on their website. Here's the list of recordings they've done so far:

• Getting started with hybrid identity - Youtube - Presentation
• Integrating your applications with Azure Active Directory - Youtube - Presentation
• Take your apps to the next level with provisioning - Youtube - Presentation
• Upgrade your security with multi-factor authentication - Youtube - Presentation
• Starting your journey to Zero Trust with Conditional Access & Identity Protection - YouTube - Presentation
• Empower your users with better IT scalability - Youtube - Presentation

They'll pick up the recordings from March 5th, with many more to go. Make sure you check out their website for registration links:

• March 5, 2020: Your journey to passwordless
• March 12, 2020: Manage Partner Access with B2B
• March 19, 2020: Enable New Customer Experiences with B2C
• April 2, 2020: Identity Governance for Modern Organizations
• April 9, 2020: Getting started with Azure AD Reporting and Insights
• April 16, 2020: Azure AD as the New Security Control Plane

Don't forget to check out Azure section under Microsoft Tech Community; it's no Stack Overflow but some good questions and answers are in there.

As I posted that I took on certification challenge and I have passed my first exam, I also passed the second exam (AZ-301) and I'm now a Microsoft Certified: Azure Solutions Architect Expert!

Exams are particularly difficult for someone with a developer background. Even though I'm more focused on PaaS and SaaS components these days (like most people), the exams mostly cover IaaS components such as VNETs and VMs, including the disaster recovery scenarios with Azure Site Recovery. They also include a lot of Hybrid-Cloud scenarios, again with Azure Site Recovery. Long story short, most questions come from Azure Site Recovery (sigh). I understand the point; as an architect, you need to be confident around network and security components, but I believe it covers a tad too much of the exams.

Another area that exam heavily tests you is Azure Active Directory and its synchronisation scenarios. Especially with Azure AD Connect and how to use it with Hybrid-Cloud requirements, such as multi-national corporations with multiple regions as well as multiple on-premise sites. Again, as a developer, we mostly focus on how to use AD rather than design it, so it requires a bit of first-hand knowledge there.

However, it is manageable and achievable, and I'm happy to prove to myself that I'm capable of covering those scenarios, which mostly was in my blind spots. I hope to encounter many more different use cases!