How to increase the efficiency of the team with a decoupled application architecture.
I have been thinking about this for some time. Most people have good resources that can be put to achieve something remarkable, but in most case what happens is that responsibilities are entitled to a few people just because of the tightly-coupled architecture of the application/services. This will hamper the entire development because a few resources have to work on almost all areas of the application. Even though the team have free resources, they will be unable to take part in development or they have to depend on other team members.
I will exemplify with a scenario that I have gone through. While working in a project I had too much on my plate, and manager needs to use a front end resource to reduce some of my work. We were rendering forms using django-forms at that point. Using django-forms allow backend developer to render html forms together with css classes but the less sweeter part comes into picture when there is a full time front end resource who is supposed to work on the html pages and s/he cant do that since forms are rendered by django using python codes as s/he is familiar with html and javascript only. Here what did was instead of removing the entire form rendering from django, we kept the forms intact but constructed forms with html only and name of input attributes were kept as same of the form fields. This way, instead of rendering, django-forms was taking care of only the data validation at backend. This proved to be an efficient way and provided us with a better pace in development.
I am a web developer who develops web applications in Python/Django. According to my view an application should be having a decoupled architecture as described below. But please bring forward opinions if there is any thought that I am wrong or a change is required.
The team, repository, and branches.
Entire code base must be managed by an efficient version control system, needless to say git is always the preferred option. There should be one repository for each team. For instance, frontend team maintains a repository for frontend framework like AngularJS, ReactJS or any efficient JS framework that can handle the entire frontend. Team can have multiple resources working on same repository. In case of a new functionality that should be maintained in a new branch and have to be maintained as a pluggable application with minimal dependencies which in most cases is possible. Developer access to repository should be restricted to Feature/development branch of repository. Pre-Production, production/live branches are meant to be handled by devops/QA team or anyone who have a clearcut picture of what functionality is needed for the release and what code is in which branch.
QA/Devops
It is recommended to maintain a QA team with members having experience with devops technologies as well. Reason is that deployment can be handled by QA with devops experience and this helps developers to engage in development only rather than handling multiple servers. This really helps if the product/feature have to be developed immediately. Devops/QA team is responsible for the deployment as well as moving features across different branches. This, however require help from developers but if the process is performed in regular intervals the time and effort spent on deployment will be low. After developers push code to feature/dev branch, QA/Devops should verify the same before it goes to pre-prod and production. Any bugs found can be raised on a good bug tracking tool like bugzilla. When the code have to be moved from production to live, one more round of testing should be done. Team can automate deployment process with tools like fabric/ansible/puppet etc.
Docker is recommended at this stage since docker can containerize every build and these containers can be deployed easily. Having A docker repository with containers/dockerfiles is better. This repository holds every build of the app. One can spin up these containers to get the application running or docker containers can be spawned from a dockerfile using a one-liner bash script. For instance a docker container can contain all the code of a release. Then this container can be moved from production after testing and verification and then can be deployed in server in this case instead of updating code to implement functionality, replacing a docker container is easy and more useful as this helps from reverting code in server if any bug that is not tested is found after deployment.
Application Architecture
Below depicted is an example for application architecture. According to this diagram, The REST-Api is the core component that support Create/Read/Update/Delete operations on a database based on HTTP methods. More sweet part is that there can be multiple instances of the api running that the application can be made more fail proof. Server powering the Backend can be swapped with multiple pluggable instances. All the mobile/web platforms are decoupled from the backend.
Android/IOS/Website will make appropriate api calls to perform CRUD operations on database. Here one thing to take care is security. For ease of use one can implement token authentication. But be aware that tokens are not stored as hashed strings like password hashes by some frameworks. So it is recommended to use token refresh mechanism to provide improved security. Then comes the database part. There can be one single database or multiple instances of a database. Latter is recommended since it will help to restore from a backup if database crashes somehow and data recovery becomes a very hard task. Database is connected to backend as well as some of the micro services. Reason being micro services like elastic search requires updating key-value store maintained by itself whenever CRUD operations are performed on database. Micro services can be connected to database as well as to other micro services if needed. There are a few more techniques like the 12 factor method that will help to keep local settings without conflicting server settings. 12 factor take care of many aspects of development like Code base, dependencies, configuration, build etc. Please refer to the below diagram for a better picture.
I hope my first Linked In post can be of certain use to my connections.
Thanks for going through the post,
Gladson