Introduction

Completed100 XP
 2 minutes

Cloud-native apps represent a modern approach to app development, where

When designing cloud-native apps, many cloud architects choose to leverage Open-
Source Software (OSS) like Kubernetes and Docker, but turn to proprietary offerings
like Cosmos DB when the benefit is overwhelming. Because of this, cloud-native apps
make the end-to-end process of building an application easier, with a focus
on architectural modularity, rather than monolithic, all-in-one applications. You can
utilize the technologies that suit your skillset and situation, without being locked into
technology choices.

Scenario: Smart fridges, smarter service, at scale

We could, for example, start with creating a small inventory management app for the
fridges, so businesses can know what needs to be restocked, or potentially, have
items reordered automatically. It’s the nature of cloud-native apps to have loosely
coupled functionality, so we can be more agile in our design and don't need to
predict future requirements. Rather, we can extend the app if it becomes necessary.
Later, we can add functionality to the app, such as connecting to fridge telemetry
and onboard sensors.

Prerequisites
 A basic familiarity with Azure
 A familiarity with basic cloud concepts and terminology
 An understanding of cloud computing is helpful, but isn't necessary

Learning objectives
In this module, you will:
  Describe the fundamental structure of a Cloud Native App
 Identify situations where you should build a Cloud Native App

Next unit: What are cloud-native apps? What are

 5 minutes

The cloud-native approach allows you to build cloud-based applications where you choose
the components you want to use. Components, such as a database and a .NET Function app,
could be coupled together as a service, to form an isolated part of a system. For instance, you
might have an inventory service, an ordering service, and a payment service, each with their
own technology choices.

Additionally, cloud-native apps are modular in nature. You choose the cloud services and
technologies, and loosely couple them together as shown in the diagram. Cloud-native apps
often employ another pattern, called Microservices. Notice how each service has its own
technology stack, independent of what other services use, meaning you choose the
technologies that suit each individual service, rather than a one-size-fits-all solution.

With Cloud Native, we're leveraging many pre-built types of services or services with pre-
built infrastructure. So we can get scaling from Kubernetes or Azure Function Apps, and geo-
redundant data storage from Cosmos DB or Hyperscale for PostgreSQL.

So, while apps built on "microservices" in general share many of the same characteristics,
"cloud-native apps" can have parts of their tool chain where little to no custom code has to be
used to get advanced functionality or operational excellence.
Further, with different components loosely coupled together to create an application, you can
change technologies as required without rewriting the entire application. Such as with our
smart fridges, each service can be upgraded, deployed, scaled, and restarted with no impact to
other services, allowing for frequent updates.

Leverage technologies that you’re strong with

Most cloud-native services support a wide range of technologies. Kubernetes supports

You can connect a backend to your relational database of choice for one service, while also
using a NoSQL database and a pre-built analytics service when it’s a better fit for another
service. You can do it all quickly and simply, within the same overall cloud application.

Next unit: Using containers with cloud-

 6 minutes

Because cloud-native apps are made up of the components of your choice, you can easily
architect a solution that uses technologies you're comfortable with. For example, if Python
better suits your data analytics service, but your email service is more suited to using a pre-
built solution, the architectural modularity of cloud-native apps significantly simplifies
implementation. This even extends across different cloud providers.
For example, many cloud services, such as Azure Database for MySQL, allow you to develop
using the open-source versions of technologies that you’re used to, but have Azure take care
of administration and deployment responsibilities for you.

Architecting a cloud-native solution for Adatum

In our scenario, we can architect a solution that’s easy for a small team to develop but also
scales safely to thousands of devices. This is because cloud functionality eliminates many
development issues arising from a need to connect to large numbers of devices and process
data on demand. By using cloud infrastructure, pre-built services can be easily configured to
communicate with each other and autoscale as needed.

Later, if necessary, the solution can grow to accommodate new or updated products. In our
scenario, if a hotel chain ordering thousands of fridges needs extra functionality, you can
create an extra service with no downtime for existing customers.

Starting small

To begin, we could use a basic webapp for a management interface. A simple backend in the
cloud can relay messages from smart fridges to the webapp, which can then be containerized
and deployed to a Kubernetes cluster—so the number of containers can scale as needed. This
is represented in our image by the Node.js Express box relaying messages to our Webapp
Next.js box, which are deployed from our Kubernetes service.

This solution is easily connected to your database of choice, allowing a scalable, end-to-end
service to be up and running quickly.
Growing our application

Smart devices offer a wealth of connectivity and data options. Advancements in the IoT field
offer cost-effective options for gathering data and streaming it to the cloud. IoT cloud
services for smart devices are easy to connect, allowing you to stream telemetry data such as
fridge temperatures, power consumption, and water quality.

Developers can use cloud-services, such as IoT Hub and Stream Analytics, to develop cloud-
native apps with IoT integration. Since much of the groundwork has been done for you,
development time can be significantly decreased.

Because of the loosely coupled nature of cloud-native apps, for telemetry data you can
choose a different database solution that is more suitable for streaming data, such as Cosmos
DB. Rather than a traditional, relational database that might be more suitable for an inventory
service.

As the services are separated, your team can also develop and deploy an IoT service with no
impact on your existing inventory service, as shown in the image below.
Next unit: When to use cloud-native apps