Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction and Overview

Cloud Computing and Modern Software Development

Moderns software development methodologies like Agile, Scrum etc. have relied heavily on the shift towards on demand based cloud based computing (LEAD INNOVATIONZ, 2025).

These approaches leverage automation using CI/CD pipelines to enable rapid prototyping, innovation at scale and offer a commercial flexibility lacking in purely on-prem deployments (Surya S, 2023).

Containerisation and Serverless are the epitome of this approach where application running costs can be directly linked to business revenue and even API requests in the case of serverless. (REF:)

The move from multi-week on-prem deployments to a service model can be summed up in the phrase “cattle, not pets” as described by the DevOps movement (Hava, 2020). Resources become ephemeral and disposable.

Infrastructure automation tools like Terraform, Bicep (Azure), Cloudfront (AWS) enable the flexibility to stand services up, turn them off and then rebuild them at the touch of a button.

Move Fast and (Don’t) Break Things

Mark Zuckerberg announced in 2014 that Meta’s internal motto would change from “Move fast and break things” to “Move fast with stable infrastructure” (Wikipedia, 2023). The era of “Move Fast and Break Things” is over both technically and culturally (Taneja, 2019). End user demand and expectation of a reliable, consistent online experience is now absolute following people’s interactions with the internet over the last 20+ years (John, 2026)

Empowering dozens of engineering teams to make daily changes across different applications and repositories requires automation to support test environments, deployment pipelines and visibility of changes over time.

Having an at-a-glance way to see what’s been deployed when and where allows software delivery managers, team leads and business leaders to surface the rolling changes that now make up process of modern software development. TODO: (REF: CI/CD what it means and why it’s an indicator of a successfull or high performing team)

Batteries Included via IaC automation

This automation - infrastructure as code (IaC) - is now the enabling layer to having a robust, scalable, monitorable and disaster resistant solution (about.gitlab.com, 2026)

It defines everything from hub/spoke networking, firewalls, traffic to/from the environment, secure access, monitoring, security, alerts, user groups and roles defining who can do what inside a particular cloud.

What’s going on?

With all this fast moving software development happening it’s challenging for various stake holders to understand where a particular program or service has reached in its deployment cycle.

Each stakeholder group has their own particular view and context:

Developers & Testers

  • What application versions are deployed?
  • Are all environments (dev/test/production) on the same release?
  • Where a new version is in the pre-deployment test cycle

Project & Release Managers

  • What versions are likely to be coming next?
  • Are there items that need resolving or are holding up progress?
  • Is there any sort of release pipeline holdup

Support

  • When was the last release/change made?
  • What was in it that might impact users or their experience?

Business Owners

  • Is version ‘x’ with feature ‘y’ released yet?
  • How many sprints left till a particular feature is released?
  • Where in the feature delivery pipeline is a particula application?
  • Development/Testing/Live

While Azure DevOps provides an individual ‘per-project’ view there’s no single place where this sort of information can be surfaced across an organisation

(REF: developing in silos, business management, expectation management)

Solution Overview

A cloud-based delivery visibility site provides a single, organisation-wide view of application and infrastructure status, connecting code changes to deployment outcomes across environments.

It aligns with the software development lifecycle by supporting planning, build, test, release, and live monitoring.

Design Cloud Based Tool

Requirements Gathering

Functional Requirements

Functional requirements define what the cloud-based delivery visibility tool must do to meet stakeholder needs.

  • Aggregate delivery and release data from multiple Azure DevOps projects into a single organisation-wide view.
  • Show deployment status by environment (development, test, production) for each application or service.
  • Display a timeline of recent releases with version number, deployment time, and impacted services.
  • Support search and filtering by project, application, service, environment, release version, and status.

Non-Functional Requirements

Non-functional requirements define how well the tool must perform in terms of quality, reliability, and operational fit.

  • Availability: The platform should achieve at least 99.9% monthly uptime.
  • Performance: Dashboard and reporting pages should load in under 2 seconds at the 95th percentile under normal load.
  • Data freshness: Pipeline and deployment updates should be reflected within 5 minutes of source-system change.
  • Scalability: The solution should support growth to at least 200 services and 1,000 daily pipeline events without major redesign.
  • Reliability: Ingestion and processing should recover automatically from transient failures using retry and dead-letter handling.
  • Security: Access should use enterprise identity, role-based access control, and encryption in transit and at rest.
  • Maintainability: Infrastructure and deployment should be managed via IaC and CI/CD to reduce manual effort.
  • Usability: Core stakeholder tasks should be completed in three clicks or fewer.

Security Requirements

Non-staff members should have absolutely no access to the dashboard at all. It should only be accessible to members of a particular security group via 2 Factor Authentication (2FA) and enrolment into the group should be managed via the security team following the creation of a support ticket with line manager approval.

While the URL could exist publically there should be absolutely no access without having to sign on first. Sign ons should also be logged and monitored as well as restricted to UK logins only.

Solution Design

TODO: Explain what a function app is TODO: Add references (Microsoft docs)

The design uses an event-driven Azure architecture so pipeline outcomes are captured in near real time and exposed through a secure, lightweight dashboard API.

flowchart LR
    subgraph UK[UK Region Boundary]
        ADO[Azure DevOps Pipeline]
        Q[Azure Queue Storage<br/>Pipeline Result Events]
        ING[Azure Function<br/>Event Ingestion]
        DB[(Azure Table Storage<br/>NoSQL)]
        API[Azure Function App<br/>Backend API]
        AI[Application Insights<br/>Access and Telemetry Logs]
        CA[Entra ID Conditional Access<br/>UK geo-restriction + MFA]
        SG[Entra ID Security Group<br/>Authorised Staff Only]

        ADO -->|Post result events| Q
        Q -->|Queue trigger| ING
        ING -->|Upsert release status| DB
        API -->|Read dashboard data| DB
        API -->|Send logs and metrics| AI
        CA -->|Policy enforcement| API
        SG -->|Group-based authorisation| API
    end

    U[Internal User] -->|Sign in via Entra ID| CA
    U -->|Access Function App URL| API

In this model, Azure DevOps emits pipeline outcomes to a queue, an ingestion function normalises and stores the records in a simple NoSQL store (Azure Table Storage), and a separate Function App serves the dashboard backend. Access to the Function App is restricted to members of a specific Entra ID security group, with MFA and UK-only conditional access policies enforced before requests are accepted. Application Insights captures authentication, request, and operational telemetry for audit and support.

Alternative Storage and Platform Options

Azure Table Storage is the baseline because it is low cost, simple, and well suited to key-value release events. Viable alternatives are:

  • Azure Cosmos DB: Prefer when low-latency global scale or richer querying is required; trade-off is higher cost.
  • Azure SQL Database: Prefer when relational joins and structured reporting are central; trade-off is tighter schema and more administration.
  • Azure Data Explorer/Log Analytics: Prefer for large-scale time-series and operational analytics; trade-off is less suitability for transactional API reads.
  • Blob Storage (parquet/json): Best for low-cost archive/history; trade-off is not suitable as the live dashboard store.

Additional platform substitutions:

  • Azure Service Bus instead of Queue Storage for ordered processing and advanced messaging controls.
  • Container Apps/AKS instead of Functions for long-running workloads or stricter container portability.
  • API Management in front of the Function App for throttling, versioning, and consumer governance.

Networking Considerations

The networking design must balance UK residency, secure access, and low-latency event flow.

  • UK data boundary: Place queue, functions, storage, and telemetry in UK regions to meet residency requirements.
  • Secure ingress: Enforce Entra sign-in, MFA, and UK-only Conditional Access before Function App access is granted.
    • Conditional Access rules could also be extended to device level if necessary
  • Private service paths: Use private endpoints and VNet integration for storage/telemetry to minimise public exposure. TODO: Read up more about this
  • Controlled egress: Restrict outbound calls to approved Azure DevOps and Azure platform endpoints.
    • This site is ‘read only’ so in fact no outbound calls should be possible.
  • Performance and resilience: Keep ingestion and storage co-located and use retry/dead-letter plus geo-redundant storage where recovery objectives require it.
  • Network observability: Track dependency latency, throttling, and failed calls in Application Insights.
    • Add alarms for failed calls and health checking

Develop Cloud Based Tool

IMPORTANT: REFER BACK TO THE FUNCTIONAL, NON-FUNCTIONAL and SECURITY requirements

Development Workflow

Use Azure DevOps to capture all the tasks, split these into sprints, create milestones and report against those. Architectural design docs and so forth get published in the Azure DevOps wiki

TODO: add a Gantt chart here?

TODO: Everything uses IaC - WHY?! (do we even have to explain this? It’s 2026)

Challenges encountered

Publishing events

Publishing from a pipeline run to an accessible but secure endpoint

Event Design

No-SQL dashboard design

Azure DevOps security

Who can publish what to where? Is sending a CURL event from a pipeline even a good idea?

Azure Function and Function App debugging

Testing Methodology

In order to meet the non-functional requirements (speed, security) etc. a tester was assigned to the project TODO: research testing methodologies - perf, resource utilization, COSTS - not just security.

Is scalability an issue? Azure functions/function apps are inherantly scalable.

Resilience and recovery from failure

TODO: come up with a better title for this section.

Alternative architectures

Containers

Work is only going to be carried out on a per-change basis and with containers there’s actually ‘too much’ network/infra overhead to justify this. We’d need a queue anyway so… might as well go full serverless…

Hosted Server

Let’s not host a website - that’s so 2010’s now (Function Apps FTW!!)

Conclusion and Recommendations

TODO: Highlight how this sort of observability and visibility is going to become even more important as AI enables the INCREASE in deployment speed, change rate increases and so on <– come up with a better way to describe this

ROI

Ongoing cost is very low ROI in terms of time saved is very high

  • come up with meetings saved in status updates
  • executives time is valuable so anything that saves this matters

Further enhancements and reliability

Attach an MCP server to the database backend so people can ask natural language questions about project progress

Improve/expand the record schema to include more things - especially related to DORA metrics - refer back to these again

Observability and Monitoring improvements possibly? What new things can be done with App Insights? Or do we just lob all the data/events into App Insights and use THAT for reporting even? Possibly less integration work and the framework/endpoint is already there!!

Summary

This cloud-based tool delivers a secure dashboard that shows application releases and deployment status across the organisation.

It uses an event-driven architecture that posts Azure DevOps pipeline status messages which are picked up by Azure functions and stored in a NoSQL backend. The function app uses this backend as the basis for the dashboard which is only accessible via Entra ID access using 2FA.

Application insights monitoring, especially around user logins, complete the security protecting this sensitive data.

By making this information widely accessible across the organisation a high ROI is achieved by reducing status reporting meetings, cross team calls, faster triage of release based issues while running on low cost serverless and managed cloud resources.

References

about.gitlab.com. (2026). 4 Benefits of CI/CD. [online] Available at: https://about.gitlab.com/blog/positive-outcomes-ci-cd/ [Accessed 10 May 2026].

‌Hava, T. (2020). Cattle vs Pets - DevOps Explained. [online] Hava.io. Available at: https://www.hava.io/blog/cattle-vs-pets-devops-explained [Accessed 3 May 2026].

John (2026). What Users Expect From Online Platforms in 2026. [online] TechJihad. Available at: https://techjihad.com/what-users-expect-from-online-platforms-in-2026/ [Accessed 10 May 2026].

LEAD INNOVATIONZ (2025). Introduction Cloud computing has redefined the way businesses develop, deploy, and manage software. No longer constrained by physical infrastructure, organizations now leverage the cloud to drive innovation, boost efficiency, and scale at unprecedented speed. [online] Linkedin.com. Available at: https://www.linkedin.com/pulse/how-cloud-computing-transforming-modern-software-engineering-5vjyc [Accessed 3 May 2026].

‌Surya S (2023). History Of How Deployment Used to work & How Containerization revolutionized IT. [online] Medium. Available at: https://medium.com/@suryasaravanan2002/history-of-how-deployment-used-to-work-how-containerization-revolutionized-it-da785f4573ca [Accessed 3 May 2026].

Taneja, H. (2019). The Era of ‘Move Fast and Break Things’ Is Over. [online] Harvard Business Review. Available at: https://hbr.org/2019/01/the-era-of-move-fast-and-break-things-is-over [Accessed 2 May 2026].

Wikipedia. (2023). Meta Platforms. [online] Available at: https://en.wikipedia.org/wiki/Meta_Platforms#History [Accessed 10 May 2026].

‌

Appendix

Module 6 Project Brief Criticism

The phrase “cloud-based tool” creates unnecessary ambiguity.

In practice, the brief appears to ask for a cloud-based solution involving architecture, networking, security, deployment, and DevOps practices.

However, “tool” implies a smaller standalone utility, which makes it difficult to judge the intended scope of the project. Using terminology such as “cloud-based solution” or “cloud workload” would make the expectations clearer.