First answers to these questions that can be answered more "simply":
For each service one is generated WAR
?
It obviously depends on the technologies/platform used. In a real environment you will notice that some micro services can be packaged in WAR
to be deployed in Java web containers, but others will not, may be a simple Javascript deployed in an HTTP server.
Working with a separate application in modules and in 3 layers: API’s, Services and DAO: This is or is not considered a micro service architecture (not isolated in different instances)?
It’s probably not a micro-service architecture. It’s likely that it’s more of a monolithic architecture and we’ll soon see what this is.
Briefly (but not so much :P) we can say that:
- micro service is the consequence of when we apply the principle of single responsibility at the architectural level, whether software, systems, etc.
- considering the above, a micro-service-oriented architecture can be defined as a set of small services, each running independently and communicating with each other through a lightweight mechanism, each micro-service may or may not provide a form of user interface. If we look at the "guts" of each micro service we will see that it is independent, so comparing with its architecture, each micro service will publish its own API (which can even be the form of integration between micro services), its own(s) DAO(s)etc. Granularity will depend on your need, always taking into account independence, scalability, deployability, etc.
- a monolithic architecture is one where an application is built in a single unit, considering the Java Web platform, all services in one
WAR
would be an acceptable comparison of how a monolithic application is packaged.
Using the graft of the article you quoted:
...it is possible to separate the services into specific instances (machines) according to the hardware requirement of that service.
Yes, this is possible with this architecture, but also with other less granular architectures.
What we gain with micro services is the high granularity that architecture allows, that is, we can have several micro services on the same server and scale on another server only other micro services.
In addition, we have the standard amusements that are directly related to micro services, such as unique services by virtual machine or by container, registration and discovery of services, etc.
In the links below you can find in detail what a micro service architecture is. As you will notice is quite large, so it is not worth including here, the detailing would be very extensive:
Beyond the blog of Martin Fowler, see also those of the Spring, Nginx and technical blogs of companies that have very granular architectures and rich Apis, such as Netflix, the aforementioned Soundcloud, among others, they always publish something about how they are using micro services to improve the form of deployment of their services, quick response to business changes, scalability, etc.
As you can see, there is already enough content on the subject. So, good studies =)
I found this post very interesting and you will want to read to understand a little more: http://www.itexto.net/devkico/? p=1768
– viana
@rray thank you. I had already seen this question but it does not encompass the scope of SOA, which is what makes me more confused when comparing to the microservices architecture
– guijob