Successfully reported this slideshow.
You’ve unlocked unlimited downloads on SlideShare!
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
Performance Microservices in the Cloud
¿A qué huelen las nubes?
Performance testing of Microservices in the Cloud
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]
start_timer = time.time()
r = requests.get('http://www.slideshare.net/almudenavivanco')
latency = time.time() - start_timer
self.custom_timers[‘Test Academy’] = latency
if __name__ == '__main__':
speech = Speaker()
A well designed microservice
Highly Maintainable and testable
Minimal Lead Time
High Deployment Frequency
Implements a business capability
Developed by a small team/squad
Service Purpose Type When to
Event Grid Reactive
Event Hub Big data