Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Assume I have separated my monolithic application into 5 microservices.
Now do I need to run these 5 microservices in 5 processes or is it OK to have all 5 of them run in a single process? Why?
The very purpose of choosing to go with Microservice Architecture is to achieve scalability and agility through independence of services. Here is an excerpt from a good article on the matter, you might find interesting. It is by a pretty credible source - SmartBear (the creators of SOAPUI):
While there is no standard, formal definition of microservices, there
are certain characteristics that help us identify the style.
Essentially, microservice architecture is a method of developing
software applications as a suite of independently deployable, small,
modular services in which each service runs a unique process and
communicates through a well-defined, lightweight mechanism to serve a
business goal.
So yes, you should absolutely go for deployment as separate processes. You will be much more flexible this way. For example, running all 5 services in a single process could make it impossible to hot-swap new versions of single microservices without stopping all the others (even though they might not be logical interdependence between all services).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
If there is any PLC programmer or Twincat3 user out there. I would like to write my master thesis on Twincat3 in a company. Basically, They have different kinds of the Test bench, and they want someone to develop drivers for them. I have no experience with PLC or C++ or IEC61131 languages. Is it possible to learn any of these in 3 months, and then start writing the thesis? I have three months of Internship time before starting. I am having a bit of doubt. Even though it is daunting as an Electrical engineering student, I have no other options.
I thank you in Advance.
Also, The test benches are mainly Powerelectronics or Electrical machine test bench. I believe I need to automate the test processes in twincat3.
Best Regards
Good choice with TwinCAT 3. TwinCAT 3 is very capable, and quite easy to learn (of course dependent on your background, but generally a good platform to work on).
All I can support you with is a link to a TwinCAT 3 tutorial that I've created that is free of charge (available on YouTube):
https://www.youtube.com/playlist?list=PLimaF0nZKYHz3I3kFP4myaAYjmYk1SowO
There are also some other resources available both on YouTube and on the website. I've created a set of links here to help you find all the resources you might need.
To answer your question I would say it depends. Three months is not much time, especially considering you probably have a lot of other things that need to go in there (doing studies, writing the thesis, implementation, conclusions etc). It depends on the complexity of your project (it's not very specific what "writing drivers for them" means). If it's a simple project (including a very basic set of I/Os) it might be do-able. If it's anything more complex (like needing to add a front-end, doing motion control and maybe even safety) then it's most likely going to be hard to finish it in three months.
But again, I think more details on what you want to achieve is necessary.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We're evaluating ITextSharp (now known as IText) for producing pdf documents. This will be used in our websites which will be published across a load-balanced solution amongst several servers.
According to Itext, this will require a production license per server (we're not open-source) in our load balanced configuration, as well as uat and developer licenses. This is obviously a considerable investment.
Could anyone recommend any alternatives to reduce the costs?
Also, is there a pattern we could adopt to minimise the migration effort of the existing website prototype if we were to use another product?
You could change your architecture a bit and have a dedicated PDF generation server. You'd then need to boil your requests down to something that could be sent between the servers. Depending on your goals, that could be something relatively simple, such as a user ID and a report name, or complex (text layout, that image there).
As far as distancing yourself from the commercial iText, there are two options.
1) Use the older MPL iTextSharp. It won't have all the latest features and bugfixes, but it's hard to beat the price.
2) The "wrapper" design pattern. Build a relatively generic interface, and have your current implementation of that interface sit atop iText. If you later need to swap it out, you're rebuilding the glue code, not your whole app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 months ago.
Improve this question
I'm currently developing a micro service that basically provides calculation services to other micro services. It does not store data or have any resources like a sales order. It only calls other micro services and then calculates metrics and prices to return a result.
I'm kind of struggling trying to make a rest API with resources names that are nouns when all I do is calculate stuff and return results (more like an action).
So can we have a micro services that behaves more like an HTTP API than a Restful service (is it a bad practice, an anti pattern , an architecture smell, ....)
Regards
You can use whatever you want and in your particular case I am pretty sure you won't see any drawbacks. From my point of view only difference with rest is mostly semantic -some people may also argue about cacheability but I don't think so-
Apart from rest/rpc creating microservices without any actual domain could cause a maintenance issue in the long run as you totally depend on some other microservices data whenever a change required in their side you may also need change this microservice. That is why I don't recommend those kind of calculation services unless you have a valid scalability requirement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am studying the current architecture of uber rider app and I got to know the current rider app was evolved from MVC to a specific architecture called riblet, which is designed on top of viper by Uber themselves. As I understood riblets is independently testable pieces that each have a single purpose. I'm aware that the new architecture is capable of handling performance and scalability. I am interested in knowing the cons of riblet architecture.
Okey. I found some cons of the riblet architecture. I will post them here to discuss with anyone who is interested. The main cons are as follows,
Since there is a higher number of independent riblets communicating through their interfaces, there is a probability of failure of a particular interface compared to a system with fewer components.
Yes testing a single riblet is easy yet it makes integrations and handling the requests among riblets more complicated.
Changing the technology stack in the long run is difficult
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a newbie Java EE 6 Developer (EJB 3.1 ; JPA 2.0 ; JSF 2.0; etc..).
I want to start learning SOA using Java. I found 2 ways:
SOAP: which is complicated and boring to learn; the only strong point: is the UDDI/WSDL listing
REST: easy to learn & to deploy; many strong points : performance, security, speed...
My question: What the market needs now? SOAP or REST? If I choose REST, it will be the right choice ??
This will depend a lot on your business area. For fast moving technology areas such as back end for mobile phone apps, ticket systems, anything Google or areas where you have most of the control yourself - REST is probably the best choice, but if you work with business areas that changes technology slower, SOAP is still dominant and will be for a very long time. Examples are banking, medicine etc. It is often the same areas that get a lot of value out of the strict WSDL design.
it is no "right" choice, it depends on what you are working with, and what kind of systems you plan to integrate with. That being said, REST is probably the architecture for the future.
to get more information, read this:
Representational state transfer (REST) and Simple Object Access Protocol (SOAP)