Thursday, October 31, 2019

Decomposing the last monolith - The UI-Monolith with web components

Enterprises tend to move away from the monolith based architectures and decompose existing solutions in smaller services. The use of functions and microservices is a common implementation model at this moment. However, a common observation is that enterprises tend to build (maintain) one last monolith even when adopting a modern architecture. In many of the microservice based applications the UI tends to be the last monolith.

Where all backend services are broken down into smaller pieces the frontend services tend to stay as one single monolith. In this model multiple teams are responsible for building and operating all their own individual (micro)service. Another team, the frontend team is responsible for consuming those services, potentially as REST services and create a appealing user experience with it.

The problem with this is that there is a tight coupling, and with this a dependency, between the backend teams and the frontend team. The below image, drawn by Johannes Giani shows the common model as well as the alternative where the frontend is also broken into much smaller pieces.

Micro-UI and domain driven architecture
breaking the UI-monolith into UI fragments will allow for full decoupling between teams and will push the UI responsibility into the team responsible for the backend service. This makes that you can achieve a much higher level of domain driven architecture.

As an example, the team responsible for the shopping-cart, originally responsible for the backend services, can now also take the responsibility of the front-end services. There will no longer be a direct shared, or delegated responsibility, with the UI team.

Technical components
decomposing the UI-monolith into UI-fragments can be done in multiple ways, all having their pros and cons. The most promising one is the use of web components. Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

Web Components allow you to basically include rich, custom build, features by creating your own "HTML tags". While having the freedom of custom build tags the entire "framework" of web components is a W3C standard and the entire web component idea is driven by Google who is pushing for the general adoption of web components in the browsers.

The architecture view
From an architectural view you have the more traditional and common deployment view on how microservices are used to decompose a monolith in the backend while still maintaining a monolith in the UI layer. This is shown in the below architecture diagram:

If we look at the use of web components you will have an architecture drawing as shown below.

Here you can observe a number of things;

  • The UI elements are pushed down into the responsibility of the domain/service. This means that the team responsible for the backend services is now also responsible for the development and operation of the web component. This has become a complete and isolated service no longer depending on the UI team to provide the end-2-end service

  • A new layer is introduced, the stitching layer (for the lack of a better word). The stitching layer is still developed and operated by a central UI team. The responsibility of this team is to ensure that all the (web) components are jointly integrated in a single UI. 

On how the individual web components are being served and presented to the outside world is a discussion in itself and is primarily driven by the architecture views on routing and is not discussed in this specific post.

When decomposing a monolith, or building a greenfield microservice based application, it is a good thing to understand that the UI in itself can become a "new" monolith. Using technologies like web components can provide a solution to this and support a more clear domain driven architecture and provide less dependencies between teams while creating a higher level of end-2-end responsibility within an individual team

Wednesday, October 30, 2019

Add Oracle Linux 8 Vagrant box

When using Oracle Linux (a lot) for local development you most likely want to use Vagrant to quickly deploy new environments locally. Oracle originally supports the use of vagrant by providing Oracle Linux vagrant boxes. In line with the "traditions" Oracle provides a Vagrant box for the latest version, version Oracle Linux 8. Below are instructions to add the an Oracle Linux 8 box to your local machine.

Firstly you will have to check (can check) which boxes are available. The below commands show this:

louwersj-macbook:OL8Test louwersj$ vagrant box list
ol69     (virtualbox, 0)
ol73     (virtualbox, 0)
ol74     (virtualbox, 0)
oracle69 (virtualbox, 0)

As you can see in the above example there are a number of boxes already available on my local machine. To add Oracle Linux 8 you can use the below example:

louwersj-macbook:OL8Test louwersj$ vagrant box add --name ol80
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'ol80' (v0) for provider: 
    box: Downloading:
==> box: Successfully added box 'ol80' (v0) for 'virtualbox'!

You will now have a new Oracle Linux 8 Vagrant box available for use.