Limited-time dealSupermicro HGX B200, 8 GPUs8-GPU NVIDIA HGX B200 server in stock
View the specification Call +91 92058 93902innovations@udhyamlabs.tech
Five practices for work where the standard approach has not been enough.
Each practice can be engaged on its own, and each starts with a fixed-fee assessment. Each assessment ends with written findings and a short paper for your management. The practices are intended for work where the standard approach has been tried without solving the problem, or has been costed and found too expensive or too risky. The standard approach may be a lift and shift migration, a full rewrite or a larger hardware order.
Cloud to cloud migration
This practice moves a production estate from one hyperscaler to another, or into a sovereign or private cloud. The plan is built from what the estate is observed to do. The move is made in waves, each of which can be reversed up to a point of no return that the wave plan states and you sign off. The work is planned through to the decommissioning of the source estate.
What the work is planned to deliver
- The estate running on the target provider, with every wave verified
- Infrastructure code for each environment covered, in your repository
- The source estate decommissioned, with a reconciled final bill
- Terraform
- AWS
- Azure
- Google Cloud
- Sovereign cloud
- Identity re-mapping
- Replication
- Parallel run
The drawing shows a move part way through: ten services verified on the new provider, two running on both, and eight still to move.
The assessment
We take a named slice of the estate and read its billing export, network flow logs, load balancer logs, DNS query logs, the provider's API audit log and traces. You receive a dependency map, a classification of each workload, a wave plan for that slice, an estimate for the rest of the estate, and a model of what running two estates in parallel will cost.
What you provide
You provide read-only access to those sources, one engineer who knows the estate, and a named owner for each service when its wave is planned.
Where the risk is
Stateful services carry the risk. Once a service has taken writes on the target, returning it to the source is a data operation and no longer a traffic change, so each wave states its point of no return and who signs it.
Platform re-engineering
This practice replaces the parts of a system that can no longer carry the load or accept the changes the product needs. The system is designed to stay in service throughout, and your team keeps shipping outside the areas you agree to freeze. We separate what is still sound from what has to change, and the change is made one function at a time.
What the work is planned to deliver
- New components carrying production traffic
- Data migrated and verified as part of the project
- The old path retired, once the new path has met the retirement test agreed in advance
- Service decomposition
- Data model redesign
- Outbox and change data capture
- Backfill
- Traffic shifting
- Shadow comparison
The drawing shows requests divided between the old system and its replacements, with both answers compared before more traffic moves.
The assessment
We read the code, the data model and production telemetry. You receive a map of what is sound and what has to change, the order in which components can be extracted, and the cost of the period in which the old and the new must both run.
What you provide
You provide read-only access to the repositories and to production telemetry, the engineers who know why the system is the way it is, and a decision on which areas are frozen while they are being replaced.
Where the risk is
Data carries the risk. A request that moves money or calls a third party cannot simply be sent down two paths, and an application that writes to two datastores itself leaves them inconsistent when one of the writes fails.
Delivery engineering
This practice rebuilds the path from a code change to production, so that a release can be made on any working day and reversed within a known time. It covers infrastructure as code, the build and test stages, gradual release, and the telemetry that decides whether a release continues.
What the work is planned to deliver
- Infrastructure defined as code in each environment covered
- Gradual release gated on error rate, response time and a business signal you choose
- A rollback rehearsed in production, with its restore time recorded
- Terraform
- Pulumi
- Kubernetes
- GitHub Actions
- GitLab CI
- Argo Rollouts
- Policy as code
- OpenTelemetry
The drawing follows one change from commit to release. It is held at five percent of traffic until its signals have been judged.
The assessment
We read the pipeline, the differences between environments, and the record of recent releases and incidents. You receive a list of the points where a faulty release can pass unseen, a target rollback time, and an ordered plan of changes.
What you provide
You provide read-only access to the pipeline, the repositories and the incident record, and agreement on one or two business signals, such as approval rate, that a release must not move.
Where the risk is
Database changes carry the risk. Code can be rolled back in minutes and a destructive schema change cannot. Schema changes therefore ship as expand, migrate and contract in separate releases, and the contract step, which is the irreversible one, ships only when no version that still reads or writes the old structure is a rollback target.
AI inference systems
This practice takes an AI use case from a working pilot to a service in daily use. In the assessment we agree with you what a correct answer is, on a set of your own cases, and what accuracy, response time and cost for each request the service has to reach.
What the work is planned to deliver
- The service in production, available to the people it was built for
- Evaluation cases drawn from your own work, which show whether its answers are right
- A measured cost, in your currency, for each type of request
- PyTorch
- TensorFlow
- vLLM
- TensorRT
- Retrieval
- Quantisation
- KV cache sizing
- Evaluation cases
The drawing follows one request through the system and shows where the waiting time and the cost arise.
The assessment
We run the pilot against a sample of your real requests, in an account you control, and measure accuracy, response time and cost. You receive those figures, the evaluation cases, and a statement of whether the use case can reach its targets and what that would take.
What you provide
You provide the pilot or a description of the use case, a sample of real requests, and people who can say which answers are right.
Where the risk is
Data and cost carry the risk. Data can reach a provider you have not approved, and neither the response time nor the cost at full load can be predicted from a test with one user at a time. You choose and approve the model provider, and your data stays in an account you control unless you approve a provider to receive it. We measure response time and cost at the concurrency you expect at peak.
AI hardware advisory
This practice answers one question: what hardware you should buy and house yourself, buy and colocate, or rent, for what you intend to run. If you already hold a quotation, we check it. We take no commission, referral fee or rebate from any supplier, and an assessment never recommends equipment that we have listed for sale.
What the work is planned to deliver
- A written recommendation, with the arithmetic shown in your currency
- The cost of owning the servers, in your own facility or colocated in another firm's data centre, and of renting, compared on one basis in your currency
- A specification for the servers and their network, where you ask for one, with the power and cooling the data centre must supply
- NVIDIA
- AMD
- Bottleneck profiling
- Network design
- Power and cooling envelope
- Cost per million tokens
The chart shows what renting, colocating and buying cost at different levels of use. The three bars show which limit of the hardware the work reaches first.
The assessment
We take the quotation, if there is one, and a description of what you intend to run, and we test a representative workload. You receive a written recommendation to buy as quoted, buy less or more, buy a different part or rent first, with the arithmetic shown in your currency. For a quotation check, the assessment is the whole engagement.
What you provide
You provide the quotation and its validity date, if there is a quotation, the models and the number of users you expect, and the response time the use case needs.
Where the risk is
Demand that is not yet known carries the risk. Where there is no workload to measure, we run a representative one on capacity rented in an account you control, and we state how uncertain the result is before any capital is committed.
Describe the problem, and an engineer will reply within one working day
Tell us in general terms what you are trying to do and what has stopped it. If it is not ours to take on, we will say so.