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.
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 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.
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.
Warning: count(): Parameter must be an array or an object that implements Countable in /home/austri/public_html/wp-content/themes/nfq/single-blog.php on line 334