Hot answers tagged

73

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


57

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


43

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


32

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


30

Well, there are a lot of ways to learn how to build a RESTful web application and no, there isn't a unique right way. RESTful is not a standard but it uses a set of standards (HTTP, URI, Mime Type, ...). Start with this: How I Explained REST to my wife Then, proceed with this: RESTful Web Services Cookbook And then put your entire effort to develop web ...


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


16

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


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


13

Java was (and still is) simply the most popular language for the kind of application where the SOA concept is most attractive, i.e. heterogenous distributed and integrated systems with constantly shifting requirements aka "enterprise applications". So everyone was already using Java for such systems before SOA became a buzzword in exactly the same area. As ...


13

I was part of a team that successfully built a microservices architecture using a service bus. Initially, we believed that microservices and an event driven architecture would enable us to fix the underlying shared data ball-of-mud database. What we learned was that microservices and an event driven architecture required us to get rid of the underlying ...


12

I've encountered this before (many times) and what I've ended up doing preferring is: Take the BL out of the website. Make the website a consumer of the API. Treat the website as just some other client of your API. Your API IS the service. If you find yourself thinking that you need special API methods just for the website, think again! If its good for ...


12

Service Providers, doing only one thing The core difference, which has widespread consequences of the project, is that with Microservices these Service Providers are independently deployable and scalable. This is great, because you can be more agile. If a service needs changed, you just change that one, none of its kin. If you want to try a new framework ...


10

Are your web services individually deployable? Individually scalable? Individually monitored? Microservices are just more granular (and decoupled) varieties of the web services most places have to provide a little more control on the Ops side of the world. Is that useful for you? Maybe. Maybe not. Different solutions have different needs, and if your ...


10

Never over architect from the get-go. You will spend most of your time on the architecture and not the actual business case you are implementing. (This is especially true if you are trying out a new architecture approach, like micro services) When I start out with something new and especially something that I have no idea if anyone will ever use, I always ...


9

What exclusive traits Java has that other languages/platforms don't, that makes it so popular for SOAs? There's nothing much in Java itself that makes it especially suitable for SOAs. Sure, it offers garbage collection and dynamic code loading and the like, and they're all useful, but they're hardly unique features of Java. What did make a difference ...


9

Not allowing "direct database access" from an application allows the underlying database, and even the schema, to change without having to change the client applications. Clients simply code to the service interface, never needing to know how the data is persisted.


9

I'm not sure what you mean by "one and only one software!" but I think you may be reading too much into this document. Since it talks about what not how, it sounds much more like a high level requirements document for a system and not a single application. This is actually a very important document for any large project. I'm sure that if you were to look ...


8

Because <5% of code is actually defining a service, and I would argue a substantially less amount of time. Once the interface is defined, it's largely done. The rest of the time is spent in OO (or alternatives) making things work. Simply put, it's not a big win to make a specialized language for that small slice of the problem. If anything, having two ...


8

Library Advantages: Lower overhead per call (only jump or even inlined) = may increase performance Simplest thing that could possibly work No risk of centralized service going down and impacting all consumers Service Advantages: Everyone gets upgrades immediately and transparently (unless versioned API offerred) Consumers cannot decompile the code Can ...


8

From a developer's point of view, you are right in saying that these "visual" environments are really hard to work with. SharePoint 2010 Workflows, which I use, throws out every best practice around creating good enterprise software - no automated testing, no code reuse, unreadable software... Anything more complex than an out-of-the-box template can be ...


7

OOP is a programming paradigm. SOA is a system architecture concept.SOA can be implemented using OO code (or any other type of coding, it does not matter). OOP can be part of a SOA architecture or can be used outside of that architecture. OO and SOA are two different concepts (level wise). We could for example compare SOA based architecture to non-SOA based ...


7

There is only one real benefit, yet its huge: Separation of Concerns. So, instead of process orchestration logic being embedded in our system, it becomes and external configuration. A map, basicly. You can change it (much more) independently, you can have multiple processes, multiple versions of processes, multiple versions of multiple processes running at ...


7

I've had to use WF before in an integration scenario based on a Pub-Sub messaging system... and we found that using WF was a pain in the ass. Firstly, it's awkward to code with. At first you'll be tempted to code all your logic with activities in the Designer, but this is a very bad thing. Even simple things like object instantiation turns into either a ...


7

That referential integrity is a concern at all suggests that there are implicit dependencies between the domains. One thing that I think people who have drunk the microservices kool-aid often misunderstand is that these kinds of dependencies and the issues related to them do not magically disappear once you break down the monolith. It's good that people ...


6

My take is that yes, it's a complete buzzword for the following reasons: 1) Too many people equate SOA with only web services. 2) Re-packaged message brokers and other obsolete technologies (visual programming) as "ESBs". Ironically this leads to vendor lock-in and less flexibility because you don't have the source code. 3) No focus on where solutions ...


6

First, as the comments point out, you aren't really talking about realtime here -- that has a pretty strict definition and implies lots of stuff that isn't really on the table. You are talking about connecting two systems in a near realtime sort of manner. Anyhow, yes, the best bet would be some sort of message queueing solution here. The POS system would ...


6

However, does it make sense to have one 'database' service responsible for handling a monolithic database (i.e. holding users, orders, inventory, etc in one db)? Is this something that's considered reasonable? I think this is a mistake to make a service (or whatever) in SOA or any other architecture responsible for a database or a part of database or ...


6

I believe your question is a catgory error. In short, microservices are a way of organizing your architecture, while bounded contexts are a way of organizing the classes/objects you manipulate in code. There may be a one-to-one correlation between the two, or there may not be. There is certainly no necessary connection between the concepts. If I may borrow ...


6

In a SOA application, instead of a monolith component solving some problem, you have multiple services - each dealing with its own business concern - that now must communicate and collaborate to solve the same problem together. That means they need to know about each other and what each one is doing. That's a dependency, plain and simple. Services are self ...


5

Simply because many of the first systems that were being connected using SOA techniques were in already built in Java. There's nothing inherit in Java that makes it a superior language for SOA solutions. Some might argue that it's rich ecosystem of BDD/TDD frameworks and community around that helped build more robust SOA solutions, but then again I've seen ...


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