The Cloud Native Journey of an online platform begins!
Cloud Native Journey of a crowd-testing platform


AppQuality (Unguess since January 2022) is the solution that helps companies create user-centric products and services by involving its community (the Crowd) of real people in all phases of the process, from design to development up to testing. The service offered has the objective of bringing products and services to the market with a memorable user experience for real users.


Accompany the Customer along the path of adopting a Cloud Native approach.


The Cloud Native Journey is a transformation that affects the entire software production cycle. The company and the team that decide to embark on the journey know (or soon discover) that significant changes are on the way: this is certainly the biggest challenge and to start it in the best way a thorough knowledge of the environment and of existing processes. For this reason, our journey begins with a barrage of questions asked to the development team, which we ask to describe the architecture and the functioning of its components, data flows and development tools.

The first need that emerged was to uniform the development environment so that it could be used by team members working on heterogeneous platforms, both as operating systems and as IDEs. This was the focus of the first phase of the Cloud Native Journey, aimed at completing the containerization of the main application and making the container-based implementation compatible with the platforms used by the development team. At the end of this phase the container-based environment is available to be used for development and debugging activities on different OS (Linux, Windows, MacOS) with different editors/IDEs (VSCode, PhpStorm).

After the first phase, the goal moved to the creation of a Proof of Concept of a real application deployment based on container orchestration. This process was anticipated by the introduction to the concepts and practices of declarative configurations, shown at work both in terms of infrastructure and application architecture.

The challenge is to validate the feasibility, advantages and possible limitations of this type of solution in the field. A further challenging element is constituted by the specific characteristics of the AppQuality application, based on a CMS, a generally “monolithic” type of application that requires particular attention for cloud-native transformation.

During this phase, several needs related to the specific characteristics of the platform emerged, which provided the opportunity to explore innovative solutions to address the distributed log management, the persistence on file systems,authentication and user authorization,networking with services inside and outside a cluster.

Finally, in the last phase, the elements seen in the previous segments were included in the source code development and management processes, enriched by the best practices ofContinuous Integration and Continuous Delivery, to increase the quality and reliability of the software releases, which for AppQuality occurs at a rapid pace, at the end of each sprint. In this phase, the already familiar tasks of Continuous Integration (automation of tests and QA controls) were added to the interactions with the components of a native cloud architecture, for example the container registry, and the different options of delivery for pipeline artifacts, with different levels of automation possible.


As mentioned above, the Cloud Native Journey starts with gaining insight into the processes and tools used by the development team. The result of this investigation, which also continues during the journey, when the presence of implicit knowledge not originally shared emerges, then serves to model the stages of the journey, to establish the concrete objectives of each phase and how to achieve them in practice. This is because the Cloud Native Journey is not simply a set of knowledge transferred in a “frontal” way, but a set of finished (in the sense of “done”) digital objects, mainly in the form of code on which the team has already started working during the trip and will be able to do so again in the future.

After the initial assessment phase, the interaction method that was more functional than not interrupting and not impacting the timing of the other development activities in progress was discussed with the team.

  • We identified two weekly slots available and not overlapping recurring commitments (sprint plan, releases, etc.) and it was decided to meet every week, to update on the progress of the activities.
  • We have received access to the code repositories and tracking system for bugs and development tasks
  • We opened a shared channel on Slack used as a organization tool and to ask each other questions during the week

At the beginning of each phase, the objectives and deliverables of the phase were shared, in a moment of co-planning which confirmed or further explored the results of the initial assessment and clarified the practical needs of the team with respect to the Cloud Native transformation.


For this case the results are not quantitative if measured at release, but coincide with what has been concretely left to the internal development team in terms of concrete deliverables.

Phase 1 (containerization)

  • Dockerfile code for creating container images and orchestrating them in local environments (docker compose)
  • Documentation for the set up of the development environments on the various platforms used by the team has been included within the same code repository
  • Crowd ecosystem architecture diagram, reviewed multiple times along the way

Phase 2 (Container Orchestration Based Deployment)
  • Current infrastructure declarative configuration code
  • Materials used for a brief introduction to the Kubernetes architecture and the use of Infrastructure as Code
  • Declarative configuration code for an AWS Cloud Kubernetes cluster (EKS)
  • Declarative configuration of the application installed in the created cluster
  • Helm chart for installing packaged components of the solution
  • Diagram of the POC that implemented the Crowd platform and ancillary services in a Kubernetes cluster
  • Example of an application able to interact with the Kubernetes API thanks to a client library
  • Crowd ecosystem architecture diagram, reviewed multiple times along the way

Phase 3 (CI/CD)
  • Continuous Integration and Continuous Delivery Pipeline Code for a Crowd Platform Component
  • Example Diagram of a Branching and Tagging Approach to Pipeline Management
Matteo Toto

Matteo Toto

CTO, AppQuality

Those who have developed technology in their life know how difficult it is to focus on solving business or product problems while maintaining technological excellence. This requires continuous and tireless study skills, but we know that we don't always manage to be like this. The Cloud Native Journey with SparkFabrik it was an invaluable opportunity for discussion and growth. The team members were patient and available with respect to our needs and unexpected events, the team was able to increase their skills by sacrificing the minimum compared to the important objectives that we could not postpone, guaranteeing business continuity.

Do you want to discover what it would be like to be part of our team?

Look at our open positions and immerse yourself in the world of our values.

Are you looking for a partner who can make a difference?

Getting to know us better is the first step in understanding how we can help you.