DevOps and Microservice Architecture

Microservices are an architectural option, not a maturity badge. A well-structured modular monolith can be easier to test, deploy and understand when one team owns a product, demand is moderate and its domain boundaries are still moving. Distributed services become more defensible when different capabilities genuinely need independent ownership, release cadence, scaling, security treatment or failure isolation. NobleJackal records the decision case before recommending decomposition. If the operating cost would exceed the expected benefit, the responsible answer may be to repair the monolith and its delivery path instead.

The assessment maps what actually runs: applications, modules, scheduled jobs, queues, databases, external providers, repositories, build systems, environments, network paths, secrets, manual steps and the people who approve or support them. It follows representative changes from request to production and representative incidents from detection to recovery. Architecture diagrams are compared with source, configuration, telemetry and team practice rather than accepted as current because they carry a recent logo. Unknown dependencies and undocumented production exceptions remain visible in the register.

Quality attributes turn a general modernisation wish into a decision. The brief names expected availability, latency, throughput, data integrity, recovery, security, privacy, auditability, release independence, maintainability, portability and cost constraints for the relevant user journeys. Current baselines and evidence quality are recorded where data exists. A target such as ‘deploy more often’ is not accepted without defining the change class, team, environment, measurement period and acceptable failure or recovery conditions.

The commercial unit is fixed in writing: applications, domains, teams, environments, service candidates, interfaces, data paths, pipelines, infrastructure, migration waves, workshops, implementation tasks, reviews and support window. Pricing upon request does not buy an unlimited platform team. Product development, custom software, managed cloud operation, cybersecurity architecture, backup and disaster recovery, hosting, third-party cloud consumption and continuing on-call support remain separate unless expressly included.

Service candidates are modelled around business capabilities and bounded contexts, then tested against how the organisation can own them. Functions that change together, depend on one transaction or require constant coordinated releases may belong together even when a diagram can split them. Conversely, a capability with a distinct team, data lifecycle, scaling profile or security boundary may justify independent deployment. The decision record preserves rejected boundaries and trade-offs so that later teams understand why a line exists.

Every boundary needs a contract. Synchronous APIs, asynchronous events, batch exchanges and file transfers are listed with producer, consumer, owner, schema, authentication, authorisation, availability expectation, timeout, retry, idempotency, version and retirement policy. An OpenAPI document may describe an HTTP interface, but the delivery contract also includes behaviour, error conditions and change rules. Consumer and compatibility tests protect the interactions that matter; they do not replace end-to-end evidence for real journeys.

Data ownership is settled before extraction. The design names the system of record, permitted readers and writers, identity keys, privacy classification, retention, migration route and reconciliation owner. Shared-database coupling is not disguised as service autonomy. Where one business operation crosses boundaries, consistency, ordering, duplicate delivery, compensation, replay and failure recovery are designed explicitly. Patterns such as outbox, saga or event sourcing are selected only when their additional machinery is justified and can be operated by the team.

The dependency map covers calls, events, identity, DNS, certificates, configuration, queues, caches, databases and external services. For each important path, the team decides what happens when a dependency is slow, unavailable, duplicated or returns an ambiguous result. Timeouts, bounded retries, backoff, circuit breaking, bulkheads, load shedding and graceful degradation are applied selectively and tested. Adding every resilience pattern by default can create as much uncertainty as leaving failures unmanaged.

A service is independently deployable only when its source, build, artefact, configuration, database change and release authority can move without hidden coordination. The delivery design records repository ownership, branch and review rules, reproducible build inputs, dependency policy, artefact identity and promotion between environments. A container image is treated as a versioned release object, not proof that the system is cloud native. Provenance, software bills of materials or signing are introduced to the level required and actually supportable; their presence is not described as automatic supply-chain security.

Continuous integration runs the checks that protect the particular service and its consumers. Unit, integration, contract, migration, security, policy, performance and smoke tests are assigned to stages with clear failure behaviour. Expensive checks may be layered rather than forced into every commit, but no critical gate is silently optional. Test data, external dependencies and environment differences are controlled well enough to interpret a result. A green pipeline proves only that its named checks passed against a named revision.

Infrastructure, configuration and policy changes receive the same version and review discipline as application code. Infrastructure as code defines the resources that belong in scope; it does not turn every console setting or provider default into controlled state by itself. Secrets stay outside repositories, access follows least privilege, and production credentials have owners, rotation and revocation routes. Plan output, drift, state storage, provider versions and break-glass changes are recorded so that automation does not conceal an undocumented operating path.

Release design matches risk and platform capability. Rolling, canary, blue-green, feature-flagged or phased releases each require health signals, decision authority, stopping conditions and a recovery route. Database and event changes are kept compatible across the coexistence window; rollback is not promised when an irreversible data change has already occurred. In those cases the plan names forward repair, restore or compensation. A successful deployment command is not accepted as evidence that users received the intended behaviour.

Reliability starts from user and business journeys rather than server uptime alone. The team defines service-level indicators for the behaviours that matter, proposes objectives where there is enough evidence and names the measurement window, exclusions and owner. Error budgets may help balance reliability and change, but they require trusted measurements and a decision process. A newly written SLO is not historical proof, and a provider SLA does not describe the complete path experienced by a customer.

Metrics, logs and traces are designed together. Correlation identifiers follow a request across services; events contain useful context without exposing unnecessary personal data or secrets; dashboards connect symptoms to dependencies and release versions. OpenTelemetry can provide a vendor-neutral telemetry structure, but instrumentation quality, sampling, semantic conventions, storage and alert design still require choices. The aim is to answer operational questions during a real incident, not to produce a wall of colourful charts.

Security is built into identities, interfaces and delivery. Human and workload identities are separated, permissions are narrow, service-to-service trust is explicit, secrets are rotated, network paths are controlled and API authorisation is tested at object and function level. Threat modelling covers administrative paths, build systems, registries, dependencies, exposed APIs, queues, data stores and third parties. NIST SSDF and OWASP guidance can inform the controls; neither certifies an implementation or removes the need for system-specific testing and review.

Every production service needs a named owner, escalation route and operating evidence. Alerts are tied to actionable conditions, runbooks identify safe diagnostic and recovery steps, and incidents preserve timelines and decisions for learning. Capacity, quotas, rate limits, queue growth, certificates, backups, restoration dependencies and cloud consumption are reviewed before they become emergencies. Twenty-four-hour monitoring, live incident response, managed cloud operation and disaster-recovery commitments exist only when separately staffed, priced and written into the service.

A brownfield migration is planned as a sequence of controlled coexistence states. Strangler, branch-by-abstraction, modularisation or selective replacement may be used to move one capability while the existing system continues to serve users. Routing, identity, data synchronisation, reconciliation and ownership are designed for the transition, not only for the final picture. Big-bang replacement is reserved for cases with a defensible cutover plan, tested recovery and an authority willing to accept the concentrated risk.

The first slice is selected for learning value and manageable consequence, not because it is the easiest service to draw. It exercises the intended source, contract, pipeline, infrastructure, observability, security and support path. Acceptance includes functional behaviour, compatibility, performance, failure handling, data reconciliation, deployment and recovery. Pilot evidence can change the architecture decision: an extraction may be expanded, redesigned, paused or folded back into a modular application without being labelled a failure of ambition.

Change performance is measured without turning metrics into quotas. Deployment frequency, change lead time, failed-deployment recovery time, change fail rate and deployment rework can expose delivery constraints when definitions and populations remain stable. They are read alongside reliability, security, customer impact, staff load and cost. A team is not rewarded for splitting deployments, hiding incidents or changing the denominator. Baselines precede claims, and an architectural release is not credited with an improvement that occurred before it.

Handover connects diagrams to the working estate. It identifies repositories, services, contracts, data, pipelines, infrastructure code, environments, accounts, secrets owners, dashboards, alerts, runbooks, recovery dependencies, cost centres, suppliers, open risks, exceptions and retirement work. Access is transferred through approved channels and a receiving team demonstrates the agreed operations. Further migration waves, platform operation, cloud consumption, monitoring, on-call response, security work and product development continue only under a new or continuing written scope.