ASSESEMENT 2 - MICROSERVICES ARCHITECTURE

INTRODUCTION

Microservice architectures are gaining popularity as a viable alternative to traditional software

design models. Since the last three years, there has been a substantial growth in the demand
for microservices (Furda et al., 2018). This can be clearly verified using service-oriented
programming, where the major usage of this service has advanced significantly when compared
to other structural bases (Sill, 2016). Microservices provide a solution to deliver a business
feature in a restricted, autonomous, and self-sustaining manner, performing a unit role inside a
particular business context.

In Werner Vogels' speech on the development of Amazon, the initial value proposition
provided by microservices can be observed (AWS, 2021). Long delays in creating and
releasing code, as well as "huge" datasets that were hard to maintain, slowed Amazon's
development in terms of growth and new capabilities. However, despite its evident
advantages, several bigger projects are said to be experiencing delays and cost overruns as a
result of the new style's drawbacks.

The major goal of this study is to investigate the issues and challenges that arise as a result of
using software development architecture for microservices. Additionally, certain potential
privacy concerns that may arise as a result of these security issues are addressed. Moreover,
this research looks into the root causes of these issues as well as potential solutions to
decrease the threat of both privacy and security breaches.

1. MICROSERVICES ARCHITECTURE AND ITS SECURITY CHALLENGES

Overview of microservices architecture

Microservices is a method for creating application services (Esposito, Castiglione & Choo,

2016). Microservices involve breaking down a program into smaller "micro" pieces and
deploying and executing them individually, as the name indicates. Because of superior
technology choices and fewer team numbers, this strategy promises a shorter time-to-market
for new capabilities.
Microservice architecture is a tiny and self-contained architectural approach. Microservice
design has several advantages, including high maintainability, testability, and business
capabilities. It may also run on its own and be governed by a small group.

Figure 1: Comparisons of Monolithic and Microservices (Sill, 2016)

Figure 1 demonstrates how the monolithic system packed all components together, making
flexibility difficult. Microservices, on the other hand, segregate all components, making them
easier to manage.

Back in the 2000s, Amazon, one of the world's largest logistic firms, employed a monolithic
system, but it had an adverse effect on overall production. As a result, the firm chose to use a
microservice design, with each service serving a specific function through web APIs ("What are
Microservices? | AWS," 2021). When the technology was completely operational, the
productivity skyrocketed, and they are now the world's largest corporation.
Figure 2. A typical microservice architecture on AWS ("What are Microservices? | AWS", 2021)

However, Amazon faced several challenges in order to deploy microservices, including forming
an in-house development team, testing, bug patching, and so on. Although security is a highly
specialized subject, recognizing security in the setting of microservices architecture is critical for
everyone working in this space due to the dispersed design and reliance on communications
integration (Swinhoe, D., 2020).

The use of monolithic systems has a long history, but it is now feasible to divide them into
microservices. Transforming from monolithic to microservices, however, brings certain
problems.

Challenges that arise owing to the use of microservices architecture

According to S. Newman (2015), in the current microservices environment, there are

challenging new and growing barriers for programmers to address.

 Larger area to be attacked: The services were distributed and APIs were exposed as a
result of open ports. Identification becomes difficult since it must be done at multiple
places. Perimeters are also no longer determined. They do this because each feature
 must interact and connect with others via APIs (application programming interfaces). 
These APIs have been made public, significantly increasing the attack surface.
(Alshuqayran, Ali & Evans, 2016).
 Convergence of development and operations: Microservices provide a closer contact
with the architectural and activity teams to maintain the lifetime of applications. When it
is necessary to deploy more regular builds, increased mobility will generate security
issues, and each might constitute a security risk (Alshuqayran, Ali & Evans, 2016). It's
critical to give a thorough understanding of the methods engaged in both development
and operations, as well as to guarantee that any security risks are mitigated.
 Complex system communications: A microservice architecture divides an application
into a number of separate microservices that communicate with one another. All
dependencies that were previously concealed in the monolith and perhaps codified in
dependency rules between components must now be codified in the infrastructure
configuration (Alshuqayran, Ali & Evans, 2016). It's critical that the architecture
configuration is given "as code," that is, as a configuration file that can be reviewed,
confirmed, and updated without having to be manually produced.
 Technological diversity: Developers can utilize various technical platforms for each
service owing to the microservices concept. However, because each microservice uses
a distinct technology, it may be necessary to utilize several technologies for the same
task. A microservice may also be built in one computer language while another is written
in another. The decision to choose a certain language is frequently based on human
taste rather than technical need. As a result, when a developer switches teams, for
example, it becomes a skills problem. More significantly, it becomes an issue when the
application enters maintenance mode, teams are reduced, and unexpectedly more
people are required to manage the heterogeneous tool and technology environment.

2. POTENTIAL PRIVACY ISSUES AND THEIR REASONS

Potential privacy issues

The following are among the probable privacy concerns identified by Dai et al. (2020) as a result
of Microservices security difficulties/challenges:
  Attack surface: When microservices connect with one another in such a way that APIs
are independent of system programming language, new attack vectors emerge. More
comprehensive facilities also enhance the total number of possible critical loss point.
 Standard logging is unreliable: The new microservice architecture is widely dispersed.
There will be more logs since microservices are spread, unmanaged, and therefore
basically independent. The difficulty is that as they appear, more logs appear to try to
hide the situation.
 Fault tolerance: In the microservices context, fault tolerance will get more difficult than
in a classic monolithic design. Users must be capable of dealing with service disruptions
and other timeouts that occur for unknown reasons. Other systems will be affected as a
result of such service failures, resulting in clustered failures.

Ethical and security issue in transition to microservice Architecture

When moving an operating system from a monolithic to a microservice architecture, specific

domains are generally separated from the system and deployed as a new service. The
Blackboard, for example, is a third-party IT firm that offers student learning and administration
tools to over 600 colleges and institutions across the world. It is transitioning to a monolithic
system to manage large amounts of data.

In the move to microservices, there are various responsibilities to handle the data of students,
teachers, and other employees. Because each component delivers its own service, the
developer must be mindful of ethical and security concerns.

Ethical:
During the transitional stage, application log files are one of the most important files that
developers must manage for each service, such as student and teachers log files. They are the
only individuals who have access to personal files for microservice splitting. If a corporation or
programmer engages in unethical behavior, they can remove or wipe log files, posing an issue
for individual users.

Another important ethical problem is data protection. Many organizations map users' data
because consumers utilize them as a third-party authentication method, such as utilizing
Gmail to log in. As a result, during the transition time, users must take ethical precautions to
ensure that firms do not give out their profiles to cops or other authorities without their consent.
Security:
 In terms of security concerns that may arise in the future, the firm should take precautions even
before the transition period. The following points will focus on security problems in microservice
architecture transitions:

- How will each service's verification work?

- How will the firm protect the privacy of its users' data?

- Who will have the authority to separate the log files from the monolithic system?

Reasons of these challenges

The services are separated because microservices are self-contained, flexible, and accessible.
APIs are open, and authentication becomes problematic when it is required at many locations
(Dai et al., 2020).

Another reason is that the precision, speed of operation, and volume of data transit in secure
microservices systems necessitates novel techniques. According to Furda (2018), the pace with
which microservices are implemented is also a significant factor in these difficulties.

Microservices also allow applications to be divided into separate services, resulting in greater
data flow and perplexing access control requirements.

3. RECOMMENDATION TO MANAGE RISKS FROM MICROSERVICE ARCHITECTURE

The following are some of the most significant mitigations for managing the risk of privacy and
security:

Designing for security: Create an application with security in mind. Encrypting at rest, access
control, and other security features should be implemented straight away. When they're
introduced later in the development cycle, they might result in a lot of refactoring work.

Autoscaling: Each element of a microservices system may be scaled independently. This

helps to optimize resource use by ensuring that only the components of the program that are
truly needed consume resources. A nighttime background process, for example, might utilize
the same resource as a greater website that operates during the day. Auto-scaling (e.g.,
based on the amount of requests) helps reduce overall resource use by automatically
distributing resources.
Infrastructure automation: Containerize software applications such that the same container
may be used in many contexts. Define the infrastructure configuration "as code" in version-
controlled configuration files. Everything should be automated so that it can be delivered
automatically to upgrade operation or establish a new test environment.

Improved transparency and control: A microservices design would provide greater mobility
and a more complete perspective due to the utilization of microservices, since the systems
would be more complex. The protection system must be able to identify any visual changes in
traffic patterns, any emergent risk mechanisms, and any violations of laws and regulations.
Application-aware security technologies must be purchased in order for them to have the
necessary power and exposure to protect software and larger networks.

Identification and authentication: Access to APIs should be regulated and authorized. The

defense stance would be significantly strengthened if this was paired with a smaller attack field.
The notion of least privilege should be used to control access based on needs. Connections to
internal resources might be considered off-limits to avoid human mistake.

CONCLUSION

To conclude, every innovation has advantages and disadvantages. As a result, microservice

architecture has a number of advantages as well as some drawbacks during the transition
phase. Actually, monolithic design is appropriate for basic, compact, and lightweight systems,
whereas micro-service architecture is ideal for developing sophisticated applications.
Microservices are a drive for programs to be appropriately modularized.

As a new development approach in software engineering, microservice architecture introduces

new security risks and vulnerabilities. Threats can come from both insiders and outsiders. To
properly secure microservice platforms, all threats must be identified and avoided, independent
of their source, utilizing either existing mitigation techniques or providing new approaches.

Developers are utilized to promote their technologies and apps as a result of the transition to
microservices. However, these advancements necessitate a completely new security strategy. 
A strong security program for microservice-based systems should cover the full technological
lifecycle. Using the aforementioned best practices, one may assure the safe development and
implementation of containers and microservices.
 REFERENCES

Alshuqayran, N., Ali, N., & Evans, R. (2016). A Systematic Mapping Study in Microservice
Architecture. 2016 IEEE 9Th International Conference On Service-Oriented Computing And
Applications (SOCA).

Dai, F., Chen, H., Qiang, Z., Liang, Z., Huang, B., & Wang, L. (2020). Automatic Analysis of
Complex Interactions in Microservice Systems. Complexity, 2020, 1-12.

Esposito, C., Castiglione, A., & Choo, K. (2016). Challenges in Delivering Software in the Cloud
as Microservices. IEEE Cloud Computing, 3(5), 10-14.

Furda, A., Fidge, C., Zimmermann, O., Kelly, W., & Barros, A. (2018). Migrating Enterprise
Legacy Source Code to Microservices: On Multitenancy, Statefulness, and Data
Consistency. IEEE Software, 35(3), 63-72.

Newman, S. (2015). Building microservices: Designing fine-grained systems. California, USA:

O’Reilly Media.

Sill, A. (2016). The Design and Architecture of Microservices. IEEE Cloud Computing, 3(5), 76-
80.

Swinhoe, D., August 11, 2021, The biggest data breach fines, penalties and settlements so far.
CSO. Retrieved from https://www.csoonline.com/article/3410278/the-biggest-data-breach-fines-
penaltiesand-settlements-so-far.html?page=2

What are Microservices? | AWS. (2021). Retrieved 12 August 2021, from

https://aws.amazon.com/vi/microservices/