GenesisApp - A journey through containers, security and deployment

Summary

This post introduces a series of articles about a sample application I built during my personal discretionary time. The application aims to pre-game all the business and technical requirements most business applications would generate. The application addresses as many concerns as possible like authentication, function level access control, Cross Site Scripting prevention that every application should address. I affectionately call the application GenesisApp as it’s a beginning, a garden for everything else to grow in.

Baking Security In

During office hours I practice security. I like to describe what I do as a practice to remind myself I perform my work to get better at it. One of the realizations I’ve embraced is that security can be “bolted on” effectively with proper planning. I captured a few thoughts about the baked-in vs. bolt-on cliche here if you’d like read more about that. Ultimately I determined this project would be a mix of baked-in and planned bolt-on strategies to expedite time to market. The reality of prematurely requiring security could preclude business viability. Unless… I could solve all those problems before project kick-off. GenesisApp was born.

Learning to Document

Working with numerous technology stacks is a fun challenge to tackle. As a young engineer I could remember all the things and recall them when I wanted. As pride proceeds a fall, I learned I can’t remember everything I wanted to recall later. There is too much to learn, so write it down. Then I realized I was terrible at documentation as well. In plain and simple terms, I needed practice. I needed to practice and solicit feedback in my professional writing and I needed additional practice in my personal time to improve. (ala this blog)

Choosing an Architecture for GenesisApp

Architecture is the opportunity to plan for problems not yet identified. There are numerous shortcuts to accelerate time to market. The architecture to accommodate the challenges required several attributes to be successful:

• Modular - components must address a defined problem and be replaceable
• Maintainable - components must be tuned over time and provide metrics about their performance
• Scalable - components must be able to work in concert with similar components to handle unplannable demand requirements.

Note: This list captures the primary non-functional requirements for GenesisApp.

Stay tuned for posts describing my rationale for this approach. The technology stack that evolved to address these design goals looked like this:

• Staging Environment - Centos Virtual Machine
• Persistence - MongoDB on CentOS on Centos-based container
• Business Logic - Python Falcon on Centos-based container
• User Interface - AngularJS served from Nginx on Centos-based container
• Search - Elastic Search

Building a Staging Server

Stay tuned for additional explanation about the implementation decisions. This procedure describes the process to build the staging server.

Photo Credit: Tatiana from Pexels