I have software product that gets shipped to the customer as a package (.exe).
Now, if I write microservice to do some computations and return the result to the client application, how can I package the microservice to ship it to the customer?
Related
I have a monolithic Spring boot application that exposes a REST API /getUserList.
Now we are taking the micro service approach, so that we extracted some business code and create /getCountry microservice REST API.
Normally, /getUserList should call /getCountry to get all countries.
Now for testing purpose, I want to use these two REST API in the same server, but separately. What I can think of is to create two seperate JAR and let one call another. I want to know what is the right way to do this :
Should I list /getCountry as a module of /getUserList? Or should I create a separate project ?
You decided to break your monolith into microservices. You started on the right foot, separating the application logic based on the bounded contexts you defined. In this case you describe "countries" context and the "user" context.
Microservices are independently deployable, so you are correct, they have to be separate jars. Your "user" service will call the "countries" service via the network as usual in microservices architecture.
Usually, each microservice has their own repo (project), so that developers who have to work on the service, do not need to familiarize with a large codebase, or figure out why code not related to their service (bounded context) is there.
That being said, if currently your project is quite small you can decide to keep these as separate modules (do not import countries module in the user module) under the same project and break them later.
I am developing a bookstore application based on microservices architecture with Spring and Netflix OSS.
I made a shopping service, with all the stuff necessary to buy a book. But I need to integrate with two services.
One service is a shipping service, this is an internal service. Connected through a Feign client.
The other service is an inventory service, this is an external service. Connected through an external library. This is a problem because it's more difficult to mock.
In order to connect with this services from shopping service, I thought that the adapter pattern was a good idea. I made another service, a shopping adapter service, that is used to connect with the other two services. And with this architecture, I can test the shopping service mocking the adapter service.
But now I think that is a bit awkward solution.
Do you know which is the best architecture to connect with external or internal services?
First, is it correct that’s what I understand?
Compound Service --(use)--> shipping service
----------------------------(use)--> inventory service ( this project uses external
library )
If it is right, I think it is not difficult to mock.
Create an inventory microservice project for wrapping external library.
Because compound service doesn`t need to care what we need to use a certain library for inventory. Your Inventory microservice project just exposes endpoint for using inventory service.
In the microservices world, services are first class citizens. Microservices expose service endpoints as APIs and abstract all their realization details. The internal implementation logic, architecture, and technologies, including programming language, database, quality of services mechanisms, and more, are completely hidden behind the service API.
Then, You can mock Inventory service at your compound service test code.
#Configuration
class MessageHandlerTestConfiguration {
#Bean
public InventoryClient inventoryClient() {
return Mockito.mock(InventoryClient.class);
}
I don't think creating another microservice which you should maintain and monitor and keep resilient and high available etc. just to have a kind of facade or adapter is a good idea. This statement may be proved wrong for some very special cases but generally if you don't have a context to maintain then it is not a good idea to create a new microservice.
What I could recommend would be directly calling shipping service by paying attention to anti corruption layer pattern which keeps your actual domain's service code clean from other microservice's domain entities.
You can find some more information about anti corruption layer here https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used
I have a microService architecture with 10 microServices and each of those provides a client. Inside of that client which is managed/controlled by microService team we just receive the parameters and pass them to a generic http invoker which receives the endpoint and N params and then does the call.
All microService use http and web api (I guess technology doesn't matter).
For me doesn't make sense to be the microService team to provide a client, should be the responsibility of the consumer, if they want to create some abstractions or invoke it directly is their problem, not a microService problem. And the way I see a web API is as a contract. So I think we should delete all clients (pass responsibility to consumers) on the microService side and create a service layer on the consumer's side that uses the generic invoker to reach the endpoints.
The image below represents all components where the red line defines the boundaries, who is responsible for what:
The gateway has Adapter Layer
Adapter Layer references the microService client package
MicroService client package references Generic HTTP invoker package
The other side of that is because we might have N number of consumers and they are all repeating the code of the client. And if the microService provides a client, we have a unique/central place to control that.
Which approach is correct? Is the client a responsability of the microService or the consumer?
This is an internal product.
I have a similar setup at work, with several microservices (~40) and a dozen teams. I was asked the same question several times, and my answer is the consumer is responsible for consuming. If the API works as designed and expected, there is no point in making the providing team responsible for anything.
The team that provides the service (team a), may provide a client, if they want (in doubt, without warranty). The consuming team (team B) may use the client if they want (taking all the risks included).
The only contract should be the API, everything else should be a goodie a team may provide on top. If team a has to provide a client, why do they provide an api at all then?
Given that both teams are loosely coupled and may use different technologies (or e.g. different spring framework versions), providing a client library to the other team proves to bring more problems than solve any. In a Java+spring-boot world e.g. you get into dependency problems very fast, especially if you include several clients from different service providing teams that evolve differently in time.
And even worse: what if the client-library of team A makes the system of team B unstable and introduces bugs? Who is responsible to fix that now?
If you want to reduce the work needed for your consuming teams because re-coding the client is so much work, your API may be to complex and/or your microservice may be no more microservice at all.
Imagine using HATEOAS on a restful API - writing a client for that is just a few lines of code, even with included API-Browser, Documentation and whatnot. See e.g. spring-rest-docs, hal-browser, swagger and various other technologies that make reading/browsing/documenting an API and implementing a client a breeze.
Above cases are described with two teams, imagine that with 10. We had a "client library" provided by one team, used by 4 other teams. You can guess how fast it became a complete mess until it was just deleted :)
Recently a friend of mine asked me about N-Tier architectures and I was able to explain to him about 1, 2 and 3 tier architectures with examples. But I was stuck when I wanted to give examples for more than 3 tiers. I googled and binged for help, but could not find any decent examples.
The fact that it is named N-tier makes me think that 'N' can be any number starting from 1. But I couldn't find any examples for 4 or 5 tier.
Can somebody share some examples of N-tier architectures that involves more than 3 tiers?
Fundamental Services : e.g. Database, Directory Services, File & Print Services, Hardware abstraction. This tier is increasingly called the platform.
Business Domain Tier : An Application Server such JavaEE including EJB, DCOM or CORBA Service Objects. Provide business functionality, increasing using SOA and Micro-services.
Presentation Tier : e.g. Java Servlets/JSP, ASP, PHP. This tier will increasingly include WebServices as proxies and adaptors for business tier services.
Client Tier : Thin clients like HTML Pages on Browsers and Rich Clients like Java WebStart & Flash.
In Java EE it is common to divide the Business Domain tier into Data-Access (Entity Beans) & Business Services (Session Beans).
In an Enterprise SOA (Service Oriented Architecture) the ESB (Enterprise Service Bus) would typically exist as an additional tier between tiers 1 & 2. It may be part of the platform provision.
In Mashups you could have an aggregation tier between tier 3 & 4.
The move to being called N-Tier is a reflection of the move to increasingly componentised architectures from the older client-server to first 3-Tier then 4-Tier. The defining characteristic of a tier is a clearly defined interface with a separation of concerns.
Five minutes ago I've read an article of this
https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture
Client is where you read it
Api or your application back-end is where you assemble it ..
Data aggregation.. Either goes through the jsons/xmls from outsourced things or queries on your database and lastly service tier is where you actually do the query on database or run function on big data or read GPS locations and maps from google ... That is how I see it in this case. It simply divided the data layer from three tier.
But this N-tier model is totally abstract so you can tear your infrastructure until you have some logically atomic parts only. Still dividing the previous structure.
I'm leaning towards less abstract and more practical explanation that answers the question: "How and why do I want to split my system into tiers and where do I place them on the servers?"
Essentially, when you create a simple website that uses a database, you already have 3-tiers "out of the box":
data tier - the database. But if you are using a short-lived memory cache or file system then we might argue if that can be considered a "tier" or not.
application tier - the code that executes on your server(s).
presentation (or client) tier - the code that executes on the client's machine and presents the results to the client
Now, how do we get the 4th tier?
Most probably, there is no need to split the client tier. It's on the client's device and we want to keep it as simple and efficient as possible.
Could we split the data tier? I have seen some systems with APIs around databases, Azure blobs, file systems etc. to create some subsystem that could be considered a tier. But is that still the same data tier (a.k.a fundamental services tier) or can we consider it a separate entity? And if we separate it out, will it be on the same physical (or virtual) server as our database, so we can protect the data from direct access?
However, in most cases, it's the application layer that gets split.
One part is still named application tier. It becomes an internal API web application and lives in secured zone where it can access the database. Nobody can access the database directly, but only through this application layer.
The other part becomes a consumer of the application tier APIs through some kind of a connection (HTTP client etc.). The consumer might be called presentation tier (confusing - wasn't it the same as client tier?), even if it itself has only JSON APIs and no any user-friendly formats.
But then the question arises: in which cases we, developers, might want to complicate our lives and split our web application into presentation tier and application tier, instead of keeping them as layers inside the same web application?
At serious workloads, a separate application tier might be good for scalability or it might be a requirement of security to deny database connectivity to the web server that is exposed to users (even the intranet ones).
I have seen some ambitious projects going for 4-tier from the start and then cursing themselves for overengineering things. You have to keep track of those internal connections, security, authentication tokens, keeping sockets under control (not opening a new HTTP connection on every request), avoiding accidental sharing of data of multiple parallel requests through carelessly created global HTTP client instance etc.
That would depend on what you want to call a Tier. Each vertical of the Presentation layer could be called a tier.
Mobile app or webpage frontend (one page Javascript and the like)
The caching or CDN (Content Delivery Network) as another layer.
Frontend or API tier
The business layer, could also be split if the service requires multiple microservices. For instance
a Business process tier
an Administration tier.
Then the data Layer split into:
Database
Data Lake
Reporting
Enterprise Service Bus
Third party access data (where your app is connecting to other APIs)
For more see Cloud Application Architecture
A four tier architecture consists of the following
a. client tier -- node.js angularJs, etc basically independent of server side and UI team work on the client artifact independently
b. Aggregation tier --- content delivery networks (akamai)
c. api tier -- gateway for all the server side calls and can have its own caching
d. services tier -- includes internal or external services...
An easy example of 4 tier architecture is RMI JDBC Servlet. This involves
The client tier
The application server for theservlet
Rmi server for server program
Jdbc server for database
I am interested in finding a business model for a software product (iprocurement). However, I got quite confused between ASP (Application Service Provider) and Saas models. What are the differences?
Thanks in advance.
Though medium of delivery is the same i.e. internet, ASP takes a packaged-base approach while SaaS takes product approach. ASP provider need not be a manufacturer of the product. He can be a trader or a middleman who takes the responsibility of selling it and customising and implementing it when required. On the other hand, a system based on Saas model had been designed, built, delivered, configured and implemented normally by a single party who has total control of the system.
In case of ASP there can be multiple instances (or implementations) of a software running on a single server, suitable as per customer needs while in case of SaaS, a single software will serve to many clients allowing them to configure the service as per their requirement.
The fundamental difference is how software is built and used. ASP follows traditional development with a twist when it comes to deployment. It is built on data centric and it is deployed as an application with a centralized host sever. SaaS is built on service centric and deployed as web services.