Some months have passed since we first evaluated the initial version of the MUSA framework and the updated version is currently being developed, addressing the feedback that we, end-users of MUSA, provided together with our partner, Tampere University of Technology.
The use case application provided by Lufthansa Systems is a working prototype for a multi-cloud oriented application related to the domain of flight schedule planning; the focus for the MUSA project is on the used architecture and the implemented security concept.
The prototype is realized as a multi-layered, distributed web application and provides a scalable platform of loosely coupled, component oriented building blocks. In contrast to a monolithic approach, server-side applications are decomposed in self-contained, collaborating and independently scalable business components, each capable of running in a separate process and interacting by use of lightweight REST style communication protocols.
The overall architecture encompasses major styles of REST Architectures, Domain Driven Design (DDD), Command Query Segregation (CQRS) and Event Sourcing (ES). In combination, these styles are complementary and covering non-functional criteria on different architectural levels. In turn, a layered architecture enables to address various non-functional and conceptual requirements with explicit design decisions on each level.
Architecting and designing the business domain of the application prototype is a substantial discipline to identify and to decompose the software model into cohesive service components with well-defined business purposes, consistency definitions and clear context boundaries. Domain Driven Design is a strategic approach in software design, providing best practices and patterns to facilitate the process of business domain analysis and functional modelling of the domain logic. Successfully applied, the software model closely resembles business domain concepts and enables direct and unambiguous linguistic translations with feature responsible domain experts.
In conjunction with CQRS, a clean decomposition of the domain into decoupled components and services is a prerequisite for flexible software distribution and elastic scalability demands either in reaction on high data loads or computational requirements. The architectural goal is to provide a highly scalable component-based architecture which is cloud-ready by its nature. The main strategical architectural patterns applied for this goal are:
- CQRS – Command Query Responsibility Segregation
- Event sourcing
CQRS is used to speed up read and write performance of the application services. According to CQRS, different models are used to process commands and queries. Applications are vertically split in decoupled read and write models, each optimized with respect to layering and specific processing requirements. Commands invoke state changing behaviour, whereas Queries are used to read information.
The diagram in Figure 1 illustrates a functional CQRS component consisting of a distinct read and write model to segregate command and query processing. Synchronization between read and write models is based on an event propagation mechanism. Commands trigger business logic within the write model and result in state changes on data aggregates. Each state change is represented by an event and published for updates to all subscribed read models. Services of the application are designed by standardized component patterns. The CQRS component pattern implies usage of RESTful service APIs as standardized entry points and supports high performance requirements based on a distribution model of individually scalable and deployable subcomponents.
Figure 1: CQRS Pattern used in the flight scheduling application prototype
Event sourcing is applied to decouple the read models and write models and create a resilient architecture able to survive crashes and enable quick restarts. Event sourcing enables a continuous view of data evolution. Besides traditional techniques in maintaining only the current state of application data, historic data is immutably stored and not subject of deletions or updates. Every state change is represented by an event and sequentially stored on a linear time scale. Historic states can be replayed and reproduced. Every data manipulation results in a persistent state change, application data is seen as a sequence of historic state changes on a timeline until the current state is reached. Events are stored in an event store and may be projected at any time to adapted and specialized data views as required for revision management, user tracking or reporting purposes. Based on configurable business policies, snapshots are drawn at certain points in time; they represent the complete application state at that point in time and may be used for several purposes. Snapshots play an essential role in lifecycle phases of an application to quickly initialize aggregates and read models. Furthermore on the lowest level of scale, snapshots support advanced sharing, distribution and replication concepts.
During evaluation the MUSA framework was successfully used for (a) identifying the cloud providers that best fulfilled application security requirements and (b) for automatically deploying the prototype application components using the identified providers.
The selection of cloud service providers is a non-trivial process. It requires that the security controls offered by the providers are appropriately characterised and match best with the controls required by the application. To do this, both sides need to be clearly identified and specified. MUSA helped in this task by offering tools for analysing the risks and specifying the security requirements of our components. In fact, the risk driven security specification is one of the unique selling propositions of MUSA compared to other solutions.
Another innovation brought by the MUSA framework is the integrated SecDevOps (Security Development Operation) toolset, which addresses the needs of multi-cloud applications by considering security and privacy as primary design tenets, thus, including security and privacy requirements and by-design practices since the very beginning of the development.
This first evaluation of the MUSA framework resulted in a number of interesting findings regarding the usability and the functionality of the MUSA tools.
The evaluators gave a rather positive feedback regarding the Kanban-style MUSA Dashboard. Providing this interface for the user makes the MUSA process more interactive.
On the other hand, users sometimes felt lost by dragging and dropping components between the different columns and it became a bit annoying if this needs to be done repeatedly for many components. The UI needs to be improved; there are too many occasions when a window pops up.
Also, the Modeller got a positive feedback from the evaluators. The syntax checks (underlining wrong parts in red) where welcomed by the users. The documentation seems to be sufficient but requires a good knowledge of model driven engineering and preferably experience with the CAMEL language.
The SLA Generator got a very positive feedback on its efficiency but left some room for improvement in usability and reusability of the results. According to the evaluators’ opinion, the tool provides a lot of information on threats, security controls and metrics for the end user and therefore draws attention to unknown security aspects for application design.
On the other hand this amount of information, as it is currently presented, is a drawback: a chore to scroll through for an experienced user, and information overload for an un-experienced user. As a consequence the user tends to overlook / click-over important parts. Probably it would be more user-friendly to hide some details by using tooltips, etc.
The evaluated DST-Risk Analysis prototype was a Kanban style dashboard for the continuous risk assessment on a multi-cloud application. According to the evaluators, the tool properly supports DevOps and it is efficient in the security risks definition aligned with the application security requirements.
The major drawbacks found were related to the fact that the tool allowed only for basic features of the risk characterisation inherited form the SLA Generator Proof-of-Concept (PoC) but still did not support some process steps like the security metrics identification, a feature that will be included in the final version. Besides, many UI improvements need to be added to ease the usability. In general, this should be easy to do for the final version.
According to the evaluators summary the DST-Decision worked mostly fine, although some integration and UI issues were identified. Besides, the lack of proper documentation explaining the way the tool ranks the cloud service combinations and how it supports the selection is required.
The complete, detailed evaluation report including all the other parts of the MUSA framework will be available as a deliverable (D5.3) on the MUSA website once it is approved. So far, the public deliverable on the use cases planning can be reached at: http://www.musa-project.eu/wp-content/uploads/2017/02/MUSA-D5.1-MUSA-case-studies-work-plan.pdf
Currently the MUSA development team is working hard to finish the final version of the MUSA framework which will include an overall application Service Level Agreement creation by composing the individual components’ SLAs. This will serve for the monitoring of the security and privacy levels guaranteed in the SLA at both component and application levels.
As end users and validation work package leaders, we are coordinating the preparation of the final evaluation and identifying the best way to demonstrate the benefits brought by MUSA to our development.
Author: Stefan Spahr, Lufthansa Systems GmbH & Co. KG, Germany (stefan [dot] spahr [at] lhsystems.com)