My takeaways from Lightweight Microservice Collaboration, using HTTP at NDC by @chr_horsdal

A natural occurance in Microservice development, is to separate an originally deviced feature into a new microservice. It's a continual evolution.

Enabling continous delivery enables business to experiment and turn around quickly. This is real agility; it's not about the technology as such, but that it enables business to experiment.

By writing very narrowly focused services, they become much more maintainable.
On a negative side, distributed systems are hard! Furthermore, maintaining 100s of services, quickly gets complicated with a complex production environment and a lot of deployments. Refactoring across services are cumbersome. For this last reason, I urge you to start out with slightly too large services and break off distinct functionality as it emerges.

Prefer modelling your communication around events, rather than commands and queries, whenever possible, as events are facts - this thing actually happened.

Both Command and Queries are synchronous in the sense that the recipients must acknowledge the request.

HTTP is there anyway, and is stable - why not use it? And embrace it - return NotFound on queries where the requested object is not found, for example.

Nancy makes implementing ASP.NET Core based systems easy.

For events, the service can publish a get endpoint, supporting paging (HTTP GET /events?from=100&to=200). With an eventing architecture, we can accept (expect) that the service whose events we are polling is down. Perhaps it's being deployed? So we sleep for an hour or so, before we try again, as most events do not need millisecond synchronization anyway, when we dig a bit deper.

You can execute http requests in Visual Studio Code to test your endpoints! .http files.

There are a lot of cases where queuing makes sense, but it does come with a learning and management cost. I think that you can get a long way just by getting your asynchronous communication done correctly.

By prominently showing 'last updated' information on views that are based of an eventually consistent read model, you minimize the risk of someone making a wrong decision, because the data is not yet up-to-date. We are used to see these fields in views that track our deliveries, but they are useful everywhere were we have eventually consistent data.

Some Microservices are more cohesive than others, and that's okay. You group a number of microservices to a bounded context, for example. This goes back to the evolutionary approach of microservices that we further refactor into multiples. Within a bounded context - within a cohesive "bubble" - commands and queries are more acceptable, whereas beteween bounded context, event based synchronization is preferred, as the services are often further away from eachother, organizationally and technically.

Book: Microservices in .NET Core

Comments

Post a Comment

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Image
TL;DR: Yes, they will. Thank you for your time. 😄 Background At Redgate, engineers enjoy a great benefit in that we get are expected to spend 10% of our time to improve on our craft.  Having suffered this week with manually having to copy a bunch of properties from a domain object to its HTTP representation, I decided to spend this week's 10% time to see if I could answer the following questions: Can use AutoMapper to simplify mapping between two types?  Does it also allow me to map between a regular type and a record type? What about the other way around? Can I use this to reduce the maintenance burden in my product? Mapping between two types [automapper fundamentals] To started and get a basic mapping done, created a .NET 5 ASP.NET Web API project, added the below package references and configured automapper : < PackageReference Include ="AutoMapper" Version ="10.1.1" /> < PackageReference Include ="AutoMapper.Extensions.Microsoft.DependencyInj
Read more

Unit testing your Azure functions - part 2: Queues and Blobs

In our last installment , we discovered how to start unit testing our Azure Functions, looking at the HTTP Trigger (and evaulating the function's HTTP response). This time, we'll take a look at using the QueueTrigger, getting supporting data from table storage and outputting Blobs. Yup, I'm tossing you into the deep end! What are we trying to accomplish? This time, we will test a function that performs some arbitrary business logic on bank accounts. The function responds to a storage queue request, logs each command and ensures that each received command is executed exactly once. Almost like a real-world function, huh? ;-) In the function above, we are introduced to three types that we need to deal with in our unit tests - the IQueryable interface, IAsyncCollector and the CloudBlockBlob concrete type. IQueryable is easy enough to work with: Introducing the Testable Async Collector When I first started exploring this topic, I figured I could just use my favourit
Read more

Testing WCF services with user credentials and binary endpoints

Image
This article discusses the following error messages that you might receive from a WCF service An error occurred when verifying security for the message HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml;charset=UTF-8;action="..."' was not the expected type 'application/soap+msbin1' When doing analysis work on existing services, invoking them in a safe test environment is a handy way of getting an understanding of their operations, especially if the documentation has gone missing (or was never written). SoapUI is a tool that can be used to test WCF Services, but did you know that Visual Studio also comes with its own set of tools? Let's start with SoapUI, which is available from  http://www.soapui.org/ . Its operations are quite straight-forward; however, you might run into issues when trying to access services that are protected by user credentials, or when accessing services with binary endpoints. I
Read more