5

I am interested what would be the ideal way to scale Microservices in DDD world?

In case of the following scenario, where Sales context is hosted as a microservice on a different host then Support context, if sales context exceeds hardware limitations, would you:

a) scale vertically (increase the resources of the server)

b) scale horizontally (adding more servers)

c) split microservice so for example Sales Context is now (just a generic solution)

  1. Sales Teritory Context (Customer, Product, Teritory, Sales Person) and
  2. Sales Teritory Oportunities Context (Teritory, Opportunity, Pipeline)

As an alternative, would it be a good approach to use all three techniques but in a specific order ie. so first split microservice (software scale), then scale horizontally (easier hardware scale in terms of maintain application), and then scale vertically (more difficult hardware scale).

I know each scenario is specific, but I would like to know what technique do microservices and DDD encourage?

enter image description here

4
  • 1
    How is c (without a or b) a scaling technique? Oct 19 '16 at 12:57
  • 2
    The same way you would scale microservices if you weren't using DDD. Oct 19 '16 at 23:27
  • @guillaume31 i believe by decreasing complexity of a single microservice by breaking into one or more new microservice would allow existing hardware resources to keep up with the increased requirements. If this is scaling or not, its up to you to decide
    – John
    Oct 24 '16 at 14:16
  • This video might also help: youtube.com/watch?v=MTArpO7rSQE Udi Dahan talking about decomposition Oct 26 '16 at 14:51
1

There is no best solution for this question. It's only a question of costs and benefits:

  1. Vertical scaling is often the easiest path, until a certain stage: extending processing capacity of the services with additional cores, RAM, network cards, faster disks is mostly a plug & play effort; Moore's law combined with decreasing hardware prices are on your side.

    However, when you come close to the limit of your hardware architecture, and if you can't split your microservice further, moving to the next high volume server technology might require much more investment, and one day you'll be close to the financial or technical limits.

  2. Horizontal scaling is the most flexible. Containters in large server farms are nowadays a comodity. With this approach you generally can reach much higher volumes than with vertical scaling at a better cost (compared to buying a huge supercomputer). However, this requires your the bottleneck microservices is designed to be run in multiple instances (e.g. stateless rest API instead of state dependent API; use of messaging queues, etc. ).

  3. Partitionning of data between services based content criteria (e.g. geographic location of customer) is a very interesting approach. It's common business for microservices. But you need some dispatching mechanisms that the right service instance processes the right requests.

    Combined with horizontal scalability, this could help to get rid of any bottlenecks, and optimize network performance, especially if you manage to use a geographic partitioning relevant for your users (e.g. put the data on the continent where most user access it). However this is also the most delicate to design : it requires a very good knowledge of data dependencies across the partitioning criteria and services, as well as some dynamic registries to manage the deployment scheme.

So now, up to you to balance the pros and cons of each approach in your context.

2

It depends. But the best solution is to use all three techniques. Only you can choose the order however.

You must decide what will be cheaper and faster to achieve. For example, if you don't have top-level hardware, then adding some more RAM can help you achive your goal quick and cheap. However, if you already had a top-level hardware and buying a new one, that has even more performance, can be very expensive. In this case it's a good idea to use horizontal scaling. You can further split your micro-service into multiple micro-services or you can just use horizontal scaling of your database or back-end servers in the context of existing micro-service. Also i want to note, that there are many techniques to speed up your code, not only hardware.

So just sit down, look at these three techniques and choose one that is more suitable for you at a concrete time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.