Last week, the cross-media platform on online trends Frankwatching, published an article on the 12 factor design methodology. The 12 factor design is a best practices methodology for building qualitative software-as-a-service apps. Just for fun, we interviewed one of our very own Hifluence Architect/Developer, Alexander Verbruggen, posting the 12 factors as questions. To make the interview more challenging Alexander chose to explain how the 12 factors are applied at Hifluence using NABU, our very own Integration Software, as use case. 1.1 One codebase tracked in revision control, many deploys Version control is a no-brainer, no one develops anything without it. In nabu, each project gets its own version control. If the repository is modelled on the file system you have your choice of existing version controls, we currently use git. All artifacts necessary to run a project are contained within the repository which means there are no external artifact dependencies required to make it run (apart from the server itself of course). 1.2 Explicitly declare and isolate dependencies The nabu server takes special care of dependencies, it knows at all times how each repository entry depends on the others. Combined with the fact that everything (up to configuration) lives inside the repository, this allows for full dependency management. 1.3 Store config in the environment Configuration is in general a tricky thing, especially in standard java application servers. It takes a decent amount of voodoo to prep your releases correctly so the configuration is correct for each environment. Nabu goes about it differently, everything (including configuration) exists in the repository, this makes it very easy to manage and reference. During the deployment phase there is a differentiation between artifacts that must remain static (e.g. actual code) and artifacts that must differ between environments (e.g. configuration). This gives you the best of both worlds. 1.4 Treat backing services as attached resources Java (and by extension nabu) is very good at abstracting such systems, for example databases are generalized using the JDBC API, allowing you to switch from postgre to oracle based on configuration alone. However even then you have to be careful with the SQLs you write as they can quickly contain database-specific syntax variations. Nabu addresses these syntax-specific implementations using a “dialect”. For message queueing there is JMS, for email there are standard protocols like SMTP/IMAP/…
1.5 Strictly separate build and run stages The deployer will allow you create a “build” which contains all the necessary information to push a project (or a subset) to one or more servers. 1.6 Execute the app as one or more stateless processes Statelessness is always very nice, and integration servers (e.g. nabu) are stateless by nature as they follow a service oriented architecture (comparable to functional programming). There are of course still places where state must be kept (e.g. web sessions). It is however up to the implementation of the session provider to provide a good user experience, this can be through sticky sessions or clustered sessions. Clustering can be done through a database or a cache cluster,… 1.7 Export services via port binding Integration servers follow a service oriented architecture. Everything is a service. Combined with native support for protocols like REST, SOAP,… it is trivial to expose this functionality to the outside world. 1.8 Scale out via the process model Integration servers are meant to model business processes using appropriate syntax (e.g. BPMN). As such integration servers are always process-driven. 1.9 Maximize robustness with fast startup and graceful shutdown Nabu uses lazy loading as much as possible to spread the load time. Additionally because of its stateless service oriented architecture, caching comes naturally. Service caching is a very powerful way to enable fast access to otherwise slow data. Nabu has the ability to create persistent caches (which survive server reboots). Nabu also supports live reload of artifacts which enables live deployment. 1.10 Keep development, staging, and production as similar as possible Staging and production must be as similar as physically possible to ensure your application works as designed. The more development can use the same tools (e.g. the same database), the faster you get a solution that runs on staging/production but there is something to be said for doing development using different resources as it does ensure a greater robustness of code. Especially combined with automated testing, the slowdown can be reduced to a minimum.
That said, we develop on windows, linux and mac though currently we do use the same database. 1.11 Treat logs as event streams Logging is of the utmost importance as it is the only thing allowing you to find errors in production. Nabu has a very extensive hook system that allows logging to be as detailed as you want. 1.12 Run admin/management tasks as one-off processes Nabu allows you to connect the developer to any server (including production). You will get access to the exact codebase being used by whatever server you connect to.
LOOKING FOR A DIGITAL BUREAU TO HELP YOU BUILD SOFTWARE-AS-A-SERVICE APPS? Contact us via email or call +32 3 84 32 900 for more information. Alexander Verbruggen