Cloud Computing and DevOps [CSE3PE41A ]

Unit III : Cloud Computing Architectures

Microservices Architecture, Serverless Computing, Edge Computing,
Hybrid Cloud Architectures

DEPARTMENT OF COMPUTER ENGINEERING AND TECHNOLOGY

 Microservices Architecture
Microservices are an architectural approach to
developing software applications as a collection
of small, independent services that
communicate with each other over a network.

Instead of building a monolithic application

where all the functionality is tightly integrated
into a single codebase, microservices break
down the application into smaller, loosely
coupled services.

Microservice is a small, loosely coupled service

that is designed to perform a specific business
function and each microservice can be
developed, deployed, and scaled independently.
This architecture allow you to take a large monolith application and decompose it into small manageable
components/services. Also, it is considered as the building block of modern applications.

Microservices can be written in a variety of programming languages, and frameworks, and each service
acts as a mini-application on its own.
 The advantages and disadvantages of
monolithic architecture
Starting a new project and developing it is simpler using monolithic architecture
It is much easier to test a structure that is a monolith
Components like frameworks, templates or scripts can be easily applied
Deployment is very simple. All you have to do is paste the previously prepared application to the server.

Like any solution, monolithic architecture has its drawbacks. Here’s a list of some disadvantages:
A large code base can be significantly harder to understand
The Integrated Development Environment can become overloaded, and size may also slow down startup time
Every element is closely related and dependent on the others, so it is difficult to change to a new or advanced
technology, language, or framework
Updating can be a challenge as it redeployment of the application
Problems with scalability, because each element has different resource requirements
 Monolithic architecture vs microservices comparison chart
Area Monolith architecture Microservices architecture
Deployment This architecture allows you to Deployment is a complexprocess
deploy once and then customize in microservices. Each
your solution based on current microservice must be
changes. But if something goes implemented separately, which
wrong, the whole project will extends the implementation
break down. process. If something goes wrong,
only one microservice will be
damaged, and it will be easier to
fix it.
Maintenance Maintenance in a monolithic Maintenance in microservices is
architecture requires an IT team faster than in monolith. Smaller
that specializes in multiple services are also easy to test,
platforms, like Pascal, .NET, Java, saving programmers time. Over
orDB2. Finding errors and making time, it increases efficiency and
changes takes a lot of time in the saves money.
monolith. However, testing itself is
simple and will be done in one go.
 Monolith architecture Microservices architecture
Reliability If it comes to reliability, the Microservices are stable and
monolith has no chance against mostly reliable. Breaking one part
microservices. If something goes only affects that element, while
wrong in monolithic architecture, the others remain intact. Such
it can stop the whole structure. flexibility allows for a fast pace of
Meanwhile, in microservices development and the introduction
architecture, breaking one service of changes in one function without
will not cause critical problems in interfering with others.
the overall application.
Scalability Scalability in monolithic In the case of
architecture is difficult to achieve microservices,scalability is much
due to the size and scale of the easier because we can scale only
structure. This option is hard to those parts that require more
upgrade resources.
Development The development of monolithic Microservices guarantee fast
architecture takes a little bit development. Teams don’t have to
longer than microservices. This is work in parallel, as they do in
due to the need for a parallel monolithic architecture, because
operation on the same code by all each application can be delivered
teams. independently.
 Monolith architecture Microservices architecture

Releases A monolith is a one-piece Due to the structure, microservices

structurewhich cannot be allow for faster releases of new
separated into smaller features.
[Link] is why everything
must be ready before release.
Potential delays in the work of the
team will impede the entire
project.
Cost Monolith architecture is more Microservices are usually more
affordable and faster to develop, expensive, and the whole
but each case must be considered development takes more time
individually. For businesses, than in monolith. But in the long
monoliths involve one huge run, they can cost less, if we count
investment, which is a higher risk developers’ work time in the long-
and a bigger strain on the budget. run will be less than with a
monolith.
Monolithic architecture vs microservices:
Which to choose for your company?

Like everything, these two technologies both have their advantages and disadvantages.
Monolithic architecture is a solid solution for simple eCommerce applications or blog platforms,
especially when ongoing changes and development are not predicted.
Microservices have grown to become a better fit for complex applications and are the modern
solution in a time when constant improvement and development of sites and services is the
norm.
Real-World Examples of Companies using
Microservices Architecture

Organizations have undergone significant changes by adopting microservices, moving from

monolithic applications. Here are some real-life examples:
Amazon: Initially a monolithic app, Amazon uses microservices early on, breaking its platform
into smaller components. This shift allowed for individual feature updates, greatly enhancing
functionality.
Netflix: After facing service outages while transitioning to a movie-streaming service in 2007,
Netflix adopted a microservices architecture. This change improved reliability and performance.
Uber: By switching from a monolithic structure to microservices, Uber operations were become
smoother, resulting in increased webpage views and search efficienc
Real-World Example of Microservices
Amazon E-Commerce Application with Miscroservices

Amazon's online store is like a giant

puzzle made of many small,
specialized pieces called
microservices.

Each microservice does a specific job

to make sure everything runs
smoothly.

Together, these microservices work

behind the scenes to give you a great
shopping experience.
Below are the microservices involved in Amazon E-commerce Application:
User Service: Handles user accounts and preferences, making sure each person has a personalized experience.
Search Service: Helps users find products quickly by organizing and indexing product information.
Catalog Service: Manages the product listings, ensuring all details are accurate and easy to access.
Cart Service: Lets users add, remove, or change items in their shopping cart before checking out.
Wishlist Service: Allows users to save items for later, helping them keep track of products they want.
Order Taking Service: Processes customer orders, checking availability and validating details.
Order Processing Service: Oversees the entire fulfillment process, working with inventory and shipping to get orders delivered.
Payment Service: Manages secure transactions and keeps track of payment details.
Logistics Service: Coordinates everything related to delivery, including shipping costs and tracking.
Warehouse Service: Keeps an eye on inventory levels and helps with restocking when needed.
Notification Service: Sends updates to users about their orders and any special offers.
Recommendation Service: Suggests products to users based on their browsing and purchase history
Components of microservices
Microservices: Small, loosely coupled services that handle specific business functions, each focusing on a distinct
capability.
API Gateway: Acts as a central entry point for external clients also they manage requests, authentication and route
the requests to the appropriate microservice.
Service Registry and Discovery: Keeps track of the locations and addresses of all microservices, enabling them to
locate and communicate with each other dynamically.
Load Balancer: Distributes incoming traffic across multiple service instances and prevent any of the microservice from
being overwhelmed.
Containerization: Docker encapsulate microservices and their dependencies and orchestration tools like Kubernetes
manage their deployment and scaling.
Event Bus/Message Broker: Facilitates communication between microservices, allowing pub/sub asynchronous
interaction of events between components/microservices.
Database per Microservice: Each microservice usually has its own database, promoting data autonomy and allowing
for independent management and scaling.
Caching: Cache stores frequently accessed data close to the microservice which improved performance by reducing
the repetitive queries.
Fault Tolerance and Resilience Components: Components like circuit breakers and retry mechanisms ensure that the
system can handle failures gracefully, maintaining overall functionality.
 How to deploy microservice
architecture?
You can deploy a microservice architecture with single machines, orchestrators, containers,
serverless functions, and more. No matter the way, follow a structured approach that ensures
reliability, scalability, and agility, such as these six essential steps:
Ways to deploy a microservices
architecture

Option 1: Single machine, multiple processes

Option 2: Multiple machines and processes
Option 3: Deploy microservices with containers
Option 4: Deploy microservices with orchestrators
Option 5: Deploy microservices as serverless functions
 Option 1: Single machine, multiple
processes

Imagine your microservices running on a single machine, each as a separate process.

This option is a straightforward approach to deploying microservices.
It’s suitable for small-scale applications and can be cost-effective.
However, it has limitations in terms of scalability and resilience.
The entire system can halt when the machine experiences issues or becomes overwhelmed.
 Option 2: Multiple machines and processes

To address the limitations of the single-machine approach, you can deploy your microservices across multiple machines.
Each microservice runs as a separate process on its server.
This approach improves scalability and reliability, making it suitable for larger applications.
Implementing load balancing is essential to distribute traffic evenly across the microservices and maintain high
availability.
Option 3: Deploy microservices with
containers
Containers, such as Docker, have revolutionized
microservices deployment.

With Containerization you can package each microservice

and its dependencies into a lightweight, consistent
environment.

This approach ensures that your microservices are

isolated from each other, making it easier to manage,
scale, and deploy them across various environments.

Containers are also portable so that you can run them on

different cloud providers or on-premises servers with
minimal changes.
Option 4: Deploy microservices with
orchestrators
Container orchestration platforms like
Kubernetes offer a powerful solution for
deploying and managing microservices at
scale.

Orchestrators help automate the

deployment, scaling, and load balancing of
microservices.

They provide advanced features like self-

healing, rolling updates, and service
discovery, making managing many
microservices more manageable.

Kubernetes, in particular, has become the

de facto standard for container
orchestration.
Option 5: Deploy microservices as
serverless functions
Serverless computing allows you to deploy
microservices as individual functions that
automatically scale with demand.

This approach eliminates the need for

managing infrastructure and ensures cost
efficiency by only charging you for the
resources used.

While serverless is an attractive option for

specific workloads, it’s unsuitable for all
applications.

Consider latency, execution limits, and the

stateless nature of serverless functions
when deciding whether to go serverless.
Docker
[Link]
Docker is an open platform for developing, shipping, and running applications.
Docker enables you to separate your applications from your infrastructure so you can deliver
software quickly.
With Docker, you can manage your infrastructure in the same ways you manage your
applications.
By taking advantage of Docker's methodologies for shipping, testing, and deploying code, you
can significantly reduce the delay between writing code and running it in production.
Docker is written in the Go programming language and takes advantage of several features of
the Linux kernel to deliver its functionality. Docker uses a technology called namespaces to
provide the isolated workspace called the container. When you run a container, Docker creates
a set of namespaces for that container.
 The Docker platform
Docker provides the ability to package and run an application in a loosely isolated environment called a
container.
The isolation and security lets you run many containers simultaneously on a given host. Containers are
lightweight and contain everything needed to run the application, so you don't need to rely on what's installed
on the host.
You can share containers while you work, and be sure that everyone you share with gets the same container that
works in the same way.

Docker provides tooling and a platform to manage the lifecycle of your containers:
Develop your application and its supporting components using containers.
The container becomes the unit for distributing and testing your application.
When you're ready, deploy your application into your production environment, as a container or an orchestrated
service. This works the same whether your production environment is a local data center, a cloud provider, or a
hybrid of the two.
Docker architecture
Docker uses a client-server architecture.
The Docker client talks to the Docker daemon, which does the heavy lifting of building, running,
and distributing your Docker containers.
The Docker client and daemon can run on the same system, or you can connect a Docker client
to a remote Docker daemon.
The Docker client and daemon communicate using a REST API, over UNIX sockets or a network
interface.
Another Docker client is Docker Compose, that lets you work with applications consisting of a
set of containers.
Figure: Docker Architecture
The Docker daemon - The Docker daemon (dockerd) listens for Docker API requests and manages Docker
objects such as images, containers, networks, and volumes. A daemon can also communicate with other
daemons to manage Docker services.

The Docker client - The Docker client (docker) is the primary way that many Docker users interact with Docker.
When you use commands such as docker run, the client sends these commands to dockerd, which carries them
out. The docker command uses the Docker API. The Docker client can communicate with more than one
daemon.

Docker Desktop- is an easy-to-install application for your Mac, Windows or Linux environment that enables you
to build and share containerized applications and microservices. Docker Desktop includes the Docker daemon
(dockerd), the Docker client (docker), Docker Compose, Docker Content Trust, Kubernetes, and Credential
Helper. For more information, see Docker Desktop.

Docker registries – it stores Docker images. Docker Hub is a public registry that anyone can use, and Docker
looks for images on Docker Hub by default. You can even run your own private registry.

Docker objects – we can create and using images, containers, networks, volumes, plugins, and other objects.
Kubernetes
Kubernetes is an open source container orchestration engine for automating deployment,
scaling, and management of containerized applications. The open source project is hosted by
the Cloud Native Computing Foundation (CNCF).

Kubernetes or K8s was a Google Project as a open source next-gen container scheduler and is a
linux kernel of distributed systems. It abstracts away the underlying hardware of the nodes and
provides a uniform interface for applications to be both deployed and consume the shared pool
of resources.
Before Kubernetes, developers used Docker to package and run their applications inside
containers.

Docker made creating and running a single container easy, but it became hard to manage
many containers running across different machines. For example, what if one container
crashes? How do you restart it automatically? Or how do you handle hundreds of
containers that need to work together? That’s why Kubernetes was created. It helps
manage and organize containers automatically.

Kubernetes makes sure your containers keep running, can scale up when there’s more
traffic, and can move to healthy machines if something goes wrong.
Kubernetes or K8s is an open-source platform that helps you automates the deployment,
scaling, and management of containerized applications. In simple words, if you're running a
lot of apps using containers (like with Docker), Kubernetes helps you organize and control
them efficiently just like a traffic controller for your apps.

You tell Kubernetes what your app should look like (how many copies to run, what to do if
something fails, etc.), and Kubernetes takes care of the rest making sure everything is up
and running properly.
Kubernetes Key Terminologies
Pod
◦ A Pod is the smallest unit you can deploy in Kubernetes. It wraps one or more containers that need to
run together, sharing the same network and storage. Containers inside a Pod can easily communicate
and work as a single unit.

Node
◦ A Node is a machine (physical or virtual) in a Kubernetes cluster that runs your applications. Each Node
contains the tools needed to run Pods, including the container runtime (like Docker), the Kubelet
(agent), and the Kube proxy (networking).

Cluster
◦ A Kubernetes cluster is a group of computers (called nodes) that work together to run your
containerized applications. These nodes can be real machines or virtual ones.
There are two types of nodes in a Kubernetes cluster:
◦ Master node (Control Plane):
◦ Think of it as the brain of the cluster.
◦ It makes decisions, like where to run applications, handles scheduling, and keeps track of everything.
◦ Worker nodes:
◦ These are the machines that actually run your apps inside containers.
◦ Each worker node has a Kubelet (agent), a container runtime (like Docker or containerd), and tools
for networking and monitoring.

Deployment
◦ A Deployment is a Kubernetes object used to manage a set of Pods running your containerized
applications. It provides declarative updates, meaning you tell Kubernetes what you want, and it
figures out how to get there.

ReplicaSet
◦ A ReplicaSet ensures that the right number of identical Pods are running.
Service
◦ A Service in Kubernetes is a way to connect applications running inside your cluster. It gives your Pods
a stable way to communicate, even if the Pods themselves keep changing.
Ingress
◦ Ingress is a way to manage external access to your services in a Kubernetes cluster. It provides HTTP and
HTTPS routing to your services, acting as a reverse proxy.
ConfigMap
◦ A ConfigMap stores configuration settings separately from the application, so changes can be made without
modifying the actual code.
◦ Imagine you have an application that needs some settings, like a database password or an API key. Instead
of hardcoding these settings into your app, you store them in a ConfigMap. Your application can then read
these settings from the ConfigMap at runtime, which makes it easy to update the settings without changing
the app code.
Secret
◦ A Secret is a way to store sensitive information (like passwords, API keys, or tokens) securely in a Kubernetes
cluster.
Persistent Volume (PV)
◦ A Persistent Volume (PV) in Kubernetes is a piece of storage in the cluster that you can use to store data —
and it doesn’t get deleted when a Pod is removed or restarted.
Namespace
◦ A Namespace is like a separate environment within your Kubernetes cluster. It helps you organize and
isolate your resources like Pods, Services, and Deployments.
Kubelet
◦ A Kubelet runs on each Worker Node and ensures Pods are running as expected.
Kube-proxy
◦ Kube-proxy manages networking inside the cluster, ensuring different Pods can communicate.

Fig : Historical context for

Kubernetes
Traditional deployment era:
◦ Early on, organizations ran applications on physical servers. There was no way to define resource boundaries
for applications in a physical server, and this caused resource allocation issues.
◦ For example, if multiple applications run on a physical server, there can be instances where one application
would take up most of the resources, and as a result, the other applications would underperform. A solution
for this would be to run each application on a different physical server.
◦ But this did not scale as resources were underutilized, and it was expensive for organizations to maintain
many physical servers.

Virtualized deployment era:

◦ As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single
physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of
security as the information of one application cannot be freely accessed by another application.
◦ Virtualization allows better utilization of resources in a physical server and allows better scalability because
an application can be added or updated easily, reduces hardware costs, and much more.
◦ With virtualization you can present a set of physical resources as a cluster of disposable virtual machines.
◦ Each VM is a full machine running all the components, including its own operating system, on top of the
virtualized hardware.
Container deployment era: Containers are similar to VMs, but they have relaxed isolation properties to share the Operating
System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own
filesystem, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are
portable across clouds and OS distributions.

Containers have become popular because they provide extra benefits, such as:

◦ Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image
use.
◦ Continuous development, integration, and deployment: provides for reliable and frequent container image build and
deployment with quick and efficient rollbacks (due to image immutability).
◦ Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time,
thereby decoupling applications from infrastructure.
◦ Observability: not only surfaces OS-level information and metrics, but also application health and other signals.
◦ Environmental consistency across development, testing, and production: runs the same on a laptop as it does in the cloud.
◦ Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else.
◦ Application-centric management: raises the level of abstraction from running an OS on virtual hardware to running an
application on an OS using logical resources.
◦ Loosely coupled, distributed, elastic, liberated micro-services: applications are broken into smaller, independent pieces and
can be deployed and managed dynamically – not a monolithic stack running on one big single-purpose machine.
◦ Resource isolation: predictable application performance.
◦ Resource utilization: high efficiency and density.
Figure : Kubernetes architecture
Key Components of Kubernetes
Kubernetes-Master Node Components –
Kubernetes master is responsible for managing the entire cluster, coordinates all activities
inside the cluster, and communicates with the worker nodes to keep the Kubernetes and your
application running. This is the entry point of all administrative tasks. When we install
Kubernetes on our system we have four primary components of Kubernetes Master that will get
installed.
The components of the Kubernetes Master node are: API Server, Scheduler, Control Manager
and etcd.
API Server
The API server is the entry point for all the REST commands used to control the cluster. All the
administrative tasks are done by the API server within the master node.
If we want to create, delete, update or display in Kubernetes object it has to go through this
API server.
API server validates and configures the API objects such as ports, services, replication,
controllers, and deployments and it is responsible for exposing APIs for every operation.
We can interact with these APIs using a tool called kubectl. 'kubectl' is a very tiny go language
binary that basically talks to the API server to perform any operations that we issue from the
command line.
It is a command-line interface for running commands against Kubernetes clusters
Scheduler
It is a service in the master responsible for distributing the workload.
It is responsible for tracking the utilization of the working load of each worker node and then
placing the workload on which resources are available and can accept the workload.
The scheduler is responsible for scheduling pods across available nodes depending on the
constraints you mention in the configuration file it schedules these pods accordingly.
The scheduler is responsible for workload utilization and allocating the pod to the new node.
Controller Manager
It is a daemon that runs in a non terminating loop and is responsible for collecting and sending
information to the API server.
It regulates the Kubernetes cluster by performing lifestyle functions such as namespace
creation and lifecycle event garbage collections, terminated pod garbage collection, cascading
deleted garbage collection, node garbage collection, and many more.
Basically, the controller watches the desired state of the cluster if the current state of the
cluster does not meet the desired state then the control loop takes the corrective steps to make
sure that the current state is the same as that of the desired state.
The key controllers are the replication controller, endpoint controller, namespace controller,
and service account, controller. So in this way controllers are responsible for the overall health
of the entire cluster by ensuring that nodes are up and running all the time and correct pods are
running as mentioned in the specs file.
etcd
It is a distributed key-value lightweight database.
In Kubernetes, it is a central database for storing the current cluster state at any point in time
and is also used to store the configuration details such as subnets, config maps, etc.
It is written in the Go programming language.
Kubernetes-Worker Node Components
Kubernetes Worker node contains all the necessary services to manage the networking between
the containers, communicate with the master node, and assign resources to the containers
scheduled. The components of the Kubernetes Worker node are:
Kubelet
◦ It is a primary node agent which communicates with the master node and executes on each worker
node inside the cluster. It gets the pod specifications through the API server and executes the container
associated with the pods and ensures that the containers described in the pods are running and
healthy.
◦ If kubelet notices any issues with the pods running on the worker nodes then it tries to restart the pod
on the same node. If the issue is with the worker node itself then the Kubernetes master node detects
the node failure and decides to recreate the pods on the other healthy node.
Kube-Proxy
It is the core networking component inside the Kubernetes cluster. It is responsible for
maintaining the entire network configuration.
Kube-Proxy maintains the distributed network across all the nodes, pods, and containers and
exposes the services across the outside world.
It acts as a network proxy and load balancer for a service on a single worker node and manages
the network routing for TCP and UDP packets.
It listens to the API server for each service endpoint creation and deletion so for each service
endpoint it sets up the route so that you can reach it.
Pods
◦ A pod is a group of containers that are deployed together on the same host. With the help of pods, we can
deploy multiple dependent containers together so it acts as a wrapper around these containers so we can
interact and manage these containers primarily through pods.

Docker
◦ Docker is the containerization platform that is used to package your application and all its dependencies
together in the form of containers to make sure that your application works seamlessly in any environment
which can be development or test or production. Docker is a tool designed to make it easier to create,
deploy, and run applications by using containers. Docker is the world's leading software container platform.
◦ It was launched in 2013 by a company called Dot cloud. It is written in the Go language. It has been just six
years since Docker was launched yet communities have already shifted to it from VMs. Docker is designed to
benefit both developers and system administrators making it a part of many DevOps toolchains.
◦ Developers can write code without worrying about the testing and production environment. Sysadmins need
not worry about infrastructure as Docker can easily scale up and scale down the number of systems. Docker
comes into play at the deployment stage of the software development cycle.
Figure : Kubernetes working model
Kubernetes v/s Docker
Feature Docker Kubernetes
Purpose A containerization platform to build, ship, and A container orchestration tool that
run containers. manages, deploys, and scales
containerized applications.
Developed By Docker Inc. Originally by Google, now managed
by CNCF.
Container Management Manages individual containers. Manages multiple containers
across a cluster
Scaling Manual scaling of containers using docker Auto-scaling with Horizontal Pod
run or docker-compose. Autoscaler (HPA).
Networking Uses a single-host bridge network by default. Uses a cluster-wide network to
connect services across multiple
nodes.
Load Balancing Basic load balancing via Docker Swarm. Advanced load balancing with
Services and Ingress.
Self-Healing Containers need to be restarted manually if Automatically replaces failed
they fail. containers (Pods).
Feature Docker Kubernetes
Rolling Updates Not natively supported; requires Supports zero-downtime rolling
recreating containers manually. updates for applications.
Storage Local persistent storage. Persistent storage with Persistent
Volumes (PV) & Persistent Volume
Claims (PVC).
Cluster Management Limited to Docker Swarm (less Manages large-scale distributed
complex, but less powerful than systems with multiple nodes
Kubernetes).
Use Case Best for developing and running Best for running, managing, and
containerized apps on a single scaling containerized applications
machine. across multiple machines (clusters).
Deploying and Managing Containerized
Applications with Kubernetes

Step 1: Install Kubernetes and setup Kubernetes cluster there should be minimum at least one
master node and two worker nodes you can set up the Kubernetes cluster in any of the cloud
which are providing the Kubernetes as an service.
Step 2: Now, create a deployment manifest file. In this file, you specify the desired
number of Pods, the container image, and the resources required. After creating the
manifest, apply it using the kubectl command
Step 3: After creating the pods know you need to expose the service to the outside for that you
need to write one more manifest file which contains service type (e.g., Load Balancer or Cluster
IP), ports, and selectors.
SERVERLESS COMPUTING
Serverless computing is a method of providing backend services on an as-used basis.
A serverless provider allows users to write and deploy code without the hassle of worrying
about the underlying infrastructure.
A company that gets backend services from a serverless vendor is charged based on their
computation and do not have to reserve and pay for a fixed amount of bandwidth or number of
servers, as the service is auto-scaling.
Note that despite the name serverless, physical servers are still used but developers do not
need to be aware of them.
Why Servereless Computing?
• In the early days of the web, anyone who wanted to build a web application
had to own the physical hardware required to run a server, which is a
cumbersome and expensive undertaking.
• Then came cloud computing, where fixed numbers of servers or amounts of
server space could be rented remotely. Developers and companies who rent
these fixed units of server space generally over-purchase to ensure that a spike
in traffic or activity will not exceed their monthly limits and break their
applications.
• This means that much of the server space that gets paid for can go to waste.
Cloud vendors have introduced auto-scaling models to address the issue, but
even with auto-scaling an unwanted spike in activity, such as a DDoS Attack,
could end up being very expensive.
 Fig : Cloud DDoS attack
Source: [Link]
protection-67d24cd37032
Serverless computing allows developers to purchase backend services on a flexible ‘pay-as-you-go’
basis, meaning that developers only have to pay for the services they use.
This is like switching from a cell phone data plan with a monthly fixed limit, to one that only charges
for each byte of data that actually gets used.

The term ‘serverless’ is somewhat

misleading, as there are still servers
providing these backend services, but all
of the server space and infrastructure
concerns are handled by the vendor.

Serverless means that the developers can

do their work without having to worry
about servers at all.
What are backend services? What’s the
difference between frontend and backend?
Application development is generally
split into two realms: the frontend and
the backend.

The frontend is the part of the

application that users see and interact
with, such as the visual layout.

The backend is the part that the user

doesn’t see; this includes the server
where the application's files live and the
database where user data and business
logic is persisted.
What kind of backend services can
serverless computing provide?

• Most serverless providers offer database and storage services to their customers, and many
also have Function-as-a-Service (FaaS) platforms.
• FaaS allows developers to execute small pieces of code on the network edge.
• With FaaS, developers can build a modular architecture, making a codebase that is more
scalable without having to spend resources on maintaining the underlying backend.
• Function-as-a-Service (FaaS) is a serverless way to execute modular pieces of code on the edge.
FaaS lets developers write and update a piece of code on the fly, which can then be executed in
response to an event, such as a user clicking on an element in a web application. This makes it
easy to scale code and is a cost-efficient way to implement microservices.
Edge Computing
Edge computing is the process of bringing information storage and computing abilities closer to
the devices that produce that information and the users who consume it.
Traditionally, applications have transmitted data from smart devices like sensors and
smartphones to a central data center for processing. However, the unprecedented complexity
and scale of data have outpaced network capabilities.
By shifting processing capabilities closer to users and devices, edge computing systems
significantly improve application performance, reduce bandwidth requirements, and give faster
real-time insights.
Edge computing is becoming more popular because it allows enterprises to collect and analyze
their raw data more efficiently. More than ever, organizations need instant access to their data
to make informed decisions about their operational efficiency and business functions.
When appropriately used, edge computing has the potential to help organizations improve
safety and performance, automate processes, and improve user experience.
 Benefits of edge computing.
• Autonomy : It processes data on a local network reducing the sheer amount of data that needs to be sent and
received. This means you need less bandwidth and connectivity time.
• Data jurisdiction : By keeping data close to the source, there are fewer problems associated with the crossing
of national borders, boundaries, and sovereign laws. This means that edge computing creates fewer legal
issues, including security and privacy.
• Security: Edge deployment allows data to be encrypted when it travels to the cloud or to the data center. Also,
edge computing can be strengthened against cybercrime, such as hacking. This is even possible if the IoT
devices are limited in terms of security capability.
• Minimal latency : Due to processors being available close to where the data will be used improves processing
time. It also enables real-time analytics. The opportunities for new markets are exponential.
• Simplified maintenance : Micro-data centers (µDC) are tiny, can be transported on the back of a truck, and are
created with as much accessibility and modularity as possible.
• Reduced cooling costs: Large data centers can cost a lot to cool. However, cooling a range of smaller data
centers could cost a lot less, at least in theory.
• Climate consciences : It is possible that many smaller data centers will use less energy than one huge data
center if edge could appropriately maximize accuracy and efficiency within its computerizations.
 What is the difference between edge
computing and cloud computing?
Edge computing is running workloads
at the edge—that is, closer to devices
and end users. On the other hand,
cloud computing is a broad term that
includes running all types of
workloads in a cloud service
provider’s data center.
However, it is important to note that
cloud service providers also provide
edge computing services. For
example, AWS edge services deliver
data processing, analysis, and storage
close to your endpoints, allowing you
to deploy APIs and tools to locations
outside AWS data centers
Edge Computing Architecture
Overview
A typical edge computing
architecture can be divided into
three layers:

The cloud layer, or the layer that is

responsible for processing and
storing all data;
The edge layer, or the layer that
handles the data processing near
real time;
And the device layer, or the layer
that is in charge of detecting and
performing simple processing.
Cloud Layer
Although edge computing was introduced to address network congestion and latency problems commonly found in cloud
computing, cloud computing in fact still plays an important role in the entire edge computing architecture. We can say that
cloud computing and edge computing complement one another.
Through the edge layer described in the next section, the entire system determines if data needs to be processed in the cloud
layer. If that is the case, edge servers will pass data to the cloud layer for complex processing. On the other hand, edge
servers will also pass a part or critical data to the cloud layer for storage and comprehensive analysis. This also demonstrates
the integration between both the cloud and edge layers.
Edge Layer
This layer mainly consists of edge servers, and when compared to the cloud layer, the edge layer contains edge servers that are larger
in quantity and more vastly deployed. Therefore, through distributed edge computing, the edge layer can process data that is closer to
the data source and address latency problems found in cloud computing.
The edge layer can be considered the core in the entire edge computing architecture. After data from the device layer is analyzed and
processed in the edge layer, data is transmitted to the cloud layer for subsequent processing and analysis. Data which cannot be
processed in the edge layer can be sent to and analyzed in the cloud layer to ensure data integrity.

Device Layer
Amongst the three layers, the device layer contains the most devices. Ranging from devices that are as small as our mobile phones or
computers to ones that are as large as buses and factories, these devices are all examples of components in the device layer.
Through their sensors, devices in the device layer collect and capture data used to help products achieve the purposes they are
designed for. Equipment in a hospital collecting vital signs of patients and autonomous vehicles capturing data of other nearby
vehicles are all such examples.
Although components in the cloud and edge layers possess better computing power, the devices in the device layer can still perform
data analyses, processing and storage tasks which require negligible computing power, as well as process data closest to the data
source in almost real-time.
 Edge Computing Examples and Use Cases
Healthcare & Patient Monitoring: Edge computing is being used in the Healthcare industry. Medical devices generate
vast amounts of data that need to be processed quickly and efficiently. By deploying edge computing, healthcare
providers can process this data at the edge of the network, allowing for faster diagnosis and treatment.
Smart Homes: Implementing edge technology in smart homes offers a more feasible solution than traditional systems
that rely on sending and receiving data to and from a main storage hub. This approach not only reduces latency, but also
enhances security while minimizing backhaul costs. As a result, voice commands are executed more quickly and in real-
time, providing a seamless and efficient experience for users.
Smart Cities: Edge computing is also being used to create Smart Cities. By deploying edge computing devices across the
city, local authorities can monitor traffic, air quality, and other environmental factors in real-time. This approach can
help them identify and respond to issues quickly, improving the overall quality of life for citizens.
Traffic Management: As road traffic continues to increase, the need for smarter traffic management systems becomes
more pressing. Edge computing can be instrumental in optimizing traffic flow in cities by dynamically opening up lanes
where and when necessary, and it will play a crucial role in managing the movement of autonomous vehicles.
Self-Driving Cars: Edge computing plays a crucial role in the development of autonomous vehicles. It enables real-time
response to traffic situations: In general, it takes about 100ms to transmit data from the car sensor to the back-office
cloud data center, and the transmission time may increase as the data volume increases. In terms of driving decision-
making, data transmission delays may significantly affect the situated response of self-driving cars. Hence, edge
computing can help resolve the data transmission delay among data centers to enhance driving safety.
Crowd Management : Edge computing is essential for managing large events, such as concerts and
matches. It facilitates crowd control by enabling mobility applications to program messages for each
attendee regarding ticket purchase, transportation routes, entrance or seat locations, and exclusive
event content. Additionally, edge computing helps organizers understand attendee mobility and
engagement, allowing them to make informed decisions such as launching flash sales.
Logistics : Logistics is another industry that is using edge computing to improve their operations. By
deploying edge computing devices in warehouses and shipping centers, logistics companies can
monitor inventory levels, track shipments in real-time, and optimize routes. This approach can help
them reduce delivery times, lower costs, and improve customer satisfaction.
Security : Edge computing has proven to be a game-changer in various domains, and security is no
exception. One such application of edge computing technology is in ensuring worker safety in
hazardous work environments. The data collected from devices like onsite cameras, safety devices,
and sensors are crucial in achieving this objective. These devices help in preventing unauthorized
access to the site, and they also monitor the safety protocols followed by the employees. In the
event of a safety breach or a potential hazard, the data collected by these devices can alert the
concerned authorities in real-time. This timely response can help in averting a disaster and ensuring
the well-being of workers.
Manufacturing & Smart Factory : Manufacturing industries are using edge computing to improve
their operations, such as effective accelerating platform data communication and Facilitating
machine maintenance and parameter adjustment. This technology also facilitates the construction
of a scalable and flexible platform by integrating predictive analysis and machine learning
algorithms. Machine automation is the key to the success of manufacturing industries. The Internet
of Things (IoT) is utilized to detect and monitor machine operations, while edge computing is
employed to analyze on-site data. When an anomaly is detected, workers can make corrections or
implement predictive maintenance in advance to prevent it from affecting the production line.
Edge Computing, IoT, and 5G
Possibilities
Edge computing is an evolving entity with new technology being brought in all the time. All this
enhances its availability, capabilities, and performance. More and more products are being
specially made with edge technology. Decentralization of data is the future.
5G will have an effect on edge by increasing its capabilities, such as with the autonomy of
vehicles. It will also make wireless networks much more flexible while reducing costs.
Due to the fact that the IoT is still rapidly rising, it means that the development of edge
computing will evolve alongside it. There will be scope for MMDCs (micro modular data centers)
that are already in development and are about the size of a box. These MMDCs can be deployed
close to where the data is needed.
Hybrid Cloud Architectures
Public and Private architecture principled cloud platforms allow customers/clients to host and
manage services on the internet.

The back-end cloud systems are powered by artificial intelligent (AI), enhanced by Infrastructure as
a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and fuel by
data/information whilst providing high capacity cloud storage databases.

The "hybrid cloud architecture" solution orchestration for Company/Enterprise is driven by private
cloud (on-premises), public cloud and third-party services and modulated by the Internet of Things
(IoT), Kubernetes (K8s), Docker, ISTIO, Application Programming Interface (API), Monolithic Services
and Microservices.

In a hybrid cloud architecture, organizations host their data and applications in multiple locations,
depending on workload requirements, regulatory compliance needs, technical capabilities, security
and cost.
Core components that make hybrid
cloud architecture work.
Hybrid cloud resources - To enable a hybrid cloud, there is a need to have resources from a
public cloud provider as well as private computing resources, such as an on-premises data
center and some private cloud capabilities.
Connectivity across environments -The backbone of hybrid cloud architecture lies in the
interconnection of diverse environments through various network connections. Technologies
such as virtual private networks (VPNs), wide area networks or WANs, and application
programming interfaces also known as APIs, are critical to enabling connectivity. Hybrid cloud
architecture relies on public internet services for private and hybrid cloud connectivity -- such
as AWS Direct Connect, Azure Private Link and Google Cloud VPN -- to support connectivity and
data movement between private clouds, public cloud services and on-premises infrastructure
Virtualization and containerization - Hybrid cloud architecture makes use of virtualization with
technologies such as VMware, and containerization technologies including Docker, to abstract computing
resources.

Workload Portability - The use of virtualization and containers in hybrid cloud architecture enables
workload portability. This flexibility allows applications and workloads to run in different environments.

Orchestration and automated provisioning - Efficient management of resources in a hybrid cloud

architecture is achieved through the orchestration and automation of provisioning. Management
software platforms help to facilitate resource deployment across environments.

Data synchronization and consistency- Ensuring consistency across environments can often be a critical
part of how hybrid cloud architecture works. This is achieved through data synchronization to employ
replication tools.

Unified visibility and control - Using unified visibility and control capabilities makes hybrid cloud
architecture work. Centralized management consoles and platforms provide organizations with the ability
to oversee and govern infrastructure and services across on-premises, public cloud and private cloud
environments.
 Hybrid cloud architecture patterns
Public cloud and private cloud. This involves connecting infrastructure from a public cloud provider such
as AWS, Google Cloud or Azure with an organization's own private cloud environment. The private cloud
can be hosted on-premises or operated by a third-party vendor. Applications and data can move between
the public and private clouds as needed.

Public cloud and on-premises. In this model, public cloud services are utilized in conjunction with legacy
infrastructure that remains on-premises. It allows taking advantage of public cloud benefits without
completely overhauling on-premises systems.

Multi-cloud hybrid. Organizations can choose to host applications across two or more public clouds or
private cloud infrastructures. This provides flexibility to use the best services from different providers.

Hybrid host. The hybrid host pattern deploys a gateway architecture between the on-premises data
center and public cloud to facilitate secure data transfer and movement.
 Examples of hybrid cloud architecture
There are numerous ways to deploy hybrid cloud architecture. Some common examples of hybrid cloud
architecture include:

Backup and disaster recovery. Public cloud IaaS provides an inexpensive way to back up data from on-
premises workloads and enable disaster recovery capabilities.
Cloud bursting. During peak demand, additional computing capacity can be "burst" to the public cloud,
provisioning extra resources.
Policy-based placement. Organizations can set policies to determine where data and workloads reside
based on factors such as security, compliance, latency and cost.
Security segmentation. Host sensitive data and apps on a private cloud or on-premises, with other tiers
of less sensitive workloads on public cloud infrastructure.
Distributed processing. A hybrid cloud architecture can be used to perform basic collection and
processing at the edge using on-premises resources, with aggregation and deep analysis in the public
cloud.
Legacy application modernization. As part of an overall modernization effort, an organization can leave
legacy on-premises apps while modernizing others using containers and moving them to the public cloud.
 Five considerations when building hybrid
cloud architecture
Here are five considerations when building a hybrid cloud architecture:

Overall strategy. Rather than just arbitrarily deploying some workloads on premises and some in
the cloud, it is best to have a strategy. That strategy could include goals for cost, performance,
availability and manageability for different workloads.
Technologies in the foundation. There are several technologies that can be used for hybrid cloud
architecture. It's important to choose platforms that enable interoperability and don't lead to
vendor lock-in.
Different workloads. Hybrid cloud architecture is all about workload placement with some running
on-premises and others in private or public cloud. Build out an inventory of workloads and the
criteria for deployment including compliance requirements to help determine placement options.
Digital transformation and workload modernization. For many organizations, hybrid cloud
architecture can be a pathway for digital transformation and workload modernization. It's important
to determine an approach for migrating workloads to the cloud, such as lift and shift or re-
architecting.
Security. With multiple locations for deployment, security can be a complex issue. It's critical to
have a unified policy layer to secure workloads and access
 What are the challenges of hybrid cloud
architecture?
Complexity. With multiple components across different environments, it can be complex to integrate all
the required pieces.

Control. As opposed to an on-premises deployment, there can be less perceived control since part of the
infrastructure is externally hosted.

Performance. With the distributed nature of hybrid cloud architecture, there are potential performance
issues for applications requiring extremely low latency.

Cost. Hybrid cloud architectures have higher costs compared to pure public cloud since on-premises
infrastructure must also be maintained. Network connectivity and bandwidth costs for private links can
also be expensive.

Security. There are potential security risks in bridging on-premises, private and public cloud resources.

Staff skills. Employees need specialized skills to manage the integration.

 Benefits of hybrid cloud architecture
Eases cloud migration. The hybrid model offers an intermediate approach for organizations
transitioning from on-premises to the public cloud.
Saves costs. There may be cost savings compared to having only on-premises or public cloud
because hybrid cloud architecture optimizes resources.
Ensures regulatory compliance. Organizations can keep sensitive data on-premises to adhere to
regulatory compliance and data sovereignty concerns.
Maximize value of existing assets. A hybrid cloud architecture can enable an organization to
continue to benefit from existing on-premises assets, alongside new public cloud resources.
Enables workload portability. With the use of containers and virtualization, workloads can move
across environments, giving an organization more deployment options and flexibility.
Improves disaster recovery and resilience. By using different types of environments for
deployment, organizations can help to improve resilience, business continuity and disaster recovery
capabilities.
Provides scalability. Hybrid cloud architecture provides flexibility and scalability to use the optimal
environment for each workload and can allow for cloud bursting to scale dynamically.
 Cloud Bursting
Cloud bursting is a configuration method that uses cloud computing resources whenever on-premises
infrastructure reaches peak capacity.
When organizations run out of computing resources in their internal data center, they burst the extra
workload to external third-party cloud services. Cloud bursting is a convenient and cost-effective way to to
support workloads with varying demand patterns and seasonal spikes in demand.
Traditionally, organizations purchased and maintained their own computing infrastructure, such as servers,
storage devices, and network hardware, in a private data center or colocation facility.
However, with the advent of third-party cloud providers like Amazon Web Services, organizations can now
use publicly available computing infrastructure that is secure, can easily scale up or down to meet workload
demands, and is available in many regions around the world.
It became more convenient to use infrastructure that was fully managed by others. The term public
cloud emerged to differentiate between the internal infrastructure and the external third-party cloud
resources.
Fig : Cloud Bursting
Source: [Link]
[Link]

[Link]
[Link]
[Link]
[Link]