Design and Implementation of Microservices by @samnewman (@NDC_Conferences) [ 3 / 4 ]

(This is a continuation post: Part 1 discussed what Microservices are, capabilities, complexities, service modelling and collaboation styles; Part 2 discussed SOAP or HTTP services, splitting, databases, continuous integration, containers (docker), service location and service discovery).


Identify which of your data is sensitive within your domain. Talk to your team about the threats described in OWASP Top 10:

Patch your OS! It will mitigate 70% of existing threats. Beware of wasp/bee mentality where we are happy with only a perimeter defense and reason that "anyone inside can access anything anyway, if they would like to".

There are some low hanging fruits that we can pick: Enable HTTPS. It will ensure the client that it is, in fact, talking to the server it thinks it's talking to. Some caveats here is that it's easy to get certificates wrong. You will also need additional logic to identify your clients. Now, don't use HTTPS for public data, unless you need to guarantee your clients that it is you that is publishing this information. HTTPS comes with a cost which is extra noticeable in 3G networks, so, as always - think before you act. ;-)

Client-based certificates are hard to get right. When discussing client tokens, remember to include a discussion about termination of said token - what should happen when a customer's subscription end or an employee moves on to a different company? Look into OpenId Connect if you haven't already, recommended Sam.

To mitigate a confused deputy attack- that is, executing a request on behalf of someone else - follow these guidelines:
  • Are you, as a server, allowed to execute said request / access requested resource?
  • Are you, as a server, allowed to execute this request on behalf of your user?
  • Does the user have access to the given resource / is allowed to execute the request?
confused deputy is a computer program that is innocently fooled by some other party into misusing its authority. It is a specific type of privilege escalation. In information security, the confused deputy problem is often cited as an example of why capability-based security is important, as capability systems protect against this whereas ACL-based systems do not. -- Wikipedia
More: Some history about the threat, going back as far as 1988.

Async programming - middlewares - brokers - MQs

Middlewares are awesome! They can handle resilience, retry logic, node failover ... they can manage client state ("what have I seen already?"). However, when they get too smart, they become a liability. The ESB is bad ([2], [3]). Keep your middleware dumb!, Sam stresses and recommends us to look at RabbitMQ and Tibco and to read the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.

Orchestration vs. Choreography

Orchestration Choreography
  • + Easily Visible
  • - Centralization of Logic
  • - Dumb "Services"
  • - Risky to Change
  • + Easy to add sub-processes
  • - Implicit Process Model, which makes it ...
    • Hard to get an Overview, which can lead to ...
      • Tricky bugs, such as customers getting charged for services they haven't ordered.
Because of the implicit process model, we need a reconciliation process to verify our business logic.

Reasoning about choreography in nature, Sam asked us to imagine an ant: It acts autonomously but is choreographed with the rest of its peers to fulfill its purpose.

More about orchestration vs chroreography:

Sam recommended Splunk as a good tool for log aggregation and analysis.

Microservices in greenfield projects

See my blog-post on the subject!, said Sam, and continued by advising us to, generally, start out by building a monolith until we understand the problem space and the service boundaries; then extract into services (see part 1 for a more in-depth discussion). By building up a monolith first, you can then reactively see which parts of the code is changed often as an indication of parts that should be extracted into its own service.

Testing and deployment

Don't let integration testing (a fan-in operation) be a bottleneck, causing multiple new components to be published into production at once. Timing issues and non-deterministic errors lead to complacency and teams ignoring failed tests. Consider not performing integration tests before production, but instead publish your service first in production and then (or in parallel) to your integration test environment, so that you have a production-like environment in which to reproduce bugs.

To succeed with this, you will want to look into each module/service releasing expectations (tests) that they trust their service providers to run:

Pact provides an fluent API for service consumers to define the HTTP requests they will make to a service provider and the HTTP responses they expect back. These expectations are used in the consumer specs to provide a mock service provider. The interactions are recorded, and played back in the service provider specs to ensure the service provider actually does provide the response the consumer expects. 
This allows testing of both sides of an integration point using fast unit tests.
Sam played out a scenario where a consultancy would get paid when the pact tests passed, rather than when fulfilling an arbitrary legal contract.

Focus on the core journey your system should provide: Even big systems have a few of these.


Next up:

  • Testing vs. Monitoring-and-Acting
  • UIs
  • Versioning


Popular posts from this blog

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

Unit Testing your Azure Functions

Blob identifiers must be in the format 'container/blob'. #webjobs rocks.