Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/tidylab/microservices

Breakdown a Monolithic Application to a Suite of Services
https://github.com/tidylab/microservices

microservices r

Last synced: 3 months ago
JSON representation

Breakdown a Monolithic Application to a Suite of Services

Awesome Lists containing this project

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` 



[![CRAN

status](https://www.r-pkg.org/badges/version/microservices)](https://CRAN.R-project.org/package=microservices)

[![R build

status](https://github.com/tidylab/microservices/workflows/R-CMD-check/badge.svg)](https://github.com/tidylab/microservices/actions)

[![codecov](https://codecov.io/gh/tidylab/microservices/branch/master/graph/badge.svg?token=ZLBYE2NIWF)](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