Towards agency-designed solutions based on cloud building blocks

Auteur
Heini Withagen
Datum

Micro-services are the current trend in software development. From a system architecture perspective this means separation of concerns: the ability to develop and scale functionalities independently. For each of the services choices can be made on whether to buy or build the needed functionality.

Although several software vendors of larger CMS and E-Commerce solutions start to adopt micro-services, the dependency on their total platform is usually very high.

Solutions bring inertia

Large CMS and E-commerce systems come in versions, usually several minor versions and one major version in the timeframe of about a year. While the minor versions update only certain functionality, the major versions update the total system. Both minor and major updates usually need to be applied in total, updating the total solution. Updates of individual components are not possible, by design.

In larger E-business implementations, the total architecture usually comprises solutions from different vendors. System integrators and agencies supply the glue between the solutions, e.g. an E-Commerce platform and a CMS.

To some extent vendors recognise that they need to standardise their solutions for interoperability. However, most vendors have limited focus on joining multi-vendor discussions. In recent years, CMS vendors have tried to improve interoperability through CMIS, the Content Management Interoperability Service. However the CMIS initiative failed, the proposed standard is dead. Their information at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis was last updated in 2014.

Agile architecture

While many development and deployment teams work in an agile mindset, choices in the overall architecture are usually long-term and solutions tend to stay longer than needed. This is due to the fact that replacement of the solutions is difficult and cumbersome. Most architectures are held back by the roadmap of the larger solutions within the architecture, bound to the roadmap of the vendor with 1 or 2 releases per year.

In the longrun, it would be beneficial to the vendors of the larger solutions to start offering granular building blocks and services. The building blocks could be applied and updated individually, removing the dependency on solution-wide version-upgrades. Vendors however seem reluctant to adopt this approach; most probably as it will hurt their short-term revenues.

Cloud building blocks

Many of the current micro-services architectures are developed in-house as custom software implementations. Teams are practising their skills on the decomposition of the overall functionality and are seeing the benefits of the splitting up responsibilities within the overall architecture. Developing, deploying and running all these services themselves can be quite a burden on a team.

Both smaller startups as well as AWS and Microsoft are now offering ready-to-use cloud building blocks which can be used in enterprise-wide architectures reducing the dependency on solutions from platform-vendors. The cloud building blocks adhere to the micro-services principles and are individually frequently updated, scalable and (mostly easily) interchangeable.

A current-day modern architecture now has a combination of standardised cloud building blocks for common functionality and custom-built problem-specific micro-services deployed on a cloud infrastructure.

Cautions

While a setup with standardised cloud building blocks offers great flexibility both on a development and scaling level, caution should be taken into account as well.

  • Data will be spread out over different building blocks. As micro-services need to be able to operate independently, each building block will need data to be able to fulfil its promise. This could lead to (necessary) duplication of data. From an architecture perspective this would be a design principle. However, for people (administrators, webmasters, etc.) this could lead to unexpected behaviour of the total system as they might not know which data influences which functionality.

  • Performance of the overall system can influenced by invisible factors. In a distributed system, the communication between building blocks can be of significant impact on the overall end-user performance. Special monitoring should be set up to measure and control the health of the total setup. This requires in-depth knowledge of the (inter)cloud communications.

  • Business continuity. The total platform depends on the continuity of a (possibly large) number of suppliers. Will they continue to exist/operate ? Both from a legal perspective as well as from a data perspective, caution should be taken to make sure measures are taken to protect the health and continuity of the total platform. Both Dev and Ops agility is needed to phase in and phase out building blocks which need replacing; both from a functionality as well as from a continuity perspective.

Future

Bigger platforms (e.g. hybris, Intershop, Adobe, Sitecore) would be wise to open up their suites and let clients start using parts of their solutions. This will require 2 steps:

1) Make sure that all suite functionality is available through API’s

2) A consumption based model is available to pay for services used.

The role of vendor platforms/suites will become less prominent per client but the vendors will have the opportunity to be able to service a larger number of clients based on their advanced functionalities. They will just need to open up.... and let clients start using small parts of their suites at an entry-level cost.

Digital agencies, like Mirabeau, will get and take the opportunity to design, build, and run client-solutions based on granular cloud building blocks. The agencies will be able to provide clients with more advanced end-user functionality and increased agility in the overall architecture.

Tags

Cloud CMS