In December, the entire uShip team embarked on an endeavor of great proportions: migrating our site to the cloud.
Like so many other web-based companies, the need for the migration became clearer as we continuously enhanced and grew our product. Born in 2004, the uShip site had seen massive changes throughout its lifetime, but had existed in a monolithic environment which hindered the team’s flexibility and efficiency capabilities.
In an effort to streamline our iteration capabilities, create a more reliable and scalable product, rely on a single centralized host, increase performance and improve environment parity, our engineering team began preparing for the shift more than a year in advance. To put it simply, the project had one objective: to take code and services that were deployed in a static location and moved these pieces into a more nimble and dynamic cloud environment.
The transition involved key members from teams across the organization including development, engineering, data architecture, and quality assurance. With much careful planning and cross-departmental collaboration, the team began planning the migration more than a year in advance.
When it was finally go-time, we all held our breath and watched as the team expertly executed a smooth, straightforward and successful migration. Many companies – even well-equipped big name tech companies – have to make several attempts at a shift like this, often not finding success on the first, second or even third attempts.
To hear a little more about actually went into the migration, we talked to a few key players:
Jaspreet Baweja, Director of Engineering, Data & IT Services:
Why did we need to execute the migration when we did?
“Infrastructure as code. What this means is you provision hardware as you need. There is no need to buy all this hardware and go through extensive capacity planning exercises. Capacity planning is not an exact science to begin with. More often than not you end with paying too much due to capacity planning in advance for a year. With cloud you provision hardware when you need it. As traffic increases you scale it up or if it overpowered you scale it down saving money in the long run.”
In hindsight, how did the project go?
“The actual migration was planned so well that we were able to complete it on a weekend overnight in about 6-7 hours. This is something to be proud of and boast about. I am so proud to have been a part of this move and work with all the teams who made this possible.”
What was your role?
“I led the data migration effort to the cloud. I was also involved in planning, coordinating, and guiding cross-functional teams to help them plan and execute their part.”
Angella Seaman, DevOps Engineer:
What did we actually do during the migration?
“We reworked the lower environments to be as prod-like as possible while bringing that same functionality to the cloud. We implemented a unified code delivery pipeline in these like environments so that the code we test is delivered and hosted in the same way across the board. We have a run book of everything we did the week of and night of if that would be helpful.”
What was your role in the project?
“I was cloud engineering team lead for the final half of the migration.”
Bryson Reynolds, DevOps Engineer:
Why was the migration necessary?
“Previously we served our production site, as well as regression and staging environments, on 16 servers in Data Foundry, a colocation space where numerous people host their services, right here in Austin. We hosted our dev environment in this office. Over the course of the migration, we moved all of these environments composed of static (long-living) servers to Amazon Web Services, (AWS, aka “the cloud.”) This new infrastructure consists of dynamic and ephemeral (short-living) servers that are terminated and recreated on every deploy.”
How did you contribute?
“I managed configurations, assembled and validated bigger pieces of the project as other cloud engineers completed their individual parts, and coordinated with teams outside of cloud engineering to get all the pieces functioning with ours.”
We’re so proud of the team that executed this smooth transition, and are eager to continue to watch the shift open more opportunities that will improve our product for many years to come.
Sound like your kind of place? See our open jobs here:
