Historical background
When we first entered this market back in 2013, our domain of expertise lied mostly in the area of software development. The printing industry was unexplored territory for us at that point. That affected our strategy for developing our product. We chose to focus on the front-end aspect and deliver the most powerful online editor for print product personalization. The back end of Customer’s Canvas was mostly for rendering print-ready files. We were delivering a designer module that each client could integrate into their own back end to manage assets and user data via a powerful API.
It eventually became clear that this approach was working very well for some of our customers that already had their back end. For those who didn’t, however, the integration was not exactly painless. In particular, the earlier versions of Customer’s Canvas had the following problems:
- Customer’s Canvas relied on data stored in the file system and lacked an intermediate layer allowing connections to different external data sources. For example, if you wanted to store your assets in the database, Customer’s Canvas wouldn’t be able to support this use case.
- There were difficulties with scaling up the projects. The architecture implied that all data would be stored in the same place.
- Storage overflow was a serious threat to stable operations, which is a problem for large volumes.
A few years ago, we developed a hosted service to overcome these problems. This was a simple file manager that made it easier to upload and manipulate product templates and design assets. But this workaround was still too complex for employees that weren’t tech-savvy.
As our product matured, we gained a better understanding of what our clients were demanding from a back end for a web-to-print integration. This ultimately led us to create our own asset management system for both hosted and on-premises users.
Introducing BackOffice
Customer’s Canvas BackOffice is basically an admin panel that simplifies the management of a web-to-print integration. Any integration has several different data types, for example, design assets like templates, fonts, color schemes, image libraries, and others. We also needed to consider product options like size, color, or price as well as product configurations, i.e. default settings, validation rules, and interfaces. On top of all that, we needed to something with the e-commerce integration and user data. Using BackOffice, even non-technical staff can manage all of this data.
We had to address several challenges during the development process, including these four major issues:
- Architecture
- Multi-tenancy
- Scalability
- E-commerce integration
Architecture
When we began to evaluate this project, it seemed like a standalone application with its own database and entities. The architecture appeared pretty straightforward at first glance and was initially planned to be monolithic. But as we dove deeper into this project, it became clear that BackOffice might actually be something more than just an admin panel. It could become the central hub for managing an entire web-to-print integration. To provide the desired flexibility to add new modules in the future and to ensure scalability, we decided to pivot to microservices architecture. We will break down these components in more detail in future blog posts.
Transitioning from monolith to microservices architecture was not easy. Such an undertaking requires a sophisticated DevOps and CI/CD infrastructure as well as a lot of testing before delivering updates. The only way to eat the elephant was one piece at a time. At this point, our architecture could be described as “micro-monolith”.
Multi-tenancy
We realized that web-to-print integration - especially for big projects - involves many users to operate properly, whether they be graphic designers, sales specialists, website administrators, or other personnel. Each role should have its own isolated area to ensure security and privacy.
We had two options to accomplish multi-tenancy:
1. Revisit Customer’s Canvas’s basic architecture and include multi-tenancy in its core to operate with files on a low level.
2. Create separate Customer’s Canvas instances for each tenant to separate files physically.
The first approach is certainly more favorable if you are creating a new application. For us, it would mean creating Customer’s Canvas from scratch, which would be an absurdly time-consuming and costly project. On the other hand, creating a full copy of Customer’s Canvas for each tenant would be a clumsy solution that demands a lot of resources.
Naturally, we decided on something in between. Customer’s Canvas can operate with an unlimited number of instances, and those instances might access assets associated with tenants while maintaining security for those files. Our ultimate goal is still to eliminate the need for creating separate copies of the application for each tenant. We are about halfway to this most ideal solution.
Scalability
Right now there are two key players that dominate the cloud service market: Amazon AWS and Microsoft Azure. Since Aurigma’s technology was historically built on .NET, the decision to go with Microsoft Azure, as the more native platform for Customer’s Canvas, was not difficult for us. It’s been the primary service we’ve chosen since the early days of developing BackOffice.
We wanted to avoid getting locked into one vendor and remain flexible for customers that prefer AWS or other cloud service providers, so we kept the door open for other options. Azure integration is the most optimized and provides full functionality, but other setups are possible, including on-premises installations.
Scaling is usually comprised of two main parts:
- Scaling data
- Scaling performance
Scaling data
The big obstacle here was to teach BackOffice to store all data in Azure Blob Storage (and other options with infinite cloud storage like Amazon S3). This solves the problem of maintaining and expanding data storage as needed.
Scaling performance
Getting the data onto the same server that runs Customer’s Canvas is the main challenge for scaling performance. Running it on two or more servers required full data replication – a near-impossible task to solve. The solution to scalability is to use a stateless application rather than a stateful one.
Stateful applications perform in the context of previous operations and store the service data, making it impossible to deploy such applications in the cloud.
By contrast, stateless applications function in isolation. Each operation is made from scratch for the first time. These types of applications use data and requests from other servers.
In order to make Customer’s Canvas scalable, we needed to transform it into a stateless application. To achieve this, we had to separate files from the editor and teach the editor to work with assets and configuration files located elsewhere.
E-commerce integration
One of BackOffice’s key features is the easy and intuitive way it integrates the online editor into third-party e-commerce platforms. We accomplished this by introducing a new level of abstraction to exchange data from any commercial or internal software. We also developed special connectors to simplify integration with the most popular e-commerce platforms, but it’s still possible to connect Customer’s Canvas BackOffice to any software with a public API.
Another important element of this API is the ability to create user interfaces tailored to the personalization scenario and specific products, which dramatically increases the flexibility of the integration and available use cases.
Conclusion
Although it was originally intended as a solution to the narrow task of data management, BackOffice has become the catalyst for a massive rethinking of our whole product on many different levels. Not only has it impacted the product itself, but also the approaches we use to plan, develop, and deliver the software to our customers. We devoted considerable energy and resources to deploy BackOffice and the new horizons it has opened up for Customer’s Canvas has made that effort completely worth it.
