Continuous Delivery - software-architectural topics

In my last post about Continuous Delivery was the focus on the delivery process. However in this post we will concentrate on the software and the necessary architectural requirements.

So the central question is, how to deliver new functionality as a software many times during a day without adverse effects. How is it possible that companies like Facebook despite major projects with hundreds of developers can manage this?

The first step in the praxis should be the system redesign from a monolithic application towards to split into small pieces (functions, components).
The components are separated and the communication is possible just via a clear API, like for example REST.


The second step would be the redesign of the underlying database. 
Encapsulating the access logic in an interface promotes a service oriented design. A distinction is made between an Application Database, belonging to one application, and Integration Database, shared by different applications and systems.


Avoid Server-side Session State
If short-time information are stored in a local cache of the server then we are talking about Server-side Session State and as such there are the particular instance fails the session is gone. For example during a deployment of new software version to this server instance.
Stateless services enable  a downtime-free deployments.

Keep backward Compatibility
This point is not so easy and it is very complicated to guaranty the compatibility after each modification of the system. Actually this means that the new functionality is co-exists with the old one.

Design for Failure
No system has got 100 percent availability. More important for the enduser is the impact of not functioning component. If one specific function fails, it should not cause the failure of the whole system. 
This is very crucial for continuous delivery concept, otherwise the risk of failure and its impact would be enormous.

Schema-less Database
Changes on the structure of database or its migration are in most of the time very complicated and risky.  The clear advantage is coming with NoSQL databases, or with migration running inside of the application and not in separated database migration scripts. Such scripts last too long and the migration would be not possible in the real-time.


Overall, the goal should be to reach the "Shared-Nothing" Architecture.  This architecture is defined through no direct references between two or many systems which enables a horizontal scalability and release deployment without down-time.