Services
IT architecture and modernisation
IT architecture, system integrations, cloud infrastructure and CI/CD pipelines built for a company's actual scale. Technical advisory and modernisation of existing systems.
- Who it is for
- Companies deciding between a rewrite and a modernisation
- Scope
- Architecture, integrations, cloud and CI/CD
- Outcome
- A review a whole company can read
- Principle
- Recommendations tied to no vendor
What the work covers
Architecture review
What is fine, what is a risk and what it costs to maintain.
The direction decision
Rewrite or modernise in stages, settled before the first line of code.
System matched to scale
A monolith with clear module boundaries, or separate services when there is a reason.
Integrations with a rule for failure
Retries, a dead-letter queue and an alert on a stalled flow.
Cloud matched to traffic
It can cost more than a dedicated server when the architecture does not fit.
Infrastructure as code
Terraform, with staging and production from the same description.
Rollback
A return to the previous version instead of a manual fix in production.
CI/CD gates
Building, tests, route and structured-data contracts, dependency hygiene.
Where an architecture decision starts
An architecture decision is rarely reversible without a cost. Rewrite the system or modernise it in stages, one database or several, an in-house team or a vendor: these questions get settled before the first line of code.
A review ends with a document a whole company can read, not only its technical team. It covers what is fine, what is a risk, what it costs to maintain and in what order to tackle it.
How the system is matched to scale
The system itself gets chosen for the scale of the process. A monolith with clear module boundaries is often a better choice than microservices nobody maintains later. Splitting into separate services makes sense only once there is a concrete reason to deploy them separately.
An integration usually breaks a few months after deployment, when one system changes its data format and the other stays silent about the failure. That is why retries, a dead-letter queue and an alert on a stalled flow get designed together with the integration itself.
Cloud, infrastructure and releases
The cloud can cost more than a dedicated server when the architecture does not match the traffic profile. Infrastructure gets described as code in Terraform, and staging and production come from the same description. Rolling back means returning to the previous version.
CI/CD ties all of it into one answer to a single question: can this change ship. The build passes or it stops. Building, testing, route and structured-data contract checks and dependency hygiene each halt the build instead of landing on a backlog.
Tools and standards
- Cloudflare Workers
- Docker
- Terraform
- Microsoft Azure
- Google Cloud
- TypeScript
- Node.js
- NestJS
- RabbitMQ
- GraphQL
- SQL
- GitHub Actions
Proof: architectural decisions with a named cost
A review ends with a decision, and every decision has a cost. We state it on the projects where it applies.
- Outcome
- What is fine, what is a risk, in what order to tackle it
- Independence
- Recommendations with no vendor commission behind them
- CI checks
- Our own npm package of assertions
The system for Best Assistance keeps three surfaces on one back end and one data model, so a claim filed in the field and a case worked at a desk are the same record. The price of that choice is that none of the three surfaces can be modernised without touching the others. Cyber Katalog splits its data by kind and by source: news, job offers and companies each have their own database, and the CSIRT NASK warning list proxy runs as a separate service, because it has a different data source and a different lifecycle.
What changes once it is in place
- Architecture matched to the scale of the process
- The release pipeline answers automatically whether a change can ship
- Every integration has an explicit rule for failure before the first outage happens
- Environments reproducible from a description in the repository, not from anyone's memory
- Rolling back a deployment in one step, without a manual fix in production
- Recommendations not tied to any vendor
Typical use cases
- An architecture review ahead of a decision to rewrite or modernise a system
- Extracting a module from a sprawling application and adding tests around uncovered code
- Migrating an application from a dedicated server to the cloud, in stages, with a way back
- Integrating a sales system with a warehouse and accounting through an API and a queue
- A release pipeline with tests, route-contract checks and publication to production
- Infrastructure described in Terraform, separately for staging and production
Questions that come up most often
Rewrite the system or modernise it in stages?
An architecture decision is rarely reversible without a cost, so it gets settled before the first line of code, as does the choice between one database and several and between an in-house team and a vendor.
What does an architecture review end with?
A document a whole company can read, not only its technical team. It covers what is fine, what is a risk, what it costs to maintain and in what order to tackle it.
When does splitting into microservices make sense?
A monolith with clear module boundaries is often a better choice than microservices nobody maintains later. Splitting makes sense only once there is a concrete reason to deploy services separately.
What happens when an integration stops working?
Retries, a dead-letter queue and an alert on a stalled flow are designed together with the integration, because an integration usually breaks a few months after deployment, when one system changes its data format and the other stays silent about the failure.
Is the cloud always cheaper?
The cloud can cost more than a dedicated server when the architecture does not match the traffic profile. That is why infrastructure is described as code in Terraform, with both environments from the same description.