The Cloud Native Journey of an online platform begins!


AppQuality is a solution designed to help companies create user-centric products and services by involving their community – the Crowd – of real people in all stages of the process, from design to development and testing. The service offered aims to bring products and services to the market, while ensuring a memorable user experience for real users.

The proprietary platform that hosts and feeds the community and makes it possible to organize the test execution and feedback collection activities is clearly a mission-critical element for AppQuality. Indeed, the architecture of the solution and the infrastructure that allows it to function must guarantee the highest level of reliability and optimum performance.

In 2020, AppQuality chose SparkFabrik to embark on the Cloud Native transformation of the platform, through the acquisition of knowledge and best practices focused on the Cloud Native landscape.

Cloud Native Journey of a crowd-testing platform
Application Modernization, Cloud Native Journey, AWS platform, DevOps & Automation
Starting November 2020

The challenge

The Cloud Native Journey is a complex transformation that affects the entire software production cycle. Businesses and teams that decide to embark on this journey are well aware – or soon discover – that significant changes are imminent. An aspect which, unquestionably, represents the biggest challenge to success and, to start off on the best possible footing, in-depth knowledge of the environment and of the existing processes is needed. This is precisely why our journey begins with a barrage of questions addressed to the development team, asked to describe the existing architecture and the detailed operation of its components, data flows and development tools.

The first need that emerged was to standardize the development environment so that it could be used by team members who work on heterogeneous platforms, both in terms of operating systems as well as IDEs. This was the focus of the first phase of the Cloud Native Journey, aimed at finalizing the containerization of the main application and rendering 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 operating systems (Linux, Windows, MacOS) with different editors and IDEs (VSCode, PhpStorm).

Moving on to the next phase, the goal shifted to the creation of a Proof of Concept of a real deployment of the application based on container orchestration. This process was preempted by an introduction to the concepts and practices of declarative configurations, shown in action both as regards the infrastructure, as well as the application architecture.
The real challenge is to validate the feasibility, advantages and possible limitations of this type of solution in the field. A further problematic aspect consists of the specific characteristics of the AppQuality application, based on a CMS, and thus a type of application that is generally “monolithic” and requires particular attention when it comes to cloud native transformation. During this phase, various needs related to the specific characteristics of the platform emerged, providing the opportunity to explore innovative solutions to deal with aspects such as distributed log management, persistence on file systems, user authentication and authorization, as well as networking with services inside and outside a cluster.

Finally, during the last phase, the elements identified in the previous stages were included in the development and management processes of the source code, in turn enriched by the Continuous Integration and Continuous Delivery best practices. This, in order to increase the quality and reliability of software releases, which in AppQuality’s case happens at a fast pace, at the end of each sprint. In this phase, the already familiar tasks of Continuous Integration (testing automation and QA controls) were supplemented with interactions with typical cloud native architecture components such as a container registry, together with proposals for different delivery options for pipeline artifacts, with varying levels of automation possible.

The method

As we mentioned earlier, the Cloud Native Journey begins by getting a good and thorough understand of the processes and tools used by the development team. The result of this analysis, which continues even during the course of the journey, when implicit knowledge not originally shared emerges, subsequently servesto model the different stages of the journey, defining the concrete objectives to be achieved during each phase and precisely how to do so in practice. This, because the Cloud Native Journey is much more than a body of knowledge transferred based on a “frontal” approach. Rather, it is a set of finished digital objects (in the sense of “done”), mainly consisting of source code that the team has already started working on during the journey and may also do so in the future.

At the end of the initial assessment phase the discussion with the team took into account the mode of interaction that was most functional in terms of not interrupting and not impacting the timing of other development activities in progress.

  • Two weekly slots that were available and not overlapping with recurring commitments (sprint plans, releases, etc.) were identified and it was decided to meet on a weekly basis in order to provide updates on the progress of the activities.
  • We obtained access to the source code repositories and to the tracking system for bugs and development tasks.
  • We opened a shared channel on Slack used as an organizational tool, as well as to ask each other questions during the week.

At the beginning of each phase, the objectives and deliverables of the phase were shared, as part of a co-design process that confirmed or offered new insights on the results of the initial assessment and helped illustrate the practical needs of the team with respect to the Cloud Native transformation.

Contact us for your next project

For more information about us and what we can do for you leave us a message. We will contact you as soon as possible.

Send us a message!

Read our Privacy Policy


Phase 1 (containerization)

  • Dockerfile code for creating container images and facilitating their orchestration in local environments (Docker Compose)
  • Within the same code repository, documentation was added for the setup of development environments on the various platforms used in the team
  • Crowd ecosystem architecture diagram, revised several times along the way

Phase 2 (deployment based on container orchestration)

  • Code for the declarative configuration of the current infrastructure
  • Materials used to provide a brief introduction to the Kubernetes architecture and the use of Infrastructure as Code
  • Code for the declarative configuration for a Kubernetes cluster on the AWS cloud (EKS)
  • Declarative configuration of the application installed in the cluster created
  • Helm chart for the installation of packaged solution components
  • Diagram of the Proof of Concept used for the implementation of the Crowd platform and additional 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, revised several times along the way

Phase 3 (CI/CD)

  • Code for the Continuous Integration and Continuous Delivery pipeline for a Crowd platform component
  • Example diagram of an approach to pipeline management based on branching and tagging

    Matteo Toto


    Anyone who has developed technology in their professional career knowns precisely how difficult it is to concentrate on solving business or product problems, while maintaining technological excellence. This implies a continuous and tireless commitment and ability to study which, as we know, does not always turn out to be the case. The Cloud Native Journey with SparkFabrik presented a very important opportunity for dialogue and growth. The team members were patient and available when it came to our needs, as well as to unexpected events. Moreover, the team was able to grow and develop their skills, sacrificing very little in view of the important objectives that could not be put off, guaranteeing business continuity

    Our latest Case Studies


    Cloud Native Services, AWS platform, DevOps & Automation

    Samaritan, an Internal Developer Platform for the digitalization of full-cloud Healthcare

    Il Giornale

    Application Modernization, Drupal, AWS Consultancy & Managed services, DevOps & Automation, Google Cloud Platform, Data Engineering

    How we turned an historical Italian news outlet Cloud Native.

    Zambon Product Websites

    Drupal, Google Cloud Platform, Alibaba Cloud

    How the Zambon product websites became cloud-native