If you are not convinced about a cloud architecture, prove it by making it!

Or as an Azure Architect, how to be confident before deploying your architecture.

As an Azure architect, we are asked to design technical solutions responding functional requirements (obviously) and very often, we have to work with an existing infrastructure of the company (I am thinking of an existing hub and spoke connectivity or landing zones).

Ok but what is the point?

I want to share with you some good principles that guide me every time I am asked to do so in a project. When I started with this role, a good fellow worker (an experienced architect) told me:

“When you present an architecture, you must be convinced that it will work and if you have a doubt: prove it by testing it”.

It seems straightforward but it´s tremendously true: you must be comfortable when comes the time to present your diagram to the client and the team, writing the technical documentation and don’t be afraid the day of the first deployment!

Well, ok… how can I do?

Here is some advice that works from me:

• Deploy and configure manually real components and services

• Be auto critic to yourself

• Keep it simple (KISS principle)

• 
  

Deploy and configure manually real components and services

This is by far the better advice.

Indeed, I always create and configure real services and components on the Azure portal manually. It´s not necessary to deploy using Bicep or Terraform because this part is a consequence of your architecture. In other words, you are not testing the IaC but the architecture itself.

Open Visio or PowerPoint, put all the icons (PAAS services, connectivity and configuration components, resource group…) that tell the story about the architecture you are designing.

Once done, create a real POC of this architecture and try to deploy a simple hello world or better, your application with the simplest way: you may find surprises (unpleasant surprises at the beginning for sure) and with this, you can use what you find to put more details on your technical documentation.

If it works: you are more confident and now can engage the discussion.

For example, we wanted to deploy an Azure Container App using an Azure Container Environment with workload profile (not the consumption profile) with private access connectivity. An Azure Front door was planned for having public connectivity. However, this is not working because you cannot reach the internal Load balancer from the Azure Front door and there is no private link that can work. After several hours, we decided to change to the consumption profile for the Azure Container Environment.

Remember: in the cloud everything is changing so fast, the reality of today may not be the same as tomorrow with all the updates that happen continuously.

Be auto critic to yourself

Ok so everything is working. But wait a minute: are you sure that you haven’t forgotten something? Have you covered every business and technical requirement?

Mmmuummm, I think you don´t, so just wait a minute and think about it.

Believe me, asking you the rights questions, remember the meetings with the team or read the documentation will give you some doubts: and it´s good!

For example, ask yourself those questions:

• Have I considered all aspects of network security?

• How about disaster recovery and scalability? How is the RTO and the RPO (or have I already discussed those topics with the client?)

• How about the deployment of my application and my infrastructure?

  
  

You may have a look at the Well Architecture Framework (WAF) and the five pillars: you must find out points that you cannot escape and must consider.

Keep it simple (Kiss principle)

I often see colleagues trying to complexity things when it´s not necessary (from my point of view of course).

The KISS principle always drives me to see the difference between “needs” and “wants”. Always ask the stakeholder to dig into their mind and understand what is behind.

In other words, ask yourself: “this is really necessary to have that service or that SKU?”. I am not saying that the architecture must be like a simple sandbox, but it can save time and effort in the future.

To differentiate that, you have to ask, repeatedly, in order to dig into their minds and differentiate a simple “want” with real “needs”.

For instance, the client wanted global connectivity for his website but during the discussion, you find out that 95 % of the end's users come from a single country. So, it´s not mandatory to have Azure front door but you can plan classical Azure App Services in this particular region.

Conclusion

I hope that it helps you and do not hesitate to leave a comment, put your feedback and tips about your personal experience!