Paul Preiss: SOA contrast, just a contrast. Your physical reaction, I think, was a good start. I’m just asking for your basic contrast for the- if we’re in a conference and I’m another architect, I don’t understand the difference between Microservices and SOA.
Venky: The SOA, it gives a more structural layered approach to doing something. While the Microservice is self-contained, everything is en-captured in one service. SOA advises you to divide the functionality of the abstraction to different layers of abstraction.
Paul Preiss: Okay.
Venky: So based on how closer or further from the providers and the consumers, you end up with multiple layers of abstraction. For example, your most basic services, the fine grain services, can be the ones that are accessing the data sources, systems of
Paul Preiss: Add, edit, delete.
Venky: Add, delete, update.
Paul Preiss: Right.
Venky: That kind of stuff. Now that layer of granularity is not enough to fulfill any business function. So now you can-
Paul Preiss: Can we go to the whiteboard?
Paul Preiss: Can you draw the SOA? You’re talking about granularity, layering and packaging.
Venky: You talk about these in the most basic layers. It’s closer to your system’s [operator 00:02:02]. We used to call them as integration service layers right? These can be as simple as cloud operations [inaudible 00:02:22]. The grain of the services can be hey create, read, update, delete. That kind of stuff. You can get to that granularity.
Paul Preiss: With like a wrapper for the DOA.
Venky: Right exactly. Instead of everyone calling a SQL [core 00:02:42] to data table, I create this generic service which goes hey, go do a creative data on a table then. I can now paramatize even the table name and the structure. This layer of abstraction is not enough to fulfill any business function. Now SOA recommends that hey on top of this now you have…
Paul Preiss: Like a service orchestration.
Venky: Business services layer which basically says hey now I take this discreet cloud stuff. I kind of compose them into something that can give me a business function. For example create claim. What I’ve done is to create a claim, I need to know about the person for example. That can be my customer database or my policy information for example. Now I combine those to say create a claim is a business function. I can actually relate this to a business function. This is a sort of, what do you call? An orchestration that’s done, it can be one or more or ten of these services. I maybe reaching.
Paul Preiss: Almost a service implementation of a traditional end tier app programming model.
Venky: Model yeah.
Paul Preiss: Or design.
Venky: Design. On top of this, also the [commerce 00:04:21], you can have a layer of process. The process layer comes here. Here [inaudible 00:04:37] claim or policy or whatever. This thing is talking about interactions between different systems, humans and stuff like that. This talks about the workflows but these workflows are unusually calling-
Paul Preiss: So it’s an orchestration level.
Venky: At a process.
Paul Preiss: Normally in the same package or the same, I shouldn’t say package, I should say product set.
Venky: It does not have to be a product, same product set.
Paul Preiss: What would you normally-
Venky: SOA is not a product set. It’s actually talking about the layers of abstraction that will give you a full fledged function that can be used by, you know, the consumers.
Paul Preiss: Great.
Venky: On top of this you can also have a layer which is a, you can say consumption layer. This can be your web apps.
Paul Preiss: Which is also, to an extent, an event layer.
Venky: It’s another layer where I’m taking- I may not be- it does not have to be a process layer but I can be directly using the business solutions layer to expose something.
Paul Preiss: We could call that an API if we wanted.
Venky: Right exactly. You can now- this is where we have APIs. You can stop like that, you can expose to either your computer or mobile and so on and so forth.