Why MASA is the future?

Photo by Rosie Kerr on Unsplash

MASA (Mesh Apps and Services architecture) was proposed as a new and futuristic application architecture by Gartner in its Top 10 Strategic Technology Trends for 2016. According to Gartner, the application landscape was undergoing a major transformation with the advent of IoT (Internet of Things), mobile, edge computing and cloud. This necessitated a re-look at the traditional application architecture styles such as the three-tier architecture, which was failing to keep up with the requirements of an agile, multi-channel, fast-evolving, consumer-oriented, and feature rich application.

To put the changing app landscape into perspective let us discuss some of the differentiators.

Then vs. Now in the app landscape

• [Then] Applications typically had one datasource or a federated set of datasources to access data from.
• [Now] Applications have to work with multiple and various kinds of datasources.
• [Then] Applications embedded the entire business logic and functionality.
• [Now] An Application’s functional capabilities can come from various sources in addition to in-built functions, functionality can be existing in on-premise services or apps, new services and apps on cloud, external or third-party services.
• [Then] Applications had a defined and usually a single interaction layer with targeted customers.
• [Now] Applications being composite of other apps means that the subject application interactions are also defined by the consumer interactions with constituent apps.
• [Then] Applications were normally purpose built to address a specific business requirement, most of such applications were built ground up and a great part of these applications were monolithic.
• [Now] Applications are conceived as providing a unique business value which is obtained by bringing together many functionally complete services or apps. Each of these constituent services or apps can by themselves be capable of providing independent business value, which may or may not be related to the composite app.
• [Then] Applications were mostly developed using a single programming language and all components of the application run on the same runtime.
• [Now] Polyglot programming and polyglot runtimes is the name of the development game today. With the advent of cloud based development platforms (PaaS) different components of the same application can be developed to leverage the strengths of different programming languages and frameworks.
• [Then] Applications normally were built such that their interaction points were limited to one or two.
• [Now] Applications today are built considering that their users can be using them on any of the available touch points, which could be Web, Mobile, tablets or any other device.
• [Then] Applications built for single-channel consumption.
• [Now] Applications have to be built to provide users a multi-channel experience.
• [Then] All Application parts were normally deployed in the same infrastructure, within the same network.
• [Now] Constituent parts of the application today can exist anywhere on-premise, on cloud, in the edge or in a hybrid infrastructure.
• [Then] Applications had a defined and planned update release cycles. Bringing new features to the application involved a lot of procedural and technological latency. Markets were not as volatile and businesses were not as competitive then, which is why this could be tolerated.
• [Now] Businesses are highly competitive and most of them want to ride on technology to create a market differentiation, this makes it necessary for applications to be updated and new features released in short intervals and frequently. Continuous Delivery forms a very necessary piece of application development now.
• [Then] Applications were invested in and built only when there is a valid requirement from the market, business had to have a clear vision on how to leverage the application and what needs to go into it. Development costs were so high that failing was not an option.
• [Now] Fail fast is an accepted methodology that most of the businesses today are willing to adopt. This gives them the levers to speedily release a quick and dirty version of an app and gauge how the app performs in the market with real consumers. Initial response gives them the insights on what needs to change and what works. Version 1.0 of an app is expected to have a low GTM time-frame. This also fosters developing innovative means to capture markets. Also, today being early to the market matters immensely given the fierce competition and value that initial mind share capture can create.

There may be more, but above are some of the key differentiators today’s business and technology landscape imposes on applications.

This is why Gartner announced that a change to application architecture is warranted. MASA was the new architecture model proposed which is expected to cater to the demands laid on applications today.

Mesh App and Service architecture (MASA) explained

Source Gartner: 2016

In the Masa architectural model we see that an application (A or B in the figure) is a composite of many independent apps and services. APIs form the technological connect to establish communications between these apps and services. Each of the apps and services are complete by itself and not dependent on the functioning of the application (A or B). The constituent apps have their own consumers and interaction points.

The user interactions on these constituent apps influences the data that Application A or B sees and works with. These services and apps are not limited to the composite applications, they can be used for building any other application and hence are functionally independent. This also means that each of the apps and services have their own life cycle which is different from the life cycle of the composite application (A or B).

The figure shown above, visually explains why this architecture is called MASA, we see that the apps and services form a sort of mesh to create composite applications (A or B). Applications such as A or B can use overlapping and similar services or apps though they are independent. The data and functionality in the Application A or B is a meshed composite of the constituent data and functionality contributed by the apps and services.

One of the flip sides of applications created used MASA is that such applications can become complex with many different moving parts. Intercommunication between the parts and life cycle management of the parts can make the application more complex and operationally challenging. However, these MASA apps are here to stay because they are tailored to the demands of the challenging application landscape today.

Today apps using MASA is a reality because of the advent of the supporting technologies. Some of which are:

• APIs
• Cloud
• Hybrid infrastructure
• Security (specific to Hybrid infrastructure and apps)
• Multiple touch points
• Microservices based development
• Low cost development platforms (PaaS)
• Continuous delivery (DevOps)
• Containerized environments
• Data & data & data
• IoT
• AI
• AIOps

Uber app is a well known application that fits the MASA architectural model.

MASA and your customers and MASA and your business is a good read.

What is your next MASA app?