Composite applications and microservices vs. hosted applications

There is a move in the MSP space to replace monolithic hosted applications with more dynamic composite applications built from a collection of microservices. While this approach provides a number of positive outcomes, it also comes with its challenges. Let’s look at some of the key advantages and disadvantages:

Advantages

• • Flexibility. Generally, composite applications are far easier to change than monolithic ones. As long as the base architecture is correct, the loose coupling of microservices allows for changes to be made at a granular level. However, the domino effect (see below) needs to be considered.
  • Scalability. Although monolithic applications have become much better in terms of how they sit on top of virtualised environments, it is still not as easy to provide the required flexibility of resources, as it is with microservices. For example, if only one part of an application requires more resources, a monolithic application will still need more resources to be applied to the entire application. With microservices, only the microservice that needs more resources needs to be changed – or a new instance can be provisioned to not only meet the resource needs but also allow for load balancing of that function.
  • Availability. Cloud computing has opened up a new market for developers. Rather than having to code everything (or buy in code that has to be then wrapped within their own code), third-party functions can be accessed and used via application programming interfaces (APIs). With thousands of functions available as microservices, hosted on public or third-party clouds and marketplaces to make them easy to find, developers should no longer have to create large parts of code to do things that are already available elsewhere. For example, while a hosted application may need to contain code for calendaring, payment, warehousing and so on, a composite application can focus on its core competencies while outsourcing these functions to companies who specialise in them.
  • Plug and play. The idea behind the use of a composite application is that functions can be swapped in and out as required. For example, you find a new microservice that does billing better than the one you are already using? Great – close down the one you are using and replace it with the new one using the stateless capabilities of virtual services to keep things running. Unfortunately, this can be easier said than done, so you must ensure that the basic underlying architecture is capable of enabling as many third-party services to be managed in this way.
  • Support. As many of the functions being used will be owned and managed by third parties who specialise in them, technical support is removed from being needed by the MPS providing the overall composite application. However – this can be a double-edged sword as noted below.

Disadvantages

• • Marketing. It is very easy (ok, relatively easy) to market a monolithic application as opposed to a composite application. Monolithic applications tend to have everything around a business problem wrapped up – for example, as a sales, ERP or time management system. Microservices can be single functions – such as a billing or a logistics capabilities. It’s only once a bunch of microservices pulled together into what looks like a complete application that an equivalent can be seen – and then the problem becomes one of differentiation as far as the customer is concerned.
  • Domino effect. A dependence on third-party microservices brings potential problems with it when the owner of the microservice decides to ‘improve’ it. As long as they adhere to accepted norms around the use of APIs, this should not be a problem. However, if they get it wrong, then calling services may not get the response they expect – or may not get a response at all. The impact that this can have on downstream services can be massive: the domino effect of a badly behaved third-party application should not be underestimated. It is up to the MSP to ensure that the company managing the microservice has all the processes in place to adhere to API norms – which brings us back to support.
  • Support. Although having a company that is focused on the specific service is a positive, an MSP cannot absolve itself of responsibility when things go wrong. As such, any agreement around the use of a third-party functions must include how support will operate, along with agreements on second- and third-level support, how teams will work together, how major issues will be dealt with, including escalation processes, and so on. For a composite application to work effectively for an MSP, there can be no finger pointing from your own support teams. If there is a problem that impacts the customer, you have to take ownership of it and get it fixed. Therefore, agreed upon processes in how to deal with third-party support teams are a must for MSPs.
  • Contractual elements. Contracts have to be far more than just a few check boxes saying that you as the MSP can use the function provided by them as a supplier MSP. Everything around support must be in the contract, this includes how updates and maintenance are to be managed; how payment for the service is measured; and, what timescales are involved in payments, etc. Account review and exit clauses must also be included. Remember that as the MSP owning the contract between the customer and the capabilities of the composite application, it is your company name that will be impacted if things go wrong. Protection of your brand has to come before cost.

Overall, a microservices-based architecture offers a lot more value and flexibility than a hosted application approach. The right tooling needs to be in place – including full microservices orchestration, management, patching, updating, monitoring, reporting, and so on.

With these technical aspects, backed up by a set of well-drawn up contracts and a suitable architecture, MSPs can be in a much better position to react to their customers’ and prospects’ needs much more quickly.

Photo: Alexander Veprikov / Shutterstock