Política de cookies

Utilizamos cookies próprias e de terceiros para realizar análises de uso e de medição da nossa página web para melhorar os nossos serviços. Se continuar a navegar, consideramos que aceita a sua utilização. Pode modificar a configuração ou obter mais informações Saiba mais.

#nfqLife
Re[*]

Mesh App and Service Architecture

The Internet has changed how applications are developed and deployed. Any application that still uses the three-tier application architecture that relies on a centralized database connected to a business logic layer with the same data pipeline is now obsolete.

It is obvious that Internet has changed how applications are developed and deployed. We tenaciously repeat the Internet scale mantra, meaning that the amount of devices that nowadays connect to a single application at the same time will blow up any application that still uses the three-tier application architecture. This architecture, that relies on a centralized database connected to a business logic layer with the same data pipeline, was abused until the beginning of this century, and it is now obsolete.

The first challenge was, therefore, scalability: to make a single application scale up to thousands, millions or billions of users. Now every single application is expected to scale, regardless of the fact that such performance may never be required. Scalability is considered a mere consequence of a good design.

mesh1

Scalability is about how systems deal with the workload. One expects that if the amount of work doubles, the only side-effect is that one has to double the resources to keep a constant quality of service. We have nowadays several examples about how an application can run in thousands of servers connected to millions of users. But the requirements of modern backends have gone beyond these performance requirements. In its latest reports on “Top 10 Strategic Technology Trends”, Gartner introduced a new “Architecture” buzzword, that frames well in a single term what is today’s leading edge IT innovation.

The  “Mesh App and Service Architecture” (MASA) refers to the design of solutions that link, mobile apps, web apps, desktop apps and IoT apps – and their data, whether user or operational – into a broad mesh of back-end services to create what users view as the “Application.”

MASA introduces a new benchmark for architecture design: complexity. Any application that scales beautifully under a heavy workload may be cringing every time a new feature is needed, like a new data source, or offering yet another RESTful API to one of those fancy Javascript frontends. Any issue about uptime, latency, exceptions or application bugs are immediately penalized by users, that are raising their quality expectations every day. This, together with shorter development cycles, makes complexity management the new challenge.

MASA has been abused as a reason to introduce massively the microservice architecture, but that is fundamentally flawed. The microservice architecture is just a linear combination of classical three-tier applications that are connected to the same network. It is an improvement but does not deal with the complexity issues commented previously.

mesh2

The microservice architecture makes a great job hiding complexity to frontend development, since the backend is separated into parts that fulfill a functional purpose. However, each one of those parts may become complex by itself. Complexity is not strictly managed, but sent to a different level deep down the backend. Hard problems cannot always be solved by breaking them into a linear combination of smaller pieces, and that is what microservices are.

One year ago, Nfq decided to tackle the challenge of managing architectural complexity with PALM, and its Python implementation pylm, even before the MASA acronym was ever mentioned.

The goal of PALM is to manage complexity by allowing a more diverse flow of information between standard components. Pylm supports nowadays load-balancing, message subscription, multiple protocols, and many other interesting patterns aimed at managing gracefully cases that were quite infrequent many years ago, but that are becoming standard requirements of complex architectures.

Pylm is open source (https://github.com/nfqsolutions/pylm), you can install it with a single command in Windows, Linux and MacOS (pip install pylm), and it is extensively documented (http://pylm.readthedocs.io/). It is mature enough to be deployed in production, and it is a key component in the future products developed by Nfq.