Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

9 patterns of microservices


Published on

Most common 9 patterns of microservices architecture

Published in: Technology
  • Be the first to comment

9 patterns of microservices

  1. 1. Top 9 patterns of microservices architecture Highlights from Martin Fowler, Sam Newman and James Lewis’s articles, talks and Book
  2. 2. What’s Microservices Architecture ? In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- James Lewis and Martin Fowler
  3. 3. Monolith vs microservices
  4. 4. #1 Componentization via Services Pros ● Independently deployable ● More explicit component interface. Cons ● Remote calls are more expensive than in-process calls.
  5. 5. GraphiQL and Swagger vs. requirements.txt (python example) Components Scenario: ● Team A develops a package that wraps the super important external API (SAPI). ● Teams B,C and D depends on this package whenever Team A releases a new version of the package the other *depndent* teams should at least should change requirements.txt and rebuild. Services Scenario: ● Team A develops a RESTful API and Teams B,C and D consumes this API. ● Team A is making whenever a new change happens the swagger gets changed automatically and end-point as backward compatible as possible. ● Teams B,C and D should be tolerant about response
  6. 6. #2 Organized around business capabilities.
  7. 7. #2 Organized around business capabilities. ● Siloed functional team leads to siloed application architecture. ● Simple changes will lead to huge time and budget loss. ● Different priorities. ● With monolithic it’s very hard for individuals.
  8. 8. #2 Organized around business capabilities. ● Cross-functional teams organized around capabilities. ● End-to-end responsibility. ● Challenging to implement.
  9. 9. How big/small is a microservice ? ● The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. ● The smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services. ● Bottom-line it should be micro-sized responsibility. ● Check spotify’s squad, chapter tribe formation.
  10. 10. #3 Products not Projects ● You build it, you run it ● Devops culture is adopted by Facebook, spoitfy and others. ● Projects are time bounded. Products are continuous activity including but not limited to developing features, deploying, fixing and up to getting 3AM support calls.
  11. 11. Challenging at scale? Not for spotify!
  12. 12. #4 Smart endpoints and dumb pipes ● Unlike ESB simple messaging queues are prefered RabbitMQ, 0MQ and ActiveMQ. ● Choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool. ● Changing messaging protocol / rpcing in monolithic may led to more complex/chatty application ● This may be one of the main differences between SOA and microservices architecture.
  13. 13. #5 Decentralized Governance ● Not every problem is a nail and not every solution a hammer. ● Prefer using the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn't that common. ● Internal opensource model. ● Consumer Driven Contracts. << This is where GraphQL plays a great role. ● Tolerant Reading. ● Postel's law (Conservative about what you send. Tolerant about what your receive.)* *=Also called the robustness principle by Jon Postel who wrote an early specification of TCP
  14. 14. #6 Decentralized Data Management Different perspectives of same entity. ● Campaign has like 10 meaning in our current system. ● Polyglot persistence ● A huge problem is data consistency and updates (distributed transactions) ● As long as the cost of fixing mistakes is less than the cost of lost business under greater consistency.
  15. 15. #7 Infrastructure Automation
  16. 16. #7 Infrastructure Automation ● CI/CD ● Make it easy to do the right thing. ● If deployment is boring there isn't that much difference between monoliths and microservices. ● Difference between CI/CD in monolithic and microservices applications
  17. 17. #8 Design for failure ● Applications need to be designed so that they can tolerate the failure of services. ● Netflix's Simian Army induced failures of services and even datacenters during the working day to test both the application's resilience and monitoring. ● Blackout drills. ● The Circuit Breaker ● Choreography and event collaboration. The RX Era. ● sophisticated monitoring, logging setups and dashboards for each individual service.
  18. 18. This tree is having a hard time? Good because your legacy services will be migrated the same way!
  19. 19. #9 Evolutionary design ● Usually it’ll never be microservices from day1. ● Many microservice groups expects many services to be scrapped rather than evolved in the longer term (2 weeks replaceability). ● The Guardian website Monolith to Microservices [add new features by building microservices that use the monolith's API] ● StranglerApplication Pattern (Killing Softly!) ● Versioning of APIs and consistency. ● Evolutionary replaceability is another organic design.
  20. 20. Sources
  21. 21. Thank you!