Throughout this book, we have learned a number of tools and techniques to aid us in building reactive applications—futures with imminent, Observables with RxClojure/RxJava, channels with core.async—and even in building reactive user interfaces using Om and React.
In the process, we also became acquainted with the concept of Functional Reactive Programming and Compositional Event Systems, as well as what makes them different.
In this last chapter, we will bring a few of these different tools and concepts together by developing an application based on a real-world use case from a client I worked with in Sydney, Australia. We will:
- Describe the problem of infrastructure automation we were trying to solve
- Have a brief look at some of Amazon's AWS services
- Build an AWS dashboard using the concepts we have learned so far
This client—which we will call BubbleCorp from now on—had a big problem that is all too common and well known to big enterprises: one massive monolithic application.
Besides making them move slow, as individual components can't be evolved independently, this application makes deployment incredibly hard due to its environment constraints: all infrastructure needs to be available in order for the application to work at all.
As a result, developing new features and bug fixes involves having only a handful of development environments shared across dozens of developers each. This requires a wasteful amount of coordination between teams just so that they won't step on each other's toes, contributing to slow the whole life-cycle further.
The long-term solution to this problem is to break down this big application into smaller components, which can be deployed and worked on independently, but as good as this sounds, it's a laborious and lengthy process.
As a first step, BubbleCorp decided the best thing they could improve in the short term is to give developers the ability to work in the application independently from each other, which implies being able to create a new environment as well.
Given the infrastructure constraints, running the application on a single developer machine is prohibitive.
Instead, they turned to infrastructure automation: they wanted a tool that, with the press of a button, would spin up a completely new environment.
This new environment would be already preconfigured with the proper application servers, database instances, DNS entries, and everything else needed to run the application.
This way, developers would only need to deploy their code and test their changes, without having to worry about the application setup.