Cloud Native Applications in AWS supporting Hybrid Cloud – Part 1

Let us talk first about what is cloud native and the benefits of SUSE Cloud Application Platform and AWS when building cloud native applications.

So, what is a cloud native app?

Usually people mistake a cloud native app with a 12 factor app and that is not correct. 12 factor is a set of good development best practices which should be in place when developing a distributed application involving many teams/vendors or that requires fast, agile development cycles.

How does that differ from developing a cloud native app? As the name implies, cloud native apps are applications built natively on a cloud platform. What exactly does that mean?

First let us talk about the requirements of a cloud native application:

1. It needs to meet the target load, with a high SLA.
2. It must adapt to variable loads. Load is not easily predictable as may happen when the application is available for public usage, similar to YouTube or Facebook.
3. It may be a pay as you go, so it must be cost efficient.
4. It must be responsive to changes in requirements and have a fast time to market.
5. It must enable smooth integration with other apps, services, and APIs, with no restriction to enable digital transformation. Put simply, this is the ability to let different business contexts interact together and learn from each other and be highly responsive. If you want more details, you can read about the interview I did for digital transformation Digital Transformation: An Interview with Rania Mohamed (Global Services)
6. Application development time must be extremely fast without impacting the quality.
7. It must be highly integrated with the underlying cloud service, to enable native
8. It must be portable, even though it is leveraging the underlying cloud service, it must allow the ability to be portable across different clouds.
9. It supports and enables polyglot development languages and methods.

Now that we understand the CNA (Cloud Native App), let us discuss how is that related to MSA (Microservices Architecture).

MSA is an architecture design principle which mainly emphasizes breaking down the application/problem into smaller chunks which are loosely coupled from each other. Such chunks are called microservices. So simply think of a microservice as the smallest standalone service that can ever live independently by itself. Ok but what are the benefits of MSA and how is it linked to CNA?

MSA main benefits are:

• Efficiency of scalability as just the required service can be scaled and not the whole application or service or module.
• Enables a high SLA as now we have a set of microservices that can operate independently without impacting another microservice or app or service if it has downtime.
• Improves development productivity as it enables and supports agile development.

So is MSA another technical term for CNA?

Simply, no. You may have MSA application which is not CNA, but it is very hard or I would even say impossible to have a CNA which is not designed as an MSA. Because MSA fully supports  CNA principles, it achieves some of the main important principles of CNA such as handling of variable load in a very cost efficient way as well as supporting increased development speed and productivity.

Here is the main question — how is SUSE Cloud Application Platform together with AWS help with CNA?

SUSE Cloud Application Platform is a cloud native application platform that offers application runtimes based on the application properties, defined using a buildpack. It enables the developer to really just focus on doing what he/she is best at, which is writing code. Let me put on the developer cap (which I am always honoured to put on and would never put it down) and explain the steps I go through if I am using SUSE Cloud Application Platform:

1. I am a Java developer so I just focus on writing my Spring MSA and the APIs I consume and offer.
2. I need a database so I write down in Maven and in the Spring initialization the required configurations for the supported database. I choose to support PostgreSQL and MySQL.
3. I then create a manifest file which used by a buildpack and then I do the CF push, to push the application into SUSE Cloud Application Platform on AWS.
4. Then I can provision the database using the SUSE Cloud Application Platform marketplace, which uses the AWS Service broker, to provision a service instance and then bind it to my application.
5. Voila, I have my application ready to test in the cloud.

So as a developer, I really didn’t get into understanding the AWS cloud or even how to set up a database. I just focus on writing code and my application needs and the platform takes care of the rest.

Now if my application wants to integrate with AWS SQS, all I need to do is to define such dependency and let the service broker together with SUSE Cloud Application Platform handle the load and the binding of the service instances to my application instance.

So in simple terms, SUSE Cloud Application Platform enables native cloud application development as the it will be able to provision and manage a service instance in the cloud using the underlying cloud native language. How does that happen? The magic words are service broker, using the open service broker API.

By using SUSE Cloud Application Platform and AWS, services can be automatically provisioned based on the load on the app workload. Here is what happens during the development lifecycle of an MSA or an app:

1. Developer decides on the pre-requisite for his/her app, for example the required services and runtime from the underlying CNA platform, regardless the target cloud platform.
2. Developer chooses the technologies to be used in developing the application.
3. He/she develops the app and uses CF push to push the application into SUSE Cloud Application Platform.
4. SUSE Cloud Application Platform offers a marketplace and service catalog showing all the available cloud services based on the configured service broker(s). Think of the service broker as the link between the cloud(s) used by the platform and SUSE Cloud Application Platform. We can have as many service brokers as we want as long as they support Open Service Broker API standards. SUSE Cloud Application Platform highly enables and supports hybrid cloud native applications.
5. The developer or the operator uses the CF CLI to provision the required services in AWS using the configured AWS Service broker. They can also use SUSE Cloud Application Platform’s Stratos UI to provision the instance and bind it to the pushed application instance.

The following picture depicts the marketplace embedded in Stratos which displays all services offered by the configured service brokers.

In my next post , I’ll discuss two ways to get SUSE Cloud Application Platform installed on AWS and configure the service broker:

• Use the AWS Quick Start for SUSE Cloud Application Platform on Amazon EKS to stand up the platform on a managed k8s cluster automatically
• Build it using Helm Charts.