The United States
The client is a B2B software company with a data analytics product. The product was reaching its release after a long cycle of development. However, the requirements for the platform and distribution model were vague, so Corewide as a DevOps vendor had to develop both the application infrastructure and delivery model. Keeping flexibility was also a crucial part to maintain a “distributed” approach if the clients wanted to run the computing part of the product on their premises. The application was written in mostly pure Python, and the business logic heavily relied on PostgreSQL functions.
Long time to market. The majority of the existing application functionality was based around the usage of PostgreSQL functions. Any change in the database structure had to be explicitly defined as a new SQL file. Thus, it was required to run a set of custom migration scripts in a specific order to start the application. The number of scripts had grown over the years by the time we got introduced to the project. This system was obscuring the setup of any of the environments and was taking hours to prepare the application to work.
Lack of technical documentation. The setup had no clear documentation and structure drastically increasing the time to onboard.
Absence of application reproducibility. Lack of consistency in documentation and a clear way to run the setup was resulting in different behavior in different environments. This was obscuring the development process and was leading to unexpected behavior between local and production environments
No production-ready infrastructure. The application was aiming to be a B2B platform. However, it had no clear infrastructure architecture besides manually spawning per-customer virtual appliances that would later be upgraded (also manually) to a newer release. It was important to provide a production-grade design from the start that would allow us to abstract the application away from the infrastructure and let it scale separately.
We performed an initial audit to get familiar with the application stack and gathered business-level requirements.
It was suggested to switch the outdated application logic built around PostgreSQL functionality to Django as this framework perfectly aligns with the application logic and future plans as well as taking the least possible actions to update the code to match the industry standards and best practices. Django’s ORM is powerful enough to handle complex querying the initial application version tried to encapsulate in PSQL functions. However, the business demanded to have a working MVP first in order to proceed. So our DevOps engineers automated the process of application bundling by introducing Docker: developers were able to easily get a working persistent version of the application although the build time was wanting - around 8 hours due to application architecture specifics. The build process was automated with CI/CD to relieve the burden of bundling from the development team. Then, we provisioned a portable infrastructure solution built around cloud-managed Kubernetes. This approach allowed running the current version and considered further updates and upgrades on the application level. After the MVP demo, with coordination with the development team the application was updated to use Django within two weeks. Since the majority of the DevOps decisions made by Corewide are designed to be environment-agnostic, the newer application version was then provisioned to the infrastructure with the least possible actions.
Once the application architecture was stable and running in the Corewide-provisioned infrastructure, the next step was to provide the ability to host the client part of the product on the client’s premises. We utilized automation tools to create an easy-to-use bundle that bakes the client’s application part of the product into a VM image with Packer and then uses Terraform to provision it to the cloud.
We provided both project and infrastructure-level documentation. It contains guides on how to work with the implemented tools as well as describes the application and infrastructure layers along with their implementation and usage.
The application build time was reduced by 15 minutes (by ~3200% approx). The uptime improved up to 99.5% (from the average of 68%) due to simplified application architecture and lower reliance on the complex PostgreSQL functions. The overall costs dropped by 30% as well since the application stopped being built around the database and thus, expenses for its computing and maintenance got reduced.