Tag: Microservices

Microservices & the Great Negotiator

So you’ve just finished your 8.30 am daily standup and you bump into this scene on the way back to your desk


Obviously this wont do, so you spent a few minutes asking whats wrong, then back at your desk, halfway through the morning tele-scrum with the London team (you’ve missed Hong Kong) and you realise you’ve doodled this on your notepad.

what they said

Clearly the system isn’t working. And I don’t mean Capitalism. People want to buy, people want to sell, but the pipeline is blocked, the Brent crude isn’t flowing, and the Pork bellies are going off in the warehouse. Being a practical fellow however, by the end of the 10am scrum-of-scrums call (to Dublin, the new financial centre of the EU, don’t you know), you’ve come up with a rough draft of a solution and it looks something like this.

how it should work

Finally, just what all parties have been crying out for. Customers can place an order with their preferred price range. This will get looked at immediately by the Negotiator, which will decide on a response. Outrageously low bids by Customers will never get anywhere near the Suppliers, who will be happily spending their time on servicing sensible orders. Customers can up their game by increasing their bid, but only a set number of times before the pending order expires, to prevent them playing unfairly by incrementing by 0.1c… Of course they could just open a whole new order each time with an incremented bid, but thats a challenge to deal with on another day.

To your mind, this is crying out for a microservices implementation. And why not. Looks like you’ve got at least 3 semi-independent processes here, with what could be broken out as semi-independent data-stores, if one were so inclined. And maybe you want the flexibility of being able to deploy, stop and start the services independently, ie you could stop the Negotiating service for maintenance, and still be receiving new/pending orders, and (if you maintain a very large backlog) you could have the PrepForSupply service dispatching and updating agreed orders, while the Place Order service is on hiatus. In short, you have convinced yourself that microservices is the way to go on this one. Considering this in more detail, you arrive at this:

microservices to the rescue


Clearly this diagram doesn’t show the normalised form, with the extra tables where you would store the supplier’s or customer’s details for example, but in terms of getting the message across, it packs a punch. This is where you get bogged down in the detail of whether each service should only talk to its own database, or be limited by schema within a shared database, or whether there should be a shared data access layer and so on. Being in a decisive mood this morning, you decide that yes each service should have its very own private data-access layer/code. However some tables can be shared between certain services to a limited extent. And maybe the tables are in different databases, maybe they aren’t.

And do you really need different tables for PendingOrders, RejectedOrders, and AgreedOrders, or could you just use a single table with a status flag?

The thing is, its almost 11am and you are not sure all the thinking you’ve done so far actually qualifies as being hard at work, so you run off some scripts at the database(s) to create the relevant tables (scripts here), fire up Visual Studio (or EnterpriseArchitect), and open up its CodeTrigger ‘DB To Microservice’ wizard extension. Pointing the wizard at your new database(s)/tables/schemas, you click through and generate the microservices. 5 minutes later you have 3 microservices up and running, connected to their respective data-stores.

generating 2 microservices

services running bare

Well its a good thing all that plumbing code is taken care of. So you can concentrate on delivering value to the business. With that in mind, you can dive right in and put in the business logic. Replacing the skeleton service ‘start’ methods in the generated code with the code snippets here¬†you can run all the services, and there you have it.services running full2

All done, and just in time too. Maybe after lunch, you could turn it into a distributed system, using Akka.Net for clustering on the servers ?


Full Project files and Code Snippets here