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


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


10

I’m finding it hard to avoid data duplication.... According to the Microsoft ebook on microservice architecture, there is nothing wrong with data duplication. Basically, duplicating data increases the decoupling between the services and therefore strengthens their roles as a single authority. A relevant passage: And finally (and this is where most of the ...


9

People often hear "micro-service" and think "nano-service", and this can cause some confusion. These are micro-services, so you don't need a separate service for every single entity. Everything you are trying to do should be in the booking and notification services. You don't need the driver service (for any of the activity you described). Getting a list of ...


8

No code reuse is usually understood as a selling point for microservices! the microservices can be developed and deployed independently different microservices can use different technologies, in particular different programming languages If this does not seem like an advantage – in particular if all microservices are developed by one team, using one ...


8

I'll preface my answer by saying that I actually maintain a couple microservices that use stored procedures. Also I've written a lot of stored procedures at various points in my career, and I definitely agree that things can go very, very wrong if they are used incorrectly. So the short answer is, no, stored procedures aren't inherently bad in a ...


7

Big companies are often a bunch of small companies operating under a common name. Either because of historical reasons (they used to be independent until some merger or take-over) or because of practical reasons (having decentralised management can be more agile). The sub-companies enjoy some independence and may even have their own culture. They can make ...


6

I vehemently opposed Vehemence makes others stop listening and, at the same time, limits our perception of the problems and their solutions. To my experience, we become vehement at defending or opposing ideas we don't fully understand. Although shared entities sound harmless to me, I opposed the idea of having shared repositories MS architectures ...


6

You could split your application in "bounded contexts" (see Domain Driven Design) and use events to communicate between contexts. The events should only use simple data types that could be easily transferred over the wire later. Direct object references to another bounded countext wouldn't be allowed.


6

If you notice, most of these systems are setup in such a way that you're going to get some well known string input and have to produce some well known string output. At that point, they can take your code and run it as a plain old executable (in some highly disposable sandbox), testing via stdin and stdout while ignoring what language actually created the ...


6

As I see it, the size of the application doesn't really have much to do with the microservices pattern. After all, you can always choose to build a few large monoliths or to build a monolith out of lots of smaller libraries where it makes sense, or keep it in one large codebase using modules/namespaces/packages/whatever-your-language-offers. The use cases ...


5

However, let's say that I want to split a service into its own "microservice". Where would it store its data? If I have 5 microservices, spinning up 5 RDS instances, 5 redis clusters doesn't seem to be the most cost effective and seems to be a lot of management overhead. In order to a pure microservice, your services need to have autonomy over their data. ...


5

If we consider the cache to be orthogonal to the architecture (and it's), the first pic is ok. For the same reason that we don't deploy one security service, one API gateway, one message broker or one service locator per POD we don't have to deploy one Cache (in replica-set) per POD.1 Be aware of premature optimizations Caches are meant to solve specific ...


5

Did you click through to the full description of the first factor? If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor. So when thinking about 12-factor apps in the context of microservices, treat each microservice as a ...


5

Dynamically selecting the correct API implementation sounds cool, but is actually a nightmare. a REST API exposes a bunch of URIs that identify resources cool URIs don't change here, the interpretation of the URI depends on the implicit version so your URIs do not identify resources by themselves this breaks REST, to some degree Your implicit version ...


5

Yes, querying each microservice is unavoidable in this case. That's one of the main trade offs of microservices. However, I think if you actually sat down and designed the endpoints, you would find it's not as burdensome as you think. For example, it would surprise me very much if your billing service doesn't already have a way to list all the subscriptions ...


5

1 or 3 depending on the data and your needs. A shared database is a no-no since it then means your services are not independently deployable and scalable. You need one service that owns the data and is its source of truth. It can then make sense to also replicate the data to cut down on latency if that is more important than the data being up to date.


5

Data is not a service. Access to data may be a service. Processing data definitely is. You should ask yourself: what does my system do with that data? What is the service interface that my domain components require to access in order to use the country data? And then: Do all my components agree on the syntax of that interface? Do all my components agree on ...


4

I think you correctly diagnose the problem, Micro-service architecture is designed for scalability and distributed systems. You don't want them to talk to each other, or use the same database. Either, go for the distributed stateless approach. Or, merge the services to make one macro-service. You can still separate the code out into service classes etc, but ...


4

Separate services should use separate REDIS instances. Reason: Bad usage of REDIS by another service, causing REDIS outage, should not impact your application. Only queues which are used for inter-service communication should be shared.


4

The entire point of microservices is that they are independently deployable and scaleable. If you're talking about 5-6 literal endpoints (uri endpoints, sockets, message types - effectively 5-6 callable functions) then putting them together is fine. Having a single function per deployment is probably pathologically/impractically micro. If you're talking ...


4

When a user registers I assume they specifically opt-in to receive notifications due to legal reqiuirements such as the GDPR regulations in the EU. Therefore you could have two events during user account registration: UserRegistered and UserOptedInToReceiveNotifications. The opt-in event would be consumed by the notification service to configure their ...


4

The other answers are correct as far as the coupling being at the data interface level. But they don't really answer the question posed in the title: How do I manage shared models among many microservices? Conventional microservice wisdom is to err on the side of coupling loosely; share as little code as possible. A brief overview of the problems with ...


4

Microservices have technical and social aspects: each microservice can be developed and deployed independently each microservice can scale independently For each of these aspects – development, deployment, scaling – it took some time until microservices became a sensible option.   Most problems then and now are simply not so big that scaling would ...


4

Use environment variables. They've existed for decades and all current (and past) tools support it, including Docker, Kubernetes and the like.


4

You've got options. Bare Metal/Standard Virtual Machines If you are on bare metal (getting rarer these days, but still common enough in some industries), you can always have an instance of your discovery service on each machine. Since just about all of them handle clustering, you just need to look at localhost for your discovery service. Dockerization ...


4

Synchronous is not instantaneous. The network operation still takes just as long, possibly longer because synchronous operations occupy threads longer, which decreases server resources. It's still possible for two drivers to hit the accept button at the same time. If you don't want the UX of a driver's acceptance not being confirmed, the only real ...


4

services that are not internally developed and maintained but still play a part in the overall system environment Components/parts/whatever that your team/company/etc. did not develop themselves but got from another party (could be another team within the same company, depending on your scope), are commonly referred to as "third party" components/parts/...


4

Stored procedures are implementation details. Database functions, lambdas, or a shell script stored somewhere in the file system are all implementation details and irrelevant for the architecture. most books on microservices recommend one database per microservice. Ok, so we can code the stored procedures in these databases. again most microservice ...


3

In order for this to be considered a proper microservices architecture each app needs data-autonomy. Without that, you still have coupling between the applications via the database schema. Whether you need a full-blown microservices approach here is something you need to decide. This could be a step in that direction but you need to realize that you will ...


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