Developing Cloud Native Applications

Cloud native applications consist of microservices that work together to leverage the
advantages of cloud computing.
Cloud native capabilities propel companies like Netflix and Pinterest. These
companies have leveraged the velocity of cloud native development to reap huge
rewards in the marketplace. According to a recent study, more than 60% of
organizations will use a cloud managed service offering from an external provider
within the next few years.

The cloud is the delivery of on demand computing resources everything from

applications to data centres over the Internet on a pay for use basis.
US National Institute of standards and technology (NIST) defines cloud computing
as:
 a model for enabling convenient on demand network access to a shared pool
of configurable computing resources that can be rapidly provisioned and
released with minimal management effort or service provider interaction.
Examples of computing resources include:
 networks
 servers
 storage
 applications and
 services

This cloud model is composed of:

 5 essential characteristics:
 3 deployment models and
 3 service models

The five essential characteristics of the cloud:

Which include:
 on demand self-service
 broad network access
 resource pooling
 rapid elasticity and
 measured service.
On demand self-service, the first characteristic, means that you get access to cloud
resources such as the processing power storage and network you need using a
simple interface without requiring human interaction with each service provider.

The second characteristic, broad network, access means that cloud computing
resources can be accessed via the network through standard mechanisms and
platforms such as: mobile phones, tablets, laptops, and workstations.
The third characteristic, resource pooling, is what gives cloud providers economies
of scale, which they pass on to their customers, making cloud cost efficient.
Using a multi-tenant model, computing resources are pooled to serve multiple
consumers.
Cloud resources are dynamically assigned and reassigned according to demand
without customers needing to concern themselves with the physical location of these
resources.

Rapid elasticity, the 4th characteristic, implies that you can access more resources
when you need them and scale back when you don't because resources are
elastically provisioned and released.

The 5th characteristic, measured service, means that you only pay for what you use
or reserve as you go.
If you're not using resources, you're not paying resource usage is monitored
measured and reported transparently based on utilisation.

Cloud computing is really about utilising technology as a service, leveraging remote

systems, on demand over the open Internet, scaling up, scaling back, and paying for
what you use.

It is a revolution in that it has changed the way the world consumes compute
services by making them more cost efficient while also making organisations more
agile in responding to changes in their markets.

The 3 deployment models:

There are three types of cloud deployment models:
 public
 private and
 hybrid
Public cloud is when you leverage cloud services over the open Internet on hardware
owned by the cloud provider, but its usage is shared by other companies.

Private cloud means that the cloud infrastructure is provisioned for exclusive use by
a single organisation it could run on premises, or it could be owned managed and
operated by a service provider.

When you use a mix of both public and private clouds working together seamlessly
that is classified as the hybrid model.

The 3 service models:

Are based on the three layers in a computing stack:
 infrastructure
 platform and
 applications

these cloud computing models are referred to as:

 infrastructure as a service (IaaS)
 platform as a service (PaaS) and
 software as a service (SaaS)
 In an infrastructure as a service model, you get access to infrastructure and physical
computing resources such as:
 servers
 networking
 storage and
 data centre space
without the need to manage or operate them in a platform.

As a service model you get access to the platform, that is hardware and software
tools, usually those needed to develop and deploy applications to users over the
Internet.

Software as a service is a software licencing and delivery model in which software

and applications are centrally hosted and licenced on a subscription basis and
sometimes also referred to as on demand software.
Cloud Native Applications
Traditional monolithic applications are built out of one piece of software; applications
that tightly couple the user interface, business-logic layer, and data-layer.
They rely on load balancing and stateful applications to spread user workloads
across multiple servers, which makes them difficult to scale, and can result in a poor
user experience if there are server outages.

A cloud native application is an application designed and developed to leverage the

advantages of cloud computing.
A cloud native application consists of microservices working together as a whole to
comprise an application and can be easily scaled.
These microservices are often packaged in containers, which are executable units of
software in which the application code is packaged along with its libraries and
dependencies so that it can be run anywhere.

In a cloud native app, the application code is designed, built, and delivered very
differently than it would be for conventional, monolithic apps.
Examining the cloud native solution stack will help you to understand where each
part of cloud app development takes place, and how it relates to other parts.

Here are the layers of the cloud native solution stack.

 The cloud infrastructure layer defines the environment. Cloud native apps are
developed for public, private, hybrid and multi-cloud environments.
 The scheduling and orchestration layer is all about control planes, like
Kubernetes, Istio, and Knative.
 The application and data services layer is all about backing services and
being able to integrate application code with existing services that may be
available on other clouds, or even on-premise.
 This layer defines the application runtimes, traditionally, or conventionally,
known as middleware and
 the Application Code layer holds the cloud native apps.
Everything that exists in the cloud should have a cloud native app design and
approach.

This means that application code needs to be instrumented with things like:
 standardized logging,
 standardized events,
 a standard catalogue that multiple microservices and cloud native apps can
use to match those logging and events and
 standardized tracing for microservices.

Everything that is standardized is something that development teams don’t have to

do themselves, they can buy into a commoditized system.
As time has passed and technologies have matured and emerged, many of the
services are being refactored lower down in this stack.
This means that core services can rely on standardized services, freeing up time and
resources for innovation at the application code layer.
The benefits of this commoditized stack for cloud native apps is the provision of
enterprise and engineering at scale, so that Cloud App developers can focus on the
functionality of their app, not it’s support system.
CNCF
The Cloud Native Computing Foundation (CNCF) hosts critical components of the
global technology infrastructure.
Founded by the Linux Foundation shortly after the release of Kubernetes 1.0 in
2015, it brings together developers and experts from influential tech companies to
agree on guidance for developing cloud native computing technologies.
CNCF founding members include IBM, RedHat, Google, CoreOS, Mesosphere,
Twitter, Intel, Cisco, Docker, and VMware.
Open governance is key for the CNCF.
Members collaborate to produce shared, standardized guidance for developing each
technology to support developers working in the Cloud.

The CNCF believes that:

 "Cloud native technologies empower organizations to build and run scalable
applications in modern, dynamic environments such as public, private, and
hybrid clouds. Containers, service meshes, microservices, immutable
infrastructure, and declarative APIs exemplify this approach.”

The mission of the CNCF is: To make cloud native computing ubiquitous, and To
make cloud native innovations accessible for everyone.

To achieve its goals, the CNCF considers itself responsible for:

 Stewardship of projects:
o Ensuring that the technologies are available to the community.
o Ensuring that trademarks and logos are used appropriately. and
 o ensuring that brand and image are maintained across
implementations, especially for uniform user experience and
compatibility across applications.
 Fostering the growth and evolution of the ecosystem. Evaluating additional
technologies to add to the ecosystem, working to encourage the community to
deliver them, and integrating them if advance the general agenda. Providing a
way to foster common technical standards. Promoting technologies.
 By holding events and conferences each year, CNCF promotes technologies,
provides education around them, and creates an opportunity for developers to
collaborate on projects together.
 Making technologies accessible and reliable. Offering fully integrated and
qualified builds of each of the constituent pieces, on a well-defined cadence
across the reference architecture.

To build its ecosystem of cloud native technologies, CNCF encourages member

companies to submit project assets to the CNCF review board, which is called the
Technical Oversight Committee or TOC.
The goal is to have a growing collection of projects that relate to and integrate with
projects already accepted into the CNCF.
CNCF technology projects are catalogued with a maturity level of Sandbox,
Incubated, and Graduated, in ascending order.
The level of the project is determined by factors like the rate of adoption, longevity,
and the reliability of the open-source project for building a production-grade product.
The more mature the project is, the more marketing and promotion effort CNCF
provides.

To help companies navigate the cloud native landscape, CNCF provide a trail map
that illustrates the recommended path through the cloud native landscape.
The trail map leads you through implementing cloud native computing technologies
in the following sequence:
  Containerization,
 CI/CD,
 Orchestration and application definition,
 Observability and analysis,
 Service Proxy, Discovery, and Mesh,
 Networking, policy, and security,
 Distributed database and storage,
 Streaming and messaging,
 Container registry and runtime, and
 Software distribution.

At each step, companies can decide whether to develop and implement the
technology themselves, use a vendor offering, or not implement that technology at
all.
Hybrid Cloud
What makes a hybrid cloud?
A hybrid cloud is a combination of one or more public clouds and one or more
private
cloud environments.
Public clouds are hosted by external vendors, with multiple tenants on a single
hardware platform, and can include servers in multiple locations.
A hosted private cloud is maintained by an external vendor for one organization.
An on-premises private cloud belongs to a single organization who hosts and
manages their own cloud space.
Private cloud provides maximum control over the computing environment and data,
which is especially important, or even mandatory if your company deals with highly
sensitive data or must comply with strict industry or governmental regulations.
On-premises (legacy) data centre servers require that organizations install and
maintain their own on-premises hardware and software.
Public clouds and private hosted clouds enable organizations to consume PaaS and
IaaS on demand.
Organizations can quickly update their platforms and infrastructure with the latest
technology, mitigating technology investment risks.
On premises private clouds require that organizations plan ahead for storage and
memory upgrades.
On premises legacy data centres face the most risk with commitments to longer-term
storage and memory technology.
With platform and infrastructure needs rapidly changing, many organizations use
cloud to free their developers from concerns about storage and memory,
empowering them to focus on business needs.
Security as a Service is a SaaS capability offered by both public cloud and private
hosted cloud vendors.
Vendors secure the hardware, enabling hosted organizations to focus on data and
application security and development.
On premises cloud and legacy data centres must allocate resources to secure their
hardware, data, and applications.

Security as a Service is a SaaS capability offered by both public cloud and private
hosted cloud vendors.
Vendors secure the hardware, enabling hosted organizations to focus on data and
application security and development.
On premises cloud and legacy data centres must allocate resources to secure their
hardware, data, and applications.

Public and hosted private cloud tenants can access the IBM Cloud catalogue of
tested, deployable database, API, and end-user applications, saving their
organizations development and deployment time.
On premises cloud and data centre locations, with some exceptions, need to build in
additional time and money for database, API and end-user application development,
testing and deployment.

Here are some additional hybrid cloud benefits:

 IBM Cloud offers Cloud Packs that enable open data access, within or across
clouds applications, vital for Digital Analytics Programs (DAPs). These
solutions help you run containerized software and middleware consistently
whether on cloud or on premises.
 Hybrid integration platforms (HIPs) intelligently manage hybrid cloud
automated platforms and systems.
 DAPs and HIP technologies combined enable organizations to track and
control the resources and manage dynamic hybrid IT architectures.

IBM offers Cloud Packs for both off premises and on premises hybrid and multi-cloud
environments.
Preparation for Modernization
Application modernization is the process of taking existing legacy applications and
modernizing the underlying platform infrastructure, deployment strategy, and the
code architecture to increase developer productivity and reduce costs.

Modernization approach includes refactoring into cloud-native microservices and re-

platforming traditional apps on container runtimes.

Containerization refers to the ability to take your existing software with minor updates
to move to the cloud.

Refactoring means changing and extending the application over time to enable an
easier move to the cloud.

Finally, the goal is to transform into a cloud native application with an architecture
built on loosely coupled microservices and API first architecture.

This modernization effort touches the build, deploy, and run stages.

Modernizing your application has some immediate benefits:

 Increased developer efficiency. Get rid of “it works on my machine” issue.
Everybody is using the same containerized environment and, therefore,
reproducing and fixing bugs is easier.
 Operational Optimization. Generally, operations dictate how fast applications
are written. With modernization, DevOps pipelines need to be set up once.
They then run automatically when new code is committed or pull requests are
merged.
  Easier deployment and maintenance. Code is replaced instead of patched in
this modern application environment. This reduces time to cloud substantially.
 Modernization helps make the application ready for the cloud. Using standard
containers can help you reap the benefits of in-built scalability and flexibility of
the cloud.
 The result of all these benefits is lower costs and better developer
productiveness.

One of the more popular patterns for modernization involves refactoring and
breaking down legacy monolithic applications into a collection of small, loosely
coupled microservices.

Each microservice can be aligned to a feature or a business function.

The application is broken down one service or feature at a time until the whole
application is moved over. This way, you have strangled the monolith.

The second approach is not to touch the existing application but add any new
features and capabilities using microservices.

The third approach is to refactor the code to lift-and-shift portions of the application.
While this may be possible, a complete restructure of the application to run on the
cloud provides more benefit in the long run.

An alternate approach is to leave the complex parts of the application as is and

expose the functionality via Application Programming Interfaces or APIs.
The new solutions can talk to the API instead of the older legacy application.
This migration to cloud runtime may involve one or more clouds, while others may
move to public or private clouds.
This last approach moves the monolith to a runtime so it can benefit from scalability
features provided by the cloud.
Continuous Integration/Continuous
Delivery - SRE, TDD
Test Driven Development (TDD)
Continuous Integration and Continuous Delivery also known as CICD.
Site Reliability Engineering (SRE)

Test-driven development is the practice of creating tests before writing code.

This ensures that every line of code written is backed by a test.
TDD follows the red-green-refactor pattern where it is necessary for a test to fail first
before writing a feature.
The next step is to write just enough code to make the test pass or green.
Finally, refactor the code base to eliminate any duplicate code and potentially add
abstractions to make it more extensible. Since development is led by testing first,
you can also write functional and acceptance tests and are not limited to unit tests.

Test Driven Development by its very definition ensures that all production code has
been tested and passes at least one test.
TDD makes the code base more flexible and extensible as the architecture requires
developers to think of features as small units of code that are tested independently
and integrated with the other pieces.
This leads to loosely coupled modules that work well with each other.
Ultimately, this pattern is a natural fit for the continuous delivery model, where code
is automatically and continuously pushed to production.
TDD ensures the code is robust and catches any failures before deployment.
CI/CD is an approach to software development where you build and deploy your
software so that it can be released into production at any time.
DevOps teams work with developers to build pipelines that continuously test the
code before releasing into production.
This leads to a mindset where consequences of breaking a build are less severe,
encouraging teams to work more closely with each other.
Continuous delivery naturally favours more frequent builds with small number of
changes in each build instead of doing a big deployment with many code changes.
This use of automated pipelines that ensures code is delivered continuously through
the test and production environments in a repeatable and orderly fashion ensures
less breakdowns in production.
While Test Driven Development and CI/CD are crucial to deliver usable software,
efficient operations are essential to create reliable and scalable solutions. An SRE or
Site Reliability Engineer bridges this gap between development and operations.
They spend at most 50% of their time on improving existing operations to reduce
failures and future efforts and the other 50% on development tasks like creating new
features and implementing automation.
Any additional workload is shared with the development teams.
SREs embrace risk in a controlled fashion instead of avoiding it completely.
They use error budgets to determine how much time the system can be down when
making changes. This budget is in turn defined by service-level-agreements (SLA) or
intended service-level objectives (SLO).
Module 1 Summary
At this point in the course, you know:

 A cloud native application consists of microservices working together to

comprise an application that is easily scalable.

 Containers are executable units of software in which the application code is

packaged along with its microservices, libraries, and dependencies so that it
can be run anywhere.

 The CNCF is an independent body that provides guidance on the use and
evolution of cloud native technologies.

 It helps participating companies by providing marketing and support for their

projects.

 Hybrid cloud infrastructure is a combination of hosted public and private cloud

spaces.

 Application modernization involves building or refactoring existing legacy

applications to enable them to run on the cloud.

 Application modernization helps improve developer productivity and reduce

costs.

 TDD, CI/CD, and SRE are approaches that enable rapid development and
reliable deployment.
IBM Cloud Overview: IaaS, PaaS, and
Runtimes
IBM Cloud is an open cloud computing platform that combines infrastructure as a
service (IaaS) with platform as a service (PaaS), and includes a catalogue of diverse
cloud services, which can be used to rapidly build and deploy business applications
or infrastructure.
As an IaaS, it allows developers fine-grained control over the infrastructure on which
their apps are deployed. Developers can deploy high-performance, bare-metal
servers, virtual servers, containers, and cloud storage, in IBM Cloud data centre
locations around the world.
As a PaaS, it provides developers access to IBM software for integration, security,
transaction, and other key functions, and software from IBM Business Partners. The
application types can range from web, mobile, big data, and smart devices to the
Internet of Things.

IBM Cloud enables you to deploy high-performance compute and storage

infrastructure in nearly 60 IBM Cloud data centres around the world that are
automated and standardized to provide a seamless global platform for cloud
resources.
In addition to virtual servers, IBM Cloud offers bare metal servers, which provide the
raw horsepower that many organizations require for processor-intensive and disk
I/O-intensive workloads.
Many organizations favour IBM Cloud because of the easy access it provides to bare
metal servers. IBM Cloud also allows you to deploy containers, storage, and
networking resources across the world-wide data centres.
A catalogue of services enables you to deploy, access, and manage the deployed
infrastructure. The services that are available in IBM Cloud might change over time,
as new services are developed, and older services are deprecated.

As a PaaS provider, IBM Cloud allows you to build, manage, and run applications,
such as web, mobile, big data, smart devices, and Internet of Things.
IBM Cloud uses Cloud Foundry, which is an open source platform as a service
offering that provides a choice of clouds, frameworks, and application services.
Cloud Foundry provides the monitoring, deployment, and logging tools for hosting
apps.
IBM Cloud also adds the following enhancements to Cloud Foundry:
 Extends Cloud Foundry with services from IBM and IBM partners.
 Provides a scriptable command-line interface (CLI).
 Provides integration with development tools to ease the deployment process.
 DevOps services provide an online code editor, a build pipeline, and a version
control system.
IBM Cloud runs on IBM Cloud data centres locations around the world.
IBM Cloud enables application developers to focus on application capabilities by
providing the following resources on the cloud:
 Runtimes on which to run applications.
 A catalogue of selectable services, such as databases, mobile support,
analytics, artificial intelligence, and security, which are used to build
applications.
 Ability to integrate with data from the organization and traditional workloads
that are running in on-premises systems.
 DevOps capabilities and tools, including code-editors, version control,
deployment pipelines, and hosting, monitoring, and scaling apps.
Integration services allow applications to access traditional workloads that are
running in the organization’s on-premises environment.
The services and runtimes available in IBM Cloud might change over time, as new
services and runtimes are developed, and older services are deprecated.
With IBM Cloud, developers are given a choice of runtimes on which to run their
applications.
You can run your app using a particular runtime, without the need to manage the
underlying infrastructure.
A runtime is a set of resources that is used to run an application.
Each runtime features an associated build pack, which is a collection of scripts that
prepare your code to run on IBM Cloud.
Runtimes are provided by IBM or through Community Build packs.
Consider the following points:
 The IBM runtimes include Liberty for Java, SDK for Node.js, and Runtime for
Swift.
 IBM Cloud and Cloud Foundry support more runtimes through the Community
Build packs. This open-source community features written build packs for
other runtimes, such as Go, PHP, Python, Ruby, and Tomcat.
 The following runtimes are available for Java: Tomcat: An open-source Java
web application server.
 Liberty for Java: IBM WebSphere Liberty is a Java EE application server
which can deploy any Tomcat application.
 It also offers support for more Java web features for example, Message
Beans and JMX.
Note that the available runtimes in IBM Cloud can change.
IBM Cloud Overview: Services, Regions
and Cloud Foundry

IBM Cloud provides a broad range of pre-built services (from IBM and third-party
providers) that can be used when assembling your application.

Watson services enable you to add the power of artificial intelligence to your
application with speech, vision, and natural language processing APIs.

Data & Analytics services help you to get data from integrated cloud databases, build
data-driven applications, and analyze your data.
In addition, services in the following categories help you to develop key features
within your application:
 Integration services: APIs: Create, manage, enforce, and run APIs
 Integrate: Access traditional workloads running in the organization’s on-
premises environment
 Mobile: Use mobile backend infrastructure to build, monitor, and test mobile
apps.
 Internet of Things: Communicate with connected devices, sensors, and
gateways.
 Functions: Execute in response to incoming events (based on Apache
OpenWhisk).
 Application Services: Many application services, such as Blockchain.
Message Hub, WebSphere Application Server, Business Rules, and other
application services on the cloud.
 DevOps: Tools to help innovate new applications faster and cheaper.
 Security: Build security into your application design.
 Infrastructure services help you to manage the underlying infrastructure your
application runs on.
Note that the services available in IBM Cloud can change.
A region is a defined geographical territory to which you can deploy your
applications. Locations are data centres within the region in which hardware is
deployed.
Locations are not specified during application deployment. Not all IBM Cloud
services are available in all regions.
Not all IBM Cloud services are available in all regions.

You can choose to deploy your application to a single region or multiple regions.
Consider the following points: For low application latency, select the region that is
nearest to your users.
To meet certain countries’ data security requirements, select the region where you
are required to store the application data. For high availability, select multiple
regions. If your application fails in one region, it is still available on another region.
You should use similar criteria when choosing a location to deploy infrastructure.
Within the IBM Cloud console, the region is automatically set to the closest healthy
region. To switch to another region, click the user account link, expand the Region
menu and select the region. If you use a Lite Account, you can use only one region
for your applications and services.

Cloud Foundry uses the Diego architecture to manage the application life-cycle for
deploying and starting the application on Cloud Foundry.
As a developer, you interact with IBM Cloud by using your web browser or the CLI.
When you create an app and deploy it to Cloud Foundry, the IBM Cloud environment
determines an appropriate virtual server to which to send the app.
The virtual server is chosen based on several factors, including the hardware/file
system that is required by the app, and the load that is on the machine.
After a virtual server is chosen, the following tasks are completed:
 An application manager on the virtual server installs the appropriate
framework and runtime for the app.
 The app is deployed into that framework.
 When the deployment completes, the application artifacts are started.
 When the app is deployed, if it has a web interface (as for a Java web app), or
other REST-based services (such as mobile services exposed publicly to the
mobile app), users of the app can communicate with it by using normal HTTP
requests.
 Each virtual server has multiple apps deployed on it.
Building in the IBM Cloud
You can build applications in IBM Cloud by using IBM Cloud Foundry. Cloud
Foundry is a platform that provides a developer focused environment, where you can
build different kinds of applications powered by DevOps and Security:
 Front-end, Back-end, Mobile, Web, Internet of Things, Blockchain, Enterprise
grade Messaging Apps, and Quantum.
Once your application is built and tested, you can deploy it using technologies like
serverless computing, IBM Cloud Foundry and Kubernetes.

The IBM Cloud Code Engine is a new service that provides a fully managed,
serverless platform to run your containerized workloads, including web apps, micro-
services, event-driven functions, or batch jobs. Code Engine even builds container
images for you from your source code.
Because these workloads are all hosted within the same Kubernetes infrastructure,
all of them can seamlessly work together. The Code Engine experience is designed
so that you can focus on writing code and not on the infrastructure that is needed to
host it.
Services hosted by IBM Cloud provide ready-to-use functionality that your
application can access. You can use predefined services provided by IBM Cloud,
which include database, messaging, push notifications for mobile apps, and elastic
caching for web applications, along with various machine learning and AI services.
You can build custom services to meet your needs.
These services might be simple utilities, such as functions for a runtime library, or
complex business logic for a business process modelling service or a database.

The IBM Cloud catalogue lists Services, Software, and Consulting resources.
Resources are entities such as Cloud Foundry applications, services, virtual
machines, and containers, that you can create according to your requirements. To
help you locate the resource you want to create, the IBM Cloud catalogue organizes
resources into Category, Provider, Pricing Plan, Compliance, and Release.

IBM Cloud catalogue features different types of resources: An infrastructure is a

resource that provides a fine-grained control over the computing infrastructure. A
platform is a resource that helps you rapidly build and deploy your application. In
platform resources, note that applications can be built by using Cloud Foundry Apps
or Starter Kits, which provide the runtimes and optionally other services to create
your applications and services enable you to easily add relevant functionality to your
application.
You can select infrastructure resources from one of the categories Compute,
Containers, Networking, Storage, etc. You can order physical bare metal servers and
virtual servers in the Compute category. The Container category provides an
alternative way to run and manage your application. Although containers allow more
control over the underlying infrastructure and configuration, they require more work
by the developer. For fine-grained control over computing resources, you can order
physical resources from the remaining categories.

IBM Cloud manages and maintains the infrastructure that runs your Cloud Foundry
applications. To support apps in varied scenarios, IBM Cloud supports multiple types
of infrastructure:
 IBM Cloud Kubernetes Service. Kubernetes containers provide more control
over the computing infrastructure to run the application and services through
Docker-like APIs. Docker packages software into standardized units that are
called containers. Containers are described later in this course.
 Virtual Servers. Virtual servers are software implementation of hardware that
runs applications. You can configure the operating system, server runtime
environment, and application. Use Virtual Servers when you want to control
the infrastructure right down to the operating system level.
 IBM Cloud for VMware Solutions. IBM Cloud for VMWare Solutions offers on-
demand deployment and management of VMware Cloud Foundation and
vCenter Server.
 Physical infrastructure resources. You also can deploy and use physical
infrastructure resources, such as bare metal servers, storage, networking, and
security, for fine-grained control over computing resources.
IBM Cloud supports the following infrastructure types:
 Containers include all the elements that an application needs to run, providing
greater control over the computing infrastructure by running the application
and services through Docker-like APIs.
Docker packages software into standardized containers.
The IBM Cloud Kubernetes Service combines Docker and Kubernetes to
deliver powerful tools, an intuitive user experience, built-in security, and
isolation to automate the deployment, operation, scaling, and monitoring of
containerized applications over a cluster.
You can create a Kubernetes cluster that consists of one or more VMs that
are called worker nodes.
Every worker node represents a compute host in which you can deploy, run,
and manage containerized applications. You can use and extend public
images, such as the IBM Integration Bus V10 Developer Edition, which you
can use to start developing your own integration solution. Containers give you
more control, but still do not require you to manage an operating system or
network. IBM containers resemble the popular open-source container engine
Docker but have some IBM Cloud specific features, such as their ability to
integrate with Cloud Foundry routers.
 Virtual servers are a software implementation of hardware that runs
applications that is similar to a computer. You can configure the operating
system, server runtime environment, and application. If you want to control
the infrastructure down to the operating system level, consider the use of
Virtual servers.
Containers and virtual servers share objectives:
 To isolate an application and its dependencies into a self-contained unit that
can run anywhere. They both remove the need for physical hardware, which
allows for more efficient use of computing resources.
 Virtual servers, or virtual machines (VM), provide hardware virtualization and
are created by using a hypervisor.
 The hypervisor virtualizes the physical hardware to create a software-defined
computer that runs its own operating system. Unless special software is
installed for cloud management, an operating system that is running on a VM
is unaware that it is running on VM.
 A container provides operating system-level virtualization.
 A container library such as Docker separates different user spaces for each
container. On the surface, these spaces might resemble a VM to a user. The
main difference between containers and VMs is that containers share the
operating system kernel with other containers that are running on the
machine, which is not the case with VMS. Therefore, you might see a VM
running Linux on a Windows server or Windows on a Linux server. However,
you do not see a container that runs Linux on anything other than a Linux
server.
The containers on that Linux server are separate user spaces on that Linux
server and the hardware is not virtualized.
 Data storage also is managed differently in containers. In VMs, virtual disks
are created and are similar to physical disks in that after you write something
to the disk, it stays there until you delete it.
With containers, you can make changes to the disk and then delete your
changes when you are done.
Getting Started with IBM Cloud Catalogue
Resources
In IBM Cloud, starter kits are packages of sample applications.
When you create an application by using starter kit, IBM Cloud configures the
services for the application.
IBM Cloud also provides the source code and documentation for the sample
application in the starter kit. A starter kit contains an application, its associated
runtime environment, and certain predefined services. Starter kits guide you as you
begin your application development, and help you get started quickly.
For example, you can select the Python Web App with Flask starter kit to host a web
application and accelerate development time of server-side scripts by using the web
app template and SDK.

A runtime is the set of resources that is used to run an application.

IBM Cloud provides runtime environments as containers for different types of
applications.
Runtime environments are integrated into IBM Cloud as build packs and are
automatically configured for use.
To create your own application, select from the following runtime environments as a
starting point: IBM runtime environments, which are supported by IBM build packs,
such as Liberty for Java.
Community runtimes, which rely on open source and third-party build packs, such as
Tomcat.
Runtimes start with an example application that you can customize to meet your
needs.
Runtimes do not include any services by default, but you can add and bind your own
services later.
IBM Functions is a Function-as-a-Service (FaaS) platform that executes functions in
response to incoming events. By using IBM Cloud Functions, you can focus on
writing code and building solutions without the hassle of setting up, configuring, or
maintaining servers.
You pay only for the time that your code runs, which means no excess capacity or
idle time. IBM Cloud Functions uses these basic concepts:
 Actions: A piece of code that you develop that performs one specific task. You
can create the action in various run times, including Node.js, Python, and
Swift 3.
 Triggers: Actions are triggered through REST APIs, or based on certain
events, such as Alarm-Based Trigger, Cloudant Change, and Messaging.
 Sequences: You create the flow of actions to complete one function.
 Rules: Rules link triggers to actions or sequences.
IBM Cloud Functions has the following benefits:
 Cost-Effective Computing: Pay only for the exact time your actions run, down
to one-tenth of a second; no memory, no cost.
 Automatically scale: Run your action thousands of times in a fraction of a
second, or once a week. Action instances scale to meet demand, then
disappear.
 Easy integration: Trigger your actions from events in your favorite services, or
directly by using REST API.
IBM Cloud catalogue includes several capabilities for mobile development.
The capabilities include:
 rapid development of mobile applications by using a web editor to create a
mobile application,
 test the mobile application by using cloud services, and
 gain insights into how your mobile application is being used.

Services are extensions to the cloud environment that IBM Cloud hosts and
manages. Predefined services provided by IBM Cloud include NoSQL and SQL
databases, the ability to send push notifications to your mobile app, and automated
language translation.
You can add services to your IBM Cloud application from the IBM Cloud catalogue.
Services provide a predefined endpoint that you can access from your application to
use the predefined functionality of that service.
The infrastructure for services is managed by IBM Cloud, and your app needs to
focus on the provided endpoint only.
You can bind more than one app to a service to share services between your apps.
Many IBM Cloud services are available, and more are being added.
The slide shows a sample of the available Watson AI services.
Creating and managing an IBM Cloud
Application
Let’s create an IBM Cloud application.
First, go to the dashboard and click Create resource.
Next, look in the catalogue and select the Compute category and click the Cloud
Foundry tile and then, select the runtime you want to use.
The following runtimes are now available as Cloud Foundry Apps:
 Liberty for Java,
 SDK for Node.js,
 ASP.NET Core,
 Runtime for Swift,
 Xpages,
 Go,
 PHP,
 Python,
 Ruby, and
 Tomcat.
Note that choices might change in future.
Enter your application name and hostname. Then, choose the region, organization,
and space, and select the pricing plan for this application.
Note that the free tier is only available in the Lite account. If you’re using the trial
account, the free tier isn’t available. If you are using the IBM Cloud Lite account, you
are not charged for any usage.

By default, IBM Cloud hosts your application on the mybluemix.net domain.

You do not share your memory and application instances with other IBM Cloud
accounts.
You must choose a hostname that is unique across all applications from all IBM
Cloud users.
You cannot create an IBM Cloud application with the same hostname that is used by
another application.
Your app’s name is different than its hostname and must be unique only within your
organization.
You can have the same app name as another user if the hostname is unique.
By default, IBM Cloud sets your hostname and your app name to be the same. The
app name is for your reference to use only in scripts, CLI, and to find your app within
the IBM Cloud UI.
The application’s hostname becomes part of the application’s route, which is how
users access your application over the internet.
Next, select your development style.
You can perform the following tasks:
Download Eclipse Tools for IBM Cloud, which allows you to work on Cloud Foundry
applications within the Eclipse integrated development environment.
Edit your app in your preferred text editor and use the IBM Cloud command line to
deploy. Optionally, use IBM Cloud DevOps Services to deploy your application with a
completely web-based approach.
The IBM Cloud Dashboard shows you the amount of memory that you are using in
your organization and the number of services that you are using in your space.
If you find that your organization is running low on memory, you can always stop an
application without deleting it and start it again later when needed. However, if you
are running out of available services, you must delete some services to free up
space.

To open the Application Details page, click the application name in the IBM Cloud
Dashboard. Here you can check and control status of your applications. View and
adjust the memory resources that are used and even start, stop, and restart your
application. You can also view the application in a browser and adjust the number of
instances.
To view the application route, click Visit App URL from the Application Details page.
The application route is the entry point for your application users and it lets you host
a REST service, web app, or web page. You can only access the application route if
the application is running. The application route must be unique across all applications in
the domain.
Creating an IBM Cloud Service and Web
App
You can add an IBM Cloud service to your application by clicking Create resource
from the application dashboard and then, selecting a service from the IBM Cloud
Catalogue.
You must then enter a name for the service and select a pricing plan for your
service. Plans allow you to choose different “sizes” for the service, such as how
much power you put behind it.
For example, with some services, you can choose if you share hardware or use
dedicated hardware.
You can bind the service to your application from this page, or leave the service
unbound.
If you leave the service unbound, IBM Cloud creates and provides credentials for
accessing the service, which you can access from within the service dashboard.
If you bind the service to an application, the credentials are in the application's
environment variables.

To bind the service to your application, browse to your Application Details page and
select the Connections tab on the left navigation bar, then click Create connection.
To bind a service to your application, hover over the compatible service and click
Connect.
A dialog box prompts you to restage the application.
Click Restage. Restaging the application makes the service available for use by your
application.
IBM Cloud allows you to choose one of the services that was created earlier to bind
it to your application.
IBM Cloud lists the services that you created that are compatible with your service
and runtime environment.
Some services are specific to certain runtimes, such as a Java Runtime monitor, and
might not be applicable or indeed usable from your application.
When you bind a service to an application, IBM Cloud creates a set of credentials to
access the service and places the connection information for this service in the
application environment variable, which is called VCAP_SERVICES.
Environment variables contain the environment information of a deployed application
on IBM Cloud.
IBM Cloud automatically populates the environment variable VCAP_SERVICES with
the services that you bind to your IBM Cloud application.
Use the user-defined environment variables for configuration settings, instead of
hard-coding the values in your application.
For example, you can save the web service endpoint, user name, and password for
a cloud-based database as a user-defined environment variable.
You can access the application environment variables from the Application Details
page by clicking Runtime on the left navigation bar then, clicking the Environment
variables tab.
To create a Web App, click the three horizontal bars that are next to the IBM Cloud
logo, choose Web Apps, and then, click Get Starter Kit. Web Apps contains starter-
kits that are pre-configured and integrated with various technologies that enable you
to quickly develop your web application. For example, Express.js React is a starter-
kit which provides a rich React front-end delivered from a Node.js application.
Introduction to Node.js
Node.js is an open-source language that runs on V8.
Being open source, means that node.js can run on Linux, Windows, and Mac OSX.
V8 is an open-source engine that was developed by Google for the Google Chrome
browser.
Developers often use JavaScript for client-side functionality.
Node.js is the server component in the same language.
Node.js is event-driven and uses asynchronous, non-blocking I/O.

With server-side JavaScript, Node applications process, and route web service
requests from the client.

1. In step 1, the user selects an option in the user interface, written in HTML and
CSS.
2. In step 2, this action by the user triggers JavaScript code that implements the
business logic on the client-side, for example, input validation.
3. In step 3, the JavaScript application makes a web service call over HTTP with
a JSON data payload. The REST web service, which is part of a node.js
application running on the node server, receives the HTTP request.
4. In step 4, the REST web service processes the request and returns the result
to the client as a JSON payload over HTTP.

Although developers can still use JavaScript for browser functionality in frameworks,
such as angularJS, Dojo, and jQuery, they can now use Node.js in the same
components of the architecture where they use Java, Perl, C++, Python, and Ruby.
Node.js is used in production by companies, such as Uber, Yahoo!, LinkedIn,
GoDaddy, eBay, and PayPal. It is event-driven and uses asynchronous, non-
blocking I/O.
Express.js is a highly configurable framework for building applications on Node.js.
It abstracts lower-level APIs in Node.js by using HTTP utility methods and
middleware Before you build your first Node.js app, let’s get familiar with the IDE and
some key Node.js concepts.

Express.js simplifies application development on Node.js. The following features

enable you to develop your application quickly:
1. Public: public assets like image, CSS, and javascript.
2. Templates/views: server-rendered HTML that is sent back to the client in
response to requests.
3. Routes: defines endpoints that accept and process client requests.
4. Server.js: a file which contains the main application code.
5. Package.json: contains metadata information about the project including
dependencies, scripts, and so on.

Node.js is the server-side component of JavaScript.

Using Node.js can improve application performance and express.js is a framework
that helps you build Node.js applications.
Preparing to use CLIs
IBM Cloud CLI (ibmcloud CLI) provides the CLI to manage applications, containers,
infrastructure, services, and other resources on IBM Cloud.
It also bundles cf CLI in its installation to manage Cloud Foundry resources on IBM
Cloud.
The Cloud Foundry command-line interface (CF CLI) is a client tool from the Cloud
Foundry community.
You can use this tool to manage Cloud Foundry applications and services on IBM
Cloud. Continuous delivery using DevOps practices.

Cloud Foundry is an open-source platform as a service (PaaS).

It provides an open-source CLI that is available for multiple platforms.
The IBM Cloud command-line interface (ibmcloud cli) provides an easy way to
manage all your resources on IBM Cloud from a workstation.
Use the ibmcloud CLI to log in. The Cloud Foundry command-line interface (cf CLI)
is used to manage Cloud Foundry resources on IBM Cloud.
You can use the ibmcloud CLI, commands to log in to IBM Cloud and deploy an
application to IBM Cloud, as well as to manage resources.
Alternatively, you can use cf CLI to deploy Cloud Foundry applications and manage
Cloud Foundry resources on IBM Cloud.

IBM Cloud integrates into the Eclipse IDE.

However, you might still want to use command-line tools in the following scenarios:
 You need a tool that is quick to install and has a minimal footprint on your
development workstation.
 You want to automate the management and deployment process with shell
scripts or
  you want to use different tools for different projects to provide some project-
level separation.

You can review the documentation for the command-line tool from Getting Started in
Application Details.
To work with IBM Cloud by using the CLI, you can use ibmcloud CLI or cf CLI.
Note that IBM Cloud CLI enables you to manage applications, containers,
infrastructures, services and other resources in IBM Cloud. It also bundles cf CLI, to
manage Cloud Foundry resources on IBM Cloud. CF CLI allows you to manage only
Cloud Foundry resources on IBM Cloud.

ibmcloud CLI allows you to manage applications, containers, infrastructures,

services and other resources in IBM Cloud.
CLI allows you to automate the management and deployment process with shell
scripts and cf CLI enables you to manage Cloud Foundry resources on IBM Cloud.
Using CLIs
The IBM Cloud CLI provides the command line interface to manage all resources on
IBM Cloud.
Download the most recent IBM Cloud Command-line Interface installer from the IBM
Cloud Docs, IBM Cloud CLI and Developer Tools web site
(https://console.bluemix.net/docs/cli/reference/bluemix_cli/get_started.html).
This IBM site includes a list of downloadable installers for Mac OS X, Linux, and
Windows.
After you download and install the installer to your local workstation, open a
Command Prompt window on your system and run the command ibmcloud --version
to check if the tool works successfully in your environment.
Log in to IBM Cloud by using the ibmcloud CLI. When you log in by using ibmcloud,
you also must specify the account.

After you specify the account, you can specify the resource group or Cloud Foundry
organization. If you are using a federated ID, use “ibmcloud login –sso”. A URL is
supplied for you.
Open this URL in a browser, sign in and paste your one-time passcode into the CLI
to authenticate.
The use of the ibmcloud target command allows you to select the cloud foundry
organization and space on which you work.

The cf CLI can be used to manage Cloud Foundry applications and services on IBM
Cloud.
Download the most recent cf installer from the Git project, which includes a list of
installers and binaries downloadable for most systems.
Generally, download an installer because they are faster and easier to use than the
raw binaries.
After you download and run the installer, open a command prompt on your system
and run the command line tool by entering cf --version.
Note that IBM Cloud CLI bundles cf CLI.
All cf commands can be used with IBM Cloud CLI by using the following syntax:
ibmcloud cf <cf_command> Log in to IBM Cloud by using the CLI.
The login command requires the following parameters: Cloud Foundry API endpoint,
username, password, organization name and space name.

You can use the command-line client with other Cloud Foundry regions by pointing
to other API endpoints; for example, api.eu-gb.bluemix.net for UK region. You can
use the flags -a, -u, and so on to specify the parameters at the command line.
If you do not specify one of the parameters, the command-line utility prompts you to
enter it later.
In the example that is shown in the slide, the password was not entered; therefore,
the command-line utility prompts the user to enter the password. If you use a
federated ID, use cf login –sso.
A URL is provided for you.
Open this URL in a browser; then, login and copy your one-time passcode and paste
it in the CLI to authenticate.

The use of the push command uploads, deploys, and starts the application in your
IBM Cloud space. When you are ready to deploy your application to IBM Cloud
complete the following steps: Browse to your application root directory where the
manifest.yml is stored then Run the cf push command. "Pushing your app" is the
terminology that is used to indicate that you are going to deploy the latest changes of
your app to IBM Cloud.
Remember that when you push your application, it overwrites the current contents of
your application in your IBM Cloud account. Write down the application route. You
can test your application with this entry point. This slide shows the command-line
utility accessing a manifest file.
You can control various aspects of the deployment, such as the amount of memory
an application receives and the route of the application, by specifying them as flags
in the command. However, you can also store these settings in a manifest.yml file to
make the command you need shorter to enter in later iterations of your application.

After the command-line utility finishes pushing your application, browse to the route
name you wrote down in the previous step to test whether the application is running.

 Node.js is the server-side component of JavaScript; it can improve the

performance of your application.
 Express.js is a framework that helps you build Node.js applications.
 CLIs allow you to automate the management and deployment process with
shell scripts.
 ibmcloud CLI allows you to manage applications, containers, infrastructures,
services, and other resources in IBM Cloud.
Introduction to a DevOps Approach
The term DevOps comes from merging the words development and operations.
DevOps is a software methodology that integrates application development and IT
operations.
With a DevOps approach, teams can deliver code faster to production.
They can use market feedback to iterate continuously.

Before DevOps, there were two teams that were responsible for code delivery: the
Development team and the Operations team.
1. The development team designed the code, delivered new features, fixed
bugs, and tested the code.
2. The Operations team deployed the code to the different environments,
maintained the uptime on production, and diagnosed failures.

With DevOps, both teams work together to support the software lifecycle, from code
design to deployment to production.
You can use DevOps processes and tools to automate the build process, code
testing, deployment to the different environments, and monitoring.
Developers actively and continuously perform tasks to keep the automation,
pipelines, and other entities in this realm up to date and even improve them, as well
as develop code.

DevOps provides many benefits:

 You can work from code to production in minutes: Work on your own or use
the collaboration tools to work with a team.
 In minutes, you can go from source code to a running app.
 Accelerate app delivery: Innovate like a startup, and scale for the enterprise.
 You can host an open-source project, run a hackathon, or start a skunkworks
project.
 DevOps code is continuously delivered and integrated into the main shared
repository.
 Deploy with confidence: Leverage the repeatability of the process by using
automation to ensure that the same steps are executed every time you
deploy.
 Leverage automated testing as a quality gate before deploying code to a
specific environment, or in some cases, to enable the monitoring or testing of
the code in a live environment.

The IBM Cloud Catalogue provides services to enable end-to-end DevOps, such as
Auto-scaling, Monitoring, and Continuous Delivery.
You can access these services from the catalogue by selecting the Developer Tools
category.
IBM Cloud Continuous Delivery Overview
Continuous Delivery is a DevOps service that you can use to build, test, and deliver
applications.
You can use toolchain to:
 Create integrated DevOps open toolchains to enable tool integrations that
support your development, deployment, and operations tasks.
 Edit and push your code from anywhere by using the web-based IDE.
 Create, edit, run, and debug code, and complete source-control tasks in
GitHub.
 Seamlessly move from editing your code to deploying it to production.
 Collaborate with your team and manage your source code with a Git
repository (repo) and issue tracker.
 Manage Git repos through fine-grained access controls that keep code
secure.
 Deliver continuously by using automated pipelines.
 Automate builds, unit tests, and deployments and
 be ready to release into production at any time.

A toolchain is a set of tool integrations that support development, deployment, and

operations tasks.
Toolchains can include open-source tools, IBM Cloud services such as IBM Cloud
DevOps Insights, and third-party tools such as GitHub, PagerDuty, and Slack.
You can use a toolchain collaboratively and make operations repeatable and easier
to manage.

In Web IDE, you can develop code such as Node.js, Java, or other languages.
No software other than your web browser is necessary.
Web IDE saves your current work in a cloud-based file directory, which is known as
the local repository. You can also configure the build, deploy, or test scripts within
Web IDE.
IBM Cloud provides Eclipse Orion as the Web IDE. You can also use a desktop IDE
with DevOps services.
For source control management (SCM) and issue tracking, Continuous Delivery
creates a Git repo as a change management system.
The local repository is a copy of your latest edits before you submit your work to the
SCM system.
The Git repo, which is the remote repository, is hosted on the IBM Cloud DevOps
infrastructure.
The issue tracker tracks your work including defects, enhancements, and tasks.
The issue tracker is hosted by IBM and built on GitLab Community Edition.
Track issues and share ideas through the issue tracker.
Review code and enhance collaboration through merge requests.
Document projects on the wiki system.
The Delivery Pipeline tool automates the process of building and deploying your
code as an IBM Cloud application. Build, test, and deploy in a repeatable way with
minimal human intervention.
Creating IBM Cloud Continuous Delivery
Toolchains
To add Continuous Delivery to your application, complete the following steps:
1. First, in the IBM Cloud dashboard, select Continuous Delivery.
2. Select a region closest to you and select a price plan. The free Lite plan is the
default selection.
3. Optionally, update the service name.
4. Now, to create the service instance, click Create. When you create the
service, the Getting Started page appears.
5. To add your first toolchain here, click Create a Toolchain. You can also add a
toolchain from the catalogue.
6. Another way would be to add a toolchain to an existing application by
enabling Continuous Delivery.
7. You can create a toolchain from a template or build one from scratch by
enabling an application for continuous delivery. The toolchain will use the
Continuous Delivery service under the covers. Depending on how the
toolchain was created, it might contain some preconfigured tools.
8. You can add additional tools by selecting Add tool.

The user interface (UI) to create a toolchain groups the tools into the following four
phases:
1. THINK is for planning the application by creating bugs, tasks, or ideas using
the Git repo Issue Tracker.
2. CODE is for implementing the application by providing a GIT repo as an SCM
system and a Web IDE to edit your code online. In the repository, you can
specify whether to clone a repository or start from scratch by selecting New in
the repository type.
3. DELIVER: is for configuring the delivery pipeline. It allows you to specify
automatic build, deployment, and testing of your code after a developer
pushes new code to the Git repo and
4. RUN is for running the application in the IBM Cloud environment.

The collective power of a toolchain is greater than the sum of its individual tool
integrations. In the Tool Integrations section, select each tool integration that you
want to configure for your toolchain. Consider the following examples:
 If you configure Sauce Labs, the toolchain is set up to enable adding Sauce
Labs, which you can use to add test jobs to the pipelines.
 If you configure PagerDuty, the toolchain is set up to send alert notifications to
the specified PagerDuty service when a major issue occurs.
 If you configure Slack, the toolchain is set up to send notifications to the
specified Slack channel and
 if you configure GitHub for source code tool integration, the sample repo can
be cloned or forked, for example, into your GitHub account.
Web IDE Features
The Web IDE features in Continuous Delivery provide the following capabilities:
 IBM Cloud uses Eclipse Orion Web IDE. No installations are required. You
can use a browser to code. It’s a full-featured environment for writing your
application code in your web browser, with rich code completion capabilities
for CSS, HTML, and JavaScript. The Edit Code feature provides a workspace
to develop source code and configuration files. From the Run bar, you can
deploy, stop, and run applications, and view the logs.
 IBM Cloud Live Sync features available for Node.js applications include:
o Live Edit, which allows you to make changes to your application from
the Web IDE without the need to redeploy it.
o When a Node.js application is in Live Edit mode, you can shell into it
and debug it.

Let’s examine the Edit Code perspective.

When you select a file, the editor displays the contents on the right side of the page.
You can review and edit source code, configuration files, and other artifacts.
This view is for your local workspace on IBM Cloud.
To commit the code changes, switch to the GIT view.
When you open a Node.js script file, the editor provides real-time validation and
syntax checking of the source code.
It uses tools such as JSHint, which is a JavaScript code quality tool that helps detect
errors and potential problems.
A preview window flags warnings and errors.
The code completion feature displays any available methods or properties based on
the context, including third-party modules that you imported in the script.
For example, as we see here, the code completion feature displays functions and
templates for the Express web application framework for Node.js because this point
is the cursor point.
You can use templates to add blocks of code for common tasks such as error
handling or object creation.
To use the code completion shortcut, place your cursor within the editor and press
Ctrl + Space bar.
You can quickly build and deploy your application to a test environment on IBM
Cloud without committing your code to the Git repository.
Consider these six features:
 The status area displays the launch configuration that the run bar uses during
the build and deploy task.
 To build and deploy the code in your user directory to your IBM Cloud
account, click the Play icon from the Run bar. To stop the application, click the
Stop icon.
 To open the application route, click the Open Deployed App icon.
 To open application logs, click the Open Logs icon.
  To access the dashboard from the same bar, click the Access icon and
 to deploy only the changes that you checked in to the repository, use Delivery
Pipeline.

If you are building a Node.js application, you can use IBM Cloud Live Sync to quickly
update the application instance on IBM Cloud and develop without redeploying.
When you make a change, you can see that change in your running IBM Cloud
application immediately without the need to recompile and redeploy.
IBM Cloud Live Sync works from the Web IDE. Its features for Node.js applications
include Live Edit and Debug.
With Live Edit, you can change a Node.js application that is running in IBM Cloud
and test in your browser immediately.
Any changes that you make in a synchronized desktop directory or in the Web IDE
are instantly propagated to the application’s file system.
The Debug features works only in the Chrome browser. You can edit code
dynamically, insert breakpoints, step through code, restart the runtime, and perform
other debug functions.
Source Code Management (Git Repo) and
Issue Tracker
You can collaborate with your team and manage your source code with a Git
repository (repo) and issue tracker that is hosted by IBM and built on GitLab
Community Edition. The toolchain does not bind you to use Gitlab.
GitHub is also supported.
Alternatively, you can also use other version control systems by adding them as
tools in the toolchain.

The Git Repos and Issue Tracking tool integration supports teams in many ways.
You can:
 Manage Git repos through fine-grained access controls that keep code
secure.
 Review code and enhance collaboration through merge requests.
 Track issues and share ideas through the issue tracker and
 document projects on the wiki system.

By default, enabling Continuous Delivery for an application creates a Continuous

Delivery toolchain for your application.
This toolchain includes a Git repo that is based on GitLab.

Git is an open-source change management system.

The Git repo perspective in the Web IDE supports common Git commands to
manage your code.
You can also develop your application on your own workstation and commit your
changes to the Git repo with a standard Git client.

Switch to the Git perspective from the navigation bar on the left side of the Web IDE.
You can review the commit history with the time and date for each commit.
You can also perform actions for each commit such as viewing the files committed
and reverting changes that were introduced by any commit.
The Working Directory Changes pane detects any updated files in the user directory
files.
Click a file to review the changes that were made in that file.
Select the files that you want to commit and add a descriptive comment about the
change.
Click Commit to commit the changes to your local repository.
The Outgoing pane lists the files that you want to commit to the remote repository.
View the outgoing changes and then click Push to push the committed changes to
the remote repository.
If another user updated the files in the remote repository, the incoming pane lists the
updated files.
You can still develop your application on your own local workstation.
If you do not have a Git client installed, download and install the latest version of the
Git client from: https://git-scm.com/downloads.
To verify that the installation is successful, issue the git --version command from the
command line.
To find the URL of the Git repo that is associated with your application, click View
toolchain from the Application Details, then click Git.
To start, retrieve a copy of the IBM Cloud application source code by using the git
clone command.
Issue git clone $git-URL on your Command Prompt.
After you have a copy of the source code, use a text editor or integrated
development environment to write and test your application.
You can get the Git repo address from the toolchain or by using the IBM Cloud
command line interface (CLI).
To check whether another developer on your team updated the source code, run the
git status command.
Save the updated source code by running the git add command to stage the files to
be committed.
Then run the git commit command and enter a message for the history log to commit
all the added files to your local repository.
Finally, run the git push command to send your committed changes to the remote
repository.
Issue Tracker is the tool for tracking items that require resolution or improvements in
a project. Issues can be bugs, tasks, or ideas to be discussed. Issues are searchable
and filterable.
To create a bug or task, complete the form.
Then click Submit issue.
Build and Deploy Automated Delivery
Pipeline

By default, Continuous Delivery automatically runs the build and deploy tasks when
you commit changes to the Git repository (repo).
The pipeline also features a "run" icon that runs a stage of the pipeline but only runs
on committed code or builds, depending on the stage.
You can access the Continuous Delivery toolchain by clicking View toolchain from
the Application Details page.
To navigate to the pipeline, click its tool card in the toolchain overview page.
Jobs are Build, Deploy, and Test.
They are grouped into stages.
You can change the order of the stages by dragging and dropping.
You can also configure a stage to include more than one job of the same type.
For example, you can have a stage that features one Build job, one Deploy job, and
two Test jobs.
In fact, the pipeline is completely customizable.
You can explicitly state what branch should trigger a build,
you can run various tests when a pipeline is triggered, and you can tell the pipeline
to create output in each stage and pass it to the next stage in the pipeline.
The default build script is simple: It takes the files that are pushed to the remote Git
repo and triggers IBM Cloud to build your code in the server runtime.
You can customize the settings for the server runtime through the manifest.yml file.
After the Build stage completes successfully, the Deploy stage runs.
Delivery Pipeline deploys the built files to your IBM Cloud space.
By default, Delivery Pipeline runs the Build stage when a client pushes any change
to the master branch in the remote Git repo.
If you do not want to automatically push your changes to your IBM Cloud account,
change the State trigger setting to Run jobs only when this stage is run manually.
You can extend the features of the Build stage by adding jobs.
Although by default Delivery Pipeline names this stage configuration the Build stage,
you can also add Test or Deploy jobs.

Builder Type supports types like:

 Simple,
 Ant,
 Container Registry,
 Gradle,
 Grunt,
 IBM Globalization Pipeline,
 Maven,
 npm : For Node.js projects,
 NPM Build,
 and Shell Script.
The simple build type runs the appropriate build scripts for your runtime
environment.
For example, the IBM SDK for Node.js runtime resolves modules that your
application requires.
In this example, you create a deploy task that pushes the application to a specific
space on IBM Cloud.

Two Deployment types are available:

1. Cloud Foundry deploys applications to Cloud Foundry servers.
This is the default type for the Deploy job.
2. Kubernetes provides a set of default deployment patterns for containers on
Kubernetes Cluster.

Containers are typically built by using the Docker Builder.

Your application is pushed to the development space in your organization.
You can also publish your application to your staging and production spaces.
You can customize the Cloud Foundry command-line interface commands (cf CLI) in
the deploy process in the Deploy Script section.
The default deploy action is equivalent to running the cf push command from the
CLI.
You can add custom shell script commands.
Here ${CF_APP refers to the application name.
Tests are usually run in the Build stage as shown here.
The first job fetches the code.
The second job runs the test.
If all the tests pass, the Deploy stage is run.

The following Tester types are available:

 Simple,
 Advanced Tester,
 DevOps Insights Gate,
 IBM AppScan Dynamic Analyzer,
 IBM Security Static Analyzer,
  Sauce Labs,
 And Vulnerability Adviser.

The default settings for the pipeline are two stages.

1. For Build stage:
Input that triggers this stage is whenever a change is pushed to Git.
Jobs are Simple Builder Type.
2. For Deploy stage:
The input that triggers this stage is as the Build stage is completing successfully:
it takes as input the build artifacts that were produced from the Build stage and
jobs are deploying the application to IBM Cloud.
In this example, all jobs in both the Build and Deploy stages were completed
successfully.

The LAST EXECUTION RESULT pane shows that the application was successfully
deployed to your IBM Cloud account and that the application is running on IBM
Cloud.
You can also check the build logs in the JOBS pane in the Build Stage column, the
deploy logs in the JOBS pane in the Deploy Stage column, and the runtime logs from
the LAST EXECUTION RESULT pane also in the Deploy Stage column.
You can clone the Deploy stage and deploy the application to any number of spaces
in your IBM Cloud account by clicking the settings wheel icon on top of Deploy Stage
and selecting Clone Stage.
IBM Cloud Code Engine
One of the biggest challenges the developers face is that they have to spend effort to
maintain infrastructure, learn and understand Kubernetes, update the Kubernetes
clusters and install security patches. There is also an issue of learning every different
way of deployment depending on where the code is sourced from.

IBM Cloud Code Engine is a fully managed, serverless platform that hosts all of your
cloud-native containerized workloads. The user experience is developer-centric and
designed so that you focus on writing code instead of dealing with the underlying
infrastructure complexity and its security. Cluster complexity is invisible to the
developers and there is no need for the developers to be trained on Kubernetes.

If your containers, applications or batch jobs need to scale, Code Engine takes care
of that for you, as well. The underlying cloud-scale architecture will dynamically scale
up or down to match your requirements in order to keep your apps running smoothly.
You only pay for what you actually use, including nothing if you allow Code Engine to
scale your applications down to zero.

Code Engine is more than a platform to deploy your existing container images. If you
don’t have an image, Code Engine will build one for you from your Git repository.
The build process is automated, and you choose whether to use a Dockerfile
(describing the build process), or a cloud native build packs. The deployment
experience is unified irrespective whether you are running containers or deploying
from source code through Docker files or submitting large batch of code to the IBM
Cloud.

Types of workloads supported by IBM Cloud

Code Engine
 Interactive and HTTP-driven web applications or microservices.
 Batch jobs that run a one-time task.
Key terms of code engine
Four key terms of code engine are: projects, applications, jobs, and builds

 Project: A project is a grouping of Code Engine entities such as applications,

jobs, and builds. Projects are used to manage resources and provide access
to its entities.
 Application: An application, or app, runs your code to serve HTTP requests.
An application has a URL for incoming requests. The number of running
instances of an application are automatically scaled up or down (to zero)
based on incoming workload.
 Build: A build, or image build, is a mechanism that you can use to create a
container image from your source code. Code Engine supports building from
a Dockerfile or Cloud Native Buildpacks.
 Job: A job runs one or more instances of your executable code. Unlike
applications, which include an HTTP Server to handle incoming requests, jobs
are designed to run one time and exit.

Advantages of Cloud Engine

 Pay-per-use
When you have a deployment on the IBM Cloud Code Engine, you are billed
for the memory and vCPU that your workloads consume, as well as any
incoming HTTP calls. If your app scales to zero or your job or build isn’t
running, you’re not consuming resources. It doesn’t make sense to pay for
what you are not using. IBM Cloud Code Engine allows you to pay for only the
resources you use.
 Secure Private network
The apps deployed on Cloude Engine are automatically secured with
Transport Layer Security (TLS) and isolated from other workloads. IBM Cloud
Engine deployments are bound by pod security policies, resource quotas and
limit ranges.
 Serverless Management
IBM Cloud Code Engine is a serverless platform to run your applications. The
developer can focus on application development instead of spending effort to
maintain infrastructure, such as continuing to update your Kubernetes clusters
and installing security patches.

At this point in the course, you know that:

 DevOps is a software methodology that integrates application development
and IT operations. With a DevOps approach, teams can deliver code to
production faster.
 IBM Cloud Continuous Delivery is a DevOps service that you can use to build,
test, and deliver applications. You can create integrated DevOps
open toolchains to enable sets of tool integrations that support your
development, deployment, and operations tasks.
 IBM Cloud provides several ways to add a toolchain to your applications. You
can use toolchains collaboratively and make operations easier to manage.
 Web IDE is a web-based integrated development environment for developing,
editing, and deploying code. When you use IBM Cloud Live Sync, you can
see your changes in your running IBM Cloud application immediately
without having to recompile and redeploy.
 Enabling IBM Cloud Continuous Delivery provides the Git Repos and Issue
Tracking tool integration. You can manage your source code
and collaborate with your team to resolve issues and share
ideas. You can retrieve a copy of the source code, check status, push code to
the remote repo, and track and report issues.
 Delivery Pipeline automates tasks for builds, tests, and deployment. You can
use the default automated settings or customize the stages to suit your
needs.