The cloudtec platform stack

The post The stack as a foundation for online platforms and portals looked at what a software stack does in general. Here it gets specific: our own stack, its components and the reasons for how it is built.

The building blocks are established open-source components throughout. The result is a foundation designed for long operation that still stays flexible: individual parts can be replaced without everything depending on them.

How the stack came about and what went wrong first

For us too, every project runs in the triangle of time, quality and budget. The idea of always starting new projects on the same software and infrastructure foundation came from the simple observation that we kept building the same groundwork over and over again.

The first attempt failed nonetheless. New developments could not be fed back into the stack, so it could not grow with the projects and set-up did not get any faster. The solution was branching and subtree splits: since then, improvements from one project land back in the shared foundation.

A second detour was the templates. At the start we used many different ones, which made management and design unnecessarily laborious. With the decision for a fixed template library, development and design became consistent. Everything can still be adapted to corporate design and client requirements. At the same time, we switched the application language from German to English.

The deployment process was also standardised step by step. Since then, downtime during a deployment has been around 20 seconds at most. We continuously revise server and database configuration as well as file system management. Because the stack runs from the infrastructure all the way to the software, installation is largely standardised. That reduces the complexity of a platform and simplifies its operation.

The layers of the stack

When choosing technologies, frameworks and languages, one principle applies: open source. Such components are continuously developed further, can be adapted in depth and do not tie us to a vendor.

The stack is divided into four layers:

• The infrastructure layer provides the technical foundation on which everything runs.
• The platform layer supplies the frameworks and the recurring functions of an online platform.
• The software layer is the custom development for each client.
• The security layer spans the other three with monitoring, error detection and off-site backups.

The infrastructure layer

No application runs without it. We opted for a uniform environment with Docker: it no longer has to be set up for each project, each with its own PHP version and operating system. Locally, a replica of the production environment is created with the same configurations. That makes set-up and development fast and debugging predictable.

Docker separates the application from the infrastructure. The operating system is containerised and abstracted. This is also how we provide auxiliary services such as virus scanners and PDF indexing, which talk to the project containers locally.

Then there is Portainer for container management: managing, configuring, orchestrating and securing containers centrally, with a web interface for day-to-day work.

Hosting, containers and the virtual data centre (and with them all project data) stay with us. We run the servers and are responsible for versioning. Client data is kept isolated in its own container and cannot get mixed up.

Two further components of this layer are security and DevOps. A large part of the deployment processes is automated via DevOps. On the security side there are a firewall and a web application firewall, network segmentation and automated checks in the build process.

The platform layer

The foundation is formed by Symfony and Sylius, both based on PHP and extensible at will. Symfony provides reusable components for web applications, APIs and microservices.

We chose Symfony because it does not bring along exactly what other frameworks impose, a ready-made CMS for example. Sylius builds on it and supplies the functions and APIs for running an online shop.

On this foundation we added what an online platform usually needs: grid mechanisms, filters, user management and the groundwork for messaging. RabbitMQ is added so that interfaces can be connected with transactional safety, and API Platform for REST and GraphQL endpoints.

The software layer

This is where the stack meets custom development. It is extended and adapted according to the project’s requirements: interface, client-specific modules, roles and access.

Technically, the limits are wide; the question is usually a different one. Does the benefit of a special solution justify its effort, in the build and in every later update? If not, the standard variant is the better answer.

What the stack gives us

• Many business applications have similar requirements: lists, filters, user management, workflows.
• A new project does not start from scratch.
• Anyone joining an existing project already knows how it is built.
• Recurring functions are built once and used many times.
• The base components are comprehensively tested, which benefits every project.
• Less in-house building means less technical risk.

The stack is not a finished product but keeps growing with every project. What has proven itself once is available to everyone the next time.