At ten24, our mission is to build software solutions that give our clients a competitive advantage. Our Slatwall eCommerce platform, for example, makes it possible for businesses to work smarter and capitalize on powerful, cloud-based eCommerce management. It’s an exciting industry to be in because innovation is the name of the game. There is always something new on the horizon that can help our clients be faster, better, and stronger.
It’s the same for the technology that powers the solutions we build. Soon, we will be putting the finishing touches on a major project that we started back in September of 2018. We are making the move to Amazon’s elastic container service (ECS), and it may just be the most important thing you’ve probably never heard of.
Before we explain why ECS is such a big deal for us and our clients, a little trip back in time is in order. About two years ago, ten24’s entire infrastructure was with hosting.com, an enterprise, cloud-based, virtual service. With hosting.com, we still had physical hardware but we deployed our software on top of virtual servers. So we were essentially creating virtual servers on top of physical ones. This gave us the power to create a big super-resource that lived up in a secure and private cloud. Sounds great, right?
Well, it was, except for when we needed to provision a new site or server. We had to sign in to a portal and request that new server. It took almost an entire week to provision the server and get everything working. And in the fast-moving world of eCommerce, a week is an awfully long time to wait. Even worse, there was no way for us to automatically scale up or down with fluctuations in site traffic. We simply had to guess based on what we thought we needed, cross our fingers, and hope we guessed correctly. To make things even more challenging, a lot of the workaround provisioning new sites and servers was manual. The situation was far from ideal for us and our clients. There was clearly room for improvement.
It wasn’t long before we made the move to Amazon Web Services (AWS), which provided a scalable infrastructure that was 100% scripted. That meant no more manually “pushing” stuff every time we wanted to provision a new site or server. Whenever we needed to create a new site, we didn’t have to write code. Instead, we simply chose “create a new site” and it would be up and running in about 10 minutes, automatically deploying to the development and production servers. No more one-week waits!
Moving to AWS also let us take advantage of something called an Elastic Beanstalk (and no, there aren’t any giants involved). In an Elastic Beanstalk environment, you can decide what your CPU (traffic) threshold is and whenever the load exceeds that threshold, your environment will automatically scale to meet the increase in traffic with additional servers.
If a server dies or goes down unexpectedly, Elastic Beanstalk automatically spins up a new one and the site comes right back up. In technical terms, this is known as “self-healing.” It was a huge improvement that let us stay ahead of problems because it enabled us to be proactive and not reactive. What’s more, our environment was load balanced across multiple availability zones. There were different data centers in the eastern region of the United States, so if something really bad (like a massive power outage) happened in one data center, then traffic would re-route to another data center. In the industry, this is what’s referred to as “high availability” All of this was really great – until it wasn’t.
After a while, the “new normal” of waiting ~ 10 minutes for a site to scale up or recover from a failure got pretty old. That’s 10 minutes during which our clients were losing valuable business and missing precious opportunities. So we started wondering if there was something even faster out there – perhaps a solution that got servers and sites to scale and recover in a minute or less and provided almost 100% uptime.
Amazon’s ECS offered a great alternative because it’s based on a philosophy of not being tied to a specific server. Compare that to the Elastic Beanstalk model, which requires spinning up a new server that’s dedicated to a specific container. With Amazon’s ECS, we can run each site in its own container. These containers run across virtual servers, which in turn run across physical servers. Simply put, these containers do nothing but run your applications. If you think in terms of Legos, then containers are the smallest-possible building blocks that sit on top of the larger bottom level, which stays as static as possible.
A good real-world example of how containers work is illustrated by your laptop computer. In order to run the applications that live in the laptop, you need to power up and wait for the computer to start in the first place. Once the laptop is up and running, you launch the application, whether it’s Word, PowerPoint, Excel, or whatever else you need. But when your laptop is already on, you don’t have to wait for it to start up. You just open and run your app right away. Further, imagine running that same application on Mac, Windows, or Linux without any change in application. That’s exactly the idea behind a containerized environment and ECS.
By using a container-based service, your “laptop” (i.e., your eCommerce platform) is running all the time. So all you’re doing is starting up your “application” (i.e., your site). That cuts down the startup, or provisioning, time to about a minute. And we can all agree that’s a great improvement from 10 minutes. But what if we can cut that application startup time to less than a minute? With that kind of improvement, visitors wouldn’t be able to detect that a site is even down! The business implications are obvious.
ECS lets us (and our clients) get away from server dependency and rely more and more on container deployment. In the industry, it’s called “container orchestration.” It’s fast and powerful. To return to our laptop analogy, you’ll recall how quickly you can open and get to work with those apps as long as your laptop is already fired up. Think of all those apps as containers. ECS lets us spin off (or scale) as many containers as we need, quickly and efficiently.
From a security standpoint, nothing changes with ECS, and that’s critical for our clients’ (and their customers’) sensitive information. ECS infrastructure is completely secure because containers are provisioned in complete isolation from another container. As an additional security measure, we provision all our virtual servers without any remote access, so nobody has physical access to any servers.
Using immutable deployment through ECS (we used immutable deployment in Elastic Beanstalk as well) also eliminates the “scheduled maintenance hours” and associated downtime that every site visitor or system administrator dreads. Because we’re talking about 100% uptime, sites using ECS stay open for business even when maintenance is being done on them. Talk about a game-changer!
By February of 2019, we completed migration to ECS in the development environment. By March, we were testing. In April, migration to some of the production sites began. We are on track to have the entire ECS migration project complete by the end of this month.
Here’s to better business and the quest for 100% uptime!