Cloud Native Fundamentals - Step 2

The First Step in Cloud Native Journey - Code Base Detailed

We looked at the 12 Factor Methodology to create Cloud Native Applications. Let us dive into each of the factor and what are the modern ways to implement it.

Factor 1 : CodeBase :

Each Cloud Native Application should have one and only one codebase

If an Enterprise Application there are multiple Code base , then each of them is considered a Cloud Native App and have to follow all the 12 Factor principles

A quick example of an Enterprise Application can be

• GUI - Contains FrontEnd, Admin Portal Etc
• Backend/ Middle Layer - Contains Core Logic and Database Communication
• Customisation - Contains Customisation or Integration Part
• Common Code - To be created has Libraries

Ideally each one of them can contain a separate code base and is called a separate Application

If there is a common code base being used in all of the application then it has be created has a library separate code and should be included in dependencies ( Factor 2 of Cloud Native Principle )

Even if there are many deployments or versions the code base has to be one and only one codebase.

Eg Enteprise Application 6.1.x , 6.2.x, 7.1.x, 7.2.x, 8.1.x

This is the biggest problem in Enterprise teams who end up splitting the codebase based on version. This is a wrong practise and hence a single codebase with versions should be preferred

Source Code Tools

The best preferred code base tool for a Cloud Native Application is GitHub, GitLab, BitBucket, AWSCodeCommit ,Azure Repos

The Main selection of this tool depends on the Business Model of the Application - On Prem, Hybrid Cloud, Opinionated Cloud ( Single Cloud ),Multi-Cloud

Any Selection of this tool is long term and has to be done with proper planning as this cannot be changed mid way without lot of disruption

People/Process

The Main part of this tool is the Maker and Checker Model, the person who approves or Merges the Code has to be different then the person who writes the code,

• Developers x : Commits the Code
• Merger 1 : Lead Merges the Code ( After checking all KPIs are met in new code) e.g Code Coverage , Blocker and Critical in SONAR scan, etc
• Merger 2: Approves the Code based on Long term Guidelines is followed e.g. Coding Standards are followed, can be reused (Optional)

If this Human process of Merging is done perfectly chances are there will be less bugs and smooth journey to Cloud Native Application is ensured.

Smaller teams end up having same person who writes the code also merges the code, leading to quality issues in the long run with lot of Technical Debts

Additional Code

Unit Test case are also considered as part of Code and hence should be checked in regularly with the same code base

Every Deployment Details can also be checked in as code and is helpful in Infrastructure as a Service scenario and GIT Ops ( Which will be a separate topic in itself )

Some of the additional points in code are Branching strategy etc ( which we will visit separately )

If you are using SVN or any other single CVS better to exit if you want to start with Cloud Native Application

#CloudNative #DevOps