IT on Business: Cloud Computing and Microservices Implementation

This report delves into the realm of cloud computing, specifically focusing on microservices as a method for developing applications. It outlines the benefits of microservices, such as supporting agile methodologies and enabling the delivery of complex business applications. The report emphasizes key considerations for implementing microservices, including service independence, code grouping, technology stack selection, operational complexities, and continuous delivery. It further explores two primary approaches to migrating to microservices: splitting a monolithic web service and building microservices around a monolith. The report provides a comprehensive analysis of these approaches, highlighting their challenges and potential benefits, and concludes by emphasizing the importance of aligning microservices implementation with specific business needs. The report aims to guide businesses through the process of adopting microservices and leveraging their potential to enhance performance, particularly for companies that handle large datasets. It is a valuable resource for students seeking to understand the practical aspects of cloud computing and microservices architecture.

RUNNING HEAD: CLOUD COMPUTING 1
CLOUD COMPUTING
Name
Institutional Affiliation
Date

CLOUD COMPUTING 2
Introduction
Micro services can be defined as method of developing a single application as a suite of
small services, each running its own communication with insubstantial mechanisms generally an
HTTP API. These particular services are from around business abilities and individually
deployable.
The Micro service technique has major benefits, particularly on enabling the
development of agile methodology as well as delivery of multifaceted business applications. The
technology architecture breaks soft wares into manageable portions hence enforcing modularity
which in reality is extremely challenging to attain with the monolithic code base(Balalaie,
Armin; et al, 2016). On the other hand, the method supports the lightweight communication bus.
The applications created from Micro services target to be cohesive and decoupled (Michael
(2014). They usually have individual domain logic which filers, receives a request, apply logic as
needed, and generating a response. However for proper implementation Micro service the
videoDEV needs to consider various things before the implementation of the system which
includes;

IT ON BUSINESS 3
Design of the video processing application
Things to be considered before implanting Microservice
1. Degree of Independence
The independency of the service matters a lot during migration. The company needs ensure
that the service is entirely self-governing with its own UI and Database. This is constant with an
extreme Micro services design where services are decoupled and share nothing. However, this
method makes it very challenging in ensuring that all information stores are consistent.

IT ON BUSINESS 4
2. Code grouping
There are various ways through which the company can arrange its codebase. First they can
build repository for every service, company can also build single "mono repo" for the whole
services and have folder for each service.
3. Technology Stack
Picking the technology stack for the monolithic application can be very challenging ,
however this particular decision needs to be made in the process of Micro service
implementation. What seems striking in model can become challenging in reality if the services
are too mixed.
We commend a balanced method where there is ideal technology stack in the whole
application (Federico (2018). In case a team attempts to override this nonattendance stack, the
need to defend their decision with pros and cons of why a different stack is more suitable for
their Micro service. Your technology stack should include storage, cloud provider, programming
language, testing as well as logging structure, infrastructure, monitoring, etc.
4. Operational Complication
Micro services significantly rise operational complication since the experts need to
reconsider operations from fundamental position. They need to reflect these aspects:
Infrastructure: Defining groundwork requirements for the Micro services, then provisioning
and maintaining infra for each Micro service adds a point of complication that majority Ops
experts working on monoliths are usually familiar with.
Load balancing and scaling: The company will probably need a scaling plan which is
somehow more complex than the monolithic applications, which are always scaled out (x-axis).

IT ON BUSINESS 5
With Micro services, the experts will have to find out in case they need to scale the whole
services or subset when demand arises.
Service discovery:
The Micro services domain changes vigorously owing to scaling as well as upgrades.
Furthermore, services have active network locations, experts must create new ways to help locate
a new service. We commend the service registry such as Consul.
Monitoring:
This has to be configured and maintained for every Micro service, growing the complication for
Ops engineer(s). Likewise, the observing solution has to deal with situations where a subsection
of the services are frequently scaled up/down. The operational complication therefore needs to
be looked thoroughly(Balalaie, Armin; et al, 2016).
5. Continuous Delivery

IT ON BUSINESS 6
APPROACHES OF MIGRATING TO MICROSERVICES
Migration to Microservices
There are 2 core fundamental methods:
1. Split Core old web service(Monolith) Into Microservices
The method is challenging and can be costly. Full re-platforming can go up to year with heavy
workload. These particular task will require talented and expert since microservices are not an
regular design .
Actually, no business should approve such a method if there is no urgent need. Businesses
usually pick to take such an essential step when the current online structure gets too large and
does not support heavy workload. Migrating into microservices, calls for experienced architects
well-versed in these particular issues.

IT ON BUSINESS 7
2. Build Monolith and create Microservices Around It
When the business team is getting too large to keep the monolith and quickly add new process,
the only way-out is to create new structures such as microservices. Thus, newcomers will work
as subgroups, while the core ~25 developers continue with the monolith. Thus the monolith
becomes one big macroservice while the firm build as many microservices around it as it
requires.
Even if the firm are the outsourcing software development, such a method will disrupt the effort
of the group. Therefore ,it is easier to employ and onboard innovative programmers with the
microservices. Additionally , flexibility of such design improves facilitates management and
collaboration of remote groups. For example, the on-site engineers can work on monolith and
the business logic of the software product, however an outsourced group builds numerous
microservices around it.
Nevertheless, the pitfall with this method is that in case the firm need to reformat monolith in
the future, the method will create bigger trial than implementing microservices fully.

IT ON BUSINESS 8
Roundup
The real world situations always vary from model, and microservices incident is not different
either. Business should always think through its own industrial needs, needs, as well as potentials
before making a decision to shift to microservices. These two approaches to implementing
microservices are just landmarks to guide you through the process. Your business situation is
distinctive and calls for a unique resolution. On the other hand, change is unavoidable and the
business must be ready to come into terms with it.

IT ON BUSINESS 9
In conclusion we can say that Micro services has a major impact on services especially for
companies which handled bug data. And with proper implementation it can greatly increase the
company performance.

IT ON BUSINESS 10
References
Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (May 2016). "Microservices
Architecture Enables DevOps: Migration to a Cloud-Native Architecture" (PDF). IEEE
Software. 33 (3): 42–52. doi:10.1109/ms.2016.64. hdl:10044/1/40557. ISSN 0740-7459.
Neumann, Gustaf; Sobernig, Stefan; Aram, Michael (2014). "Evolutionary Business Information
Systems". Business and Information Systems Engineering. 6 (1): 33–36.
doi:10.1007/s12599-013-0305-1.
Piccoli, Gabriele; Pigni, Federico (2018). Information systems for managers: with cases (Edition
4.0 ed.). Prospect Press. p. 28. ISBN 978-1-943153-50-3. Retrieved 25 November 2018.
Pautasso, Cesare (2017). ": Consistent Disaster Recovery for Microservices: the BAC Theorem".
IEEE Cloud Computing. 5 (1): 49–59. doi:10.1109/MCC.2018.011791714.