Cloud, releases and operations: hands-on experience with Azure and AWS.

Platforms with restricted production access

In projects with strict security requirements, a dedicated team manages production.

When I cannot access the production environment or databases directly, logs and monitoring tools are essential for spotting anomalies and tracing their causes. This calls for careful logging and traceability from the development stage onwards.

When something goes wrong in production

In a system with restricted access, many options are closed: you cannot go into the database, apply a quick fix, or add a log line to see more. So I start from the whole path of the request and use the monitoring of each component to work out whether the problem lies in the code or in an overloaded component that needs resizing. In complex systems these anomalous cases are often not covered by the requirements, and the other components may interpret the responses they receive in misleading ways.

Once the area is narrowed down, I analyse the component. Only software components allow the logging to be adapted, and often that is not necessary. If the problem is in the program, the logs have to be enough: I check that they contain the necessary information and that their structure makes it possible to follow the flow that led to the error, because a single event among hundreds of others does not show it. Where they are not enough, the improvement has to be planned in advance: in these environments a fix is not released on the spot.

On some projects, I have helped prepare configurations with Terraform so that infrastructure changes could be versioned, reviewed and coordinated with the release process.

Managing environments and releases directly

On other projects, I am more closely involved in operations, from development through to production.

I have configured release pipelines, including those that update several different services such as applications, CRM and Service Bus. I have worked across development, test, staging and production environments, monitoring services and investigating anomalies.

Depending on the project, integrations and data flows have involved Azure Functions, Service Bus and Stream Analytics, alongside network components such as Azure Firewall and Application Gateway. I have also used Entra ID for identity and Azure Synapse for data workloads.

A release across several systems

A release spread across several systems needs careful planning. It often involves a scheduled service outage, and the update of applications and databases has to be coordinated with other teams' systems going into production. It takes a written procedure, maintained over time, that covers the normal flow and the troubleshooting scenarios. It is not a fixed procedure: not every system is updated each time, and sometimes only a few microservices change.

The type of update determines two further aspects.

Rollback. Unexpected problems can still occur. In simpler releases you can go back to the previous version, using the modules' previously released packages (artifacts), and analyse calmly. When the deadline cannot be moved or the release is too complex to reverse, the problem has to be solved there and then, even at the cost of a longer outage.

People. In that case everyone who can help solve it, from your own team and the others, for services and for infrastructure, must be available when the release goes into production, to tackle the problem together (the so-called war room). That availability has to be planned too.