Recommended
More Related Content
Similar to The Rock Band Architecture
Similar to The Rock Band Architecture (20)
Recently uploaded
Recently uploaded (20)
The Rock Band Architecture
- 1. Architecting Systems Like a Rock Band A Federated Event-Driven Architecture @rossbrigoli www.rossbrigoli.com 1
- 2. “Despite our best efforts, software becomes harder to change over time. For a variety of reasons, the parts that comprise software systems defy easy modification, becoming more brittle and difficult to control over time.” “Since we can’t avoid change, we need to exploit it.” - Neal Ford, Rebecca Parsons Evolutionary Architecture 2
- 3. If developers are the rock stars, Software Architects are the writers, composers and the producers. - Ross Brigoli 3
- 4. Monolith - Layered Architecture Controller A B D C E F H G Business Layer Data Access Layer Data LayerUI Layer Application 4
- 5. Service-Oriented Architecture (SOA) A B D C E F H G Business Services Data Access Services Data ServicesService Bus ESB 5
- 6. Microservices Architecture Gateway A B D C E F I G H J A With direct service-to- service communication 6
- 7. Microservices Architecture Gateway A B D C E F I G H J AWith no direct service-to-service communication Service Registry 7
- 8. Service Mesh Ingress D C E F I G H A Each service has its own sidecar container as reverse proxy for routing Management Console / Control Plane A B J 8
- 9. Why did they evolve? To allow for changes to be delivered independently with minimal impact To scale out development process, so multiple autonomous teams can change different parts of the system at the same time To reduce coupling, so changes to a service are less impacting To allow components to change/evolve independently To make things easier to change. 9
- 10. Service Orchestration Service orchestration is the process of integrating two or more applications or services together to perform a process, or synchronize data and states in real-time. 10
- 11. Everyone depends on the conductor Orchestra Everyone relies on the sheet music 11
- 12. Rock Band They listen to each other They don’t depend on a single person They respond to what they hear They are not strictly following written rule sets They are choreographed, not orchestrated They are event-driven 12
- 13. Event-driven EVENT NOTIFICATION EVENT-CARRIED STATE TRANSFER EVENT-SOURCING COMMAND QUERY RESPONSIBILITY SEGREGATION (CQRS) 13
- 14. Event-driven Architecture Event Broker Batch Job Service Batch Job UI Service Service 14
- 15. A Federated Event-Driven Architecture Rock Band Architecture 15
- 16. Rock Band Architecture The role of Service Orchestration disappears Services listen for events and respond (or not) to those events however they wish Services broadcast events Uses multiple event brokers, one for each business/technical domain Services are grouped by business/technical domain and uses specific event brokers 16
- 17. Rockin'1000 performing for the first time live "Smells Like Teen Spirit" by Nirvana during That's Live - the Biggest Rock Band on Earth, in Cesena - July 2016. 17
- 18. Event Broker Batch Job Apps Service Service Edge Edge Event Broker Service Apps Service Batch Job Event Broker Batch JobMobile App GUI Service Band A Band C Band B Rock Band Architecture Edge Edge Edge services publishes event notifications to other band’s broker 18
- 19. Rock Band Architecture Event Broker Batch Job Apps DB Service Band Edge Edge Band Boundary Apps and Services are the Players Responsible for publishing events to systems external to the band Player Contains Topics 19
- 20. Use Case – Batch Job State Transfer Event Broker Service Web UI Credit Rating Service Batch Job Rating Edge Event Broker Batch Job UI Liquidity Invoicing Interest Rate Service Finance BandCounterparty Risk Band Reporting Edge Rating Changed Event 1 2 Event from Referential band • CPY ID • Old Rating • New Rating 3 3 3 4 4 5 66 Event to publish to reporting/Analytics band 20
- 21. Pros and Cons Bands can evolved independently with minimal impacts to other bands Players in a band can evolve independently with minimal to zero impacts to other players New Players can be added on the fly without having to inform other player or other teams maintaining the player Bands has the freedom to chose their own event broker product Having multiple brokers instead of centralized/enterprise-wide message broker reduces operability 21
- 22. Questions? 22
Editor's Notes
- Changes in software projects are usually driven by a reevaluation of functionality and/or scope. But another type of change occurs outside the control of architects and long-term planners. Though we like to be able to strategically plan for the future, the constantly changing software development ecosystem makes that difficult. Since we can’t avoid change, we need to exploit it. One of important quality of a good Software Architecture is Evolvability. “How easy is it to change?”
- 1. Let’s take a very quick review at how application architecture has evolved overtime, and what has triggered the evolution. 2. Each component in this system, knows exactly which component (or set of components) it needs to invoke next, and furthermore, this logic is built into the application itself rigidly. 7. Changing this logic in most cases means that a developer make changes to the application code and that requires a new version of the entire application to be deployed. Even an addition of a single column on the relational database requires the entire application to be deployed.
- SOA was created to solve some of the problems of monolith especially when it grows too big. Although SOA has a very broad meaning, in general sense it looks like this. In Service-Oriented Architecture, the layers were broken down into different services. And, this solves the problem of having to deploy the entire application even for the smallest changes. Here if the Business service A changes it does not mean that you also need to change B and E. And maybe you also don't need to change C and D. But there is a small problem. If you change the Data service G that is providing services C and D, both business services still have to be updated and deployed. Or furthermore, if H data services changes, all services may have to change.
- So Microservices came to the rescue. Microservice is actually a very specific form of SOA which very good as it solves the ambiguity in SOA. Microservice Architecture went even further by splitting each service completely independently and this time with it’s own operating system space. Each of the services are completely isolated, that’s why it’s called a ”share nothing architecture”. Even the operating system is not shared, thanks to containers. That’s the very basic form of microservices. But there is also a problem with this form of Microservices. Each service needs to know about the other services, what APIs are there and how to invoke them. That is the kind of coupling that many people don’t like very much. If a new version of E is deployed side-by-side with the existing version of E, service B will never know, until you deploy a new version of B. But you can solve this problem by making the call always go through the Gateway.
- In this pattern, the Gateway holds a registry of service that are available together with their endpoints. Some people actually employs service discovery mechanism. Here, services do not need to know where there other services are they just have to tell the gateway what they need and the gateway will route them to the right service. The gateway is acting as a reverse proxy not only to external calls but also to internal service calls. But there is also a problem with this Architecture, all the network traffic goes to the gateway, even for internal request. The Gateway becomes the bottleneck here as all the network traffic goes through it. But this is already good for small systems like 10 services with very small user base.
- Let's talk about Service Mesh. There are product Today that provides you a framework for building Service Mesh. There is Istio and LinkerD which takes advantage of Kubernetes. There is Azure Service Fabric and there are many other products that are usually being marketed as API Management solutions. Service mesh decentralizes the responsibility of traffic management, routing and load balancing to the the side car container which every service has. This also allows for health checks, metrics and telemetry, circuit breaking, etc. This is a really good architecture. It’s very flexible. The coupling is very low. But there is still a problem. Although the service do not need to know where the other services are, although it solves the problem of the gateway being the bottleneck, they still need to know how to use those services. They need to know the signature of the method to call for example or The name of the method to invoke. They need to know how to pass the parameters and the types of the parameters because it uses and RPC-type synchronous communication. If service D changes in way that it requires an additional mandatory parameter, all the services that calls D will have to know that and will have to be changed as well. But there is a solution to that. We will talk about it later, but first, let me ask you this question. Why did the architecture evolve from a monolith to service mesh?
- Here’s my answers. Most of these answers can be summarize into a statement “To make the system easier to change.” Remember what Neil Ford says? “Since we can’t avoid change, we need to exploit it.” Let’s make our systems easy to change and let’s keep changing it until it gets better and better. Microservices or Service Mesh are relatively easier to change than a monolith or a SOA application.
- All of the architectures we talked about in previous slides employs a pattern called Service Orchestration In Software, orchestration often means integration, control, synchronization and mediation of decoupled application services in order to fulfil groups of tasks as part of a business processes. All of the architecture we talked about earlier uses some form Service Orchestration. They go by different names like Enterprise Service Bus, Gateway, Ingress, Management Console, and Control Plane. In highly distributed systems, orchestrating multitudes of services through the entire service lifecycle in a high-availability and elastically scalable manner is no easy task. It’s complicated. And If not designed carefully, it can lead to a scenario where the service orchestrator becomes the blocker for future architecture evolution.
- In an Orchestra, The primary responsibilities of the conductor are to unify performers, set the tempo, execute clear preparations and beats, listen critically and shape the sound of the ensemble, and to control the interpretation and pacing of the music. if the conductor leaves the orchestra in the middle of a symphony, chaos could occur eventually. This is because each musician rely heavily on a set of rules written in the sheet music and they rely heavily on the live instructions of the conductor to interpret those rules at the right time. In other words, each musician depends on the conductor, even this guy. But not in a rock band.
- Rock bands don't need a conductor and often times they don't need music sheets. This is because each musician do not rely on a single person to give them instructions. Instead, they listen to each other. They listen to the drum beat for the tempo. They listen to the singer to know which section they are in the song. They listen to the guitarist to know when to bring down their instruments volume to bring up the guitar solo, and so on and so forth. Each musician also knows what they need to do and when they need to do their thing without being told when and how. They decide when to do things based on what they hear. And because they don't follow music sheets, they can improvise and make the music sound better than expected. They can recover quickly from failure, i.e. a broken guitar string or a thrown away drum stick or improvise when this happens so, but they never stop playing just because of it. This is why each live performance is a bit unique. To sum it up, musicians in a rock band respond to events instead of being conducted. In other words, Rock Bands are event-driven.
- So what does event-driven mean? Martin Fowler did a very good explanation on the meaning of Event-Driven in his talk entitled “The Many Meanings of Event Driven”. In that talk, he summarized it in to 4 different patterns.
- Event-Driven Architecture is recently catching the attention of software architects and engineers Today because of its simplicity and versatility. Components are very loosely coupled. Each component/services are independent of each other and they can be totally isolated like microservices. The interface contract definition does not have to be defined up front and can be easily changed. In EDA, services use messaging (asynchronous type of communication) instead of request-response (synchronous type or communication). It follows a publish/subscribe messaging model where services can either be subscriber, publisher or both. Messages are pushed and broadcasted. Because when pulling data, a service needs to know upfront where to pull the data from and how to invoke the call. But when you push events/data, one does not need to know to which specific service you need to push the data to. You just broadcast it. There are many advantages with this architecture. It solves all the problem that we've seen earlier plus it solves the problem of needing to know how to invoke other services. But if the system becomes very large, say 1000 services. The risk of loosing the centralized event broker becomes unacceptable. And the maintainability could go down dramatically. Why? Well, in this pattern, there is no "readable code or statement" that describes what the entire system does. It's not easy to understand what it does. You have to run the system and see what happens in order to understand what it does. That's a trade off. But to minimize this problem, you don't want to create a really huge event-driven systems with hundreds of services. But what if there is really a need to go big?
- Is an event-driven architecture that follows the Event-Carried State Transfer but with specific recommendation. In a rock band architecture, the role of orchestration disappears. Independent services listen for events and responds (or not) to those events whenever necessary. Services also broadcast events but they don't need to know how other services would respond to it or would use those messages, or if other services are even listening. Much like a rock band, each musician is responsible for playing his own instrument but they also communicate by listening to each others instruments Rock Bands are small, there are only 4 to 10 members of a Rock Band So how do we scale?
- When you put 1000 rock band musicians together and play the same song, it's fun for sure but it does not sound as good as a single 5-pieace rock band on a small stage. This is because it is so difficult to synchronize a huge number of musicians and that is the reason why orchestras need a conductor. Sound travels at 342 m/s. So if you put a drummer and a bassist 100 meters apart, they will be de-synchronized by 1/3 of a second and in music, that's a lot. Similar principles apply to Event-Driven Architecture. If two-closely related services need to send messages to each other but there are 5 topics to go through before reaching the other end of the channel, you are loosing time and it's not nice. Another important aspect to consider when deciding an architecture is how well it fits in the enterprise organization. Teams maintaining and building applications in a huge organization don't often speak to each other and the bureaucratic processes behind this are counter productive. No matter how you try to break the silos between teams, sections and departments, you can only do too much. So when different silos are sharing a middleware such as an Event Broker, what organizations usually do is to create another silo, such as a dedicated middleware team, to maintain that middleware. And from then on, teams and departments has to go through them when they want to establish a communication interface. That's a new layer of red tape. So what does a Rock Band Architecture look like.
- The Rock Band Architecture is a Federated Event-Driven Architecture. Because bands sound better when they are the only ones playing the music in a small stage closer to the audience. Instead of one single event broker, each silo has it's own event broker. This maximizes the freedom of the teams to choose how to implement their event broker. This also reduces the work on coordination between the silos. Overall, this reduces the effort required for dependency management.
- Let us take a closer look at the band A Band is a group of services/players that are connected to a common Event Broker. These player services are grouped functionally into a Band. The grouping can be done in an organization context or by a more detailed context like a subsystem or even an application. The goal is to minimize dependencies between systems and/or organizational unit. You don't need an orchestrator or a conductor in a Rock Band. What the system needs is a channel of communication where services can broadcast to and listen for events. The Event Broker. A rock band only needs a stage and their instrument monitors (the big speakers and guitar amps you see on stage). Events are not some generic free-form messages but are specific, small, real-time and contextual, and it must carry some information pertaining to the details of the event. The messaging channel for the event broker must have the following properties: 1. Events must be broadcasted in real-time or near real-time, otherwise the band would be out of sync. 2. The communication channel must also use a protocol that is platform agnostic so that services can be built in any platform and developed in any language 3. It supports any kind of endpoints, i.e. HTTP, HTTP/2, TCP, UDP, MQTT, AMQP etc... 4. It implements a publish-subscribe or consumer-producer messaging pattern The services in RBA are the band members or the "Players". Each player plays a specific role that makes up the entire system or subsystem. Service can be in any form of software component (or even hardware) that is either subscribed to one or more topic or is publishing to topics or doing both. Players are typically "stateful" and are always up and running, but sometimes they can be stateless and ephemeral as well. A player can be as big as an entire application or as small as a microservice or a serverless function. Players are monitored so that in the event of a crash, there is something or someone that can do something about it like a player service automatic restart or an severity 1 incident raised to the helpdesk. One way to do this is to design the player service so that they are sending heartbeats regularly to a specific topic on the event broker. Or if your services are running on Kubernetes, you don't have to worry about it. The services that are publishing messages outside of it's own band are called Edge Services. I wanted to call it the "Groupie", but the Oxford dictionaries definition of it is not very nice. There can be one or more Edge Services in a band. Edge services must only publish messages to other band's event broker and must not subscribe to other band's event broker. This simplifies the service as they don't have to maintain a persistent connection with an event broker outside its perimeter.
- When is this Architecture useful? Let take a look at this example. An event was published to event broker of Counterparty band. This event came from somewhere else, maybe the referential team Then Inside the Counterparty Risk Band, there is a service called Credit Rating service that happens to be subscribed to a topic where this event was published. Credit Rating Service updated the credit rating of the counterparty in the database, and published it as an event called “Rating Changed”. The event also contains details. A web application that is currently opened in the browser, received the event and displayed something in the UI for the user. Batch Job manager/server also received the same event, so it execute some processing. The Rating Edge service at the same time also heard the event and published/forwarded it to the Finance band’s event broker.
- Applications are being decomposed into smaller services so that small independent teams can develop and maintain a service independently. Because this supports organizational agility. Being able to decentralize event brokers in a federated manner can reduce or eliminate organizational interdependencies which in turn produce more empowered, agile teams who can make important architectural decisions on their own with minimal/isolated risk of impacts.