Today we’re going to take a peak deep inside the workings of Procure Inc. and the den of code that makes the entire thing tick. We’re also going to have some downtime coming up for maintenance to our site, planned maintenance so we can give you a little heads up.
Downtime – Friday 4/19/19
During the day on Friday our website will be offline or intermittently available starting at 10 AM Eastern Time and continuing until 6PM Eastern Time with the potential to be extended into the weekend. During this time, you will not be able to access any portion of the site.
Why The Downtime?
We’re going to be applying a significant update to our site. In testing, we’ve found this particular update to be more time consuming to apply than we’d like. From start to finish, our best deployment time was two hours on our development systems, and we’ve done this enough times to know it never goes that smoothly for the real show.
How Do You Update a Site?
That’s the boring stuff out of the way. Let’s look at the cool part of this: I get to geek out at you and Lead Sales Guy Scott about how our website works, how the internet works, and a very basic idea of what we do to keep it all working.
Every website comes from a server of some sort. This is a computer that runs a website or some networking support service. It serves data and content to you. We have database servers, web/application servers, and a caching system running our site. These all interconnect with each other to send you products and track orders.
The Database Server is just like it sounds like: it runs a database. It stores orders, product data, and any other records we need, in a special format that lets other servers pester it for data. The main Web Server is the one that brings everything together. It fetches images from storage, fetches data from the cache, generates web pages, and sends them to you and the caching server. The caching servers are the ones you actually talk to. They’re spread all over the world to optimize the site’s performance. You go to the site, the cache sends you as much as it has, and then asks the Web Server for everything it doesn’t have, and sends that data along too. The idea is that the caching server can take some load of the main server and be local to you, so the website loads faster.
From a hardware perspective, we won’t need to update the servers any day soon. They’re all cutting-edge hardware. We planned ahead in that department. Code however, ages like milk. You build a website, it seems perfect. A month in, you find something you don’t like. Two months in, another thing you don’t like. A year in, you realize that brilliant thing you did wasn’t so brilliant. Code is something that needs to continually evolve and we do constantly deploy new code to our system.
The code we want to set up is a pretty massive departure from the code that’s running now. We need to generate a last minute back up of the server (because things always go wrong), upload all our new code, adjust some configuration settings on the server, run some special update code that’ll restructure the database a bit (that’s the tricky bit), test it (the tedious bit), and finally turn everything back on for public viewing.