Devops for Growth

Un schéma qui explique les relations entre les pratiques techniques et l'agilité.

For innovative software organizations, managing the overall cognitive load on their teams is a guiding development and operational principle.

Le système d’information 3-tiers MarieKisSlaJoue

Deux articles ont récemment été publiés par SoundCloud pour décrire l'évolution de leur architecture de service vers la mise en oeuvre de Domain Gateways, en passant par les Value-Added Services. Les auteurs décrivent comment ces patterns basés sur le Domain-Driven Design ont aidé à réduire les doublons et à homogénéiser la logique métier et le contrôle d’accès.

Un value-added service est un service qui est chargé de fournir des agrégats à ses appelants. Les Domain Gateways permettent de gérer la même entité à travers différents domaines.

Selon les auteurs, la première architecture de services de SoundCloud comportait deux couches de services. Les services périphériques récupéraient toutes les données des services de base. Chaque service périphérique orchestrait tous ses appels et était également responsable du contrôle d’accès. A terme, ce pattern a fini par entraîner des doublons dans le code et la logique, lorsque différents services ont évolué pour utiliser les mêmes données de manière légèrement différente.

Les auteurs écrivent que la seconde étape de l'évolution de l'architecture de services de l'entreprise a consisté à ajouter une troisième couche intermédiaire mettant en œuvre le pattern des Value-Added Services (VAS). Cette bascule vers les Value-Added Services a permis de mieux répartir les responsabilités. La couche périphérique fournit des fonctionnalités d’API gateway et répond aux besoins spécifiques des clients, tandis que la couche VAS consomme les données des services de base, les transformant en entités agrégées. Les services de la couche périphérique consomment ensuite ces agrégats.

Source: https://developers.soundcloud.com/blog/service-architecture-2

Un pattern tel que les VAS comporte certains inconvénients que les auteurs ont identifiés, comme un ensemble de services plus large et des latences réseau accrues en raison des rebonds supplémentaires introduits par les services intermédiaires. Ils envisagèrent d'utiliser plutôt des bibliothèques partagées mais conclurent finalement qu'une couche VAS était préférable dans leur cas.

La prise en charge des réponses partielles dans les Value-Added Services permet d'adapter la quantité de données renvoyées aux besoins de chaque client. Des réponses partielles peuvent également réduire le nombre d'appels réseau, mais les auteurs précisent que SoundCloud est focalisé sur la gestion de la complexité au niveau de la couche périphérique.

Les auteurs ajoutent que leurs Value-added Services ont fini par inclure la possibilité de modifier les données des entités. Des interfaces distinctes ont permis d'isoler les opérations d'écriture des opérations de lecture en utilisant les concepts de "commande" et de "requête", qui constituent le cœur du célèbre pattern Command Query Responsibility Segregation (CQRS).

Key Takeaways

Microservices pattern doesn’t refer to the size of the services, decomposing your solution into ‘micro’ pieces is not the goal of the pattern, think of your solution as one whole then look at the requirements to guide you through what pieces to partition out. The article gives you an example of doing that.

These definitions might seem a bit obtuse, so here's how I would define them:

API stands for Application Programming Interface. APIs define how two pieces of software can connect and talk to each other. If your application were a big company, your API's job would be to keep in touch with external parties (customers or company partners, for example). Most APIs are organized around some standard, like REST or GraphQL, so that everybody knows how to use them.

Microservices are pieces of software (often just isolated functions) that do a single, tiny, independent part of a bigger application. If your application were a big company, each employee would be a microservice, each playing their own specific and small role, working alongside but independently from their coworkers. This lets you make changes to individual microservices without affecting the rest of the application. In a big company replacing or retasking one employee in a large team would probably not affect the rest of the company all that much.

It's the evolution of the monolith architecture. Instead of having one block composing the whole application, every component is divided into smaller building blocks.

Put like that, does it make a bit more sense how they're different and how they can work together?

Monolith by Rene Aigner Some patterns are just about the code. If your code looks like this, and you need it to do that, here’s what to do. You’d do well to study such patterns, as they give you a …

Flowcon online 2020

Who designs the architecture of your software systems? Conway's Law suggests that HR may be strongly shaping software architecture by deciding how teams are composed and interrelate. Do you want HR designing your software architecture?

Organization architecture and software system architecture need to be co-designed to avoid friction from Conway's Law.

There are five key software architecture patterns in wide use. Here's what apps they're best for—and their challenges.

I had my fair share in designing and building large systems. I've taken part in rewriting Uber's distributed payment systems, designing and shipping Skype on Xbox One and open-sourcing RIBs, Uber's mobile architecture framework. All of these systems had thorough designs, going through multiple iterations and had lots of whiteboarding and discussion. The designs then boiled down to a design document that was circulated for more feedback before we started building.

All of these systems were large at scale: hundreds of developers build them - or on top of them - and they power systems used by millions of people per day. They were also not just greenfield projects. The payments system rewrite had to replace two, existing payments systems, used by tens of systems and dozens of teams, all without having any business impact. Rewriting the Uber app was a project that a few hundred engineers worked simultaneously on, porting existing functionality to a new architecture.

Let me start with a few things that might sound surprising. First, none of these designs used any of the standard software architecture planning tools. We did not use UML, nor the 4+1 model, nor ADR, nor C4, nor dependency diagrams. We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows, similar this one describing information flow or this one outlining class structure and relationships between components. Two diagrams within the same design document often had a different layout and were often added and modified by different engineers.

Second, there were no architects on the teams that owned the design. No IT architects or enterprise architects. True, neither Uber nor Skype/Microsoft have hands-off software architect positions. Engineers at higher levels, like staff engineers, are expected to still regularly code. For all the projects, we did have experienced engineers involved. However, no one person owned the architecture or design. While these experienced developers drove the design process, even the most junior team members were involved, often challenging decisions and offering other alternatives to discuss.

Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature, such as Martin Fowler's architecture guide. No mentions of microservices, serverless architecture, application boundaries, event-driven architecture, and the lot. Some of these did come up during brainstormings. However, there was no need to reference them in the design documents themselves.

This blog provides various aspects that need to be considered while developing scalable and robust enterprise applications. I will discuss the following areas of enterprise applications development and considerations:

An application should have capabilities to accommodate growth and scale, should be modular to enhance or add new functionalities, and support gradual or abrupt surge. At the same time, it should be seamless for users and efficient for the organizations.
Factors or Characteristics that influence the application scalability and robustness
The different architecture patterns, pros, cons, and considerations: The standard architecture brings many advantages for development and better flexibility of the system for scaling.
How to build scalable enterprise applications: What are the different design methods to consider across various components of the applications?
Different technology, tools, framework, software that can be used while designing enterprise applications: Mostly we will highlight open source technologies as much as possible.
Basic Architectural Design principles to consider for designing large scale applications

In the end, I will provide very high-level architecture considering most of the aspects discussed in this blog. I will provide information in the form of mind maps which I captured for the above areas.

Key Takeaways

We can define different categories of design patterns, including OOP design patterns, organizational patterns, and so on.
A number of design patterns are specifically suited to the serverless paradigm.
The Pipes and Filters design pattern can be used to decouple a serveless system into simple functional units interconnected in a chain.

Extending the microservice idea to frontend development. Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

Points Clés

La notion de dépendance est une problématique qui, si ignorée, peut entraîner des complications au niveau de l’architecture en termes d’évolution et de maintenance.
Afin d’obtenir des solutions maintenables et évolutives le sens des dépendances doit être guidé par la valeur métier.
L’inversion de dépendance est un outil puissant pouvant être utilisé à différents niveaux d’abstraction afin de pallier le problème de dépendance
Les dépendances ne sont pas anodines et ont des conséquences pouvant impacter l’organisation.
L’objectif est de protéger le “core” métier de votre solution pour pouvoir, d’une part lui garantir une évolution rapide en minimisant les impacts, et d’autre part de produire, à moindre coût, le plus de valeur métier possible.