We move live applications between clouds, run heavy jobs on Kubernetes and write the infrastructure down as code. Releases become routine, and the cloud bill follows the actual workload.
Cloud work usually starts with one of these three problems. Each links to a project where we solved it.
A container image, a target setup on the new provider, and a staged traffic shift with the old setup kept ready until the new one holds the load.
A queue in front, one pod per job, and an autoscaler that adds nodes when the queue grows and removes them when it is empty.
Docker images, CI/CD pipelines and infrastructure written as code, so Dev, Staging and Prod are built the same way every time.
Each card links to a client project where this work runs in production.
We containerize the application, build the target setup next to the old one and move traffic in stages. The public site stays up while it happens.
Each heavy job gets its own pod with set CPU and memory limits. Helm charts describe the setup, and the cluster grows and shrinks with the queue.
Networks, queues, functions and secrets are written down in Terraform. A new environment is a pipeline run, not a week of clicking in a portal.
Every change is built, tested and packaged the same way. Releases stop depending on a single laptop or a single person.
Compute that runs only while there is work, and AI models picked by the size of the task. The bill follows the workload, not the calendar.
Health checks per service, error tracking and dashboards, so a failing job shows up in a log before it shows up in a support ticket.
Ben-Gurion University’s main site holds about 80,000 pages and is edited by around 1,000 people. Applicants, students and staff use it every day, so the move to AWS could not cause an outage.
Heavy, uneven workloads are where cloud bills grow fastest. A video service that keeps large machines running all night pays for nothing most of the time. We design these systems around a queue, so capacity follows demand.
compute cost while the queue is empty. Our media pipeline reads jobs from AWS SQS, gives each one its own Kubernetes pod and lets the autoscaler remove every node once the work is done. Read the case
Cost is also about which service does the work. In an AI transcription pipeline for a lecture archive, each audio chunk goes to Gemini Pro or Gemini Flash depending on its length. That choice cut AI and API cost by up to 60%, while the cluster runs more than 300 jobs at the same time.
Building AI features on top of this kind of pipeline? See AI development.
We have production systems on both, so we have no reason to push one. Our honest default: stay where your team, contracts and other systems already are, and move only for a concrete reason.
A good fit when you want containers without running a cluster (ECS Fargate), when work is queue-driven (SQS and S3 events), or when the rest of your stack already lives there.
A natural choice for .NET teams that already sign in with Microsoft accounts, use Azure DevOps, or need Azure AD B2C for customer logins.
Mixed setups happen too. The transcription pipeline stores media in AWS S3 and calls Google Vertex AI, with Google Cloud Storage alongside. What matters more than the logo is that the setup is written as code, monitored and cheap to run.
Most cloud work happens under a running system. So we change one piece at a time, keep a way back and only switch off the old setup when the new one has proved itself.
Moving a .NET application at the same time? See .NET development. Need someone to keep it running afterward? See maintenance and support.
We list the services, databases, storage, jobs and pipelines, and where each one lives. You get a map of the current setup and its weak points.
Provider, managed services, containers or not, and how releases will reach production. Decisions are written down with the reason behind each one.
Docker images, pipelines and infrastructure definitions go into your repository, so the setup can be rebuilt and reviewed like any other code.
Traffic or workloads move a piece at a time. The old setup stays ready until the new one has carried real load.
Logs, health checks and dashboards go live with the first release. Then we look at the bill and the metrics and adjust sizing and scaling.
Every item here comes from a client project. The list grows when a project needs something new, not when a new service is announced.
Cloud migrations, Kubernetes pipelines, Terraform environments and CI/CD on AWS and Azure.
The university's main Umbraco site: ~80,000 pages, ~1,000 editors, daily staff data imports and a zero-downtime move from Azure to AWS.
An event-driven AWS and Kubernetes service that turns each uploaded video into adaptive HLS streams with multi-language audio, then scales back to zero.
A Kubernetes pipeline that turns hours of mixed-language lectures into timed transcripts, subtitles, summaries and HLS video.
A cloud-native platform for multi-day, multi-venue events: 8 .NET microservices on Azure handle registration, scheduling, attendee matching and Zoom.
A rebuild of Alliant's web estate on current Umbraco: one modular architecture for many sites, Okta sign-in for editors and forms connected to Eloqua.
An internal platform for inspections, toolboxes and transport planning, upgraded from Umbraco 8 to Umbraco 17 on .NET 10 with daily workflows intact.
Quotes from verified Clutch reviews of long-running platform and custom software projects.
They maintained reliability without needing constant oversight, which made the collaboration efficient.
Guys proved to be experts in their field.
Given that the client (us) invest in giving them adequate feedback, they deliver high quality, maintainable code.
The best CRM for events depends on whether you sell services to one client or run events for thousands of attendees. We compare six options for planners, venues and conference organizers by how they handle clients, attendees, sponsors and integrations.
The best ERP for oil and gas depends on your segment: an operator needs JIB and revenue distribution, a midstream firm needs volume and plant accounting, a service company needs field tickets and asset maintenance. We compare options by segment.
The best enterprise CRM is the one that fits your identity stack, your ERP and your integration platform, not the longest feature list. We compare six platforms by data model, governance and API limits, with list prices.
Anything missing? Send us your question and an engineer will answer, usually within one business day.
Contact usYes, if the move is staged. For Ben-Gurion University we containerized a site of about 80,000 pages, built the new setup on AWS ECS Fargate with RDS, S3, ECR and a load balancer, and shifted traffic gradually. The public site had no interruption, and it handles around 300 requests per second at peak.
Usually the one your team and your other systems already use. Both run .NET, containers and queues well, and we have production work on each. A move between providers costs time and money, so we recommend one only when there is a clear business reason, not because a newer service looks interesting.
Not always. A web application with steady traffic can run well on a managed container service such as ECS Fargate, as Ben-Gurion University does. Kubernetes earns its place when work comes in bursts and each job needs its own resources, like the video and transcription pipelines we built.
We size compute to the workload. Our media pipeline adds nodes as its queue grows and removes them all when it is empty, so idle compute costs $0. In an AI transcription pipeline, picking the AI model by job length cut AI and API cost by up to 60%.
Yes. On EM2, an event platform with 8 .NET microservices, Terraform and Azure DevOps pipelines deploy separate Dev, Staging and Prod environments. On Kubernetes projects we use Helm charts. The definitions live in your repository next to the application code.
Yes. We have run Datadog on Alliant’s Azure-hosted sites, Application Insights with per-service health checks on EM2, and Serilog with Sentry on Jongeneel’s platform. The tool usually follows what your team already uses.
Our rate listed on Clutch is $25–49 per hour, and the minimum project is $1,000. A defined piece of work, such as a migration, can run as a fixed-scope project. Ongoing DevOps support can run as a monthly dedicated team or as an engineer added to your team.
A spec, a Figma file or three paragraphs is enough to start.
Cookies on oski.solutions
We'd like to use analytics cookies to understand how the site is used, and marketing cookies to measure our ads. They are off unless you allow them. You can change your choice any time via “Cookie settings” in the footer. Cookie policy