I am unsure how to make use of event-driven architecture in real-world scenarios. Let's say there is a route planning platform consisting of the following back-end services:
user-service (manages user data and roles)
map-data-service (roads & addresses, only modified by admins)
planning-tasks-service
(accepts new route planning tasks, keeps track of background tasks, stores results)
The public website will usually request data from all 3 of those services. map-data-service needs information about user-roles on a data change request. planning-tasks-service needs information about users, as well as about map-data to validate new tasks.
Right now those services would just make a sync request to each other to get the needed data. What would be the best way to translate this basic structure into an event-driven architecture? Can dependencies be reduced by making use of events? How will the public website get the needed data?
Cosmin is 100% correct in that you need something to do some orchestration.
One approach to take, if you have a client that needs data from multiple services, is the Experience API approach.
Clients call the experience API, which performs the orchestration - pulling data from different sources and providing it back to the client. The design of the experience API is heavily, and deliberately, biased towards what the client needs.
Based on the details you've said so far, I can't see anything that cries out for event-based architecture. The communication between the client and ExpAPI can be a mix of sync and async, as can the ExpAPI to [Services] communication.
And for what it's worth, putting all of that on API gateway is not a bad idea, in that they are designed to host API's and therefore provide the desirable controls and observability for managing them.
Update based on OP Comment
I was really interested in how an event-driven architecture could
reduce dependencies between my microservices, as it is often stated
Having components (or systems) talk via events is sort-of the asynchronous equivalent of Inversion of Control, in that the event consumers are not tightly-coupled to the thing that emits the events. That's how the dependencies are reduced.
One thing you could do would be to do a little side-project just as a learning exercise - take a snapshot of your code and do a rough-n-ready conversion to event-based and just see how that went - not so much as an attempt to event-a-cise your solution but to see what putting events into a real-world solution looks like. If you have the time, of course.
The missing piece in your architecture is the API Gateway, which should be the only entry-point in your system, used by the public website directly.
The API Gateway would play the role of an orchestrator, which decides to which services to route the request, and also it assembles the final response needed by the frontend.
For scalability purposes, the communication between the API Gateway and individual microservices should be done asynchronously through an event-bus (or message queue).
However, the most important step in creating a scalable event-driven architecture which leverages microservices, is to properly define the bounded contexts of your system and understand the boundaries of each functionality.
More details about this architecture can be found here
Event storming is the first thing you need to do to identify domain events(a change in state in your system). For example, 'userCreated', 'userModified', 'locatinCreated', 'routeCreated', 'routeCompleted' etc. Then you can define topics that manage these events. Interested parties can consume these events by subscribing to published events(via topics/channel) and then act accordingly. Implementation of an event-driven architecture is often composed of loosely coupled microservices that communicate asynchronously through a message broker like Apache Kafka. Free EDA book is an excellent resource to know most of the things in EDA.
Tutorial: Even-driven-architecture pattern
Related
I try to develop microservice application. When checking most of the article for microservice, where each microservice have two layers(frontend and Repository layer). usually if develop monolithic application API layer structure like
Rest API Controller(Like API Frontend) <-> Business Logic <-> Repository Layer(Data Access Layer)
When come to microservice each micro service have two layers
Rest API Controller(Like API Frontend) <-> Repository Layer(Data Access Layer)
It's fine for doing simple CRUD application. Suppose come to Complex business logic application. where should I implement complex business logics?
Microservices aren't about how many layers each application has, or indeed about how they are implemented. They're much more about clear, separation of bounded context, and having multiple different processes that are each individually buildable, testable, deployable. When working in a larger org structure, you might find this allows you to organise your people to support the services in a way that the monolith starts to struggle with at certain scales.
Imagine a commerce site - Instead of one big application that tries to do everything, we have lots of apis that do 'product', 'shopping cart', 'orders', 'payments', 'returns' etc, and each one would maintain their own state
Microservice applications don't share databases, and instead communicate with each other over HTTP for sync or some sort of event technology (Kafka, Message Queues etc) for async.
Each one of those applications might be implemented in a complex way or have complex requirements, it's not what makes them a microservice.
So to your question - your implementation is less of a concern here. You can still have services/repositories if that's a pattern that you like, or CQRS patterns can also work nicely, it doesn't matter so much as the core principles of boundaries, communication and state management.
NB : Microservices therefore come with overhead. You need to be disciplined with contracts for APIs and Messages, you need to make sure you don't reinvent the wheel, teams need to collaborate with each other effectively. They work well at larger scales and certainly promote a deployment model that allows you to utilise as much compute as you can pay for, but there are times when they can slow you down due to dependency management.
I have 2 years in the IT industry,i love to read a lot ,but when i go deep in some subjects i see a lot of contradiction in somes articles,forum or terms that are used interchangeable.
I understand the difference between Soap and Rest.
When we want to communicate between backends, we can use either of these 2 approaches, each with its advantages and disadvantages.
Situation :
If i have an application, which can be monolithic or not, where I have a backend and I will only have a front end that consumes it. Usually we create a Rest Api so that our front end can consume it. But we will never think about exposing our backend with Soap.(Lot of reasons)
Questions:
1 -Is it okay if I say that Rest , in addition to allowing us to exchange information between application and application (backend to backend ), is it also useful when exposing services for our front end? And SOAP is only useful for Server - Server communication?
2 -And finally, if I expose a backend only for a front end, it is ok to say that we expose a web service or conceptually we say that it is a backend for frontend ?
Question 1: No the First question is wrong Assumption. We can say that in SOAP, XML is the only means of communication, while in Rest, the accepted means is JSON, while there are other formats like XML, JSON, PDF, HTML etc. and Ofcourse, XML can be converted back from server into UI Language and XML Request deciphered at Server for a Response. So, its not Ok to say that SOAP is only for Server - Server Communication.
2. No, when you have typically exposed backend only for consumption by a Front end, you can typically say that it is a backend for numerous front end client requests. But IMO, Backend for a front end is a monolithic webapplication, both bundled in WAR. so in that sense, any UI Request can request response from the Back end web service. Hope i am able to clear your understanding about web services.
I see that in your question there are actually 4 embedded independent topics. And probably because they are always used in conjunction it is sometimes tough to understand.
I will give a short answer first:
REST and SOAP both can be used for Client-Server and Server-Server integrations. But the choice will be dependent on the questions like where you want server-side UI technology/client-side UI technology or is it a single page application/portal technology, etc.
If you expose a single-backend for a single-frontend it's technically a BFF although the term BFF is used only in the case where you have separate-backends for each type of frontend application. e.g. one for mobile, one for web, one for IoT devices, etc.
The long answer is to clarify the 4 principles. Let me give a try at this by separating the topics into the below four headings:
1. Backend(Business Layer) vs Backend for frontend(BFF)
In classical 3-tier architecture (UI-Business Layer-Database) world, the middle-layer that consists of the business and integration logic is mostly referred to as backend/business layer.
This layer can be separated from the UI/Frontend using multiple different options like APIs(REST/SOAP), RPC, Servlet Technology, etc. The limitation with this 3-tier architecture is that, it is still tightly coupled to the type of users and use-cases are limited to web/browser based. It is not a good choice when you want to reuse the business-layer for both web and mobile as the mobile applications are required to be light-weight by principle.
That's where we lean on to multi-tier architecture with Backend For Frontend(BFF) as a savior. It's just a methodology to segregate the business-layers based on consumers.
2. Monolith vs SOA vs Microservices(Optimized SOA)
In a monolith world all the code components mostly UI and Business Layer sits in a tightly coupled fashion. The simplest example would be a Java Servlet Pages(JSP) application with Java as Business Layer. These are typically server-side UI technologies.
In Service Oriented Architecture(SOA), the usecases revolve around leveraging reusable business layer functions aka services. Here one would have to deal with UI-Server, Inter-Service and Server-Server integration scenarios. It's heavily service dependent, meaning it's like a spider-web of dependent applications.
The Microservices is an extension of SOA, but the approach is to keep a resource in focus instead of services to reduce the spider-web dependencies. Hence, self-sufficient and standalone service-clusters are the base of micro-services architecture.
3. SOAP vs REST Webservices
SOAP stands for Simple Object Access Protocol, typically used by the business-layer to provide user-defined methods/services to manipulate an object. For example look at the names of the services for accessing a book collection
To get a book getABook()
Get the whole list of books listAllBooks()
Find a book by name searchABook(String name)
Update a book's details updateABookDetails()
On the other hand, REST is representational state transfer which transfers the state of a web-resource to the client using underlying existing HTTP methods. So the above services for accessing a book collection would look like
To get a book /book(HTTP GET)
Get the whole list of books /books(HTTP GET)
Find a book by name /book?name={search}(HTTP GET)
Update a book's details /book/{bookId}(HTTP PATCH/PUT)
4. How to make a correct choice of architecture?
Spot the diversity of the application user groups and usages: This will help to understand the platform(web/mobile/IoT/etc), nature of the application and session-management.
Determine the estimated/required throughput: This will help you to understand the scalability requirements.
How frequently and who will be maintaining the application: This will help to gauge the application and technology complexity, deployment cycles, deployment strategy, appetite for downtime, etc.
In conclusion, always follow the divine rule of KISS: Keep it simple, stupid.
1.)
A webapplication is for H2M communication a webservice is for M2M communication through the web. The interface of the service is more standardized, more structured, so machines can easily use it and parse the messages.
I don't think it matters where your service consumer is, it can run in a browser or it can run on the server. As long as it can communicate with the service on a relative safe channel it is ok.
You design a service usually to decouple it from multiple different consumers, so you don't have to deal with the consumer implementations. This makes sense usually when you have potentially unknown consumers programmed usually by 3rd party programmers you don't even know or want to know about. You version the service or at least the messages to stay compatible with old consumers.
If you have only a single consumer developed by you, then it might be too much extra effort to maintain a service with a quasi-standard interface. You can easily change the code of the consumer when you change the interface of the service, so thinking about interface design, standardization, backward compatibility, etc. does not make much sense. Though you can still use REST or SOAP ad hoc without much design. In this case having a RESTish CRUD API without hypermedia is a better choice I think.
2.)
I think both are good, I would say backend in your scenario.
I am currently working on a project made of many microservices that will asynchronously broadcast data to many possible client applications.
Additionally, client applications will be able to communicate with the system (i.e. the set of microservices) via a ReST Open-API
For broadcasting the data, my first consideration was to use a MOM (Message Oriented Middleware) such as AMQ.
However, I am asked to reconsider this solution and to prefer a ReST endpoint (over HTTP) in order to provide an API more "Open-API oriented".
I am not a big specialist of HTTP but it seems to me that main technologies to send asynchronous data from server to client are:
WebSocket
SSE
I am opening this discussion I order to get advices/feedback from other developers to help me to measure the pros & cons of this new solution. Among that:
is an HTTP technology such as SSE/WebSocket relevant for my needs
For additional information, here are a few metrics regarding the
amount of data to broadcast
considerable amount of messages per seconde
responsiveness
more than 100 clients listening for data
Thank you for your help and contribution
There's many different definitions of what people consider REST and not REST, but most people tend to agree that in practical terms and popular best practices REST services expose a data model via HTTP, and limit operations to this data model by either requesting the state of resources (GET), or updating the state of resources (PUT). From that foundation things are stacked on top of that.
What you describe is a pub-sub model. While it might be possible in academic terms to use REST concepts in a pub-sub architecture, I don't think that's really what you're looking for here.
Websocket and SSE are in most real-word situations do not fall under a REST umbrella, but they can augment an existing REST service.
If your goal is to simply create a pub-sub system that uses a technology stack that people are familiar with, Websockets are a really good choice. It's widely available and works in browsers.
My team is torn with how we should architect our microservices with using a message bus.
We currently have an API Gateway with many microservices behind it all communicating over http.
After looking into implementing Message Buses (Kafka) the team is torn on whether the consumer and API should live in the same service or if they should be two separate services.
Some think they should be separate as they have different scaling concerns, while others think they should be in the same service since they are communicating with the same database and have the same domain concerns. IE) Not duplicating code between two services.
What are your thoughts?
We prefer them to be in the same service as they logically are doing work on same objects.
This also highly depends upon how you write your business logic. Like we prefer here to write our business logic in Aggregates(Domain Driven Design) and that's why writing consumer in the same service makes sense.
In some case where they are just updating data for searching kind of things , you may write them in separate service.
You can also look at Lagom (microservices framework for java)
I am learning about microservices and I don't understand what the real difference
between creating a REST API and creating microservices?
I’m working in Go, but my question applies over all languages.
The Microservices approach is about breaking your system ("pile of code") into many small services, each typically has its own:
Clear business-related responsibility
Running process
Database
Code version control (e.g. git) repository
API (the protocol how other services / clients will contact the Microservice)
UI
The services themselves are kept small so as your system grow, there are more services - rather than larger services.
Microservices can use REST, RPC, or any other method to communicate with one another, so REST or an API is really orthogonal to the topic of microservices...
Reference: What is an API? In English, please.
API = Application Programming Interface
Microservices = an architecture
In short
Microservice should expose a well-defined API.
Microservice is the way you may want to architect your solution
API is what your consumers see.
You can expose API without microservices in the backend (in fact, most non-training scenarios don't require microservices).
You may want to read http://samnewman.io/books/building_microservices/ before you decide on using microservices (unless this is for training purposes).
Microservice is well defined when you are following SOC - seperation of Concern on the entity/domain level ,where each entity / domain are independent of any other service.
for example user service will only be responsible for storing, updating and deleting user related informations.
Microservice backend and frontend microservice can further be splitted in 2 parts
frontend microservice which exposes rest endpoint just like Web API
backend microservice which actually perform all the operations.
Rest API is more of endpoints exposed to outer world and can be used with microservices as well, as explained above.
The majority of the answers is based on the old-school understanding of API as a programmatic interface. Nowadays, this meaning is melted and start confusing people becuase some developers started (for simplicit or by mistake) interpred the API of an application as the application per se. In such case, it is impossible to distinguish between the modern API and Microservices. Nonetheless, we can say that an API-application can comprise many Microservices, the most of which interact within the application via Microservice's APIs while others may expose their APIs as Applications's APIs. Also, a Microservice (as a service) may not include other Microservices (services), but may orchestrate a composition of Microservices via API-bases invocations. Applications may contain Microservices but, in the best practices, may not contain other Applications.
Microservices
A microservice architecture is about slicing an application logic into small pieces or "components" that can act between them and/or be exposed through an API.
API
A (web) application need to design the business logic with all set of object entities (model) and possible operations on them.
An (Application Programming Interface][https://en.wikipedia.org/wiki/Application_programming_interface) is a way of making the requests to an application by exposing specific entry-points that are in charge of invoking the appropriate application operations.
ReST(ful) APIs
("ReST" as in Representational State Transfer) are APIs complying with at least these 5 constraints:
User-interface is distinct from data storage and manipulation (Client-Server architecture)
No client context is stored on the server ("stateless")
Server responses must, implicitly or explicitly, define themselves as cacheable or not
Client does not have to be aware of the layers between him and the server
Response/request messages must be: be self-descriptive; allow to identify a resource; use representations allowing to manipulate the resources; announce available actions and resources ("Uniform interface").
"The real difference"
So, while these notions are obviously related, they are clearly distinct concepts:
Being ReSTful or not, an API exposes operations provided by a server that might (but not necessarily) be shelled into smaller components (microservices).
Also, while a typical web (ReST)API uses the HTTP protocol between the client and the server, components within a microservice architecture might communicate using other protocol(s) (e.g. WAMP, AMQP, JSON-RPC, XML-RPC, SOAP, ...)
In layman's term, if you have a web API server and you split them into several independent mini servers, use a proxy-server and load-balancer to clusterize them, and (optionally, give each a separate database entity), that is a microservice architecture.