https://github.com/tidylab/microservices
Breakdown a Monolithic Application to a Suite of Services
https://github.com/tidylab/microservices
microservices r
Last synced: 13 days ago
JSON representation
Breakdown a Monolithic Application to a Suite of Services
- Host: GitHub
- URL: https://github.com/tidylab/microservices
- Owner: tidylab
- License: other
- Created: 2021-02-20T04:52:11.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2022-10-01T10:17:28.000Z (about 3 years ago)
- Last Synced: 2024-08-13T07:13:32.179Z (about 1 year ago)
- Topics: microservices, r
- Language: R
- Homepage: https://tidylab.github.io/microservices/
- Size: 247 KB
- Stars: 16
- Watchers: 2
- Forks: 2
- Open Issues: 7
-
Metadata Files:
- Readme: README.Rmd
- License: LICENSE
Awesome Lists containing this project
- jimsghstars - tidylab/microservices - Breakdown a Monolithic Application to a Suite of Services (R)
README
---
output: github_document
bibliography: [./inst/REFERENCES.bib]
biblio-style: apalike
link-citations: yes
nocite: |
@Fowler2014
@Newman2015
editor_options:
canonical: true
markdown:
wrap: 80
references:
location: section
---
```{r, include = FALSE}
source(file.path(usethis::proj_get(), "vignettes", "_common.R"))
```
# `microservices` 
[](https://CRAN.R-project.org/package=microservices)
[](https://github.com/tidylab/microservices/actions)
[](https://app.codecov.io/gh/tidylab/microservices)
`r read.dcf("DESCRIPTION", "Title")[1]`
```{r, echo = FALSE, out.width = "100%"}
knitr::include_graphics("https://i.imgur.com/nZ5jw2g.png")
```
## Introduction
`r read.dcf("DESCRIPTION", "Description")[1]`
## Should I use microservices?
As a start, ask yourself if a microservice architecture is a good choice for the
system you're working on?
::: {.alert .alert-danger}
**Caution**: If you do not plan to deploy a system into production, then you do
not need `microservices`.
:::
The microservice architecture entails costs and provides benefits. Making lots
of independent parts work together incurs complexities. Management, maintenance,
support, and testing costs add up in the system. Many software development
efforts would be better off if they don't use it.
If you plan to deploy a system into production, then consider the following:
- Favour a monolith over microservices for simple applications. Monolith can
get you to market quicker than microservices.
- Monolith-first Strategy: If possible, start with a monolith and design it
with clear [bounded
contexts](https://martinfowler.com/bliki/BoundedContext.html). Then, when
deemed necessary, gradually peel off microservices at the edges.
After mentioning the disadvantages and dangers of implementing microservices,
why should someone consider using them?
[@Newman2015] suggests seven key benefits of using microservices:
- **Technology Heterogeneity**. With a system composed of multiple
collaborating services, we can decide to use different
technologies/programming-languages inside each one. This allows us to pick
the right tool for each job rather than to select a more standardised,
one-size-fits-all approach that often ends up being the lowest common
denominator.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/vX1u9Po.png")
```
- **Resilience**. A key concept in resilience engineering is the
[bulkhead](https://en.wikipedia.org/wiki/Bulkhead_(partition)) which
originates in ship design (see illustration). If one component of a system
fails, but that failure doesn't cascade, you can isolate the problem and the
rest of the system can carry on working.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/qelkZ9P.png")
```
- **Scalability**. With a large, monolithic service, we have to scale
everything together. One small part of our overall system is constrained in
performance, but if that behaviour is locked up in a giant monolithic
application, we have to handle scaling everything as a piece. With smaller
services, we can scale those services that need scaling, allowing us to run
other parts of the system on smaller, less powerful hardware.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/1Tf9Hrh.png")
```
- **Ease of Deployment**. With microservices, we can make a change to a single
service and deploy it independently of the rest of the system. This allows
us to get our code deployed faster. If a problem does occur, it can be
isolated quickly to an individual service, making fast rollback easy to
achieve. It also means we can get our new functionality out to customers
faster.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/U60xp1V.png")
```
- **Organizational Alignment**. Microservices allow us to better align our
architecture to our organisation, helping us minimise the number of people
working on anyone codebase to hit the sweet spot of team size and
productivity.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/8mk0BlZ.png")
```
- [***Composability***](https://en.wikipedia.org/wiki/Composability).
Similarly, to the tidyverse packages, where different compositions of
packages are used in different analytic projects in R, with microservices,
we allow for our functionality to be consumed in different ways for
different purposes. For example, a *demand forecasting* service can be
consumed by several different dashboards and a logging system.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/gHMkhtV.png")
```
- ***Optimizing for Replaceability***. With our services being small in size,
the cost to replace them with a better implementation, or even delete them
altogether, is much easier to manage than in a monolithic app. For example,
during the football world cup, a news website may offer football-related
analysis. Rather than making the analysis part of the website codebase, we
can create a microservice to deliver the football analytic service and
remove it when the tournament is over.
```{r, echo = FALSE, out.width = "25%"}
knitr::include_graphics("https://i.imgur.com/SNQAINt.png")
```
To conclude, not every application needs to be built as a microservice. In some
cases, such as in a system that is an amalgam of programming languages and
technologies, microservices architecture is advised or even necessary. However,
seldom it is a good choice to start building an application as a microservice.
Instead, a better option is to design a system in a modular way and implement it
as a monolith. If done well, shifting to microservices would be possible with
reasonable refactoring effort.
## Installation
You can install `microservices` by using:
```{r, eval=FALSE, echo = TRUE}
install.packages("microservices")
```
## Further Reading
- [YouTube Video](https://www.youtube.com/watch?v=k3PuGGmA7Hg): KPMG case
study for implementing microservices in R (with
[`plumber`](https://www.rplumber.io/) and [RStudio
Connect](https://www.rstudio.com/products/connect/)).
## Bibliography