Performance Microservices in the Cloud
•Download as PPTX, PDF•
1 like•249 views
The document discusses performance testing of microservices in the cloud. It describes testing the latency of requests to a URL from a Speaker class. It then lists several common misconceptions about microservices, such as thinking they are just scattered web services or APIs. It also discusses design patterns, communication between microservices, and monitoring microservices in the cloud.
Recommended
More Related Content
Similar to Performance Microservices in the Cloud
Similar to Performance Microservices in the Cloud (20)
More from Almudena Vivanco
More from Almudena Vivanco (17)
Recently uploaded
Recently uploaded (20)
Performance Microservices in the Cloud
- 2. ¿A qué huelen las nubes? Performance testing of Microservices in the Cloud
- 3. import random import time import requests class Speaker(object): def __init__(self): born = "Avilés - Asturias" studies = "Applied Maths and Computability" jobdescription = "Performance SuperSayan" company = "SCRM Lidl Digital Hub" team = "Devops" talks = [VLC Testing, DevopsDays, WebPerfDays, Velocity] def talk(self): start_timer = time.time() r = requests.get('http://www.slideshare.net/almudenavivanco') r.raw.read() latency = time.time() - start_timer self.custom_timers[‘Test Academy’] = latency if __name__ == '__main__': speech = Speaker() speech.talk() print trans.custom_timers Almudena Vivanco (@MrsDaehin)
- 8. Microservices are Scattered Web Services
- 13. Cohesion Chaos
- 14. microservices As A goal
- 21. Building a gateway in every service
- 23. A well designed microservice Highly Maintainable and testable Minimal Lead Time High Deployment Frequency Loosely coupled Independently Deployable Implements a business capability Developed by a small team/squad
- 24. Design Patterns
- 25. Manolito
- 29. Simple Messaging
- 31. Message Size Persistence of the Message Batch Size https://www.cloudamqp.com/blog/2016-11-18-load-testing-and-performance- measurements-rabbitmq.html
- 33. Proxy vs Gateway
- 38. The Cloud
- 40. Cluttered App Service Plan Resource Management Resource Exhaustion
- 41. What to Monitor
- 43. Caso de Estudio
- 45. Service Purpose Type When to use Event Grid Reactive programming Event distribution React to status Changes Event Hub Big data pipeline Event Streaming distributed data streaming Service Bus Enterprise Messaging Message Order processing
Editor's Notes
- about me
- The monolithic architecture is an architecture style that structures the application as a single executable component Durante los ultimos 17 años que me he dedicado al performance me he encontrado con muchas arquitecturas. He pasado de una aplicación cliente servidor con un access :D pasando por un servicio web un datacenter en el que el presupuesto de performance se calculaba a un año vista, a una cloud propia gestionada por compañeros y ahora ya a un cloud provider externo gestionado por microsoft. La charla de hoy va del como ha cambiado la forma de probar? no realmente la forma de comprobar :)
- Polvo Magico To avoid this anti-pattern, it’s important to understand three things. First, you need understand the underlying root causes for your software delivery issues. Is it your development and deployment process? Your organization? Or perhaps your monolith has outgrown its architecture. Second, you need to understand the problems that the microservice architecture addresses. Hopefully, the two sets of problems intersect. Finally, you need to understand the prerequisites, such as automated testing, that you need to have in place in order to be successful with microservices.
- The service was not a loosely coupled when it came to channel specific functionality. Give independence to your services. Every service that you deliver must have a test suite, which should cover all the service functionality, security, performance, error handling, and consumption driven testing for every current and future consumer. This must be included as part of the build pipeline for automated regression testing. The preventative cure is to govern business functionalities that are not relevant to the service. Services must align clearly to a business capability and should not try to do something outside of their boundary. Functional separation of concern is vital for architecture to govern otherwise it will destroy the agility, performance, and scalability and ended up in establishing a tightly coupled architecture, resulting in delivery entropy and cohesion chaos.
- On the one hand, adopting microservices is a major undertaking and high-level support is essential. But on the other hand, the problem with making microservices the goal is that it ignores other obstacles to rapid, frequent and reliable software delivery including: Inefficient processes and practices - waterfall process, manual testing, manual deployment Silo’d organization - e.g. development hands off code to QA for testing. Poor software quality - the application is a big ball of mud, the code is anything but clean, etc. Layered Services Architecture
- Another anti-pattern that I’ve encountered is Scattershot adoption which occurs when multiple application development teams attempt to adopt the microservice architecture without any coordination. Several teams might, for example, simultaneously develop the development infrastructure, such as automated deployment pipelines, and setup runtime infrastructure, such as Kubernetes. A common reason for this anti-pattern is that a leader of the organization made the adoption of microservices everyone’s goal.
- Timeouts Strong Coupling Easy to Implement
- Automatic Retry Loose Coupling Message Broker must not fail Pipeline contains schema Two Phase commit
- Dumb Pipe Combinable with Transactional Messaging