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).

Security

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?
A 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: http://www.infoq.com/news/2008/09/Orchestration.

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

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