Cloud Native Apps

This is a guide on cloud native apps.

Check out Audible on Amazon and listen to the newest books!

 

Cloud Native and Its Principles

So let's first try to understand what is Cloud Native Applications. Cloud native applications are those applications that Utilize a cloud computing model. It's an approach that helps us to build software applications as micro services, and then run them on a containerized and dynamically orchestrated platform in order to take benefit of cloud computing model. Apart from that second essential element that we need to focus on is cloud native Uses containerization, where each part whether it is application, processes, dependencies, are packaged in its own container. When we use containerization, it facilitates with reproducibility, transparency as well as resource isolation.

We need to also know that cloud native applications Can be dynamically orchestrated because containers are actively scheduled and they are managed to optimize resource utilization. And fourth essential element of cloud native application, is applications are segmented into multiple micro services. And this significantly increases the overall agility as well as maintainability of applications. Now, what all are the Fundamental Cloud Native Principles? First principle as it is Designed for automation, where cloud native apps can be invariably orchestrated in some way in order to automate deployment and operations like scaling as well as self healing. Then comes second principle, which says that cloud native applications are built using stateless components wherever possible.

Third is it adopts managed service approach, which provides all sorts of functionalities that relieves developer from back end software or infrastructure. Fourth principle is it follows defense in depth rather than focus on perimeter security and finally, cloud native always utilizes evolving architectures. Now what all are the benefits of using cloud native applications? First benefit is fast release. Whether it's with build automation, test automation or deployment automation, the software delivery pipeline ensures that product bills are made faster and more predictable. Then comes second advantage which is better customer experience because it improves better customer experience with its capability to enhance and come up with new features faster and keep iterating continuously.

Third advantage is simplified management, when we talk about cloud native, we don't need to worry about provisioning cloud instances or configuring network or allocating storage. All that is taken care implicitly. And another benefit is related to cost. Cloud native applications helps us to reduce cost because it works with pay per use model. Apart from that there are other advantages that we can realize, first is improved reliability. Because applications that are built using cloud native principles are tolerant and resilient. Apart from that cloud native application also helps to avoid vendor lock-ins. And finally, from perspective of scale, cloud native applications provides better accessibility because you have access to auto scaling and load balancing feature of cloud platform. But yes, there are certain disadvantages as well.

Let's list certain disadvantages of cloud native. First, as it is not portable using native cloud services from any provider can bring performance and cost efficiency, but more native services you use, you lose portability of your application. And come second disadvantage, localized applications. We know applications that are localized for specific cloud platforms are not easily ported to other cloud platform. And you end up rewriting or refactoring entire code. And third disadvantage is demands a business culture. If you want to adopt cloud native applications, you need to cope up with the pace of innovation as well as derive the right cultural change in enterprise.


Cloud-native Architecture

Let's try to understand cloud native architecture derived by Cloud Native Computing Foundation. And we'll do that using a diagram which is currently displayed on the screen. At the leftmost side, we have Cloud native scheduling. Which takes responsibility of scheduling the jobs that need to be executed. Then you have Cloud native execution runtime.

Which is required in order to provide runtime environment for your applications. Cloud native execution runtime is a pluggable component which is derived using pluggable architecture. You can use any OCI-compliant runtime without having to change or re-architect your application. And then comes two essential components. Which are CSI, which makes it easy to adopt GlusterFS for file-based workload, alongside Portworx, REX-Ray, or Ceph. And second is CNI which is cloud native interface that allows different tools to provide overlay network to multi-host container deployment. There are few of them like Weave, Contiv, Docker, or even Big Switch. Apart from that we have others which are indicated using etc., which means that your REX-Ray and Contiv is dependent on etc.

And finally, all the components of cloud native architecture must be monitored. This is the reason at the top we can see Monitoring. Now what all are the essential factors that we need to keep in mind that motivates to have transition to cloud native? First motivation is Componentization. One of the main reason of using services as component is that services would be independently deployable. Second motivation comes when we talk about Achieving business capability. Microservices approach is to divide and split up different components into services, which are organized around business capability. And this helps us to aim to achieve business capability using independent services.

Third motivating factor is cloud native is more Product-focused rather than project-focused. And fourth motivation is Endpoint and pipe-based communication keeps your components decoupled and as cohesive as possible. Apart from that, Decentralized governance is also one of the motivating factor to have transition to cloud native. Because decentralized governance gives teams the freedom to develop software component using stack of their choice. Apart from that, there are three other motivating factors. Where first is Decentralized data management. Decentralizing data across microservices may have certain implications from perspective of updates, but they provide consistency. Next is Need for infrastructure automation.

You'll come up with many products or system being built with microservices and they are built by team with extensive experience of continuous delivery. Team building software this way may be expensive, rather we have to focus on more and more automation. And finally, one essential factor that motivates transition to cloud native is its principle of Design for failure and changes. We know that any service call could fail due to unavailability. Microservices which is based on cloud native would expect to see sophisticated monitoring and logging set up for each individual services. Like dashboard, showing up and down status, and a variety of operational and business-relevant metrics for applications, resilience, and monitoring.

Now let's quickly go and Differentiate Cloud Native and SOA, identifying essential factors. First is Scope, service-oriented architecture has an enterprise scope, but when you go with cloud native architecture, it has application scope. From perspective of Reusability, when we go with SOA reuse of integration is the primary goal and it is at enterprise level. But in cloud native architecture, creating a component that is reused at runtime throughout an application results in dependencies that reduces agility and resiliency. Then comes third which is Synchronous call. In cloud native applications synchronous call introduce real-time dependencies. Whereas in case of SOA, it is all about synchronous call to services after getting endpoint from registry.

And finally, Data duplication. In case of service-oriented architecture or SOA, your data is less redundant as compared to cloud native. Because cloud native services will have their own data. Apart from that there are four other Factors that we need to use in order to Differentiate Cloud Native and SOA. From Communication perspective, in cloud native architecture E-services developed independently and they will have their own communication protocol. Whereas in case of SOA, it can be shared. Interoperability, SOAs are more open to heterogeneous messaging protocols. It means they use messaging in order to provide interoperability, whereas cloud native, lightweight messaging protocols like HTTP over rest.

Now what about Service granularity? Cloud native architectures are made up of highly specialized services, each of which is designed to just do one thing. It means cloud native are more granular in nature as compared to SOA. And finally, Speed. By leveraging the advantage of sharing common architecture, SOA will simplify development and troubleshooting. But SOA operates more slowly as compared to cloud native. So you need to first understand the architecture of cloud native. Then identify principles and compare it with service-oriented architecture in order to identify motivations that may motivate you to migrate to cloud native.


Migrating to a Cloud-native Architecture

Now let's try to understand what all are the problems with monolith applications. And first problem is Difficult to extend because level of coupling will be high. Apart from that, level of complexity that will be involved in adding new functionalities on top of existing applications are next to impossible. Second, Downtime. When you go with monolith, you may face downtime in case if traffic increases.

Third problem with monolith is it is Difficult to manage security and compliance. Cost would be high, specifically when you want to maintain in long run and you have Limited upgradation to new stacks. Now we are aware about problems with monolith. Now let's try to identify Reasons to Migrate to Cloud-native, and first reason is cloud-native applications are Lightweight. They are a collection of independent and autonomous services which are packaged as lightweight containers. Second reason is Loose coupling. When you have less coupling, reusability will increase. When you use cloud-native, services that belongs to same application discover each other over application runtime. And that is only possible if services are not dependent on each other. And third is Service independence itself.

Services are considered as persistent and durable objects. They follow different patterns in order to ensure higher availability and resiliency. We need to ensure that we select stateless over stateful in order to keep service independent. Apart from that, there are two other critical reasons that will guide us to Migrate to Cloud-native from monolith, and first is Reusability. One of the principles of cloud-native is to ensure that they're discrete and reusable components, and they're specifically designed to integrate into any cloud environment. And finally, it's all Automation, cloud-native applications are designed keeping in mind automation. They play well with the concept of infrastructure as code.

Now we'll go through the process that need to be adopted to Migrate to Cloud-native. Where first step is always to Prepare plan to migrate to cloud-native. Where you will come up with a transformation mechanism, identifying the issues, and coming up with suggestion of eliminating those issues by selecting right approach. Second step is plan to have Transition from silos to DevOps. Because DevOps comes up with principle of continuous integration and continuous delivery. Third step is to plan how do you Migrate from your existing waterfall model to continuous delivery in order to get benefit of automated quick delivery of products. And fourth step is Decompose monoliths. In short, you have to break a monolith application into components that are independent and which can be deployed on cloud.

Next you have to Design service collection. Specifically when you are developing an application architecture for cloud, it must be built to interact with complex and widely distributed systems. These systems must support multiple loosely coupled applications. And this is the reason why we need to design service collections. Next step is to Decouple and decompose data. It's not only about applications or services. You need to also work with data model. It is necessary to decouple the data in order to ensure that data is independent of other and every service has its own specific data model. And finally, let's try to list essential Migration stages. And we'll do that using a diagram which is currently displayed on the screen.

Assuming that you have Non-cloud application, you want that to be Cloud-ready, you need to follow certain practices. Where first, ensure stateless processes, adopt principle of one code base one application, use port binding, use backing services, use logging, as well as dependency management. Now your application is Cloud-ready. Next transition is to a stage called as Cloud-friendly, where our focus is on configuration, credential and code, design, build, release, run, take care of all the administrative processes and ensure that they are disposable. And then comes the fourth stage, which is Cloud-resilient, where you'll focus on fault tolerance, ensure components are cloud-agnostic, and adopt proactive failure testing.

And final stage is Cloud-native, which uses microservice architecture, adopts API first principle, and focus on authentication and authorization. So depending on the need, you can plan what all are the existing issues in current deployment, and what benefit you will get once you deploy it as cloud-native. And yes, you need to focus on migration stages carefully.


App Principles for Microservices 

There are many different principles which guides developers in order to come up with scalable and highly performant applications. One of those principles are categorized as 12 factor app principles, where each factor plays essential role in order to ensure that your applications are independent and resilient. Let's start with the first factor which is codebase. As per 12 factor app principles, when we talk about codebase, you need to ensure that you have one codebase tracked in revision control for many deploys.

Then comes dependencies, which you have to explicitly declare and isolate dependencies. Third factor is config, means you have to store configurations in an environment. Fourth factor is backing services, which is all about to treat backing resources as attached resources. And then comes build, release, and run factor which is all about strictly separating build and run stages. Next is processes factor where we need to execute apps as one or more stateless processes. And then comes port binding, which is all about how you will be able to export application. Guideline as per 12 factor app principles is export services via port binding. Then comes concurrency where 12 factor app principle says you need to scale out via process model. Next is disposability, which is all about how well you are able to manage components. And you need to focus on fast startup and graceful shutdown.

Then comes one of the very important 12 factor app principle, which is dev/prod parity, which means that you have to keep development, staging and production environment as similar as possible. And then comes 11th factor which is logs, where you need to treat logs as event streams and then process them accordingly. And final 12th factor app principle that is displayed in the table currently visible on the screen is admin processes, which runs or administrates management task as one-off processes. Now why do we need to adopt 12 factor app principles? For that, let's go ahead and see benefits of using 12 factor app principles. First benefit is, it promotes focused use of declarative formats for automation setup. Apart from that, it also provides clean contract and helps to maximize portability between environments.

Third benefit is, it is considered suitable for deployment on modern cloud platforms. And fourth important benefit is, it enables continuous deployment for maximum agility. And finally, it helps you to scale up without major changes in configurations. Now we are able to understand what are the benefits. Now let's go and take up certain scenarios in order to discuss about how do we use 12 factor app principle. And we'll do that using diagrams. As the diagram indicates, your entire application is divided into three layers. You have front end, you have back end, and you have persistence, which is the storage. There are three front ends. First is game client, which might be written using C++. Then you can have website which might be written using HTML or React. Then you have Blog + CMS, prominently written in HTML plus JS.

Now when you are adopting 12 factor app, you'll find that each front end has smart endpoint for corresponding back ends. And none of the front end service is dependent on back end service of other front end. Apart from that, if we have look over persistence, you will have specific persistence for each kind of service. For example, in the current diagram we can see game client. For them backend is designed using game server. For websites, it is designed using React renderer. And for managing user authentication and authorization, we are using user accounts. And then comes microtransaction which is again written using Node.js, similar to React renderer. But these are independent services, they have their own database. And finally, in the same diagram, we can see Blog + CMS, which is build using HTML and JS, and you have a specific back end service for that.

So for each client we have independent services, so there is no chance of conflict with other service. And each service will be using their own persistence, so transaction management will also be simplified. As we can see in the diagram, we have game server using Redis, user account is using Mongo DB. And microtransactions and WordPress are using SQL. And finally, let's take up another scenario called signup. Now there are two different kind of services for which there are two different kind of interfaces. Let's try to understand it using a diagram which is currently displayed on the screen. You'll have users, and users will use Signup API in order to signup and get benefits of the services. We have Asynchronous broadcast, which will be made to email verification service, and friend discovery service to identify whether user is right or not.

And they're authorized to access services or not. Once signup is done, it will be role of user metadata service and password service to facilitate signup process. So we can clearly see that Signup API and asynchronous broadcast are completely decoupled from each other and they store their own configuration in environment. It means they have adopted certain principles of 12 factor app.


Design Patterns for Microservices

Before we start with microservices design pattern, let's try to understand what all are the elements of design patterns and their roles. When we define a design pattern, there are following elements that must be specified. First is the problem itself. It means what is the problem that we are facing? Followed by forces, which indicates what might have created those problems. And then comes the solution, which indicates what can be the right solution for the problem.

Apart from that, we need to also specify certain examples that elaborates that problem and solution. And finally, the resulting context because you may have number of different solutions. You need to identify the right solution, and that you'll be able to do by understanding the benefits that you will realize as a result of resulting context. Now when we talk about microservices design patterns, we have to classify it into multiple groups. First is application architecture patterns, where you'll find monolithic architecture and microservice architecture as two choices. Assuming that we have adopted microservice architecture, we'll go to second classification, which is decomposition patterns. Objective is to provide you guideline and solution to decompose monolith into microservices by using various different techniques like decompose by business, decompose by subdomain, as well as on basis of service utility.

Then comes third, which is refactoring pattern. Refactoring pattern applies to microservices in order to guide in what way factoring need to be done. It can be coming up with anti-corruption layer pattern to refactor or strangler application for refactoring. And fourth classification is all about data management. How do you manage data for your microservices, whether you'll go with shared database or you'll go with database per services. Apart from that, API composition, CQRS, and event sourcing also need to be identified as patterns of data management. Apart from those four classifications, we have transaction management patterns, where in case of microservices, it is all about transactional messaging, where you need to focus on patterns like transactional outbox, polling publisher, or transaction log tailing. Testing microservices is essential.

There are various different patterns for microservice testing. It can be service component test, it can be consumer driven contract test, or it can also be consumer-side contract test. And then comes patterns of deployment. You may have patterns like service instance per host, service instance per VM, service instance per container, or even serverless deployment pattern. Then comes service discovery. Once service is published, it must be discoverable, so there are various different patterns which falls under service discovery classification. It can be client-side discovery, server-side discovery, using service registry, self-registration pattern, or third party registration patterns. Now we'll talk about those patterns which are specifically used for getting quality of service from microservices.

And first is reliability, where we can use circuit breaker pattern, external API pattern, which provides us capability of deriving a proxy in order to enable access to microservices. You can use API gateway pattern or back end for front end pattern. Now let's go and list architectural patterns. There are two architectural patterns, first is Monolith architecture. Second is Microservices architecture. Monolith architecture is all about an architecture where you have high level of coupling of various different components, whereas microservice architecture pattern talks about decomposing monolith into independent services. Now let's try to understand monolith architecture using a scenario, and that we will do using a diagram which is currently displayed on the screen. Now the diagram indicates that you have four essential components.

First is the browser, which will be used by client. Once client uses browser to send request, it will be intercepted by web server, who has capability of intercepting only static content. If a request needs dynamic content, it has to execute some service. Which is bundled in WAR or WAR package, which contains storefront UI, accounting services, shipping services, inventory services, or you can say business services which will be required in order to serve the request. It is all bundled in a single WAR file and deployed in Tomcat application server, and your WAR, which contains components, will have access to database. This is a critical example of monolith architecture. Now when we go with microservices architecture, you'll find that you don't have one single container in which everything is bundled.

Rather, you have independent services. Let's try to understand it using a diagram which is currently displayed on the screen. At the bottom, you have independent databases, shipping database, inventory database, account database. If you compare it with the monolith architecture, where you have only one database, in current architecture we have three databases. One database for each service, like shipping service will use shipping database, inventory service will use inventory database, and account service will use account database. Request can get generated from browser or mobile app, which is indicated in the diagram at the top. Your browser will create the request and it will send using REST API to appropriate service.

Same goes with mobile app, it will use REST API, request will be intercepted by API gateway, and API gateway will delegate responsibility to one of the services. So you need to understand various different patterns that you can use in order to take care of certain problem whose context and solutions are already defined in patterns which are part of microservice pattern catalogue.


Containerization in the Cloud

 Let's try to first differentiate between containerization and virtualization. And to do that we'll be using a diagram which is currently displayed on the screen. At the left, we have containerization where we'll have physical host server. On top of physical host server we'll have host operating system. And on top of operating system we'll have containerization engine. There are many containerization engine that we can use.

Let's focus on the containers which are created and managed by containerization engine. If we carefully see Container A and Container B it has apps, all the bin libraries, and its own OS. In short, containerization engine supports multiple different images which are bundled with images of multiple different operating systems. Container B is bundled with MySQL app and bin and libraries along with its own operating system. Now, let's go to the diagram at the right, which represents virtualization. At the bottom we have host server which is nothing but physical server. On top of that, we have operating system and instead of containerization engine which is lightweight, we have hypervisor which is heavyweight. On top of hypervisor, we have multiple virtual machines where each virtual machine can have its own virtual OS.

They are bundled with App, all the bin and libraries as well as What is our operating system? As indicated in the diagram, your current host is having three different virtual machines, Virtual machine A, Virtual machine B, and Virtual machine C. Now let's try to understand fundamental difference. Difference is, once resources are allocated to virtual machines, they cannot used by other virtual machines even if they are idle. But when we talk about containerization, it's lightweight. So resource usage is dynamic, it is allocated and re-allocated dynamically in order to utilize existing resources. So what all are the benefits? First benefit is, it facilitates consistent environments, by giving developers ability to create predictable environments that are isolated from other applications. Second benefit is, it can run anywhere.

Once you have containerization engine on any architecture, you will be able to create and manage containers. And this is the reason why we say that containers can run virtually anywhere, whether it is Linux, Windows or Mac operating system. Third benefit that we get when we are using containers in cloud is isolation. Containers virtualized CPU, memory, storage and network resources are at operating system level. Providing developers with a sandbox view of OS logically isolates it from other applications. And now let's go ahead and try to list benefits of virtualization and containers. We will compare benefits of container and virtual machine on basis of four characteristics. And that we will do using a table which is currently displayed on the screen.

First characteristics is consistent runtime environment. Both provides consistent runtime environment whether it is container or virtual machine. Application sandboxing we can use container or virtual machine, but what about small size on disk? Virtual machine need to be pre-allocated resources containers occupies small size on disk. What about overhead? When you are using container, your overhead is in check, Virtual machines will not have check over Low overhead. And finally, let's try to take an example to understand how containers are used. And that we will do using a diagram which is currently displayed on the screen. We have application container and cloud services at the top. In short, application container is deployed in cloud services.

And whenever request is there, request will pass through load balancer and will provide access to applications which are running in container engine, facilitated by Docker in current case. So we have Java SE app in its own container, Node JS app in its own container and any other Tech-X app in the third container. You need to understand the benefits of using containers when you compare it with virtual machine and use containerized environment facilitated by cloud to build your cloud native or microservice based applications.


Container Management Platforms

 Let's go ahead and list certain container management platforms which are provided by cloud providers. In short, you don't need to install, configure container management platform. It comes as a service provided by cloud providers. Prominent container management platforms are Amazon Elastic Container Service which is called as ECS. Then you have Amazon EKS which is Amazon Elastic Kubernetes Service. Then you have AWS Fargate, which provides you serverless Compute Engine.

Followed by Google Kubernetes Engine popularly called as GKE. And Azure Kubernetes Service called as AKS. The first question that comes to our mind is why to use hosted container managed systems? Let's go ahead and find the reasons of using hosted container managed systems. First, it helps us to maintain templates for containers, which can be reused. Helps to adapt and expand existing governance models and practices. It also conform to security policies and standards of the hosting environment. And finally, it simplifies capability to integrate with existing DevOps environment. Now, we'll take up an example. Kubernetes is a container management system which comes hosted on cloud. Apart from that, you can have your own installation and configuration of Kubernetes.

Now, let's try to understand how Kubernetes orchestrates and manages containers in cloud. You'll have your application that you want to deploy. To deploy, you can use container orchestration engine or container management engine called as Kubernetes. Using Kubernetes you can create deployments for your data center or for Google Cloud Platform or for any other cloud. Now, there will be no change required in configuration of applications. It will be the responsibility of Kubernetes to create appropriate deployment for specific environments. Now, after understanding role of container management system like Kubernetes, let's go and see container management lifecycle, which always starts with first step that is build for which you need container builder.

Then comes store, you need container registry, then comes run. In short now you are creating containers with optimized operating system. And then comes orchestrate where Kubernetes engine will take care of orchestrating containers and making them available for application deployment across diversified environments. So, once we have decided our cloud provider, if we want to adopt cloud native and containerized application management system we can go ahead and select one of them. But yes, we need to keep close eye on lifecycle to see what is the status of containers in containerized environments.


Deploying a Containerized Application

Now, let's go ahead and first move to ECS dashboard of Amazon Web Services. To do that, we'll sign into our AWS account and once we are there on AWS Management Console, on the top Search text field, we'll write ECS. After writing ECS, we'll get Elastic Container Service as one of the option. We'll click on it. Once you'll click on it, it will show you all the clusters which are currently created.

[Video description begins] In the AWS management console, a page for New ECS Experience opens. It has a left pane with the following options: Amazon ECS, Clusters, Task Definitions, Account Settings, etc. Clusters is selected and a view for it is open in the center. [Video description ends] Let's go ahead and select one of the cluster. To select the cluster, we'll click on the hyperlink. It will take you to a page where it will show you what is the current status of your cluster. [Video description begins] The following information about the selected Cluster is displayed: Cluster ARN, Status, Registered container instances, etc. At the bottom, the following tabs are present: Services, Tasks, ECS instances, etc. The Services tab is open. [Video description ends]

Now, we need to create task definition in order to ensure that we are able to specify Docker enabled containerized application. To do that, we'll go to left navigation panel and we'll click on Task Definitions. [Video description begins] The Task Definitions view opens in the centre. It has a table with the following columns: Task Definition and Latest revision status. [Video description ends] Once you'll click on Task Definitions, it will take you to a page where it will display all the existing Task Definitions. Apart from that it will also provide you a button captioned Create new Task Definition. We need to click on it to start the wizard that helps us to create new task definition. [Video description begins] A page titled Create new Task Definition appears. It has two steps. Step 1 is: Select launch type compatibility. It has two options. Fargate is selected by default. [Video description ends]

First it will ask us to select the launch type compatibility we'll keep default that is fargate and click on button called Next step. Now, we have to specify Task Definition Name. [Video description begins] Step 2 is: Configure task and container definitions. It has input fields for Task Definition Name, Task Role, Network Mode, etc. [Video description ends] After specifying a name we have to select Task Role we'll select one of the roles that exists. We need to specify task size we'll select 2GB of Task Memory and one virtual CPU. Next is to add container and here we have to be careful because we need to add Docker enabled containerized application. We'll click on Add container.

Once you'll click on Add container, [Video description begins] A pop-up titled Add container appears. It has input fields for Container name, Image, Memor Limits, etc. [Video description ends] it will ask you to specify name of the container, after giving a name, you need to specify the Image where you have to specify the repository URL followed by your application colon tag which is latest. You should not forget to do port mapping. Let's specify port mapping as 8080 for the current container. After specifying Port mapping we'll click on the button captioned Add. Once you'll click on the button captioned Add you'll find that under containers it has added one container. We'll scroll down and we'll click on Create button. [Video description begins] A page titled Launch Status appears. [Video description ends]

Once you'll click on Create button, you'll find that it creates the task definition, along with that it also creates CloudWatch Log Group. We'll click on View task definition button in order to move to task. Now, our next objective is to ensure that we are able to configure load balancer. To do that, we need to create a service. To create a service, we'll go to Actions drop down button and click on it. Once we'll click on it, it will provide us an option called Create Service we'll click on it. Once we'll click on Create Service again it will take us to a page where we have to create the service. [Video description begins] A page titled Create Service appears. It has four steps. Step 1 is: Configure services. [Video description ends]

We'll select launch type as FARGATE, we'll give a service name after specifying service name we'll give number of tasks. Let's give number of task as 2. After specifying Service Configuration details you will move to deployments will return the deployment to be rolling update. Task tagging configuration will retain whatever is default and click on Next step button which is there at the bottom right. Now, you have to select cluster VPC, let's select default, [Video description begins] Step 2 is: Configure network. It has input areas for Cluster VPC, Subnets, Auto-assign public IP, etc. [Video description ends] you need to select at least two subnets. After selecting subnets, you need to move to Load balancing and select type of load balancing, you want to facilitate.

We have selected Application Load Balancer. After selecting Application Load Balancer, you can select load balancer name. We have httploadbalancer configured, so we are selecting the load balancer behind which we want to run the container. Now, once you see container to load balancer, you need to click on Add to load balancer and specify load balancer details in order to ensure that you are able to run a Docker enable containerized application on an Amazon ECS cluster behind the load balancer of your choice.


The Advantages of Cloud Analytics for Business Data

Bringing your business analytics to cloud will facilitate you with cloud specific capabilities of ensuring availability and elasticity. Now, let's try to understand, why do we move our analytics to cloud? When we move our business analytics to cloud, we will be able to use cloud resources that helps us to analyze data. Apart from that, cloud also helps in streamlining business intelligence processes, by providing you certain applications in order to quickly get real time or persistent data to make it part of your analytics.

Third, it provides advanced analytical tools in form of software as a service. And finally, cloud analytics provides on-demand real-time analytics. Let's try to understand how cloud analytics works using a diagram, which is currently displayed on the screen. Now, assume that you have your data which is present in on-premises. You'll have users and you will have on-premises data sources. All the analytics components are there on cloud. At cloud we have three computes, first integration platform and services, second analytics data stores, and third BI and analytics platform and services. Your integration platform and services can connect to on-premises data sources to get data from there, or it can also connect to data sources which are deployed on cloud.

Now, when we talk about getting data from on-premises data sources to cloud analytics, there are two components which can connect and get data using data ingress. Those components are integration platform and services and BI and analytics platform and services. But yes, all the communication will happen through secure gateway. Now, once your data is present in cloud analytics components, you'll be able to build robust analytics using on-premises or cloud data sources. We need to ensure that all the movement of data is always through secure gateway. Now, let's go and classify cloud analytics types and it heavily depends on deployment model.

First is public cloud analytics, which is cheapest way to conduct cloud analysis, because infrastructure costs will be split among multiple cloud tenants. Then comes private cloud analytics. In this particular case, you need to have enhanced control over IT infrastructure to meet your data compliance or data security objectives. And third is hybrid cloud analytics, where you'll be able to use public cloud and private cloud analytics capabilities. You'll find that whenever data regulatory requirements need to be met, better is to keep data in private cloud analytics. Else, you can keep it in public cloud where you are able to share the load as well as you are able to cover huge amount of data present in enterprises.

Now, what all are the benefits that we realize when we go with cloud analytics? First benefit, cloud provides scalability in order to meet your demand. Second benefit is security. You'll find that most of the cloud providers are now following appropriate guidelines in order to apply right level of security on your data as well as on analytics. Third is data availability. Most of the cloud providers guarantees four nines of service availability. Now, with high availability and fault tolerant systems that are set up in cloud, there is near zero possibility of your analytics solution to be disrupted in case of unplanned downtime due to power outage, natural disasters, and others. And finally, data accessibility.

Cloud provides you a web based interface for your data analysis, and helps you to get insights to any device that is connected to Internet. Finally, let's take up an example of cloud analytics. There are two classical software as a service. First is PowerBI, which is collection of software services, apps, along with various connectors, so that it can connect to diversified kind of data sources. Second is Tableau, which is a visual analytics platform. Objective of Tableau is to connect to any data source transform the way we use data in order to solve the problems. So, depending on compliance need and data availability. You have to design your cloud analytics which has capability of connecting to huge number of diversified environments and provide rich algorithms to derive value from existing data.


Machine Learning Services in the Cloud

Machine learning and AI is being used in almost all different domains. They are being used because they are delivering value in order to understand any system better and come up with innovative implementations. All the analytics that is done using machine learning algorithms are done on data, which is huge, because when machine learning is applied on huge amount of data, you get better accuracy.

Now, let's go ahead and see reasons of using cloud for machine learning. First is the cost, cloud uses pay-per-use model. Second is the capability to provide resources to experiment with machine learning capabilities and scale up when it is needed in production. Third benefit is it simplifies implementation, because cloud provides intelligent capabilities accessible without any need of advance skills in artificial intelligence or data science. And finally, cloud providers themselves provides various different machine learning options. Now, let's go and try to list some of the Machine Learning Services hosted in the cloud. First is image recognition. Image recognition in the context of machine vision is capability of any software to identify objects not only objects but places, people, handwriting, actions and images.

Second is video analytics. You might have gone through various different video motion analysis. It's a technique used to get information about moving objects from video. And third is Speech-to-text you want to convert from speech to text, you can use ml service hosted in the cloud. Fourth is Text-to-speech, you want to convert from text to speech, you can use ML hosted services in the cloud. Apart from that, some of the services which provides translation and language analysis is also hosted in cloud. Now, let's go and list ML tools in the cloud. And we'll list tools for specific ML features. Let's do it using a table which is currently displayed on the screen. First is Image recognition, Amazon provides Rekognition Image.

Microsoft Azure comes with comprehensive solution, which includes Computer Vision API, Custom Vision Service, Face API, Emotion API as well as Content Moderator. Google also provides Vision API and AutoML vision. Video analytics, Amazon comes with Rekognition Video. Microsoft Azure comes with Computer Vision API, Video Indexer and Content Monitor. Google comes with Video Intelligence API. Then comes Speech-to-text, Amazon comes with Transcribe. Microsoft Azure comes with Bing Speech API, Custom Speech services and Speaker Recognition API. Google comes with Speech API. Text-to-speech, Amazon comes with Polly. Microsoft Azure provides same capability using Bing Speech API. And Google facilitates it using Text-to-speech API. What about Translation? Amazon provides Translate.

Microsoft Azure provides Translator Text API and Google provides Translator API. And last is Language analysis. Amazon provides Comprehend, Microsoft Azure provides Text Analytics API, Content Moderator language understanding, Web Language Model API, Linguistic Analysis API and Google provides Natural Language API. Now, let's go ahead and identify ML tool selection criteria. First factor that we have to consider is ML workloads. Now, clouds pay per use model is good for bursty AI or machine learning workloads. So, you need to go through comparison of tools facilitated by multiple cloud providers. Then comes amount of processing, cloud makes it easy for enterprises to experiment with machine learning capabilities.

Now we need to do a comparative study of what cloud provider provides processing resources in what different form, and what all are their competitive cost. Third is support to processors. When we deal with images and videos, we need high capacity processors. We can go ahead and compare processing capabilities provided by various different cloud providers. Finally support to optimized hardware AWS, Microsoft Azure, Google cloud platform offers many machine learning options. But yes you need to go and identify which cloud provider provides you right level of optimized hardware that is needed for your algorithm.


Cloud-based Artificial Intelligence (AI) Services

Let's go ahead and see how AI and cloud computing benefits businesses. First benefit is cost-effectiveness. Now, by being accessible through the internet, the cloud application development eliminates the need of expenses on site hardware and software purchases that are required in order to set up AI infrastructure.

Apart from that, cloud facilitates with increased productivity, followed by better reliability. Because you can move your AI driven infrastructure and software quickly to other regions and availability zones. And finally, availability of advanced infrastructure at affordable price. These are the benefits which AI can realize when it moves to cloud computing. Now, let's go and list certain cloud based AI services. First is IBM Cloud comes with Watson Studio, that helps to build and scale AI with lots of trust and transparency by providing AI lifecycle management capability. Amazon AI sets artificial intelligence services and offers machine learning and deep learning technologies. Lex and Polly are AI services facilitated by Amazon.

Then comes Microsoft Azure which comes up with Azure Cognitive Services which brings AI within reach of every developer without them setting up specialized hardware and software. Google comes with Cloud AI, which provides capability to host applications like social media app, work with massive scale data to perform analytics and also facilitate applications to utilize AI services. Now, let's go and talk about what do we need for cloud-driven AI. In order to build efficient learning mechanism, we need algorithm and theory that optimizes the challenges across different products. Machine perception, which is one of the research methodologies that helps us to understand and write applications to intercept images, sound, music, video and do analytics using them.

Third is machine intelligence. Machine intelligence objective is to raise deep scientific challenges allowing to contribute to broader research. And then comes explainable AI, which requires effective use of AI in real world applications like healthcare, manufacturing, retail and others. And finally, it's data-efficient learning. When you use cloud-driven AI, it provides you capability to train models with only hundreds of training examples. And then cloud AI researchers can conduct research into active learning by using self-supervised representation learning, transfer learning, as well as domain adaption and meta learning. Now, let's take up an example of cloud AI and we are going to take Amazon augmented AI.

We'll have lots of data which will come in form of input. It will be intercepted by AWS, AI service or custom ML model to make predictions. Now, those predictions are passed on to Amazon augmented AI which builds high-confidence predictions that returns immediately to client application. Low-confidence predictions will be sent for human review. And then, finally, client will get reviewed data that can be added to training data to set the improvement of your existing ML model. This is how you can facilitate implementation of AI in cloud, taking advantage of various different AI services which are provided by different public cloud providers.


Big Data Solutions and Cloud

How do we understand that we are facing scenario of big data? We understand it by identifying essential characteristics of big data. First is volume, which is the amount of data accumulated by companies, agencies or whatever data is being captured by your system. Second is velocity, which talks about the rate at which we need to process and examine the data. Then comes a variety which is type of data that gets collected, it may be diverse, and fourth is veracity, which means, what is the value that we are going to realize from the data?

Basically it talks about strategy that helps us to separate poor quality data, and take only that data which matters. Now, when you are in a scenario where you have huge volume, number of diversified types, you want processing to be fast, and you want to eliminate unnecessary data quickly. You can do that by adopting various different solutions that are provided by cloud for big data. But before we go and adopt those solutions, we need to understand why do we go with cloud for big data? First, Zero CapEx, cloud infrastructure as a service model allows consumers to practically eliminate capEx expenses because they'll be shifting it to operating expenses. So, when you want to set up your data store, you will need unlimited amount of data because you are dealing with huge amount of volume.

It becomes easy for you to scale up your storage whenever you want if you are using cloud. Second cloud commit's quick scalability and it applies to both structured as well as unstructured data. Whenever you are dealing with volume and variety of data, you need more processing power, storage and various other components that are needed for processing. Cloud helps you to quickly scale up when your demand grows. Third, cloud comes with pre build software as a service analytics tools which helps you to lower the cost of analytics. And finally, cloud provides better business continuity and disaster recovery. Because each cloud provider have diversified data centers throughout the globe. Now, let's go ahead and understand cloud and big data architecture.

And we'll do that using cloud and big data simplified architecture diagram, which is currently displayed on the screen. We have three essential tasks. First is input. Input will help us to gather data, process will help us to apply processing in order to realize value of data and output is the outcome of processing. Now, let's try to understand what we need to consider when we are talking about ingestion of data or taking data input. You'll have client interface that will provide you result analysis and visualization. But when it comes to input, you'll focus on big data analytics that helps you to understand semi structured data, unstructured data and structured data. On semi structured data you will try to find out level of variety, velocity and values. On unstructured data you will try to find out variability and veracity.

And on structured data, you will plan value derivatives, creating virtualization and also providing virtual view of actual data. Now, once you take data, it may be in diversified form. But when it comes to second step, which is process, it needs data in a particular form so that you can apply logic and execute for analytics. There comes role of extracting the data from input, transforming it and loading it for processing. And that is the reason we can see ETL, now you're processing data. There are various different data analytics frameworks that you can use, Hadoop is one of them. MapReduce is an algorithm in order to help you to collect and analyze data. And RDBMS is structured data, no sequel again provides its own capability of analytics.

Now, where the data will be stored after it is extracted from data store, it will be on some file system. There are two file system one is HDFS and second is GFS. These are distributed file systems, which are built using Hadoop framework and Google framework and then comes output. Once your processing is over your data need to be displayed to the user, or it need to be used in order to bring certain changes to your architecture. There are Multiple different output consoles that can be customized. You can have output in cloud environments which can be private, public and hybrid. They are powered by Infrastructure as a Service, software as a service and platform as a service and provides capability of analytics using various provider services that are powered by Cloud Computing.

So, depending on your need you have to identify what is the kind of data do you need ETL. What algorithms you will use in order to process it where you will store your distributed data and what is the destination of your analytics. And finally, once data is available in cloud, which is analytics outcome, client interface can generate various different visualizations to analyze the results. Also, we need to remember that we have output which is back end and we have big data analytics, which creates connectors for front end. Now finally, let's try to understand big data from perspective of cloud providers. First is AWS. It provides you capability to host your big data framework like Hadoop or even NoSQL. Apart from that, it comes with its own NoSQL called as DynamoDB.

Google Cloud Platform offers huge number of services that helps you to manage big data applications and Azure provides comprehensive support to big data solution data warehousing by providing a suite of services that helps to collect huge data and do analytics on it. So, depending on your need and cloud capabilities, you have to do assessment of big data platforms provided by cloud providers, access your need and then finally decide which big data platform present on what cloud provider is best for you.