Modern software development has to meet many different requirements: functions should be able to be implemented more quickly, applications have to scale, security should be guaranteed, the quality has to be right, and the whole thing at minimal costs. This article is about using two not completely fictitious examples to show how and why the transformation to DevSecOps supports developers in meeting these different requirements.
Example 1: Forced to succeed
The provider of a SaaS solution finds itself completely surprising in the situation that its existing offer was able to win a very large customer segmented by country. The challenge is to scale up the solution from five customer instances to 100 and to distribute these instances globally.
Many modern application architectures assume that multi-tenancy is an integral part of the architecture and that it is good and right if all customers share a highly scalable instance of the application. In this case, the following reasons led to a deliberate decision not to use a centralized solution:
- Law: The separation of the clients into their own instances made it much easier to meet country-specific legal requirements.
- Security: The separation of the clients in their own instances served as a sales argument and led to a high level of customer acceptance.
- Software architecture: The architecture of the software led to a simplification.
- Individual adjustments: The solution had to offer very flexible white labeling, and that was easier and cheaper to implement in separate instances.
Hurdles and decision making
The existing platform was based on a virtualization solution hosted in the company’s own data center. Certain components such as the web application firewall were shared by all customer instances, but the application components of each customer instance ran on their own, virtualized computers.
The first attempt was made to scale the existing virtualized solution. However, it quickly became apparent that the lack of automation and the extremely high resource consumption of virtualization made the ambitious project goals unattainable and also endangered the economic success of the project.
A bold plan arose out of necessity: the platform should no longer operate its own data center, but move to the cloud. As a second change, the application itself should be rolled out as a container.
Moving to the cloud
The decision to build the new platform entirely in the cloud turned out to be the right one. From the point of view of costs, investment costs were shifted to a service price that automatically scaled with the use by the customer and could thus be billed transparently. By choosing a suitable cloud provider, it was very easy to offer local instances for the global major customer. The operation, which now had to be ensured around the clock, required the recruitment of additional staff. Thanks to the tools available on the cloud platform and the high level of automation, the operating expenses only increased moderately. The move to the cloud even led to savings because the construction and maintenance of the hardware and network infrastructure were now purchased and no longer had to be done by the company’s own employees.
In addition to the platform, the application also received a makeover in that it learned the migration from a traditional installer model to containers. The goal was to achieve a high degree of automation in order to be able to operate and maintain the massively increased number of instances with the same number of employees. The tight schedules for the delivery of the new instances to the customers could not have been kept without automation.