Exam Microservices

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Randolph 1

Bryce Randolph
CST 438
09/24/2021
Microservices: Benefits, Drawbacks, Considerations
The practice of splitting a monolithic codebase into a series of much smaller and
independent microservices has become increasingly popular with big tech companies.
This has led to wider implications for the industry as a whole with smaller firms seeking
to adopt this practice to emulate the success of the big guys. This technical report will
seek to outline the benefits of implementing microservices as well as the downsides that
can come with such an approach. In addition, the process of converting a monolithic
system to one using microservices with be discussed along with the considerations that
precede making such a change.
To summarize this technical paper, the benefits of microservices are mostly in
their scalability, agility, and overall independence of each component. This has the
downside of increased cost, overhead, and complexity. Communication between teams
and individual systems’ documentation must be exceptional to facilitate the microservice
approach. It is important to consider your specific needs when choosing to adopt this
approach, and factors like project lifespan, budget, and team size all factor into the final
decision. Finally, it is important to remember that the transition from monolithic to
microservice should be gradual and holistic as opposed to an overnight shift.
The benefits of using microservices primarily lie in their horizontal scalability,
focus on individual quality of each service, as well as independence from other services.
A project can be nearly infinitely scalable when using microservices that do not rely on
each other directly. Microservices also prevent widespread program failure by using
Restful APIs to access information from each service. This creates a system that is very
tolerant of failure, and a specific service going down doesn’t sink the entire ship. In the
case of a specific microservice needing more load capacity, additional instances of that
specific service can be deployed by a company that will require much less processing
power than an entire monolithic service. The agility of a team is greatly enhanced by the
microservice model as individual components can be updated without worrying about
other services. This adds to the overall quality of components on an individual level as
they receive more close attention and more frequent updates as opposed to a
monolithic setup.
The benefits of microservices are just one part of a two-sided coin. The additional
failure tolerance, agility, and scalability contribute directly to exponentially increasing
infrastructure costs. Along with infrastructure costs comes overhead in the form of all
the teams and their communication channels to ensure smooth operation. The
communication between each microservice can result in poorer performance in the form
of latency. Finally, splitting components into microservices increases the overall
environment complexity, and large-scale testing is harder with multiple distributed
services composing the architecture as a whole. Each microservices is going to require
Randolph 2

its monitoring tools, hosting infrastructure, test suite, and team to manage the
aforementioned components. With each team comes more people that need to be in
communication with each other. Documentation of each microservice and its Restful
APIs must be robust to facilitate the previously mentioned scalability and frequent
updates. Overall, these downsides are essentially increased overhead, cost, and
complexity.
Over the lifespan of a project, the necessity for breaking a monolithic service
down into many more manageable microservices can become apparent. The size of the
full team must be large enough to not stretch individuals too thin when adopting the
microservice model. Hiring more employees may not be allowed by the budget. Often, it
does not make sense to use a microservice model in the case of a short-lived project
where lifespan does not exceed a few months. The increased overhead and cost can be
detrimental to the goals of a company. However, in the case of a project with an
indefinite lifespan that could stretch years, starting with a monolithic design while
planning for a future split is a more appropriate option. In general, starting with a
monolithic design makes the most sense, as often a project’s lifespan is not a given. In
this case, steps can be taken to make the future transition to a microservices model
much smoother for the teams involved. Keeping data structures divided from the
beginning allows for an easier pivot to microservices. Similarly, all employees
understanding the boundaries of each component within a monolithic service can create
an easier transition over time. Pieces of the monolith are broken off and molded into
microservices as company resources allow. This change does not have to happen
overnight, and a gradual approach is recommended by experts in the included articles.
Developers need to understand that not every project will directly benefit from using the
microservices model.
With more and more companies adopting microservices as their preferred
development and deployment framework, it is important for those currently employing a
monolithic system to understand the benefits and drawbacks of microservices. For each
benefit, there is a corresponding downside that comes with it which usually ends up
being related to increasing cost, overhead, or complexity. Adopting the microservice
model is something that should happen over time as a company determines that it is a
necessity for their use case. The microservice approach is relatively new in the timeline
of software development, and hasty adoption may be more harmful than beneficial for
smaller-scale projects. The most important takeaway is to further research how
microservices can help your specific application.
Randolph 3

This included image is an example of an implementation of the microservices model.

References
https://www.atlassian.com/continuous-delivery/microservices
https://www.atlassian.com/continuous-delivery/microservices/building-microservices
https://raygun.com/blog/what-are-microservices/
https://microservices.io/

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy