Mudanças entre as edições de "Microserviço"

De Basef
Ir para: navegação, pesquisa
Linha 1: Linha 1:
 
'''FROM IBM COURSE:'''  
 
'''FROM IBM COURSE:'''  
  
* [https://blog.codeship.com/so-youre-thinking-of-decomposing-your-monolith-into-microservices/#disqus_thread Jones, T (2017). “So You’re Thinking of Decomposing Your Monolith into Microservices.”]
+
* [https://blog.codeship.com/so-youre-thinking-of-decomposing-your-monolith-into-microservices/#disqus_thread Jones, T (2017). “So You’re Thinking of Decomposing Your Monolith into Microservices.”]
  
 
* [https://www.infoq.com/articles/microservices-intro Richardson, C (2014). “Microservices: Decomposing Applications for Deployability and Scalability.”]
 
* [https://www.infoq.com/articles/microservices-intro Richardson, C (2014). “Microservices: Decomposing Applications for Deployability and Scalability.”]

Edição das 15h57min de 16 de abril de 2018

FROM IBM COURSE:


FROM UNIVERSITY RESEARCH:

  • Team Communication Overhead - Microservice architecture reduce the team management complexity, but it is not able to diminish the need of team communication. They need to make sure update in one’s service is not breaking other functionality. We can found this problem in monolith architecture application too.
  • Formal documentation overhead - Every individual running component app need to keep updated schemas and interface documents all the time. It helps other team using the service.
  • Non uniform application - We can choose different technology stack for different component (plygot). It leads to problem of non uniform application design and architecture. It may can increase maintenance cost in long run.
  • Dev Ops complexity - We need to have a mature Dev Ops team to handle the complexity involved in maintaining Microservice based application. Due to several moving parts of the application, it become complex and required a level of expertise.
  • Increase Network communication - Independently running component interact with each other using network. Such system require reliable and fast network connections.
  • Testing - Testing of such application is definitely harder in compare to monolith application.
  • Production monitoring - Cost to monitor such application are higher. Unavailability of the right tools are also an issue to be considered.
  • Adds complexity to development due to its distributed nature.
  • Adds overhead in terms of costs and operational complexity (build-test-deploy-run).
  • Time to market may be hit adversely due to the distributed nature of the application.
  • Monitoring the application in production deployment becomes a complex job, with multiple services.
  • Service interface versioning needs to be managed for the multiple services.
  • The operational challenges of Microservices architecture mean you need high quality DevOps and release automation skills as part of your development team.
  • The asynchronous communication and distributed nature of the micro-services based system poses challenges for testing the system as a whole.
  • Operational expenditure could be significantly higher depending on the complexity of the system.
  • Large numbers of microservices are difficult to orchestrate.
  • Understanding, managing and testing dependencies is difficult.
  • Introspection into what happens between microservices and testing across entire architectures is difficult. Think of microservices as many little monoliths. Services are separate and independent but the business logic is still hampered by a single address space.
  • Large numbers of microservices are difficult to secure.
  • Once requirements change, do you want a microservice for one new feature or re-write and add to an existing service. That is a difficult decision in an architecture with many microservices.