Microservices - modern software architecture
Download as PPTX, PDF1 like586 views
This document discusses microservices architecture and how the Nomadays tourism software transitioned to use microservices. Key points include: - Nomadays refactored their monolithic architecture into microservices in 2015 to allow for independent deployability and scaling of services. - Microservices architectures improve scalability, reduce single points of failure, and allow different programming languages/tools to be used for different services. - Nomadays partitioned their application into 11 microservices plus additional components like a configuration server and service registry. They use Netflix OSS tools and RabbitMQ for communication between microservices.
![Microservices
The services are easy to replace.
Services are organized around capabilities, e.g., user interface front-end, recommendation, logistics,
billing, etc.
Services can be implemented using different programming languages, databases, hardware and
software environment, depending on what fits best.
Services are small in size, messaging enabled, bounded by contexts, autonomously developed,
independently deployable, decentralized and built and released with automated processes.[7]](https://image.slidesharecdn.com/microservices-161114092149/85/Microservices-modern-software-architecture-15-320.jpg)
Microservices - modern software architecture
- 2. About me ● Software start up since 2010 ● Professional interest ○ To build big scalable apps ○ Engineering as an art of state ● Fine art photography and bio hacking hobbyist
- 3. About nomadays Tourism software started in 2010 October Complete rewrite from 2013 Refactored into microservices from 2015 2 main UI: Backoffice - for company manager Platform - for travelers
- 4. Why do we need microservices?
- 5. Monolithic architecture 5000 requests per minute 50 requests per minute Mostly writes, few reads Compute heavy
- 6. Monolithic application architecture cons Different non functional requirements (read, write, compute...) & optimized for none Single points of failure Overloads your IDE and container Has physical limit
- 11. Scaling vertical vs horizontal
- 12. The scale cube
- 13. Y axis scaling & X axis scaling
- 14. Microservices Microservices is a specialisation of and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems.
- 15. Microservices The services are easy to replace. Services are organized around capabilities, e.g., user interface front-end, recommendation, logistics, billing, etc. Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best. Services are small in size, messaging enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.[7]
- 17. Partitioning strategies Too few Drawbacks of the monolithic architecture Too many - a.k.a. Nano-service anti-pattern Runtime overhead Potential risk of excessive network hops Potentially difficult to understand system
- 18. When partitioning Focus on building cohesive services that make development and deployment easier… not just tiny services. - Chris Richardson
- 19. Real world example Amazon (100-150 services to build a page) Netflix (~600 services) SoundCloud Ebay Uber …
- 20. Nomadays 11 microservices, 1 config server, 1 service registry
- 21. Client service interaction design
- 22. Inter-service communication options Synchronous HTTP vs asynchronous AMQP Formats: JSON, XML, Protocol Buffers, Thrift, ...
- 23. Pros and cons of messaging Pros Decouples client from server Message broker buffers messages Supports a variety of communication patterns Cons Additional complexity of message broker Request/reply-style communication is more complex
- 24. Pros and cons of HTTP Pros Simple and familiar Request/reply is easy Firewall friendly No intermediate broker Cons Only supports request/reply Server must be available Client needs to discover URL(s) of server(s)
- 27. Our technology choice Netflix OSS Api gateway: Zuul Service registry: Eureka Client side load balancer: Ribbon Circuit breaker: Hystrix Reactive programming: RxJava RabbitMQ Cloud foundry PAAS
- 31. Lessons learned Data is different and difficult. Split your database Reactive programming is necessary. It can be difficult. It will take time to put pieces together. Inconsistent failures are SCARY.
- 32. Next steps Event sourcing & cqrs More reactive programming Log aggregation
- 33. Q&A Thank you