Creating a Fully Automated and Scalable Infrastructure for ten24

← Back to Articles

CHALLENGE

ten24 Digital Solutions creates and manages eCommerce websites for clients in a wide range of industries, including manufacturing, government, publishing and consumer products. They are also the team behind the Slatwall Commerce (http://www.slatwallcommerce.com) platform which they provide as a completely managed SaaS solution. Each of ten24’s client websites must be an entirely separate environment that maximizes uptime and minimizes costs. As their client base grew, it became clear that maintaining its existing datacenter environment was unsustainable. The company’s development team members were maintaining more than 50 public-facing websites that leveraged Java Application Server on a Windows Server, along with a mixture of SQL Server and MySQL databases. Whenever a new client service was required, it would take multiple days to provision the resources. As ten24 grows, it wants to be able to focus on its core business: creating and maintaining eCommerce websites for its clients. The company was looking to leverage an infrastructure that would be fully automated, from the deployment of the infrastructure and application code to the application servers.

SOLUTION

ten24 engaged Cloudnexa based on our expertise in designing highly automated and scalable infrastructures for our clients. We initially proposed a number of modifications to make ten24’s infrastructure run as efficiently as possible within Amazon Web Services (AWS). This consisted of leveraging services such as Elastic Beanstalk, CloudFront, EFS, WAF, ACM, Route53, and RDS to provide a highly scalable infrastructure that could also be automated. Following this proposal, Cloudnexa worked with ten24 to create a proof of concept environment using the services listed above. This phase of the project required making extensive modifications to the Elastic Beanstalk environment .ebextensions files so they would function as required with ten24’s development and production environments. Upon successful testing of the proof of concept environment, Cloudnexa began working to build out an extremely flexible CloudFormation template that would create individual environments for each customer, allowing for a multitude of possible configurations based upon that customer’s specific requirements. Working in tandem with ten24, Cloudnexa developed a CloudFormation template that could be leveraged by a custom Node.JS application (written by ten24). The template allows ten24’s team to manage each customer’s particular infrastructure parameters and use those parameters to build the customer’s respective environment. This arrangement means the ten24 development team can provision environments by typing as few as two words, and have a fully functional new environment within 20 minutes.

 

DEPLOYMENT PROCESS

ten24’s deployment process at this point is fully automated, allowing developers to be agile while also preserving the security of both development and production environments.

  • ten24 initializes the environment creation using its custom Node.JS application, which kicks off a CloudFormation template. The template receives the parameter values from a JSON file managed within a specific customer repository. This entire process requires just two words to be typed in order to provision out multiple AWS services.
  • After the environment is created, the developer is then able to push the latest commits to their remote GIT Repository, which triggers a Codeship pipeline to pull down the respective .ebextensions files and application files. Once these files are retrieved, they go into a tarball and are deposited on S3. Codeship then executes an API call to Elastic Beanstalk to pull down the latest application files.
  • Elastic Beanstalk performs an immutable rolling deployment of these new application files to the new nodes, preventing any previous configuration details from being left on the instances. Under this new arrangement, ten24 is able to complete all of these tasks from start to finish in less than 20 minutes. Previously, it would take multiple days, because all resources had to be hand provisioned. This improvement means ten24 is more agile and better able to focus on its core business practices.

ADDITIONAL CHALLENGES AND REQUIREMENTS

ten24’s environments have many highly specialized requirements for each client. Every single one of these requirements provided an additional challenge when leveraging CloudFormation to perform the environment configurations.

  • ten24 had to make sure its clients could either leverage their own selfprovided SSL Certificate, or provision an SSL Certificate on their behalf with between one and four domains protected by that certificate.
    • Due to the nature of CloudFormation, there is no looping functionality that allows for easy iteration over an array of strings to use as configuration values. Cloudnexa solved this issue by leveraging Condition checking based upon values provided at environment configuration in order to determine whether a new certificate will be provisioned or if an existing certificate will be utilized.
  • Because ten24’s application could not be easily modified to utilize S3 as a shared static media storage location, we needed to use a shared file system.
    • Due to the cost restrictions placed on the environment, the Encrypting File System (EFS) service was chosen as the shared file system. One of the limitations of EFS is that individual requests for small objects are high latency; this required Cloudnexa to create custom scripts to mount the EFS Volume upon boot. Additionally, we positioned the EFS mount location on the local machine within the Docker container to ensure that only static media was stored within the EFS volumes.
  • For compliance purposes, ten24’s AWS Web Application Firewall (WAF) service needed to be implemented in front of each of the environments.
    • The AWS WAF service does not support classic load balancers, so we had to modify the CloudFormation script to provision Elastic Beanstalk using Application Load Balancers instead of Elastic Load Balancers. Because the AWS WAF Service could not yet be associated to a resource via CloudFormation, we had to write additional custom .ebextensions files to perform the association of the WAF to the environment at boot time.

BENEFITS

ten24 has benefited directly from a strong partnership with Cloudnexa as an AWS Premier Managed Services Partner. Ultimately, ten24 was able to decrease its deployment time for new environments from multiple days to less than a half hour. Now, ten24’s development staff can devote more time to core business activities and provide an excellent product to end clients.

 


Stay up to date with the latest from Slatwall

Contact us for more info...