Cloud Migration And Services On AWS, Azure And Google Cloud
We move applications to AWS and Azure and shape the infrastructure around how they are really used, so they stay fast under load and cost less to run. Autobuffy’s 100,000-part store now scales automatically with its traffic.
Reviewed by Azmat Rana, CEO & Founder · Updated
What We Do In The Cloud
Cloud bills grow and sites slow down when infrastructure is shaped around guesses instead of how the application is really used.
Core capability
Migration
Moving applications and databases one service at a time, with traffic switched over once each part checks out.
Scaling for traffic
Load balancers and auto-scaling so capacity follows demand. BuffyHub runs behind an Elastic Load Balancer on EC2.
Serverless and managed services
Managed databases, storage and serverless setups that remove routine server work. Whistle It runs its meeting rooms serverless on Google Cloud.
Storage and heavy files
Direct uploads to object storage and separate pipelines for large files, so uploads never slow the site down.
Security and access
Least-privilege access, encryption and secrets kept out of the code, set up before anything moves.
Project story · Autobuffy
Keeping a 100,000-part store fast under heavy traffic
Autobuffy is a US auto parts store selling more than 100,000 parts on a dropshipping model. Customers search by make, model and year while vendors send constant inventory updates. Six of our engineers have put around 28,000 hours into it.
- Team
- 6 engineers
- Effort
- 28,000 hours
- Catalog
- 100,000+ parts
- Stack
- Ruby on Rails, Angular, Elasticsearch, AWS
The problem
The server setup struggled with the volume of API calls and file activity, so the site slowed down under traffic. Admin uploads competed with shoppers for the same servers. Large files went to the server first and then on to S3, which was slow and expensive, and inventory still arrived by FTP, CSV and Excel.
What we changed
- 01Put the store behind AWS load balancers with auto-scaling, so capacity follows traffic.
- 02Split the shop and the admin onto separate servers, so heavy admin uploads no longer slow customers down.
- 03Switched to direct uploads from the browser to S3, cutting server load and cost.
- 04Built an inventory microservice that pulls vendor stock automatically and keeps it in sync in real time through APIs.
- 05Added Elasticsearch and reworked the database indexes, so searching by make, model and year is fast again.
Where it stands
The store stays reliable at peak load, and inventory is accurate without manual imports. Cloud work is mostly this: shaping the infrastructure around how the application is really used. Then it scales where it needs to and costs less where it does not.
Read the full Autobuffy case studyFrom Infrastructure To Cloud
We measure how the application is used before deciding what it should run on.
Assess
Map What You Run
We list every service, database and dependency, and how much traffic and data each one handles.
Migrate
Move One Piece At A Time
Each service moves with monitoring in place, and traffic switches only once it checks out.
Optimize
Right-Size And Secure
We tune server sizes, storage and access rules to the real load and set usage alerts.
Technology Behind Cloud Services
The cloud platforms and infrastructure tools behind our projects.
Google Cloud
Docker
Kubernetes
Terraform
Ansible
PostgreSQL
MongoDB
Prometheus
Grafana
GitHub
GitLabGetting The Cloud Right
Moving to the cloud does not make software faster or cheaper on its own. These are the decisions that do.
Scale the busy parts
Separate the pieces that see spikes, like the Autobuffy storefront, from the ones that do not, and scale each on its own.
Managed services first
Managed databases, storage and load balancers remove most routine operations work before you write any automation.
Send files straight to storage
Uploading through your own servers costs money and slows them down. Direct uploads to object storage avoid both.
Keep secrets out of code
Credentials belong in a secrets manager with access limited by role, never in the repository.
Separate staging from production
Test every change on a copy of production first. It is the cheapest insurance a team can buy.
Watch the bill
Set budgets and alerts from day one. Idle servers and oversized databases are the usual surprise.
Cloud Solutions In Action
Products whose hosting we designed or moved.
Related services
Projects like this one usually involve these as well.
Cloud Services FAQs
What teams ask before moving to the cloud or changing providers.
We map what you run today and agree a target design. Then we move one service or environment at a time, test each step, and switch traffic over once everything checks out.
Yes, including apps that were never built for it. Often the first step is separating heavy jobs, uploads or admin work from what customers use, as we did on Autobuffy.
Mainly AWS and Azure. Autobuffy and BuffyHub run on AWS, and Truck-4 runs on Kubernetes with Azure DevOps pipelines.
With least-privilege access, encryption for data at rest and in transit, secrets kept in a managed vault, private networking for databases and audit logging.
Often. Right-sizing servers, sending uploads straight to storage and scaling only the busy parts usually make the biggest difference.
You do. Everything we build for you, including the source code and the intellectual property in it, belongs to you.
Ready To Move Or Fix Your Cloud Setup?
Tell us what you run today and where it hurts. We reply within one business day to set up a discovery call.