In my previous post, I explored the idea of introducing software development principles to the world of infrastructure, specifically the translation of the ‘MVC’ design pattern to logically divide infrastructure into 3 distinct layers. Today I’m going to take a look at each of these layers in more depth, and examine how they fit together and what benefits this logical division offers.
Model
As discussed earlier, our ‘Model’ layer holds all of our application’s persistent data, which includes databases as well as any files (think image uploads) that the application might generate and store as it runs. One interesting concept that is worth considering when designing your persistent storage is that of ‘coupling’. For our architecture to be effective we need to incorporate ‘loose coupling’ between the layers. For example our ‘View’ layer containing our application logic shouldn’t rely on the Model layer being in a specific state, otherwise we introduce dependencies which complicate deployments and reduce our ability to quickly deploy changes. For this reason, NoSql databases such as Mongo are an ideal fit for this type of infrastructure. The main benefit of NoSql databases which we can take advantage of here is their lack of defined schema. Traditional RDBMS systems like MySQL rely on a defined schema which is tightly linked to your application, changes to the data models in your application require changes to the underlying schema which leads to situations where you can’t deploy changes to your application without first making changes to the schema. With a NoSql database the ‘schema’ is entirely imposed by your application, the database itself has no limitations on the structure of data stored in its records. So for our proposed architecture, any mapping of data to objects is handled by the application logic within the ‘View’ layer, which may seem counter-intuitive, but gives us the ability to completely de-couple the ‘View’ and ‘Model’ layers and make changes to our application without corresponding changes to our Database.
View
The view layer is where all of our application logic resides, it can be thought of in fact as being our ‘Application’. When we deploy a new version of our application, any changes should be restricted to this layer (we can see above how we prevent changes having to be made to the Model layer by using a schema-less database system). Using a phoenix server or immutable server pattern fits well into this layer as anything here should be thought of as ephemeral, ie: we can throw it away and replace it at any time with minimal impact on the system. Some other things to think about when designing this layer in more detail are:
- Deployments: The ephemeral nature of this layer mean we can remove the ‘big bang’ nature of deployments and deploy as and when required. Ideally we should be able to deploy whenever new code is available (and tested!) via our continuous integration process.
- Testing: Arguably the most important part of any deployment strategy, the nature of the infrastructure and the ring fencing between the 3 layers means we can easily create test environments here that mimic our real environment, even use our live data without affecting our production systems.
Controller
When developing an application the ‘controller’ section of the logical design is used to encompass the logic that links the view and the model, in our vision for Architecture this has changed slightly and our controller layer represents anything that sits between the application and the end user. So load balancers, DNS servers etc…. these are all things that are linked specifically to an instance of our infrastructure. As an example, if you moved from one cloud provider to another your Model and View layers could be deployed ‘as is’, but your controller layer would need to be re-implemented to take into account the new provider. Your DNS servers would need updating to point at the new setup, if you use some form of third party caching solution in front of your application this might need updating.
I hope this brief overview of how you might approach designing architecture using software development principles has been useful or at least given you some ideas to use in your own projects.