This blog post is based on the internal work of Thomas Baumgart, former MuleSoft Client Architect, and is now being published by MuleSoft.
In previous blog posts of this series, we discussed various architectures over the years as well as laid out the differences between a SOA approach to connectivity to an API-led approach. In this blog, we’ll discuss an example of an architecture that covers monolithic, SOA, and microservices elements.
TrinityCom: A fictitious mobile provider
TrinityCom, a fictional global mobile provider has acquired a few companies to stay competitive and participate in the digital goods business. They acquired a streaming service (TideView), as well as a cable network provider (NestorCon), that although not a global player, had been quite successful in central Europe. All three systems have their own commerce and service platforms which are supported by a few different backend systems. Let us have a look at some facts and figures:
- TrinityCom invested heavily into the creation of a “modern,” headless eCommerce system. It provides complex integrations and sophisticated user experience, but did have some performance problems during the last Christmas season. While a headless design gives additional flexibility, the solution is built around a monolithic core, which makes it hard to scale. Upon first analysis, the bottleneck seems to be the search engine which is part of the commerce core system.
- TideView commerce platform has been known for its performance, but it was unlikely to survive given the complexity of the TrinityCom commerce platform. TrinityCom has concerns that the platform will not scale given the much higher load the new type of service offering will introduce.
- TrinityCom is in the middle of migrating their homegrown CRM and service system to Salesforce. Because the migration has just started, there are processes that require access to both systems. TideView and NestorCon have their own systems. TideView’s system is quite basic and will be migrated from the start. For NestorCon, given the complexity of the network-provider business, the existing Siebel structure which has been built and customized over more than two decades will not be so easily replaced.
- With the acquisitions providing combined service offerings, TrinityCom sees the potential in generating new business. One idea focuses on the creation of apps that use all three service categories as a foundation. Potential use cases TrinityCom is considering are home automation, dynamic bandwidth provisioning, pay-per-view, and promotion-driven service update previews. These can be accelerated by a group of cloud-native developers that came with the TideView acquisition. They already built several consumable REST-services, but have yet to introduce an applicable API-management/gateway solution. NestorCon provides some SOAP-based Web Services Interfaces that have been widely adopted by its partners. Even they plan to replace them with newer, improved REST-based versions. However currently they need to be kept as is, but eventually would be proxied via an API gateway solution to apply policies and better govern the consumption.
The following image shows the proposed target architecture, which consists of monolithic, SOA, and microservice architecture elements. Let’s explain what led to these types of decisions and how MuleSoft can increase flexibility and agility supporting and complementing this combined approach.
Let’s discuss the above target architecture in more detail. The monolithic commerce application, which now contains the digital stock keeping units from TideView and TrinityCom hasn’t changed and remains a monolith. This avoids the efforts and risks of moving this highly complex, customized application that works just fine and is reliable. In the Process Layer we introduce the Mule API “Headless Commerce Service” that adds some additional orchestration logic which is done for two reasons. First, it would address the catalog search performance, by delegating the logic to a separate microservices cluster. Every Service “µ” has its own copy of the catalogue that gets filled on a regular schedule, loading data from the central “Commerce Application” database. From a service consumer perspective, the consistency guarantee of search results is eventual consistency. This is sufficient for the use case. The “Headless Commerce Service” component acts as a proxy, that delegates search requests to the “Catalogue Search” component which pushes the query to a number of Microservices “µ” listening to a central worker queue. This approach can be called the “Strangler approach” that addresses the overall performance of the commerce monolith, by cutting off the performance-intensive search logic. Another aspect implemented through the “Headless Commerce Service” is that it can enrich the original service by including new application services which are provided by the new DevOps team.
The powerful and flexible “modern API” structure of Anypoint Platform supports all required capabilities in this context. The fine-grained, all-in-one node architecture of a Mule API fulfills nearly all characteristics of a microservice, so it’s easy to use. The described “Catalogue Search” implementation is based on generic microservices leveraging Anypoint for the API management and overall orchestration logic.
The “UI Renderer” component group in the “Experience Layer” looks a bit different. Given the complexity of a rendering task, a dedicated component should be able to choose their independent implementation, scalability, and deployment model. While one of the components shown uses a similar approach as the “Catalogue Search” component, others rely on a Mule App and CloudHub autoScaling.
The “app” group on the right side of the “Process Layer” looks similar. Depending on the type of functionality provided by a certain app, a different model can be chosen. It’s likely that a “pure” microservices implementation will be the first choice, but given all of the component interfaces are cleanly managed via Anypoint Platform’s API management solution, this can be changed without affecting any existing service consumers.
Last but not least, let’s have a look at the middle of the architecture. This is the part that is closest to what we know from a typical SOA architecture. This is why TideView has decided to chose this approach:
- The overall functionality is achieved utilizing multiple existing third-party and COTS systems that introduce their own life- and service-cycles.
- Some systems will go away or will eventually be migrated, so the introduction of additional abstraction layers should make this process as easy and flexible as possible.
- All systems have strong transactional elements in their function list and consistency has high relevance.
- Using an orchestrated approach is beneficial rather than a shortcoming since this situation calls for managing multiple systems and their transition. It provides an additional level of control over a choreographed microservices-only one.
- The complexity of the underlying system can easily be abstracted using the SOA-style layered model to access the abstraction layer. Anypoint Platform’s distributed architecture offers a perfect mix of flexibility and agility.
The APIs used to aggregate the different SOA-style APIs do not refer to any additional implementation component, but utilize the applications behind a “Modern API” implementation. This is another advantage of MuleSoft’s Anypoint Platform over classic API-management solutions. Other solutions typically only provide an API-proxy layer and delegate the implementation to other components. The difference between custom implementation and using Anypoint Platform is that the latter allows for a configuration-driven approach to implementation, which increases implementation and management efficiency while reducing the risk of errors.
Anypoint Platform’s single-dimensional, modern API construct supports heterogeneous team structures as well. The example below shows how the different services could be assigned to different independently working teams, displaying the various options for deployment targets for the different services. Anypoint Platform supports high-granular hybrid deployments. MuleSoft can manage the deployment process (including CI/CD) and even certain SLAs (e.g. HA/DR) across all deployment destinations.
Anypoint Exchange not only provides a marketplace for connectors, templates, examples, and APIs, it also offers different teams a repository to save, publish, share, and reuse documentation, templates, and internal best practices, solving another problem associated with SOA projects.
Another aspect that is often misunderstood in this context is the phrase “central.” Anypoint Platform provides services out of a central service instance. The service itself supports multi-tenancy so every group can design, integrate, expose, and manage their services independently from each other without the need of a central IT’s support and ownership.
As described, there are few restrictions on where a certain Mule app or API proxy service can be deployed. Teams can act completely decoupled from each other.
However, collaboration is recommended in promoting the reuse of APIs across teams. This is where the C4E model can introduce one or more overlay teams tasked with driving and governing this approach. This will maximize the value and benefits offered by MuleSoft’s Anypoint Platform and the API-led approach to connectivity.
To learn more about how API-led connectivity is the next step in the evolution of SOA, download our whitepaper.
