In my previous blogs I have talked a lot about MSA (Microservices) and CNA (Cloud Native Application). Let me recap the main differences to both before going further.
MSA is the ability to break an application into a set of fine-grained components from a business perspective. The main architecture principles of MSAs are:
- Highly loosely coupled
- Smallest deployable unit that can operate by itself, i.e. it cannot be broken anymore.
- Serves a discrete business need
- Acts as a single source of truth for a business feature
- Decentralization of enablement as it owns its destiny, data, storage…
To get more details on Microservices you can read more in blogs/webinars I have written or presented: Software Development, Microservices & Container Management – Part I – Microservices – Is it the Holy Grail? and Cloud Native Applications in AWS supporting Hybrid Cloud – Part 1
CNA is an MSA but with the ability to leverage the underlying cloud, natively enabling better event handling, such as a change in the load or change in a backing service. The main architectural principles of a CNA app are:
- Portability: even though it is consuming the cloud natively, it is portable between different cloud platforms
- Highly agile: enabling versioning and different deployment strategies such as A/B testing and Blue/Green, providing high flexibility and agility in implementing business requirements.
- Enabling digitalized business by implementing event driven architecture principles
As highlighted, CNA is an implementation of MSA in the cloud. CNA doesn’t focus on the runtime as the MSA; it is more targeted for delivering agility in the business because of high SLA.
So what is required in providing a CNA platform?
- It must be a platform which can run on any cloud
- It must enable integration with the underlying cloud services
- It must enable auto-scaling on the level of the platform as well as on the level of the CNA application
- It must enable integration between different CNA and external services
- It must enable calculation for resource consumption per app or tenant
- It must enable multi-tenancy
How does SUSE Cloud Application Platform deliver such principles and more in Azure Cloud?
SUSE Cloud Application Platform is a cloud native application platform which offers app runtimes based on the application characteristics (application programming language, application manifest, etc.), using a buildpack. From a developer or operator perspective, buildpacks are like and builders of the code. A buildpack may target only grouping files or/and creating artifacts and deploying the artifact in the target platform. It enables the developer to just focus on coding and programming. Here’s an example:
- We have two developers who are developing an application using Java. They both want to just write code following MSA and CNA design principles and 12-factor best practices integrating with each other.
- Both applications require a database running as backing service on Microsoft Azure. Both developers create the Spring application with all the required configurations for accessing the database. Maven profiles are used to support different backing services. One application requires PostgreSQL and MySQL while the other supports MySQL and MSSQL.
- Each application has a manifest file which is used by a buildpack when deploying the application to SUSE Cloud Application Platform running in Azure using the command ‘CF push’ or using the Stratos UI.
- The operator provisions and binds the required databases to both applications using the ‘cf create-service’ and ‘cf service’ commands or using the Stratos UI.
- The operator can at any time switch or migrate the database(s) and bind it to the app instances.
- Both applications are now available for testing in the cloud and everyone is happy as the developers didn’t have to learn about Azure CLI and Azure platform and the operator didn’t have to understand the code or even communicate with the developers for switching a service 😊. In other words, each person is focusing on his/her role and doing what he/she does best – the developer is writing code and operator is administrating, governing and controlling environments.
SUSE Cloud Application Platform goes the extra mile and enables you to link and consume services from other cloud providers such as services in Microsoft Azure, AWS or GCP in our example, which enables multi-cloud and hybrid cloud.
SUSE Cloud Application Platform supports all CNA principles discussed earlier and facilitates services provisioning and management in the cloud using the underlying cloud native language as well as integrating different cloud platforms. This helps enable digital transformation using the magic of the open service broker API.
I hope that provides a good overview of MSA and CNA, as well as how SUSE Cloud Application Platform in Azure enables building multi-cloud apps.
For details of how to deploy and run SUSE Cloud Application Platform in Azure, please download the instructions in Part 2. It is very simple as we are going to use Terraform which enables auto provisioning of the E2E solution😊.