We’re rewarding the question askers & reputations are being recalculated! Read more.
216

The first tweet was mine, so I'll expand on it: Suppose you have 100 developers, working on a monolithic application. That's too many people to communicate effectively between each other, so the company has to work hard to divide them into smaller teams and create good communication patterns between them. When the organisation is "dysfunctional", teams ...


196

I have a problem. Let's use Microservices! Now I have 13 distributed problems. Dividing your system into encapsulated, cohesive, and decoupled components is a good idea. It allows you to tackle different problems separately. But you can do that perfectly well in a monolithic deployment (see Fowler: Microservice Premium). After all, this is what OOP has been ...


72

Assumed you have some services which can use the same kind of DB system and version, if you use different database or db instances is a decision you should not need to make at design time. Instead, you should be able to make the decision at deployment time, something you can simply configure. Design your services to be agnostic of the place where other ...


70

Databases are not very good at information hiding, which is quite plausible, because their job is to actually expose information. But this makes them a lousy tool when it comes to encapsulation. Why do you want encapsulation? Scenario: you tie a couple of components to an RDBMS directly, and you see one particular component becoming a performance bottle-...


61

Internal networks often use 1 Gbps connections, or faster. Optical fiber connections or bonding allow much higher bandwidths between the servers. Now imagine the average size of a JSON response from an API. How much of such responses can be transmitted over a 1 Gbps connection in one second? Let's actually do the math. 1 Gbps is 131 072 KB ...


56

What is more important and significant about a microservice: its API or its database schema? The API, because that is its contract with the rest of the world. The database schema is simply a convenient way of storing the data managed by the service, hopefully organised in a way that optimises the microservice´s performance. The development team should be ...


49

Microservices are generally undesirable because they turn your software into a distributed system – and distributed systems make everything a lot more difficult. But a service-oriented architecture has some important benefits: different services can be developed and deployed independently by different teams different services can be scaled independently As ...


45

There is nothing that explicitly forbids or argues against using stored procedures with microservices. Disclaimer: I don't like stored procedures from a developer's POV, but that is not related to microservices in any way. Stored procedures typically work on a monolith database. I think you're succumbing to a logical fallacy. Stored procedures are on ...


43

My question is: What does it mean that shifting to microservices creates a run-time problem? That is not what those tweets are saying! They don't say anything about shifting to microservices, nor do they say anything about creating problems. They only say something about shifting problems. And they put a contextual restriction on their assertions, namely ...


42

The usual approach is to isolate those microservices as much as possible - treat them as single units. Then transactions can be developed in context of the service as a whole (ie not part of usual DB transactions, though you can still have DB transactions internal to the service). Think how transactions occur and what kind make sense for your services then, ...


38

My advice? Do not share these DTOs among the applications in any kind of library. Or at least don't do this right now. I know, seems very counter-intuitive. You are duplicating code, right? But this is not a business rule, so you can be more flexible. The service that sends the DTO needs to be rigid in his message contract, like an Rest API. The service ...


36

In a Microservices architecture, each one is absolutely independent of the others and it must hide the details of the internal implementation. If you share the model you are coupling microservices and lose one of the greatest advantages in which each team can develop its microservice without restrictions and the need of knowing how evolve others ...


35

Let's talk positives and negatives of the microservice approach. First negatives. When you create microservices, you're adding inherent complexity in your code. You're adding overhead. You're making it harder to replicate the environment (eg for developers). You're making debugging intermittent problems harder. Let me illustrate a real downside. ...


34

Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and ...


30

I think the standard wisdom is to never have transactions cross microservice boundaries. If any given set of data really needs to be atomically consistent with another, those two things belong together. This is one of the reasons it is very hard to split a system into services until you have fully designed it. Which in the modern world probably means ...


24

To write software requires that you tightly couple to a technology. At the very least to the runtime environment provided by the programming language being developed within. More generally though you will find that your micro-service is tightly coupled to several technologies: Network Service Framework to provide high level HTTP/SSL/SOAP protocol ...


21

I would generally advise against having microservices do synchronous communication with each other, the big issue is coupling, it means the services are now coupled to each other, if one of them fails the second is now fully or partially disfunctional. I would make a clear distinction between state changing operations and read operations (CQS Command Query ...


21

It really depends on your scalability requirements, and how/if your microservice instances need to cooperate to provide a single result. It helps to know what the trade-offs are: Keeping it all in one database Easier configuration No coordination or communication with other instances of your service needed Easier to discover your full dataset System ...


20

The point of microservices is not to reduce processor load. In fact, because of the overhead of communication and repetition of functions that used to be global utility code, it usually increases processor load somewhat. The point of abolishing a monolith is much more to be able to maintain, deploy and run a complex system of functionality at all. Once your ...


20

A search feature can be modelled as a separate service with separate responsibility from the two services you mention. So, the approach here could be to create a new service ('search') and have it store a copy of the data from both services in a form which is easy to index and search, possibly also denormalized in order to quickly give results in the desired ...


20

Of your three options, the first (a single, shared database) and the third (a "database service") are the most common. The first is called an integration database. This is generally not seen as a good solution in a microservice architecture. It does add coupling to your services. It also makes it very easy for one service to simply bypass the other services ...


17

I think that if consistency is a strong requirement in your application you should ask yourself if microservices is the better approach. Like Martin Fowler says: Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single ...


17

There is no clear solution because this depends entirely on your context – in particular, along which dimensions your system is supposed to scale and what your actual problems are. Is the database really your bottleneck? This (unfortunately rather lengthy) answer will read a bit like “microservices are bad, monoliths for life!”, but that's not my intention. ...


16

As suggested in at least one of the answers here but also elsewhere on the web, it is possible to design one microservice which persists entities together within a normal transaction if you need consistency between the two entities. But at the same time, you might well have the situation where the entities really do not belong in the same microservice, ...


16

First, it is important to understand and be able to leverage the difference between Commands and Events. As this question succinctly points out, Commands are things we would like to happen, and Events are things that have already happened. A command does not necessarily result in a significant event in the system, but it usually does. For example, a send ...


15

Microservice Architecture is hard to describe but the best way to think about it is a marriage between Component Oriented Architecture and Service Oriented Architecture. Software as a suite is composed of many small business components with a very specific business domain responsibility. Their interface to the outside world either in provided services or ...


15

This is hard to implement because of the definition of what is healthy You answered your own question here. The definition of a health check is going to vary, because what is healthy varies. It also depends on what is issuing the healthcheck. A good question to ask yourself is, "from the perspective of the asker, is the checked service working as expected?"...


15

Why do we even need it? You don't. Creating a separate database for each service helps to enforce domain boundaries, but it's only one approach. There's nothing stopping you from having all your services share the same database. As long as your services behave and don't do unexpected things to data owned by other services, you'll be fine. I don't know ...


14

If you want your services to look like on this picture, then yes: It is not like you can't do it, but most of the time it will have bad consequences. Communication through REST will not decouple your services significantly. When some service interface changes, all dependent services most likely have to be changed and redeployed. Also while redeploying ...


13

If two services are sufficiently intertwined that it would be a pain to implement them without sharing DTOs and other model objects, that's a strong sign you shouldn't have two services. Certainly the example makes little sense as two services; it's hard to imagine a specification for 'User management' so complicated it would keep a whole team so busy they ...


Only top voted, non community-wiki answers of a minimum length are eligible