From c8468dc66762f8357bf680924bbebbdfb6f0f96b Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 30 Dec 2019 18:48:53 -0300 Subject: [PATCH] New blog post: Artifact ejection --- .../code/microservices-artifact-ejection.md | 55 +++++++++++++++++ .../microservices-artifact-ejection.pt.md | 59 +++++++++++++++++++ 2 files changed, 114 insertions(+) create mode 100644 content/code/microservices-artifact-ejection.md create mode 100644 content/code/microservices-artifact-ejection.pt.md diff --git a/content/code/microservices-artifact-ejection.md b/content/code/microservices-artifact-ejection.md new file mode 100644 index 0000000..4145500 --- /dev/null +++ b/content/code/microservices-artifact-ejection.md @@ -0,0 +1,55 @@ ++++ +title = "Microservices: Artifact Ejection" +date = 2019-12-30 + +[taxonomies] +tags = ["microservices", "artifacts", "connection", "ejection"] ++++ + +As I was discussing about [artifacts in +microservices](@/code/microservices-artifact-input-state.md), I guess I forgot to +discuss some important point: How those artifacts are "ejected" from the +microservice? + + + +"Ejected", in this case, means "pass it to the next necessary stage", which +can mean a lot of stuff (sometimes, more than one). Also, I needed some catchy +word for it 'cause simply "produces" isn't that fashionable. + +For example, if your microservice is producing intermediate data -- say, it +connects to an external service and retrieves information, which is then +processed by different microservices -- then you probably want to use a +message broker as the ejection route for the artifact. Using a message broker +will allow another services to keep listening to the creation of those +artifacts and do their thing -- producing new artifacts. + +Another possibility is that this microservice is the end of the production +line and, thus, it just keeps the artifact in order to by consumed in a +non-asynchronous way. For example, the microservice may produce elements that +are later requested by a web request, so what its needs is to produce said +artifact and keep it around, responding requests later. + +This, again, is akin to the way CQRS (command-query response segregation) +works: You have one side of your microservice receiving data and processing +its artifact, and another that allows querying the artifacts. + +You can even do both: When the artifact is produced, the microservice ejects +it through a message broker to be processed by other microservices and still +stores it internally to be queried. + +There is even the possibility of the query part be just another microservice: +It gets the artifact from another microservice and stores it, with no +processing (if you don't count as "saves in a permanent storage" a +processing). This is interesting 'cause the "query" part of the microservice +is just another microservice, instead of being some sort of specialized +microservice that produces, ejects and stores artifacts. + +When I mentioned we saved our artifacts in Firebase, we are basically building +this split microservice: While we have microservices that produce the +artifacts, the "storage and query" part is giving to Firebase -- but you can +consider this as any other service. + +(This whole post is just to give some pointers on what I want to discuss next, +which are some thoughts about self-healing microservices -- and what I meant +by that.) diff --git a/content/code/microservices-artifact-ejection.pt.md b/content/code/microservices-artifact-ejection.pt.md new file mode 100644 index 0000000..7877e3f --- /dev/null +++ b/content/code/microservices-artifact-ejection.pt.md @@ -0,0 +1,59 @@ ++++ +title = "Microserviços: Expelindo Artefatos" +date = 2019-12-30 + +[taxonomies] +tags = ["microserviços", "artefatos", "conexões", "expelir"] ++++ + +Como eu estava comentando sobre [artefatos em +microserviços](@/code/microservices-artifact-input-state.pt.md), eu acredito que esqueci +de discutir um ponto importante: Como é que esses artefatos são "expelidos" do +microserviço? + + + +"Expelido", nesse caso, significa "passa para o próximo estágio necessário", +que pode ser um bocado de coisas (algumas vezes, até mais de uma). E como eu +precisava de um palavra capciosa para chamar a atenção, já que "produz" não +tem nada de chamativo. + +Por exemplo, se um microserviço produz um dado intermediário -- digamos que +ele conecta num serviço externo e busca uma informação, que é então processada +por outros microserviços -- então você vai possivelmente utilizar um serviço +de message broker (mensageria) para expelir o artefato. Usando um message +broker irá permitir que outros serviços fiquem escutando a criação desses +artefatos e que façam seu serviço -- produzindo novos artefatos. + +Outra possibilidade é que esse microserviço é o fim da linha de produção e, +por isso, ele mantém o artefato consigo para ser consumido de uma forma +não assíncrona. Por exemplo, o microserviço produz elementos que são pedidos +depois uma requisição de um serviço web, e o que o microserviço precisa fazer +é produzir o artefato e mantê-lo em si, respondendo requisições mais tarde. + +De novo, isso é semelhante a forma com que CQRS (command-query response +segregation -- segregação de comandos e queries) funciona: Você tem um lado do +seu microserviço que recebe dados e processa o artefato, e outro que permite a +consulta dos artefatos gerados. + +Você pode até mesmo ter os dois: Quando o artefato é produzido, o microserviço +expele o mesmo pelo message broker para ser processado por outros +microserviços, e guarda o artefato localmente para ser pesquisado depois. + +Existe até mesmo a possibilidade da parte de pesquisa/query ser apenas outros +microserviço: Ele recebe o artefato de outro microserviço e o armazena, sem +qualquer processamento (desde que você não considere "salva num armazenamento +permanente" uma forma de processamento). Isso é interessante porque a parte de +pesquisa/query do microserviço é apenas um outro microserviço ao invés de ser +uma espécie de microserviço especializado que produz, expele e armazena +artefatos. + +Quando eu mencionando que nós salvamentos nossos artefatos no Firebase, nós +estamos basicamente construindo esse microserviço separado: Enquanto nossos +microserviços produzem artefatos, a parte de "armazenamento e pesquisa" fica a +cargo do Firebase -- mas você pode considerar isso como qualquer outro +microserviço. + +(Esse post é simplesmente para ter alguns ponteiros a mais para quando eu for +discutir um pouco mais sobre o que eu penso sobre microserviços com auto-cura +-- e o que eu quero dizer com isso.)