Agile, Architecture, Azure, Cloud, technology

Becoming a Cloud Architect, Part 1 – Starting a project

Introduction In this series of posts we are going to deep dive into a real world scenario of a cloud solution from...

Written by Freddy Ayala · 4 min read >


In this series of posts we are going to deep dive into a real world scenario of a cloud solution from design to deployment, the objective is to show you the entire life cycle of a web application deployed on Azure.

Before moving forward I would like to define the word “Solution” that we tend to use very often in the industry, first of all a Solution is not the same as a system, web application or infrastructure. As it it name says, a Solution is the answer to a problem.

Let’s take a simple example in order to understand: Our problem is that we need to hang a painting on the wall. So we can come up with several actions to solve our problem such as:

  • Using a hammer and a nail
  • Glue the painting to the wall
  • Use a drill to drill a hole into the wall and a screw
  • And many others

So we have different “solutions” to a problem that use different set of tools (hammer, ram-plug, drill, glue, and so on). Which one we use depends on our budget, the requirements and our common sense and experience.

Coming back to our subject at hand, a “Solution” in the cloud area is the use of different resources and tools provided by a cloud provider in orders to solve a business case. Therefore, if our use case is to deploy a web application the solution would not only include the web application itself but all the other components as well such as the security, storage accounts, networking, certificates, web servers and so on.


Moving forward, as in any project it all starts with a business case or requirement, for our use case we are going to define the following actors that are going to intervene in the project:

  • Client
    • The final client, the one that has the problem and request the solution.
  • Product Owner
    • Functional Expert, he or she is the person in charge of understanding the use case of the client and to describe it in functional terms using common industry methodologies as tools such as a backlog and user stories.
  • Cloud Architect
    • Technical Expert is the person in charge of transforming the business requirement into a technical solution.
    • The cloud candidate is a hands on expert that is not only capable of designing the architecture of the solution but also to build and deploy it.
    • Long gone are the days of the “Ivory Tower” architects, nowadays they must be hands-on.

Business Requirement

The client has a very basic requirement:

Deploy a blog platform using Azure.

As most of the time only a problem statement is not enough, thus the product owner and the cloud architect have to go into more details and ask more questions in order to understand the problem better, thus they ask many questions in order to gather the requirements in two big groups:

  • Functional Requirements
    • Are all the requirements that are going to be exposed directly to the end user, we call the Functionalities, and example of functionality would be to add a red button into a page that will display a popup when cleaned.
    • This is responsibility of the product owner.
    • Questions
      • How to site would look like?
      • What is the behavior of the site?
      • Who will use the site?
      • How will they use it?
  • Non Functional Requirements
    • All the requirements that are related to quality of service (scalability), frameworks or security, which the user doesn’t necessary interact directly with them, we call them sometime “Capabilities”.
    • An example would be to encrypt all communications with a certificate.
    • This is the responsibility of the cloud architect or technical expert.
    • Questions
      • What is the nature of the data in the site? is it confidential?
      • How many users will use the site? is this number going to increase considerably in the near future?
      • Where the data is going to be stored?

The objective of gathering all these requirements is to create what we called a Backlog, which is basically a TODO list that shows all the tasks that are to be done according to a priority defined by the product owner and the client.

Backlogs for portfolios, priority, & multi-team ownership - Azure Boards |  Microsoft Docs
An example of backlog in Azure DevOps that uses a hierarchical structure using Epics, Features, User Stories and Tasks.

So after discussing with the client, the product owner creates the following backlog:

  • [EPIC] MVP0
    • [Feature] Authentication/Login
      • There should be the possibility for the users to login into the blog platform.
    • [Feature] Admin Page
      • The administrator user should have the possibility to login into an admin page to manage the blog platform
    • [Feature] Blog Posts
      • Blog authors should be able to post blogs using a visual WYSIWYG editor.
    • [Feature] Template
      • The platform should be able to use an existing template to reduce development time.
    • [Feature] Plugins
      • The platform should be extensible using plugins to add more functionality when needed.
    • [Capability] Security
      • The page should be accessible only using an HTTPS TLS Certificate.
    • [Capability] Database
      • All the data from the blog should be stored in an open source database to reduce costs.
    • [Capability] Web Server
      • The web server should be easy to deploy and manage, we should give priority to PaaS or CaaS instead of IaaS
      • Autoscaling when needed if we reach a certain user quantity.
    • [Capability] Deployment/Operations
      • Backups should be automatic.
      • Easy to restore.
      • Backups for the site, content and database.
      • Easy to deploy and manage the infrastructure.

As the backlog has been defined with all the requirements of the client (that are supposed to be updated and change as the project advances) the cloud architect defines a technical solution:


The cloud architect proposed the following solution:

  • To respond to all functional requirements, the WordPress platform is proposed which is capable of using templates for the layout of the site, use plugins to extend the functionalities and easy to manage using an admin panel.
  • For the database, the use of a managed service MySQL that requires no maintenance of the infrastructure.
  • Similarly for the Web server, an Azure App Service it is proposed that has autoscaling, manages automatically the backups of the web application and the database and can use a custom domain with TLS certificates.
  • App Service will be used in PaaS mode, there is no need to use containers since we can directly run our Php code.
  • A custom domain and TLS certificate will be bought using the service namecheap and configured inside the app service.


Together with this proposition the Cloud Architect also uses the Azure Calculator in order to calculate a budget to propose to the client, so a Cloud Architect is not only responsible of designing and deploying the solution but also to propose a solution that correspond to the budget and constraints of the client.

In total the monthly budget will be of 93.52 Euros, taking into account that we will use a Standard Tier for App Service that includes the backup and custom domains features.

The cloud architect also will provide the client an estimation of time of each item in the backlog, he has proposed of 4 iterations of one week each.


This is a technical decision that the cloud architect should analyse, and there are the following options:

  • Use the portal to deploy everything manually
  • Use ARM Templates
  • Use Terraform

The cloud architect will use terraform to build and deploy the infrastructure.

Client Validation

So once the technical solution has been designed, the budget calculated and the backlog filled then it is time to present it to the client and get their validation.

With the go of the client the next phase of the project will begin.

Project Planing

The cloud architect, the product owner and the client agree that the project will be deployed in several iterations accordin to the following plan:

  • Iteration 0: Inception
    • The current phase of the project used to analyse, define and budget the solution.
  • Iteration 1: Build
    • Initial build of the project where the basic resource will be deployed such as the App Service and the Database.
  • Iteration 2: Security and Operation
    • Security services and backup will be tested and deployed.
  • Iteration 3: Testing
    • Deployment of WordPress components.
  • Iteration 4: Production
    • Put the site in production and open to the public.


With the backlog, project planning, architecture and GO from the client, the Cloud Architect is ready to begin the build phase of the project, so in the next articles we will follow the next phase of the project that is to deploy the current infrastructure using terraform.

2 Replies to “Becoming a Cloud Architect, Part 1 – Starting a project”

  1. I was wondering if you ever considered changing the
    page layout of your blog? Its very well written; I love what youve got to say.
    But maybe you could a little more in the way of content
    so people could connect with it better. Youve got an awful lot of text for only having 1
    or 2 pictures. Maybe you could space it out better?

Leave a Reply

Your email address will not be published.