As one of the leading cloud-based WMS platforms, 3PL Central's top priority is ensuring that your data is safely managed so that you can have confidence in using 3PL Warehouse Manager to help run your warehouse operations. That's why our software is hosted using infrastructure that guarantees the protection of your data and enables optimal system performance.
We also perform routine system maintenance to release new features and enhance existing functionalities, in which each release receives thorough testing to ensure a consistent and friendly user experience.
This article reviews how and where 3PL Warehouse Manager data is hosted, as well as how our software is tested prior to each release.
Skip Ahead: Use the following links to skip to the relevant sections below.
- Hosting services
- Disaster Recovery plan
- Testing methods
Our software is hosted at Amazon Web Services.
3PL Central's application servers are hosted in AWS US East (Ohio) region and spread across all three of this region's physical and geographically distributed Availability Zones for high availability, fault-tolerance, redundancy, and scalability. You can read more about this in Regions and Availability Zones.
3PL Central’s production servers are configured with no single point of failure (SPOF)—e.g., clustering, load balancing, storage, firewalls, etc.
Each 3PL Central customer has their own database instance to provide additional security and physical segmentation of data. 3PL Central conducts weekly full, daily differential, and hourly log backups of each of these 3PL Warehouse Manager databases.
These backups are encrypted at rest and stored on the local storage for 72 hours for quick access in the event of an emergency. They are also stored in a separate S3 bucket for 14 days to protect against accidental or nefarious changes (e.g., ransomware attacks). They are retained for 100 days in Glacier for additional protection before being purged.
The application can be accessed from any major browser via secure TLS connection, and all application passwords are encrypted and set by a 3PL Warehouse Manager administrator.
Here are some helpful resources to learn about the AWS Compliance certifications:
Disaster Recovery plan
While 3PL Central has spent considerable efforts to ensure uptime in our primary production facility, Disaster Recovery must always be considered to provide additional protection in a worst-case scenario.
The purpose of a Disaster Recovery Plan is very specific—to get 3PL Central customers up and running with at least base functionality in a reasonable timeframe in the event of a disaster that affects a portion of our production infrastructure. 3PL Central leverages the capabilities of the multi-AZ (Availability Zone) infrastructure provided by AWS to be “better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more. AZ’s are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.”
In the event of a disaster at one or two of the three AZs, the 3PL Central servers will migrate servers and route traffic automatically to the remaining Availability Zone(s) to continue operation with minimal interruption (seconds to minutes).
3PL Central also leverages the power of Infrastructure as Code (IaC). This allows the 3PL Central team time to spin up predefined infrastructure in a matter of minutes to handle additional load in the event of a spike or to migrate infrastructure to another region should a disaster be that significant to require that drastic of an action. To learn more, please see Introduction to DevOps on AWS.
At 3PL Central, the Product Engineering team is responsible for writing, maintaining, and running tests at the following levels: unit, integration, and system. The Cloud Operations team is responsible for writing, maintaining, and running tests at the operational acceptance level—which includes security, performance, failure, and recovery.
Each development ticket released by 3PL Central (as documented in our release notes) is tested at one or more of the levels defined below.
Unit testing is the testing of smaller units of code to ensure the software works as specified and that it has the appropriate error handling implemented. Unit testing is continuous and a standard part of the development methodology. These tests are written for each code change and run after every build.
Integration testing is the testing of interfaces between software components to ensure they perform as designed. The tests typically start with a limited set of software components being tested together. Additional software components are then added to the test until the software works as a system. Integration testing is largely covered by automated tests at the REST API level, which are run after each code deploy.
System testing is the end-to-end testing of a completely integrated system to verify that the system meets its requirements. System testing includes functional testing to validate that the software meets the requirements and generates the expected results.
- Functional tests are created from requirements and user stories.
- All user story and bug tickets are covered by both automated and manual testing efforts.
- Automated end-to-end tests are written in the Cypress framework.
- Manual system tests are performed at both the ticket and function level—in other words, both the parts and the sum of the parts are tested.
System tests are performed all throughout the build and release cycle.
Security testing is a type of testing that ensures software applications are not vulnerable to intrusions so that confidential data is protected. Security testing is largely performed by automated scans that analyze the code for vulnerabilities.
Performance testing is a type of testing that ensures software applications will perform well under their expected workload. Performance testing includes a number of different types of tests—the most commonly used at 3PL Central being load testing.
Load testing determines a system's performance under real-life load conditions. This testing helps determine how the application behaves when multiple users access it simultaneously. This testing usually identifies the maximum operating capacity of an application. Load tests are run prior to each of our regularly scheduled Wednesday night deploys.