Downloaded 14 times
Uploaded byMauricio Ferreyra
Tech Talks Microservices
This document discusses microservices and building REST services with Spring. It begins by defining microservices as an approach to developing applications as suites of small, independent services. It then covers microservice benefits like autonomy, scalability and innovation, as well as challenges like network latency and increased complexity. Structural principles for microservices like resilience, security and elastic scaling are outlined. Common microservices patterns and anti-patterns are also discussed. The document concludes by demonstrating how to build a basic REST service with Spring.
More Related Content
Similar to Tech Talks Microservices
Tech Talks Microservices
- 1. Microservices & SpringREST Building applications for the cloud Tech Talks
- 2. Agenda • What areMicroservices? • What are not Microservices? • REST Services • Build REST Services with Spring • Questions and Answers 215 May 2015
- 3. What is foryou Microservices?
- 4. What is Microservices? •It 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 • Fine-grained domain capability • Independently deployable • Independently releasable • Language, data storage and technologies agnostic • Designed for the Cloud 415 May 2015
- 5. What is notfor you microservices?
- 6. What is notMicroservices? • Monolithic • Layered Cross-Functional • Intelligently integrated • Centrally integrated 615 May 2015
- 7. Monolithic -> SOA-> Microservices • SOA is too coarse-grained, Microservices is fine-grained and practical SOA. 715 May 2015
- 8. Monolith vs Microservices MonolithMicroservice Simplicity Partial deployment Consistency Availability Inter-modular refactoring Real Modular Technology constraints Multiple platforms 815 May 2015
- 9. Microservice Benefits • Autonomyof the team • Ownership • Speed of change • Scalability • Elasticity • Innovation • Tech diversification • Less code, more value 915 May 2015
- 10. Microservices Hidden Costs •Network latency • Network reliability • Packet lost • Bandwidth • Security • Testing is more complicated • DevOps 1015 May 2015
- 11. Microservices Complexity • Communication –Better documentation – Fan customer empathy • Execution – Continuous deployment and delivery • Resilience – Stateless Docker Containers • Maintenance – Backward compatibility • Operational – Easy usability 1115 May 2015
- 12. Microservices Structural principles • Resilientto failure – Resiliency is designed into the application, rather than wrapped around it after the fact. Failures in cloud infrastructure are handled fluidly without interruption of service. • Resilient to latency – Applications adapt gracefully to latency rather than timing out/failing. High • Secure – Applications are based on secure lifecycle standards and include built-in security – Data at rest and in transit is encrypted. APIs are protected by authentication and authorization. 1215 May 2015
- 13. • Location independent –Applications discover services dynamically rather than relying on hard-coded dependencies • Elastically scalable – Applications respond to demand levels, growing and shrinking as required, in and among clouds • SOA/Compose-ability – Applications consume and expose web services with APIs discoverable at runtime. The structure incorporates small, stateless components designed to scale out Microservices Structural principles 1315 May 2015
- 14. • Designed formanageability – Applications are instrumented and expose metrics and management interfaces • Infrastructure independent – Applications make no assumptions about the underlying infrastructure, using abstractions in relation to the operating system, file system, database, and so on • Defined tenancy – Each application should have a deliberate, defined single tenancy or multitenancy model Microservices Structural principles 1415 May 2015
- 15. Microservices Structural principles • Availableend-user self-service – Users should be able to register themselves to use the app through a self- service registration interface, without entering an IT service request • Bandwidth aware – APIs and application protocols are designed to minimize bandwidth consumption • Cost and resource consumption aware – Application architecture is designed to minimize costs due to bandwidth, CPU, storage consumption, and I/O requests 1515 May 2015
- 16. Microservices Operational strategies • Ensureredundancy – Applications are designed to be resilent to failure though the use of redundancy. High • Utilize caching – Caching is used to improve performance, increase resiliency, and reduce bandwidth costs. High • Secure access to APIs – API end points are protected via API Management gateways. High • Stage deployments – The risk of failure due to deployment is reduced by staging the introduction of updates to components of an application. Medium 1615 May 2015
- 17. Microservices Operational strategies • 5Plan for zone/ region failures – Applications are deployed in a way that is resilient to disasters, such as entire geographic zone or region failures • Minimize inter-zone/ region latency – Applications are deployed geographically to minimize network latency • Locate high-bandwidth consumers externally – High bandwidth consumers are hosted outside the cloud to reduce cloud bandwidth utilization costs • Abstract dependencies – API abstractions are used to prevent lock-in with proprietary cloud services 1715 May 2015
- 18. Microservices Patterns • Very, verysmall • Loosely coupled ( including flow) • Versioning • Backward compatibility • Blue/Green deployments • Toggle features • Continuous delivery • Convention over Configuration • Service Discovery Service • Monitoring • Correlation IDs 1815 May 2015
- 19. Microservices Patterns • Fault tolerant,design for failure • Abstraction layer • One service at a time • Health Check • Stateless 1915 May 2015
- 20. Anti-Patterns • Complex configuration •Complicated dependencies • Managed shared state 2015 May 2015
- 21. Microservices Things to remember •Prepare for failure – Fail fast and cheap • Every integration point will eventually fail in some way, and you need to be prepared for that failure. • Do defensive programming – Defend with timeouts – Defend from thread deadlocks – Defend from resources bottleneck • Be lazy for programming, • Do not rely in others code • Communicate – Commits and early integration is the best way to communicate • Stress interfaces • Slow responses are not an option 2115 May 2015
- 22. • Keep inmind the SLAs and strict performance requirements • Use data replication and sharding • Put limits – Pagination, timeouts, big request, etc • Use queues and asynchronous for those flows that allow it • Verify integration point early • Use health checks • Avoid mocks • Learn, learn and learn Microservices Things to remember 2215 May 2015
- 23.
- 24.
- 25. REST Services • RESThas no hard and fast rules • REST is an architectural style, not a standard • REST uses Headers to describe requests & responses • REST embraces HTTP verbs 2515 May 2015
- 26. Status codes • 1xx:informational • 2xx: success • 3xx: redirection • 4xx: client error • 5xx: server error 2615 May 2015
- 27. REST Practices* • GoodHTTP Headers • Idempotent • Link and navigational • JSON • *For VCS poject 2715 May 2015
- 28. How to builda REST service 1 2 3 4 • Create REST Controller • Annotate with Request Mapping • Build the response • Deploy REST Service 2815 May 2015
- 29. Demo • Hello RESTService • Monitoring Services • Unit Test for REST Services 2915 May 2015
- 30. Resources • OPEN DATACENTER ALLIANCE Best Practices: Architecting Cloud- Aware Applications Rev. 1.0 • http://www.infoq.com/presentations/Netflix-Architecture • http://martinfowler.com/articles/microservices.html • Release It!: Design and Deploy Production-Ready Software Book • https://spring.io/guides/gs/rest-service/ • https://www.youtube.com/watch?v=wgdBVIX9ifA 3015 May 2015
- 31.
Editor's Notes
- #5 Who have heard about micro services? Tiny: lightweight, small footprint, follow SRP Uniform interface: RESTful. Decoupled, Scalable, Discoverable. OS services: self-contained, run with a single one-liner: “jar – jar”, grab port & listen. No more arcane app servers. Use existing OS process management tool
- #20 Test with Chaos monkey