We discuss using Microservices and Event-Driven Architecture to rocket-boost your software design.
Designing software systems that deliver value better, faster, and cheaper is a complex affair. So complex, in fact, some may call it rocket science.
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.
Organizations that integrate complex systems, and especially those moving more features to the Cloud, 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?
Thankfully, you don’t 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.
Moonwalk Away from the Monolith
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’s simple but not preemptive. If one point fails, then the entire deployment fails, too.
Monolith architecture may also seem simple to test. But as applications become more and more complex, so does testing them – the effort always increases in both time and cost. And as these applications progress in their lifecycles, they become much harder to change and riskier to deploy.
Switching Orbits to SOA
What did organizations do to mitigate this? As they began to apply agile approaches 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.
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.
Still, SOA has disadvantages:
- Each application connects to its dependent applications, usually over a point-to-point connection. When an application requires some functionality from another application, it simply requests it over a standard communication structure to the published location. The more services a company creates, the harder it is to know which services are available and where they reside.
- Often, these point-to-point connections are not fault-tolerant, meaning they are still too tightly entwined or tightly coupled. If one service goes down, cascading failures will result.
- Smaller features don’t necessarily mean faster, less complicated testing if they are tightly coupled to other services.
While SOA does have advantages to, organizations must use great design patterns to keep from creating more problems than they fix. These patterns can be hard to enforce.
One Small Step Toward Microservices
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:
- Independently testable and deployable
- Operate in isolation (loosely coupled)
- Faster, more agile deployments
- Increased scalability and reliability
- Asynchronous external interactions that favor message passing
- Communicate via language-agnostic APIs
- Much easier to test. Each microservice operates independently of all others, and therefore, you can test it in isolation.
Edging Toward the Event (Driven Architecture) Horizon
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. We usually categorize this by a significant change in state, which happens in a domain.
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.
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.
Other benefits of EDA include:
- Ease of third-party integration
- Can “wrap” or adapt existing systems into the ecosystem
- Can be deliberate about scaling
- Fault-tolerant
- Can log and replay event messages
- Can test subsystems in isolation
Event-Driven Architecture in Action: An EDA Space Odyssey
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’t 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:
- Alert the crew and hope they hear your message
- Eject the compartment before the entire shuttle blows up
- Steer the shuttle away from the asteroids so you don’t hit any more
- Send an SOS signal back to Earth
Time is of the essence, and you can’t do all of these things at once. More specifically, you can only do one at time. So, what do you do first?
If your rocket system design followed an event-driven architecture blueprint, then you wouldn’t have to worry about manually performing each of these tasks, one after the other. The event—in this case, the rocket striking a meteor — would trigger a range of automatic responses that occur simultaneously.
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’s 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.
Get Ready for Lift-Off
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. It is easier than rocket science, far less risky, and will take your apps further than they’ve ever gone before.
Go further
- Watch the talk EDA expert Shawn Wallace gave at the annual tech conference Stir Trek.
- Does your application design need a boost? Learn about how our Custom Development and Application Lifecycle Management services can help.
- Read how to increase customer engagement with your mobile app.