2 BACKGROUND
Organizations from all domains implement software
applications with different scales for both internal and
external use. Governments implement software sys-
tems to enable internal administration management
with thousands of users. At the same time, they might
implement an online software system to enable smart-
government online services for citizens and residents.
Another example is that of a scientific community
may implement a group-scoped system for scientific
Big Data management while enabling visualization
features for external entities.
The monolithic approach of software development
was the dominant model, in particular, building soft-
ware applications as a single deployable unit (Fowler
and Lewis, 2018a). In the past, this approach was
practical since software size was relatively small and
consisted of a low number of software components
and functionality. In addition, this approach was com-
mon due to its convenience and ease of development.
Moreover, the systems were only used by a limited
number of users, with relatively long-term and sta-
ble requirements. Figure 1 shows some examples of
monolithic applications.
However, things have changed, with the Internet,
smartphones, Big Data, Cloud Computing, and the
startups’ ecosystem. Moreover, time to market and
response to new requirements became more critical.
Scalability has reached limits that were never pos-
sible and required before, with hundreds of millions
of concurrent users accessing the same service at the
same time. In addition, Internet of Things (IoT)
also affected this wave, which increased the num-
ber of devices accessing online services exponentially
(Economist, 2008).
With all these factors, the monolithic approach of
software applications development may be a severe
bottleneck. In fact, it may affect the organization’s
existence. The high-risks produced by adopting this
approach includes a high cost of implementation and
scalability, heavyweight testing and deployment pro-
cesses, and complexity of development. Moreover,
factors such as global software engineering (Ebert
et al., 2016), and the need to use different technol-
ogists in the same project (e.g., Angular for front-
end, Python for presentation tier, and Spring-Boot
for backend) increased the challenge of selecting the
monolithic approach, where the same technology is
the main theme for most of the applications. Fur-
thermore, various front-end technologies such as mo-
bile devices, browsers, desktop applications, and IoT
devices require lighter communication and full sepa-
ration between front-end and back-end technologies
(Laplante et al., 2008).
Even with the existence of techniques and concepts
such as Object Oriented Programming (OOP), de-
sign patterns (Gamma, 1995), reusable components
development, application frameworks, and software
product lines (Linda M. Northrop, 2012), building the
modern requirements of software systems is still chal-
lenging (Garlan, 2014).
Service Oriented Architecture (SOA) is an approach
of software architecture and development driven by
the academia and practitioners (Turner et al., 2003).
In particular, it is a software constructions model that
aims to change how the software systems are built. Its
central idea is based on separating an application into
smaller self-contained components, which are encap-
sulated, independently deployable, and communicate
over a standard protocol. The common used protocol
for SOA is Simple Object Access Protocol (SOAP)
based web services. However, SOA did not get high
traction because of its heavy-weight nature, in par-
ticular, communication, development and configura-
tion complexity, tools and technologies. Moreover,
the frequent use of SOA applications was for medium
to large-scale information systems that require a rela-
tional database as the central persistence mechanism
of application data. In fact, a unified instance of the
database was used, which limits the flexibility, where
developers were constraints in terms of taking design
decisions, and created a bottleneck on architectural
and database design decisions.
Consequently, a new architectural style has evolved:
Microservices Architecture (MsA). In MsA, a soft-
ware application is built as small, lightweight,
reusable and self-deployable components that com-
municate over a lightweight protocol. In fact, these
components can be developed using any technology.
Moreover, every service has its business logic, stor-
age engine, and persistent mechanism. Therefore, de-
velopers have full decisions control over the design,
technology, and implementation of their services. The
common used protocol in MsA is the Representa-
tional State Transfer (REST). REST is a lightweight
version of SOAP web-services. In particular, it works
as a layer that operates directly over the HTTP proto-
col (Fowler and Lewis, 2018a).
The microservices architecture overcomes many is-
sues, and challenges over the monolithic and SOA
approaches. However, it requires a particular early
architecture and design, mainly for the services and
their interfaces. Notably, these decisions may affect
the overall success of the project. In fact, arguments
about whether to start monolithic or microservices are
increasing day after day (Tilkov, 2018) (Fowler and
Lewis, 2018b).
Cloud-RA: A Reference Architecture for Cloud Based Information Systems
851