IV. Adopt Mesh App and Service Architecture
Mobile, Web, IoT, Desktop built from independent apps and services
Software doesn’t mean
Desktop exclusively anymore - these times are long gone. With an advent of mobile devices, swiftly followed by Internet of Things (IoT), software development had to extend its reach to cover all these new
Nowadays, the expectation that your solution is built form a single source code and then simply
rolled out onto all these different devices -
all at once that is…
What is Mesh App and Service Architecture?
Mesh App and Service Architecture (MASA) - it’s a term coined by Gartner and you can read more about it in this particular research paper: MASA: How to Create an Agile Application Architecture With Apps, APIs and Services.
MASA stipulates that modern applications,
Mesh Applications, are built from small distinctive
Apps(Software) which run on top of
Services(APIs) which are in turn orchestrated at an
API Mediation Layer(API Management).
OK, so that sounds like quite a lot is going on there, so let’s unwrap
MASA a little…
Let’s start with the lowest layer in our MASA architecture and we’ll call it
Inner APIs. At that level you might have a number distinct APIs running on your infrastructure. And that could be internal on-premises IIS hosted APIs or more modern cloud hosted PaaS Apps, Functions or best of all Containerised Workloads on Kubernetes. It doesn’t matter how a particular piece of API is hosted, what is important is that:
The Inner APIs are only accessible on your
internalnetworking infrastructure and you have proper
authorisationmechanisms in place to guard access to these APIs.
A single Inner API in your estate could be responsible for making payments, another for submitting orders and so on… From software development point of view this approach is also called Microservice or Loose coupled service. It makes development and testing of such components easy and it also allows to fully automate software builds and releases.
However, on their own, these APIs are not very useful other than
doing one thing very well… these APIs need orchestration and we’ll be looking into that next.
Enter the world of API orchestration which we’ll call
Outer APIs in our MASA architecture. The purpose for Outer APIs is to chain together one or many Inner API calls to achieve an action or execute a process. Outer APIs are also hosted on your infrastructure, in fact, the same hosting and access principles apply as per Inner APIs. Only difference is
The Outer APIs are
the windowfor your Inner APIs and allow you to compose or orchestrate a chain of Inner API calls. The
authorisationmechanism at this level will depend on you
Apparchitecture and your identity solution.
An Outer API could be performing product sorting feature or submitting payments on your
App. Whatever the requirement is, Outer APIs will implement it in the
API Mediation Layer.
This also brings another concept for your consideration - API Lifecycle Management.
From software development perspective things get little more complicated as you’ll now deal with potentially multiple Inner APIs required to be accessible for development of a single Outer API feature. Again, thinking containers and container development helps a lot here.
From the CICD perspective situation is also similar to Inner APIs, however…
You might want to start thinking PlatformOps when it comes to running and supporting
Mesh Appshosted on
Kubernetesas these solutions will
depend heavilyon API Lifecycle Management and API Gateways components.
Finally, we got to the top of our MASA architecture which we’ll just call
Mesh Applications or
Apps for short. The applications are your products, either internal (Intranet) or external (Internet) facing. Often the Apps will be in the form of Responsive websites capable of running on many screen sizes and devices. You might also have Apps written for IoT devices such as wearable technology.
The Apps are in effect
dumb frontendswhich need to be able to
execute calls over HTTP protocolto consume Outer APIs. Outer APIs in effect provide the Apps with all the logic required for them to function. Or to put it in other words, Outer APIs are the
heart of your product.
Therefore, you can see from the above, the App just needs to look pretty, and it needs to understand API HTTP Request-Response mechanisms. You can also architect your Mesh Application from multiple smaller Apps to provide your users with what it might seem like an
end-to-end desktop product - which in effect is merged from multi-App components.
Good example could be your hypothetical
Online Store Mesh Application consisting of one App for user login, one App for products and shopping, one App for checkout process and one App for user dashboard. What’s great about this is that your user can start their shopping journey on tablet, then 2 hours later come back to your Mesh Application and finish off the purchase on Desktop PC or a smart watch. Quite neat, hey?
You need to consider
Networking, Routing and Authorisationat this stage so that your
Outer APIsfor that matter, are accessible to your users - very important for Internet and IoT facing implementations.