{"id":28477,"date":"2020-01-17T08:46:47","date_gmt":"2020-01-17T13:46:47","guid":{"rendered":"https:\/\/centricconsulting.com\/?p=28477"},"modified":"2021-12-15T00:17:06","modified_gmt":"2021-12-15T05:17:06","slug":"all-systems-go-using-microall-systems-go-how-event-driven-architecture-aids-in-your-software-designervices-and-event-driven-architecture-to-rocket-boost-your-software-design","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/all-systems-go-using-microall-systems-go-how-event-driven-architecture-aids-in-your-software-designervices-and-event-driven-architecture-to-rocket-boost-your-software-design\/","title":{"rendered":"All Systems Go: How Event-Driven Architecture Aids in Your Software Design"},"content":{"rendered":"
Before a space shuttle can successfully lift-off, NASA engineers must ensure they prepare all systems, equipment, and parts for launch. The engines, orbiters, tanks, and boosters must all work well enough together to get the rocket to the sky but work independently enough so that one system failure does not compromise the safety of the crew.<\/p>\n
Organizations that integrate complex systems, and especially those moving more features to the Cloud<\/a>, face a similar dilemma. How do you build applications so that all components and services work together seamlessly without one change risking the integrity of the entire operation? How do you strike that delicate balance?<\/p>\n Thankfully, you don\u2019t have to be a rocket scientist to build your application architecture in a way that maximizes efficiency but minimizes risk. By using microservices and an event-driven architecture approach for your software design, your applications will be ready for lift-off in no time.<\/strong><\/p>\n Just like with space travel, application architecture evolves continuously. In the early days, organizations would build one application that performed all functions in a system. This example is a monolithic design. These all-in-one systems, from the outset, are efficient, easy to write, and quick to implement. You deploy once and adjust on an as-needed basis. It\u2019s simple but not preemptive. If one point fails, then the entire deployment fails, too.<\/p>\n <\/a><\/p>\n Monolith architecture may also seem simple to test. But as applications become more and more complex, so does testing them \u2013 the effort always increases in both time and cost.<\/strong> And as these applications progress in their lifecycles, they become much harder to change and riskier to deploy.<\/p>\n What did organizations do to mitigate this? As they began to apply agile approaches<\/a> to their architecture designs, they found smaller features finished earlier. As deploying faster is a competitive advantage, this new approach made sense. So, to get applications off the ground more quickly, organizations took their all-in-one systems and broke them into smaller, logical subsystems.<\/p>\n In other words, they adopted a service-oriented architecture (SOA). By treating each subsystem as its own application, software engineers can reduce the scope of work and amount of testable code into more manageable chunks.<\/p>\n Still, SOA has disadvantages:<\/strong><\/p>\n While SOA does have advantages to, organizations must use great design patterns to keep from creating more problems than they fix.<\/strong> These patterns can be hard to enforce.<\/p>\n A microservices-based approach is the opposite of the monolith. Microservices are better versions of SOA, because they granulate into loosely coupled services that use fault-tolerant asynchronous messaging instead of tightly coupled point-to-point connections. This process can be more complex and takes more leg work to get up and running. You get application simplicity, but infrastructure complexity. However, those willing to invest will enjoy several benefits from using the microservice:<\/strong><\/p>\n <\/a><\/p>\n As you leave the solar system of the monolith and enter the universe of microservices, you may consider landing on the world of event-driven architecture (EDA). In EDA, applications interact by producing and consuming messages distributed into an event stream. Conceptually, individual applications react to events that occur in some other application by processing the resultant message and then generate messages of their own.<\/strong> We usually categorize this by a significant change in state, which happens in a domain.<\/p>\n <\/a><\/p>\n In these messaging-based infrastructures, we gain the smaller applications we tried to get in SOA, but they are easier to design and test because their loose-coupling between sub-systems makes it easier to test and deploy applications in isolation.<\/p>\n Because of the messaging infrastructure, our application teams are free to build large applications or microservices, using the technologies that are best suited for the job. Our enterprises can be a combination, so long as all applications obey the contracts for the events.<\/p>\n Other benefits of EDA include:<\/strong><\/p>\n Say you are an astronaut navigating your space shuttle through outer space, and you unexpectedly come upon an unseen asteroid belt. The tail of your rocket skims an asteroid, damaging your engine compartment, and fuel begins leaking into one of your backup engines. Thankfully, this is a releasable compartment. But two of your crew members are currently back there working, and you don\u2019t want to risk their safety. You are the only one in the cockpit, and right now, you can only do one thing first. Your options are:<\/p>\n Time is of the essence, and you can\u2019t do all of these things at once. More specifically, you can only do one at time. So, what do you do first?<\/p>\n If your rocket system design followed an event-driven architecture blueprint, then you wouldn\u2019t have to worry about manually performing each of these tasks, one after the other. The event\u2014in this case, the rocket striking a meteor \u2014 would trigger a range of automatic responses that occur simultaneously.<\/p>\n <\/a><\/p>\n Another benefit of this design is that each of these event channels can be tested, scaled, enhanced, or removed individually without affecting the other channels. So, if your ship\u2019s communication antenna is offline for maintenance and cannot send an SOS to Earth, the other event channels remain activated when the event occurs. This feature allows for a more reliable, efficient, and overall safer design. When you fix the antenna, then the SOS will automatically send.<\/p>\n For app developers, figuring out what system architecture to use can be as daunting as exploring outer space. Do you use a simple, cost-effective monolith design that is quick to implement but also quick to fail? Or do you sacrifice simplicity for reliability and scalability? As application-driven architecture evolves and more features are added, you should be ready to add event-driven architecture to your software payload.<\/strong> It is easier than rocket science, far less risky, and will take your apps further than they\u2019ve ever gone before.<\/p>\n We discuss using Microservices and Event-Driven Architecture to rocket-boost your software design.<\/p>\n","protected":false},"author":63,"featured_media":28478,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","footnotes":""},"categories":[1],"tags":[19128],"coauthors":[15012],"acf":[],"publishpress_future_action":{"enabled":false,"date":"2024-07-21 22:53:32","action":"change-status","newStatus":"draft","terms":[],"taxonomy":"category"},"_links":{"self":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/28477"}],"collection":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/comments?post=28477"}],"version-history":[{"count":0,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/28477\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/media\/28478"}],"wp:attachment":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/media?parent=28477"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/categories?post=28477"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/tags?post=28477"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/coauthors?post=28477"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Moonwalk Away from the Monolith<\/h2>\n
Switching Orbits to SOA<\/h2>\n
\n
One Small Step Toward Microservices<\/h2>\n
\n
Edging Toward the Event (Driven Architecture) Horizon<\/h2>\n
\n
Event-Driven Architecture in Action: An EDA Space Odyssey<\/h2>\n
\n
Get Ready for Lift-Off<\/h2>\n
Go further<\/h4>\n
\n