⏱ Estimated reading time: 11 minutes

Table of Contents

Why do we prefer managed Cloud services?

By Guillaume Lannebere, Head of Cloud Center of Excellence @ Betclic

PCI-DSS

Companies handling sensitive information such as credit cards are subject to stringent norms in the likes of PCI-DSS. This ensures that strong practices are followed regarding information security and fraud protection. However, a company cannot simply state that it is following standards: audits certify these claims. In PCI-DSS, there are four levels of reporting and the most stringent is triggered whenever a company processes over six million transactions per year. At this level, external independent qualified auditors evaluate the compliance and produce a report and an attestation of compliance.

In most organizations, multiple teams are fully dedicated to prepare for audits, identifying and solving potential non-compliance reports. In the long run, this leads to more effective mechanisms to secure data and infrastructure, benefitting everyone. Organizations tend to segment their infrastructure so that the PCI-DSS scope is cleanly separated from the rest of their IT assets. This means:

  • Dedicated infrastructure for credit card information;
  • Encryption everywhere before transit and before storage! Data gets stored pre-encrypted;
  • Unwieldy software stacks: Windows Server, Microsoft SQL Server, Microsoft IIS, Microsoft Entra, .NET;
  • Resource-intensive monitoring and administration tooling;
  • Complex administration procedures, mostly to comply to the standards.

Simplifying audits

Every organization, technical architecture and audit process are different: PCI-DSS scopes are fuzzy, technology and organizations evolve, the state-of-the-art changes and so on. There is a clear need of simplification:

  • Minimizing the PCI-DSS scope;
  • Establishing clear frontiers in terms of software, delivery, infrastructure and so on;
  • Minimizing operations to minimize processes, reporting and thus reports. This includes infrastructure and operating system setup and maintenance;
  • Continuous auditing;
  • Process, infrastructure and software changes beneffiting audits, such as payment tokenization or client-side encryption.

The Cloud Shared Responsibility Model helps organizations understand how the Cloud is there for them and where it is not. The actual model depends on what is being consumed: a SaaS customer does not expect to be fiddling with operating systems and runtimes. AWS offers a wide range of compute services, each taking pieces off the responsibility model:

  • Amazon EC2 Instances require the customer to manage everything from the OS up;
  • AWS Fargate leaves container images and their contents to the customer;
  • AWS Lambda requires at least the code to run, for supported runtimes;
  • Some services such as Amazon RDS only expose configuration and their nominal function. These require the least amount of management and responsibility.

Using compliant services and serverless or managed infrastructure components can truly make a difference during audits.

Architecture and key learnings

Vendor lock-in has to be considered as a key decision: cloud vendors offer large collections of services which can offer integrations with each other. This integration adds friction to move off said provider but removes procedures, maintenance and glue code which in regulated contexts can significantly impact audit preparedness positively!

An example of PCI-DSS compliant architecture for AWS would be:

Amazon CloudFront           https://aws.amazon.com/cloudfront/
+ AWS Shield                https://aws.amazon.com/shield/
+ AWS WAF                   https://aws.amazon.com/waf/
    -> Amazon API Gateway   https://aws.amazon.com/api-gateway/
    -> AWS Lambda           https://aws.amazon.com/lambda/

AWS CodeBuild               https://aws.amazon.com/codebuild/
AWS CodeDeploy              https://aws.amazon.com/codedeploy/
AWS Audit Manager           https://aws.amazon.com/audit-manager/
AWS Artifact                https://aws.amazon.com/artifact/
+ Many security services

From the application side, client side encryption with the payment processor’s public key or payment tokenization and a statically generated website that can be traced back to its source code. AWS Audit Manager handles daily PCI-DSS compliance checks from the infrastructure standpoint and can deliver a report ready for use during the audit.

At Betclic, this change cut resources dedicated to auditing from five teams during three months to just four people during three days and costs $400/m. on AWS. Additionally, the infrastructure removes most worries about licenses, operations and security and freed time for more innovation opportunities!

Though these infrastructures may not be suited for everyone: they require some cloud architecture experience and existing apps may not be perfectly suited for event-driven processing. Additionally, your cloud provider or services of choice may not be compliant with PCI-DSS or offer continuous auditing capabilities.

Questions and Answers

Did the loss of control from using managed services caused any issue?

Serverless indeed works as a black box and requires customers to trust their cloud service provider. Any service disruption is to be handled by the provider: the customer will be powerless in most cases unless they architected their service around provider failure.

What do such changes require organizationally?

Learning everything: the cloud, CI/CD, learning about a second cloud provider, infrastructure as code. Fortunately, each cloud provider has a program to get started and get the most out of their services with trainings and office hours. Finally, the organization had to change to focus on overall better practices.

How did you manage to scale AWS Lambda beyond 1000 concurrent requests?

First, read this guide about AWS Lambda scaling. Then you will need to increase quotas and use prewarming and provisioned concurrency to eliminate all cold starts and go beyond invocation limits.

MAUI: Multi-platform App UI

By Julien Daugaron, Fullstack developer @ Avanade
By Stéphane Louge, Solution Architect @ Avanade

We have often seen this promise: one framework to rule all platforms, to create universal applications that offer the same experience across desktop and mobile, Windows, macOS and Linux. These frameworks often suffer from the same fate: lack of adoption because they are lacking in terms of abilities to customize, features, performance or openness.

As support for Xamarin neared its end on May 1st 2024, Microsoft announced its successor Multi-platform App UI, or MAUI for short. This new framework can target iOS, Android, Windows, macOS, Tizen and many more platforms. Its codebase is written in .NET 8, will follow future language evolutions and its performance makes it a solid choice compared to Xamarin.

Alternatives

MAUI is far from the first cross-platform UI framework. Some of its competitors are Flutter, Ionic, React Native, Uno and Avalonia. What differentiates it from the rest are its features:

  • A project structure where one project can target all platforms;
  • The translation layer between the framework’s declarative UI and the target platform UI elements is developed and maintained by MAUI;
  • Assets are shared and selected per platform depending on its needs: vector images are converted to matrix images of appropriate size, fonts, icons, etc.;
  • Code can be written for specific platforms using compilation flags (pragma), file or directory name conventions or markup;
  • MAUI exposes platform objects, making it possible to leverage features and properties specific to a subset or the targets;
  • Xamarin used renderers, MAUI uses handlers. Handlers are lighter and can be mapped with application logic, though custom control logic requires different handlers per platform.

Tooling

Before a tool or framework reaches critical mass and its community becomes self-sustaining, it is expected for the development experience and the backing foundations to be solid. On that front, MAUI provides:

  • An extensive documentation and many GitHub repositories;
  • XAML Live Preview, a Vidual Studio extension that works as a live preview connected to the code base. It becomes easy to trace back the handler for an interface element;
  • Live Visual Tree and Live Property Explorer offer visual representations of the app, its components and highlight the component selected in the live preview;
  • Hot reloading;
  • MVVM Community Toolkit, for a solid implementation and easier adoption of the Model-View-ViewModel pattern;
  • MAUI Community Toolkit, for a collection of reusable components to speedup common development tasks;
  • Syncfusion, DevExpress and Telerik have developed complex component libraries.

Development

There are multiple ways to develop interfaces with MAUI:

  • XAML plus some code, the classic way of doing with but limiting on larger codebases;
  • Model-View-Update, similarly to React;
  • Model-View-ViewModel, which isolates the view, the model and the abstraction between the two in a ViewModel. In MAUI, the view can be expressed with XAML or code for special cases, the model is the app and the ViewModel is done through commands and bindings. Bindings are sort of subscriptions.

A ViewModel is a class implementing the PropertyChanged event to react to… well, property changes. The code is generated by MAUI following ObservableProperty attributes.

Views communicate to ViewModels through Commands. Commands implement ICommand, which exposes two methods:

  • CanExecute, that determines whether the command can execute;
  • Execute, which defines what to do when the command executes.

The View and the ViewModel need more than one-way interactions. This is why bindings come in four modes: OneTime, OneWay (ViewModel to View), OneWayToSource (View to ViewModel) and TwoWay. Bindings are dynamically loaded by default but can be compiled as long as their x:DataType is specified. References between components are possible between x:Reference and x:Name and to parents with relative bindings.

As for layout, common elements such as CollectionView, VerticalStackLayout and HorizontalStackLayout are native to MAUI. These layouts contain a list of elements displayed following a given template and implementing a style. CollectionViews implement a VerticalStackLayout by default, though this is configurable. Grids are a welcome addition, as are custom layouts.

Best practices

It is hard to overstate how important it is to test your multi-platform apps on physical devices from these platforms! Test their features extensively, benchmark their performance, the retro-compatibility of your code with older platform APIs, aspect ratios, etc. Debugging on iOS will require a Mac or using a specialized test platform such as LambdaTest.

Developing for desktop and for phones is a different experience: these devices no not share the same capabilities, although performance optimizations for mobiles devices will equally benefit desktop users. For instance, do not surround CollectionViews with scrollers, as CollectionView implement scrolling and dynamically load their contents. Simple content trees require less work from the engine and result in improved performance for the end user.

Finally, test your apps in Release mode as its compilation process is different from Debug mode.

Questions and Answers

What is the development experience like on Visual Studio Code and other IDEs?

The official MAUI extension is available on Visual Studio Code but not on its forks. The MAUI integration in Rider from JetBrains works but is shallow. On macOS, MAUI is supported in XCode.