IBM Cloud Professional Certification Program

Transcription

1 IBM Cloud Professional Certification Program Study Guide Series Exam C IBM Cloud Platform Application Development v2

2 High-level Exam Objectives... 4 Detailed Exam Objectives... 6 Section 1 - Hosting Cloud Applications... 6 Section 2 - Planning Cloud Applications Section 3 - Designing and developing Cloud Ready Applications Section 4 - Enhancing Cloud Applications using Managed Services Section 5 - Using Data Services Section 6 - Cloud Application Security Section 7 - Using DevOps toolchain to develop and deliver cloud applications Section 8 - Managing a running cloud application Next Steps... 93

3 Purpose of Exam Objectives When an exam is being developed, the Subject Matter Experts work together to define the role the certified individual will fill. They define all of the tasks and knowledge that an individual would need to have in order to successfully implement the product. This creates the foundation for the objectives and measurement criteria, which are the basis for the certification exam. The Middleware Certification item writers use these objectives to develop the questions that they write and which will appear on the exam. It is recommended that you review these objectives. Do you know how to complete the task in the objective? Do you know why that task needs to be done? Do you know what will happen if you do it incorrectly? If you are not familiar with a task, then go through the objective and perform that task in your own environment. Read more information on the task. If there is an objective on a task there is about a 95% chance that you WILL see a question about it on the actual exam. After you have reviewed the objectives and completed your own research, then take the assessment exam. While the assessment exam will not tell you which question you answered incorrectly, it will tell you how you did by section. This will give you a good indication as to whether you are ready to take the actual exam or if you need to further review the materials. Note: This is the high-level list of objectives. As you review these objectives, click for a more detailed level of how to perform the task.

4 High-level Exam Objectives Section 1 - Hosting Cloud Applications 1.1 Describe Cloud service models and IBM Cloud offerings. 1.2 Describe the different capabilities of IBM Bluemix. 1.3 Understand the capabilities of rapid application development and deployment using boilerplates and managed services. Section 2 - Planning Cloud Applications 2.1 Describe key components of selected IBM Bluemix Cloud computing platforms. 2.2 Configure and use runtimes of IBM Bluemix CloudFoundry applications Explain the process of deploying an application in IBM Bluemix Cloud computing platforms. Describe the organization management elements in IBM Bluemix Cloud computing platforms : Orgs, Spaces, Users, Domains and Quota. Manage a Bluemix organization in a development and production environment. Understand IBM Bluemix Regions and how to manage applications in multiple regions. Use the IBM Bluemix command line tool to manage applications on selected IBM Bluemix Cloud computing platforms. Section 3 - Designing and developing Cloud Ready Applications Understand how to design, develop, deploy and manage an IBM Bluemix application following the Twelve-Factor App methodology. Apply selected IBM Cloud Reference Architectures for Cloud native applications. Describe the advantages of serverless computing which can be 3.3 considered when designing, deploying and managing applications on Bluemix. Section 4 - Enhancing Cloud Applications using Managed Services Improve performance and scalabilty of IBM Bluemix applications with caching. Enable loosely coupled integration for IBM Bluemix applications and components by using Messaging Services. Describe cognitive capabilities to process unstructured data and images in IBM Bluemix. 4.4 Configure file storage and retrieval for IBM Bluemix applications and components by using Object Storage Services. Section 5 - Using Data Services 5.1 Describe the different types of data services available in IBM Bluemix.

5 5.2 Understand the capabilites and API services of Cloudant NoSQL Database. 5.3 Manage instances of IBM Bluemix data services: Cloudant NoSQL Database. 5.4 Describe the IBM Data Connect service for Bluemix. Section 6 - Cloud Application Security Understand how to configure external authentication using IBM Bluemix 6.1 web applications with the Single Sign On service (SSO) 6.2 Configure an application to use SSL with a custom domain. 6.3 Securely handling credentials for APIs and other application services. 6.4 Understand capabilities to secure application data in IBM Cloud Section 7 - Using DevOps toolchain to develop and deliver cloud applications 7.1 Describe the capabilities of IBM Bluemix DevOps toolchain Understand capabilities for source code management for IBM Bluemix Continuous Delivery toolchains. Develop and deploy cloud applications using IBM Bluemix Continuous Delivery and code editors. Describe how use Delivery Pipeline to manage continuous integration and continuous delivery. Section 8 - Managing a running cloud application 8.1 Understand scaling concepts for a Cloud application and steps to scale an application in IBM Bluemix. 8.2 Perform load testing on Cloud applications using simulated loads and describe the benefits of load testing. 8.3 Explain various methods to monitor an application in IBM Bluemix. 8.4 Debug a Cloud application running on IBM Bluemix.

6 Detailed Exam Objectives Section 1 - Hosting Cloud Applications 1.1. Describe Cloud service models and IBM Cloud offerings. SUBTASK(S): Describe Bluemix Infrastructure, IBMs Infrastructure as a Service offering IBM Bluemix Infrastructure provides self-service deployment of virtual servers, dedicated bare metal servers and related storage, networking and security infrastructure in secure IBM Cloud data centers around the world. It also provides the hosting infrastructure used by IBM Bluemix Public and IBM Bluemix Dedicated services Describe IBM Bluemix Platform as a Service (PaaS) 1.1. IBM Bluemix Platform as a Service is an open standards cloud platform for building, running and managing apps and services. It makes application development easier by allowing developers to focus on code and data alone. Bluemix Platform as a Service handles managing middleware, operating systems, and hosting infrastructure automatically. It has a rich catalogue of cloud services that can be easily integrated with PaaS and IaaS to build business applications rapidly. The Bluemix Platform as a Service model allows developers and enterprises to focus IT spend with visibility to operational costs and reduce or even eliminate capital cost Describe Bluemix Private Cloud Powered by OpenStack Bluemix Private Cloud is a Private Cloud as a Service (PCaaS) solution for organizations that demand the security and control of a private cloud with the ease of use of a public cloud. Users benefit from the performance and cost management benefits of private cloud with the ease of provisioning and operations support of public cloud. It offers a single management tool for OpenStack-based private clouds, regardless of location, bringing greater simplicity and consistency to the operation of public, private, and hybrid cloud infrastructure Describe Software as a Service (SaaS) and IBM Marketplace The Software as a Service model provides business applications on a ready-to-use and self-service model. The IBM Marketplace is a place where enterprise cloud customers can discover, learn, try, and buy applications and service available in a cloud model from IBM and Business Partners Define Public, Dedicated, Local in relation to IBM Cloud IBM Cloud provides environments which are Public, meaning services which are available for use by anybody within IBM data centers, Dedicated, meaning services which are provided for a single organizations use within IBM data centers and Local, meaning cloud services which are deployed behind an organizations own firewall Describe the IBM Cloud Garage Method The IBM Cloud Garage Method combines industry practices including IBM Design Thinking, Lean Startup, agile development, and continuous

7 delivery, to build innovative solutions. It outlines a DevOps methodology that focuses around seven practice areas; culture, think, code, deliver, run, manage, and learn. The Garage Method brings together the practices, toolchains, architectures you need to be successful. REFERENCES: ew Describe the different capabilities of IBM Bluemix. SUBTASK(S): IBM Bluemix computing platform provided by Cloud Foundry The Bluemix Ckud Foundry computing platform gives instant access to runtimes for applications. Cloud Foundry is an open source PaaS that offers developers the ability to quickly compose their apps without worrying about the underlying infrastructure. Bluemix extends Cloud Foundry with a number of managed runtimes and services, enterprisegrade DevOps tooling, and a seamless overall developer experience IBM Bluemix Container Service IBM Bluemix provides the IBM Bluemix Container Service infrastructure as a feature for app development. With Docker containers, you can build your app in any language, with any programming tools. Each Docker container is an isolated and secure app platform. A Docker container can run anywhere: from a development workstation that is running OS X or Windows, a server that is running Ubuntu, a production data center virtual machine that is running Red Hat, or a cloud platform like Bluemix. Docker containers are virtual software objects that include all of the elements that an app needs to run. A Dcoker container is built from an image, which is a readonly template for creating the container. Each image includes just the app and its dependencies, running as an isolated process on the host operating system. Therefore, a Docker container has the benefits of resource isolation and allocation, but is more portable and efficient than, for example, a virtual machine IBM Bluemix OpenWhisk IBM Bluemix OpenWhisk is a distributed, event-driven compute service also referred to as Serverless computing or as Function as a Service (FaaS), OpenWhisk runs application logic in response to events or direct invocations from web or mobile apps over HTTP. Events can be provided from Bluemix services like Cloudant and from external sources. Developers can focus on writing application logic, and creating actions that are executed on demand. The benefits

8 of this paradigm are that you do not explicitly provision servers and worry about auto-scaling, or worry about high availability, updates, maintenance and pay for hours of processor time when your server is running but not serving requests. Your code executes whenever there is an HTTP call, database state change, or other type of event that triggers the execution of your code. You get billed by millisecond of execution time (rounded up to the nearest 100ms), not per hour of VM utilization regardless whether that VM was doing useful work or not IBM Bluemix Virtual Servers Virtual Server Instances (VSIs) are scalable virtual servers purchased with dedicated cores and memory allocations. They are a great option for customers looking for compute resources that can be added in minutes with access to features like image templates. The hypervisor is fully managed by IBM. Virtual Servers are deployed to the same VLANs as physical servers allowing customers to spread workloads across VSI and bare metal servers and maintain interoperability. Virtual Servers are fully customizable at the time of order with options to scale up in place as the customer compute needs grow. Customers choose from hourly or monthly billing, private (single tenancy) or public (multi tenancy), and high performance local disks or enterprise SAN storage IBM Bluemix Bare Metal Servers Bare Metal Servers provide the performance needed for high-powered workloads. They are configurable down to the bare metal with a choice of RAM, hard drives, and more, and can be provisioned in any worldwide data center. Bare Metal Servers can be deployed in one or more data centers and have the ability to communicate on a private network as if they were stationed on the same rack. Bare Metal Servers iare used in a variety of ways, including hosting web sites and databases, storing files and running resource intensive applications. REFERENCES: getting-started-withopenwhisk Understand the capabilities of rapid application development and deployment using boilerplates and managed services. SUBTASK(S):

9 Demonstrate knowledge of Bluemix Cloud components that enable rapid application deployment Boilerplates, runtimes and managed services allow developers to quickly create and deploy applications in the cloud Describe boilerplate functionality and how they may be used as a starter for developing applications Boilerplates consist of a combination of runtime and predefined services. Because they contain a runtime and set of services for a particular solution type, they can be used to quickly get an application up and running Starter applications are available for many different languages and Bluemix services to demonstrate how they may be used to create functioning applications in a matter of minutes Describe Managed services and the benefits they provide for Cloud application development Managed services are listed in the IBM Bluemix catalog. They provide ready-for-use functionality for a running application. They may be quickly integrated via the Bluemix service broker API which allows users to create, delete, bind and unbind Managed services come in three types IBM provided services are IBM products and supported by IBM Third party services are provided and supported by a company other than IBM Community services are provided by the open source community. Support is provided by the Bluemix Developers Community Understand Bluemix runtimes and how they facilitate quick application deployment A runtime is a set of resources to run an application. Bluemix provides runtime environments as containers for different types of applications. The runtime environments are integrated as buildpacks into Bluemix, are automatically configured for use, and require little to no maintenance Buildpacks provide a framework and runtime support for your applications. Buildpacks offer a complete runtime environment and may be used to manage dependencies. Buildpacks typically examine userprovided artifacts to determine what dependencies to download and how to configure applications to communicate with bound services. REFERENCES:

10 Section 2 - Planning Cloud Applications 2.1. Describe key components of selected IBM Bluemix Cloud computing platforms. SUBTASK(S): Describe key components of the Cloud Foundry IBM Bluemix Cloud computing platform Runtime is a set of resources to run an application. Bluemix provides runtime environments as containers for different types of applications. The runtime environments are integrated as buildpacks into Bluemix, are automatically configured for use, and require little to no maintenance. Boilerplate consists of a combination of runtime and predefined services. Because they contain a runtime and set of services for a particular solution type, they can be used to quickly get an application up and running. Services provide ready-for-use functionality for a running application and are represented by two types: Managed services are listed in the IBM Bluemix PaaS catalog. A Managed Service integrates with Bluemix/Cloud Foundry via a service broker that implements the Service Broker API. The service broker advertises a catalog of service offerings and service plans to Bluemix/Cloud Foundry and receives calls from Cloud Foundry for four functions: create, delete, bind, and unbind. User-provided services can be used by developers to programmatically define services outside of IBM Bluemix PaaS. This gives a mechanism to provide credentials to applications for service instances which have been pre-provisioned outside of Bluemix/Cloud Foundry. REFERENCES: Describe key components of the IBM Containers on Bluemix Docker Engine Fully managed, scalable hosted container service built on open source Docker technology. Security compliance insight, logging, and monitoring and Container groups with fully qualified domain names, load balancer, autorecovery, and auto-scaling. Networking support Privately network your containers by using real IP addresses, configured for each in a single step. Vulnerability advisor Discover vulnerabilities and compliance problems in Docker images. Also, regardless of image source, upgrade your containers with known industry fixes.

11 Integrated container monitoring Monitor performance and gain insight per container into CPU, memory, and network utilization. Private Docker image registry With a hosted private registry, ensuring access is both secure and auditable, you can securely store and share Docker images across your organization, allowing users to push and pull containers on- and offpremises. Enterprise-ready images Along with any image from the Docker Hub, you can use images of WebSphere Liberty, MobileFirst Platform, StrongLoop Process Manager, and Node.js runtime in IBM Containers. Highly available container groups A container group includes two or more containers that run the same image. Use container groups for running long-term services with workloads that require scalability and reliability or for testing at the required scale. Container groups can run within a single availabilty zone in one Bluemix region, be spread across multiple availablity zones and even configured in different availablity zones in two regions. Container Volumes A container is ephemeral, and you cannot persist application data in it. However, you can use a volume to persist data between container restarts, to share data between containers in a space, and to have access to your application data when your container is not available. Data in a persistent volume can be backed up and restored through the CLI. REFERENCES: Describe key components of IBM Bluemix OpenWhisk Actions An OpenWhisk action is a piece of code that performs one specific task. An action can be written in the language of your choice. You provide your action to OpenWhisk either source code or a Docker image. An action performs work when invoked from your code via REST API. Actions can also automatically respond toevents from Bluemix and third party services using a trigger. Triggers & Rules A trigger is a declaration that you want to react to a certain type of event, whether from a user or by an event source. Triggers fire when they receive an event. Events are always occurring, and it's your choice on how to respond to them. A rule associates a trigger with an action. Every time the trigger fires, the rule invokes the associated action. Sequences A sequence is a chain of actions, invoked in order, where the output of one becomes the input to the next. This allows you to combine existing actions

12 together for quick and easy re-use. A sequence can then be invoked just like an action, through a REST API or automated in a rule. Action Runtimes Create actions in a variety of languages, including Node.js 6, Python, and Swift 3. You can also use any other language you prefer by putting your code into a Docker container. Develop your code in the Bluemix web-based interface, or with your favorite development IDE and use the OpenWhisk CLI to upload it. REFERENCES: Configure and use runtimes of IBM Bluemix Cloud Foundry applications. SUBTASK(S): Understand the relationship of a buildpack to a runtime Buildpacks specify and compose runtime environments for applications. Buildpacks provide the ability to easily compile required software packages The buildpack model addresses the complexity of runtime composition for modern applications. By collecting and configuring the runtime exectable as a logic units, the buildpack simplifies the process for deploying cloud applications Differentiate between IBM runtimes, community runtimes and external buildpacks

13 Bluemix gives instant access to runtimes for applications. Using these runtimes, developers have the ability to quickly compose their apps without worrying about the underlying infrastructure. Bluemix offers a number of managed runtimes Runtimes get your app up and running quickly, with no need to set up and manage VMs and operating systems. Runtimes in Bluemix are based on Cloud Foundry, which means that community buildpacks or tooling plug-ins for Cloud Foundry also work with Bluemix Create an application using an IBM buildpack Bluemix provides starter applications for the runtimes. Users can add or modify code after creating a starter application and push the changes back to the Bluemix environment Use the buildpack to modify the dependencies of your application Cached dependencies: Except the java_buildpack, the community buildpacks installed on Bluemix have a cache of the key runtime versions and other dependencies. Typically, the cache contains two patch versions for each runtime s major version. If an application requests a specific runtime version that s not in the cache, the application deployment will fail. Therefore, it is important to check if your application does not rely on a specific dependency that may no longer be in the cache after the buildpack update Buildpack defaults: The buildpacks will usually use a default version of the runtime or other key component if an application does not explicitly set it. The defaults may change between buildpack versions. Therefore, it is also important to check if your application is relying on these defaults, as they may affect your application. The best practice is to always specify your application dependencies explicitly. REFERENCES: Explain the process of deploying an application in IBM Bluemix Cloud Foundry SUBTASK(S): Explain the process of deploying an application using the cf cli tool At the command line, the developer enters the directory containing her application and uses the Cloud Foundry Command Line Interface (cf CLI) to issue a push command The cf CLI tells the Cloud Controller to create a record for the application.

14 The Cloud Controller stores the application metadata. Application metadata can include the app name, number of instances the user specified, and the buildpack, and other information about the application Before uploading all the application files, the cf CLI issues a resource match request to the Cloud Controller to determine if any of the application files already exist in the resource cache. When the application files are uploaded, the cf CLI omits files that exist in the resource cache by supplying the result of the resource match request. The uploaded application files are combined with the files from the resource cache to create the application package The Cloud Controller stores the application package in the blobstore The cf CLI issues an app start command The Cloud Controller issues a staging request to Diego, which then schedules a Cell to run the staging Task. The Task downloads buildpacks and if present, the app s buildpack cache. It then uses the buildpack that is detected automatically or specified with the -b flag to build the droplet. The Task uses the instructions in the buildpack to stage the application The Diego Cell streams the output of the staging process so the developer can troubleshoot application staging problems The Task packages the resulting staged application into a tarball called a droplet and the Diego Cell stores it in the blobstore. The Task also uploads the buildpack cache to the blobstore for use the next time the application is staged The Diego Bulletin Board System reports to the Cloud Controller that staging is complete. Staging must complete within 15 minutes or the staging is considered failed. Apps are given a minimum of 1GB memory to stage, even if the requested running memory is smaller Diego schedules the application as a Long Running Process on one or more Diego Cells The Diego Cells report the status of the application to the Cloud Controller. REFERENCE: Describe the organization management elements in IBM Bluemix Cloud computing platforms: Orgs, Spaces, Users, Domains and Quota. SUBTASK(S): The organization management in IBM Bluemix is based on Cloud Foundry organization management. The organization is the key grouping concept in IBM Bluemix. Each organization is composed of several elements.

15 Spaces provide a mechanism to collect related applications, services and team members. Every organization contains at least one space. All applications and services are associated with a single space Users participate in organizations and have varying capabilities based on assigned role. Users may be members of multiple accounts and organizations and can change from one organization to another through the Bluemix dashboard. Users may have different roles in different spaces within an organization, controlling the type of access they have within the space. At the account level, there are two user roles, owner and member: Account role Owner Permissions An owner for the account has access to their profile, team directory, billing information, spending notifications, and usage dashboard. From the team directory page, the owner can invite new team members and adjust roles. The owner can also add promotional credits, set or change the billing limit, set service access, and manage organizations and spaces. Member A member has access to their profile, team directory, and account credits and billing limits in the Bluemix header. However, on the team directory page, a member can only view the team members within the account. The owner is able to create new organizations within the account. Team members added to the account are assigned the member role for the account.

16 Users may be assigned the following roles at the organization level: Organization role Manager Permissions Organization managers can create, view, edit, or delete spaces within the organization, view the organization's usage and quota, invite team members to the organization, manage who has access to the organization and their roles in the organization, and manage custom domains for the organization. Billing manager Billing managers can view runtime and service usage information for the organization on the Usage Dashboard page. Auditor Organization auditors can view application and service content in the organization. Auditors can also view the team members in the organization and their assigned roles, and the quota for the organization. This role is assigned to all invitees, except in local or dedicated environments, by default. The following roles can be assigned at the space level: Space role Manager Permissions Space managers can add existing team members and manage roles within the space. The space manager can also view the number of instances, service bindings, and resource use for each application in the space.

17 Space role Developer Permissions Space developers can create, delete, and manage applications and services within the space. Some of the managing tasks include deploying apps, starting or stopping apps, renaming an app, deleting an app, renaming a space, binding or unbinding a service to an application, view the number or instances, service bindings, and resource use for each application in the space. In addition, the space developer can associate an internal or external URL with an application in the space. Auditor Space auditors have read-only access to all information about the space, such as information about the number of instances, service bindings, and resource use for each application in the space. Note: Users with the manager or developer space role can access the VCAP_SERVICES environment variable for an application within the space. Users with the Auditor role can't access VCAP_SERVICES Domains provide the route on the Internet for the organization. An application route is composed of both a hostname which defaults to the application name plus the domain name. A custom domain name can be configured in the organization and then assigned to an application within the organization to form a custom Internet endpoint for the application in IBM Bluemix PaaS Quota defines resource limits for the organization which is assigned when the organization is created. This represents and controls the number of services and the amount of memory available for applications within all spaces of the organization. REFERENCES: Manage IBM Bluemix organizations in development and production SUBTASK(S): Explain steps and requirements for adding a team member to an organization

18 Account owners and organization managers can invite team members to a space within an organization Team members are invited by providing the address of the team member either individually or in bulk By default, team members are added to the organization and space with the auditor role Describe motivation for partitioning applications and projects using Bluemix spaces Within an organization, team members can be assigned to specific spaces based upon needs of the entity owning the Bluemix account Granular permission controls can be assigned to team members in each space Organizations can use development and production spaces with different permissions assigned to team members in each space based upon their access requirements to support applications Understand steps to create and use a custom domain for an organization To use a custom domain, you must register the custom domain on a public DNS server, configure the custom domain in Bluemix, and then map the custom domain to the Bluemix system domain on the public DNS server After registering the domain, use the Web UI or CLI to create the domain for the organization Define a CNAME record for the domain on a public DNS server Map the custom domain name to the secure endpoint for the Bluemix region where your application is running. For Bluemix public use: US-SOUTH: secure.us-south.bluemix.net EU-GB: secure.eu-gb.bluemix.net AU-SYD: secure.au-syd.bluemix.net Use the Web UI or CLI to associate the hostname for the application to the custom domain REFERENCES: Understand IBM Bluemix Regions and how to manage applications in multiple regions. SUBTASK(S): Explain IBM Bluemix regions and how to deploy applications in different regions In the IBM Bluemix Public deployment model, a region is defined as a geographical territory that you can deploy your apps to. You can create apps and service instances in different regions with the same Bluemix infrastructure for application management and the same usage details view for billing. You can select the region that is nearest to your

19 customers and deploy your apps to this region to get low application latency. You can also select the region where you want to keep the application data to address security issues. When you build apps in multiple regions, if one region becomes unavailable, the apps that are in the other regions continue to run. Your resource allowance is the same for each region that you use Using the Bluemix user interface, you can switch to a different region to work with the spaces in that region. Click the user account preferences link, expand the Region selector, then select the region you require from the list Using the Bluemix command line interface, to connect to the Bluemix region that you want to work with, use the bx api command and specify the API endpoint of the region. For example, enter the following command to connect to Bluemix Europe United Kingdom region: bx api A unique prefix is assigned to each region. Bluemix provides the following regions and region prefixes.

20 Region name Geographic location Region prefix cf API endpoint UI console US South region Dallas, US ng api.ng.bluemix.net console.ng.bluemix.net United Kingdom region London, England eu-gb Sydney region Sydney, Australia au-syd api.eugb.bluemix.net console.eugb.bluemix.net api.ausyd.bluemix.net console.ausyd.bluemix.net Table 1. Bluemix region list REFERENCES: Use the IBM Bluemix command line tool(cli) to manage applications on selected IBM Bluemix Cloud computing platforms. SUBTASK(S): Bluemix CLI provides a unified way for you to interact with your applications, virtual servers, containers, and other components in Bluemix through a command line interface. It also leverages command line tools from Cloud Foundry, Docker, and the OpenStack community when you interact with specific compute types. Bluemix CLI helps you handle the environment settings when these community tools are used. Note: You can use a shortened format for bluemix commands; for example, bx api is short for bluemix api The commands in Bluemix CLI are organized by name spaces, to provide a structural overview. If you are using Bash or Zsh, the autocomplete feature in Bluemix CLI provides suggestions and allows you to complete commands and their arguments. These features make it easier for you to find and use the right commands The Bluemix CLI supports plugins to perform additional functions in addition to the built-in ones. Bluemix CLI plugins are available for active-deploy, autoscaling, containers, container registry, container network peering, and vpn.

21 Bluemix CLI commands to manage applications bluemix api Set or view target API endpoint. Command options: API_ENDPOINT The URL for the desired API endpoint. This selects the region where subsequent CLI commands will be performed. Example: Select the IBM Bluemix US-South ( region for CLI commands. bx api bluemix login Logs you in to Bluemix. Note: If logging in with a federated ID, you must use the single sign-on '--sso' parameter to log in. Important command options: -a API_ENDPOINT (optional only if endpoint already set) The URL of the API endpoint of Bluemix. This selects the region where subsequent CLI commands will be performed. -o organization_name The name of the organization that you want to log in to. -s space_name The name of the space that you want to log in to. Example: Log in to Bluemix with a defined endpoint of bx login -a bluemix app push Deploys a new application to Bluemix, or updates an existing application in Bluemix. Important command options: appname (required if no manifest file specified) The name of the application. -f manifest_path Path to the manifest file if not in the current directory.

22 -b buildpack_name (optional) The name of the buildpack. -c start_command (optional) The start command of your application. To reset to the default start command, specify a value of null for this option. -m memory_limit (optional) The memory limit for the application. Possible values are 256M, 1024M, or 1G. --no-start (optional) Does not start the application after the application is deployed. --random-route (optional) Creates a random route for the application. Example: Start an application named my_app with the option to run a script file named run.sh. bx app push my_app -c bash./<run.sh>" bluemix app list Lists all applications deployed in the current space. A status summary of each application is also displayed. Example: List all deployed applications bx app list bluemix app show Display the health and status for a specific Cloud Foundry app. Command options: appname (required) The name of the application. Example: Show the status of my_app. bx app show my_app bluemix app stop Stops an application Command options: appname (required) The name of the application.

23 Example: Stop the application named my_app. bx app stop my_app bluemix app delete Deletes an existing application. Command options: appname (required) The name of the application. -f (optional) Forces deletion of the application without any confirmation. -r (optional) Deletes all domain names that are associated with the application. Example: Deletes an application named my_app and all domain names associated with my_app. bx app delete my_app -r bluemix service offerings Lists all of the services that are available in the marketplace. The services listed by this command are also shown in the Bluemix Catalog. Example: List all services in the marketplace bx service offerings bluemix service create Creates a service instance Command options: service_name (required) The name of the service from the catalog. service_plan (required) The name of the service plan. service_instance (required) The name that you want to use for the new service instance that you create. Example:

24 Create an instance of the IBM Language Translator service using the standard plan and name the instance my_lt. bx service create language_translator standard my_lt bluemix service bind Binds an existing service instance to your application. Command options: appname (required) The name of the application. service_instance (required) The name of the existing service instance. Example: Bind a service instance named my_lt to your app named my_app. bx service bind my_app my_lt bluemix app restage Recreate the app's executable artifact using the latest pushed app files and the latest environment (variables, service bindings, buildpack, stack, etc.) Command options: appname (required) The name of the application. Example: Restage the application named my_app. bx app restage my_app bluemix app scale Displays or changes the instance number, disk space limit, and memory limit for an application. Command options: appname (required) The name of the application. -i instance_number (optional) The number of instances -k disk_limit (optional) The disk limit for the application (e.g. 256M, 1024M, 1G). -m memory_limit (optional)

25 The memory limit for the application (e.g. 256M, 1024M, 1G). Example: Modify the instance number to 1234, disk space limit to 1G, and memory limit to 1G for an app named my_app. bx app scale appname -i k 1G -m 1G bluemix network route-map Map a route to an existing Cloud Foundry application or container group to a specified domain and host name. Command options: appname container_group_name (required) The name of the cloud foundry application or container group to be mapped with a route. domain (required) The domain of the route. For example, mychinabluemix.net or chinabluemix.net. -n host_name (optional) The host name of the route. If not provided, the host name is set to the app name or container group name by default. Example: Map a route to an app named my_app with the domain mydomain.net. bx network route-map my_app mydomain.net bluemix app logs Displays the STDOUT and STDERR log streams of an application. Command options: appname The name of the application. --recent (optional) Retrieves recent history of logs from the loggregator buffer instead of connecting a stream of current logs to the terminal. Example: Display the recent log streams for an application named my_app. bx app logs my_app --recent REFERENCES:

26 Section 3 - Designing and developing Cloud Ready Applications 3.1. Understand how to design, develop, deploy and manage an IBM Bluemix application following the Twelve-Factor App methodology ( SUBTASK(S): Explain each of the twelve factors of the 12 factor methodology for building Saas applications Codebase: Maintain a single codebase tracked in revision control, many deploys Identify solutions available to a Bluemix developer that provide the capability to track and control revisions to your codebase Identify solutions available to a Bluemix developer that provide the capability to deploy dev, test and production versions of your Saas application from a single common codebase Dependencies: Explicitly declare and isolate dependencies Reduces time and cost by simplifying setup for developers new to an application. New developers simply check out the codebase and configure all needed parts to run the code with the dependency manager Based on a development scenario and sample code, identify examples of dependency declarations in the sample code Config: Store application configuration in the environment Based on a development scenario and sample code, identify examples of configuration specifications in the sample code Backing Services: Treat backing services as attached resources Backing Services are any combination of database, queue, memory cache, etc Based on a development scenario and sample code, identify examples of attaching backing resources in the sample code Build, release, run: Strictly separate build and run stages Explain the benefits of a multi-stage DevOps toolchain Processes: Execute the app as one or more stateless processes Describe the characteristics of stateless processes Port binding: Export services via port binding Based on a development scenario and sample code, identify examples of dependency declaration in sample code Concurrency: Scale out via the process model Disposability: Maximize robustness with fast startup and graceful shutdown Dev/prod parity: Keep development, staging, and production as similar as possible Logs: Treat logs as event streams Admin processes: Run admin/management tasks as one-off processes

27 Identify examples of establishing a clean contract with the underlying operating system Dependencies: Explicitly declare and isolate dependencies Config: Store application configuration in the environment Identify examples of minimizing divergence between development and production environments Codebase: Maintain a single codebase tracked in revision control, many deploys Dev/prod parity: Keep development, staging, and production as similar as possible REFERENCES: Apply selected IBM Cloud Reference Architectures for Cloud native applications SUBTASK(S): Demonstrate understanding of the IBM Cloud Reference Architectures for Cloud native applications Describe the cloud-native DevOps application on Bluemix reference architecture and how the architecture is realized This reference implementation provides a toolchain that enables a team to collaborate and track development, as well as to build, deploy, manage, and learn about the product being delivered The toolchain comes with a sample application written in Node.js Express 4 that you can further extend You can use this toolchain template with your own application code repository The create toolchain button will instantiate the sample toolchain in your Bluemix account Describe components of the Web Application reference architecture

28 A user or user agent sends a request to a specified URL Edge services provide capability to deliver content and include DNS, CDN, firewall, and load balancer The security layer manages confidentiality, integrity, availability and compliance as required for the business needs of the web application API management advertises available service endpoints. The API manager receives the request, determines which services or applications in the application to invoke and checks if the user has appropriate authority Application servers return resources (normally some form of web content) based on the user's request User directories may be used by the web application server to authenticate the user and to validate permission rights to perform the request. These can be at the application or enterprise level. Directories provides storage and access to user information to support authentication, authorization, or profile data Caches are used by the web application server to speed the return of appropriate content and associated data to the user File repositories store and manage data that the application server can request Transformation and connectivity enables secure connection to enterprise systems and the ability to filter, aggregate, or modify the data or its format as it moves between web components. This component takes the messages and data to be stored in the enterprise database, completes any necessary transformation from web formats to database

29 formats, and ensures that secure reliable messaging is used appropriately Enterprise data includes systems of record and metadata about the data for enterprise applications. The web application server may need to access a database and query data to generate the requested response Enterprise applications include applications that accomplish business goals and objectives that may interact with cloud services Response from the web application is returned to the user over the Internet via the edge services Describe the Implementing a Web and Mobile application with a microservices reference architecture and how the architecture is realized The figure illustrates a Reference Implementation for building a cloudnative OmniChannel Application using a Microservices architecture. The application is a simple store front shopping application that displays a catalog of antique computing devices, where users can buy and add review comments. It has Web and Mobile interface, both the Mobile App and Web App rely on separate BFF (Backend for Frontend) services to interact with the backend data This OmniChannel application contains both an Angular-based web application and a native ios application.

30 Both Client Applications (or via BFF) make API calls through an API Gateway. The API Gateway is API Connect. API Connect provides an OAuth Provider as well, allowing you to implement API Security The Web and Mobile app invoke their own backend Microservices to fetch data following the Backend for Frontends (BFF) pattern. In this Layer, front end developers own the backend logic for their front end. The Web BFF is implemented using the Node.js Express Framework. The Mobile ios BFF is implemented using Server side Swift. These Microservices run in Bluemix as Cloud Foundry Applications Reusable Java microservices are invoked by the BFFs, this component is sometimes written by a different team. The microservices are written in Java using SpringBoot. They run inside IBM Containers using Docker BFFs and Java Microservices communicate to each other using the Netflix OSS Framework The Zuul Netflix component runs in Bluemix to provide a proxy layer for the microservices The Eureka component provides a Service Registry. Java Microservices register themselves to Eureka which allows clients to find them Hystrix provides an implementation of the Circuit Breaker Pattern. This component runs as a library inside the Java applications and forwards service availability information to a Hystrix Dashboard The code for building the omnichannel application using a microservices based architecture is available from: REFERENCES: e2e_scenario Describe the advantages of serverless computing which can be considered when designing, deploying and managing Bluemix applications SUBTASK(S): Explain Serverless Computing Serverless computing refers to a model where the existence of servers is simply hidden from developers.

31 Event-driven compute services run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster Create a trigger to listen to events from your favorite services or your own system Define actions to do work when the trigger fires Identify examples of serverless frameworks: AWS Lambda, Google CloudFunctions, Open Whisk Describe the key architectural concepts of OpenWhisk Triggers: A class of events emitted by event sources Actions: Encapsulate the actual code to be executed which support multiple language bindings including NodeJS, Swift and arbitrary binary programs encapsulated in Docker Containers. Actions invoke any part of an open ecosystem including existing Bluemix services for analytics, data, cognitive, or any other 3rd party service Rules: An association between a trigger and an action Packages: Describe external services in a uniform manner An open source serverless computing platform Using the OpenWhisk CLI The CLI can be used to create and invoke actions through the wsk action command The CLI can be used to define triggers and create rules for actions to be run as a result of a trigger event firing The CLI can be used to list packages in a namespace and list the entities in a specific package through the wsk package command The wsk package bind command allows a developer to create package bindings to provide values for default parameters used by actions in the package packages

32 Section 4 - Enhancing Cloud Applications using Managed Services 4.1. Improve performance and scalability of IBM Bluemix applications with caching. SUBTASK(S): Using the Compose for Redis service to store application data Compose for Redis supports distributed caching scenarios for web and mobile applications Compose for Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries.. It provides near linear scalability, predictable performance and fault-tolerance through replication. It supports set, get, delete and more operations on entries in a cache through multiple programming language SDKs. Compose for Redis service is a good choice for caching data and can be used as a replacement for the retired Data Cache service Using Session Cache to store and persist HTTP session objects IBM Session Cache is a NoSQL style service that provides low latency data access and dynamic scalability, with an integrated web console. IBM Session Cache provides a distributed session cache for HTTP sessions. No code changes are required for applications using J2EE standard HTTP sessions. Session data is replicated to provide fault-tolerance and persistence of session data. In a Liberty runtime environment, you can deploy applications connected to Session Cache as a standard WAR file or a liberty buildpack. The Session Cache is a singleton service; only one Session Cache instance should be bound to an application. References: Enable loosely coupled integration for IBM Bluemix applications and components by using Messaging Services. SUBTASKS: Understand messaging use-cases and available APIs in the Message Hub service Messaging services provide loose coupling between components of an application in several use-cases. A very common case is asynchronous worker offload of complex tasks allowing the processes handling these tasks to be scaled independently. Messaging provides a natural eventdriven service model and avoids polling inefficiencies. Messaging provides a way to delay processing, for example to run a report at a specific time. Messaging can provide responsiveness in an application when integrating with 3 rd party or external services by queueing requests.

33 Across many of these use-cases, components using messaging services can be deployed in distributed locations to create hybrid cloud scenarios The IBM Message Hub service is based upon Apache Kafka and supports the use of multiple APIs for messaging. The Kafka API, Kafka REST API and MQ Light APIs may all be used with this service. MQ Light provides a higher level of abstraction than the Kafka API and enables apps to be written quickly for a unified messaging model Explain how to configure publish-subscribe and worker offload queue topologies using Message Hub In a publish-subscribe model every message receiver (or consumer) gets a copy of messages published by the sender (or producer). In a queue model, messages are distributed among a pool of receivers (or consumers). When using the MQ Light API to create a queue model, each receiver will join a destination with sharing enabled. When using the Kafka API (or Kafka REST API), to configure a queue, each consumer should subscribe using the same consumer group and the number of partitions on the topic should be greater than or equal to the maximum number of consumers.

34 Explain rationale of the cf option --no-route when using the worker offload pattern An application component implementing the worker offload pattern through messaging services should not be configured with an application route in an environment like IBM Bluemix Cloud Foundry application. To avoid this, you may use cf push with the --no-route option to prevent the Cloud Foundry environment from creating a route on application startup Understand benefits and usage of MQ Light API for topic hierarchies, fault tolerance, and quality of service (QoS) The MQ Light API provides a simple yet powerful AMQP-based messaging interface for Java, Node.js, Python, and Ruby To support a flexible subscription model, the MQ Light API supports the use of hierarchy and wildcards in the topic structure. Levels in a topic are separated by the / character and two different wildcard types are available. The # wildcard matches any number of levels within a topic and the + character matches at a single level MQ Light buffers messages based upon message and destination timeto-live. When an application subscribes to a topic it may specify a destination time-to-live which will cause MQ Light to store messages at the destination in the event of a receiving application crash. After the destination time-to-live expires, MQ Light will discard all held messages and stops storing new messages For QoS, MQ Light messaging provides two models for delivery assurance, at most once, and at least once. The first is appropriate when occasional loss of data caused by a communication disruption is acceptable, and the second is required when there can be no loss of data. When using at least once, duplicate messages may appear around communication disruptions and they should to be programmatically discarded.

35 Demonstrate knowledge of configuring Message Hub on Bluemix Only one instance of the Message Hub service can be created in a Bluemix space To connect to the service using the MQ Light API, the app must use the user, password, and mqlight_lookup_url details from the VCAP_SERVICES environment variable To use a MQ Light API client with Message Hub the developer must explicitly create a single-partition Kafka topic named "MQLight" REFERENCES: Describe cognitive capabilities to process unstructured data and images in IBM Bluemix. SUBTASK(S): Summarize the capabilities of Cognitive Bluemix services Cognitive services are adaptable, interactive, and contextual in the way they provide information. Instead of simply returning prepared responses, these services provide answers based on what they know to be correct, relying on information they ve acquired over time Bluemix services provide a wide range of cognitive technologies to quickly and securely build smart applications. From analyzing images and video to understanding sentiment, keywords and entities from text, Watson services enable cognitive computing within Bluemix applications.

36 Explain the benefits of popular Cognitive services Natural Language Classifier helps you improve decisions based on realtime trends by revealing valuable insights from social trends Watson Conversation lets you speed time to market and create better customer experiences by understanding and responding to customers Speech to Text service converts the human voice into the written word. Machine intelligence enables this service to combine grammar and language information to accurately transcribe meetings and conference calls, add voice control to embedded systems, and dictate and notes Watson Document Conversion service converts a single HTML, PDF, or Microsoft Word document into a normalized HTML, plain text, or a set of JSON-formatted units that can be used with other Watson services.

37 The Watson Natural Language Understanding service analyzes semantic features of text input, including - categories, concepts, emotion, entities, keywords, metadata, relations, semantic roles, and sentiment Retrieve and Rank service provides users with more relevant results by automatically reranking them using machine learning algorithms. Built on top of Apache Solr, developers load their data into the service, train a machine learning model based on known relevant results, then leverage this model to provide improved results to their end users Personality Insights service derives insights from transactional and social media data to identify psychological traits which determine purchase decisions, intent and behavioral traits. The service can infer from social media, portraits of individuals that reflect their personality characteristics.

38 The service can also determine individuals' consumption preferences, which indicate their likelihood to prefer various products Tone Analyzer service leverages cognitive linguistic analysis to identify a variety of tones at both the sentence and document level. This insight can be used to refine and improve communications. It detects three types of tones, including emotion (anger, disgust, fear, joy and sadness), social propensities (openness, conscientiousness, extroversion, agreeableness, and emotional range), and language styles (analytical, confident and tentative) from text Other cognitive computing capabilities available in Bluemix include Discovery News and Visual Recognition which reveal insights from unstructured data capable of reinventing operations and transforming industries. REFERENCES: Configure file storage and retrieval for IBM Bluemix applications and components by using Object Storage Services SUBTASK(S): Understand Object Storage offerings in the Bluemix catalog The Bluemix catalog offers two types of Object Storage, one available through infrastructure and one through the services category. Both provide OpenStackbased Object Storage services.

39 Cloud Object Storage is available as part of the Infrastructure catalog and provides two service types: The Standard Cross Region service provides U.S. based resiliency across three geographic regions and encryption of data at rest and in flight. Data is accessible via an S3-compatible API. Currently the regions available are Dallas, San Jose, and Washington, DC. Information stored with IBM OpenStack Object Storage regional is located in one of 20 global data centers. Based on the OpenStack Swift platform, developers use the community Swift API to interact with their storage accounts. This offering is managed through the IBM Bluemix Infrastructure Control portal and does not provide encryption at-rest. The Object Storage service allows you to securely store, access, and manage large amounts of unstructured data for cloud-based applications. The service uses OpenStack Identity (Keystone) for authentication and can be accessed directly by using OpenStack Object Storage (Swift) API v1 calls. You authenticate your service with Keystone and receive an authorization token. The service maintains three copies of your data that it replicates across multiple storage nodes which are independent of the Bluemix region in which the Object Storage service instance was created. If you create an instance in the US-South Bluemix region, you can read and write data to either the Dallas or London storage region. You can switch regions by selecting another region in from the drop-down list in the UI or from the endpoint provided from Keystone.

40 Authenticating with Keystone for the IBM Bluemix Object Storage Service To interact with the service, you must authenticate your Object Storage instance using the Keystone API to obtain your URL and bearer token. Provisioning a new Object Storage instance creates an isolated Keystone project in the IBM Public Cloud. The Keystone credentials structure contains a complete set of attributes to allow you to choose the OpenStack token request method or OpenStack SDK that best fits your app. When you bind a new app to the instance, a new Keystone user with access to the project is created. When you deprovision the instance, the project and user are deleted. The Keystone credentials allows access to Object Storage via commands line tools as well as applications via a REST API. Your Object Storage instance must be authenticated with Keystone to obtain your URL and bearer token. To obtain the url and authorization token, make a POST request to providing the user ID, password and projectid from the service credentials. For example: curl -i \ -H "Content-Type: application/json" \ -d ' { "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "id": "ad78b2a3f afd077731c61fc", "password": "XXXXXXXXXX" } } }, "scope": { "project": { "id": "0f47b41b06d047f9aae3b33f1db061ed" } } } }' \ ; echo Understand Object Storage Containers A container is the basic storage unit for ALL the data within Object Storage. Containers work similar to a folder or directory within many operating systems, however, are unable to be nested. After authenticating your instance with Keystone, you can read and write to your stored objects by using the Swift API. You can use the Swift REST API with a command-line client interface, such as curl, or call the API from your application.

41 To use the Swift API to access your container, add its namespace and object to the end of your Object Storage URL as shown in the following image Perform create, upload, and list operations on an object using containers Once the container is created, objects are manipulated by http requests. To create a file or upload with new data to an existing file, use the PUT command specifying the container in the path (simplified command omitting H option shown): curl -X PUT [...] storageurl/container1 -T object.jpg To list all of the objects in a container, use the GET command specifying the container name (simplified command shown): curl X GET [...] storageurl/container1 To download an object, use the GET command specifying the object name (simplified command shown): curl -X GET [...] storageurl/container1/object.jpg Purpose of metadata to store information about files in object storage For objects that are stored in object storage, information about the object is available through metadata. Object metadata includes some standard types like: last modified, length, md5 checksum, expiration date, and also supports custom data through the X-Object-Meta-{name} element. Reading metadata from a container or object is done using the HEAD request: curl X HEAD [...] storageurl/container1 Object metadata is created or updated with the http POST command. Selected standard metadata are modifiable and X-Object-Meta-{name} items may be created as needed Working with directories Swift does not have a true directory structure, but uses naming to represent a directory layout. You can specify a directory name by including a delimeter name

42 and then filtering the object names in your applications to simulate a directory structure For example the following files are all in a single container withing Object Storage but use the delimiter / in the file names to simulate a directory structure: photos/animals/cats/persian.jpg photos/animals/cats/siamese.jpg photos/animals/dogs/terrier.jpg photos/me.jpg photos/plants/fern.jpg photos/plants/rose.jpg REFERENCES:

43 Section 5 - Using Data Services 5.1. Describe commonly used data service types available in IBM Bluemix SUBTASK(S): Describe the key characteristics of a NoSQL database service NoSQL databases are managed data stores that do not follow the traditional relational database model. NoSQL databases store data using various models including column, graph, key-value, and documents NoSQL databases are used where the data model is complex and the data itself may have multiple levels of nesting. Multi-level nesting and hierarchies are very easily represented in the JavaScript Obeject Notation (JSON) format used by some NoSQL products Examples of NoSQL database services available in IBM Bluemix are Cloudant (an extension of Apache CouchDB) and Compose for MongoDB. Both these databases use JSON format to store data NoSQL document databases offer flexibility as there is no enforced schema for documents and document structure can be changed at any time without having to modifying existing data NoSQL databases like Cloudant and Compose for MongoDB can scale horizontally on commodity hardware to provide low cost, scalable performance as data volumes grow. To support this type of scalability, Cloudant was designed to prioritize database availability over consistency between distributed nodes. This is referred to as eventual consistency Describe the key characteristics of a SQL database service A SQL database service provides applications access to relational databases that are queried using SQL Relational databases are traditionally used for On-Line Transaction Processing (OLTP) workloads and require a strict data-model which is enforced by keys within the data to maintain data consistency The IBM DB2 on Cloud service in Bluemix is an example of a SQL data service, as are Compose for PostgreSQL and ClearDB MySQL Database Key characteristics of an in-memory columnar database service An in memory columnar database service provides optimized database access for analytic workloads In memory columnar databases are used for Data Warehouse and analytics workloads, where large, often long-running queries are performed that benefit from memory-intensive computing The dashdb for Analytics service in IBM Bluemix is an example of an in memory, columnar database service. It is optimized for data warehouse and analytics workloads. dashdb for Analytics combines DB2 and Netezza technology with in-memory data processing, columnular tables and in-database analytics Describe the key characteristics of key value pair data service Key value pair data services allow the efficient storage and retrieval of key value pair data.

44 Typical use cases for key value pair data services are: Session management at high scale User preference and profile stores As a cache fr heavily accessed but rarely updated data Examples of a key value pair data services in IBM Bluemix are Compose for Redis and Compose for etcd. Such services are particularly useful in web applications that need to maintain state between requests because they offer fast, efficient access to stateful data that is accessible by multiple instances REFERENCES: Understand the capabilites and API services of Cloudant NoSQL Database IBM Cloudant NoSQL DB for Bluemix is a NoSQL database as a service (DBaaS) that scales globally, runs non-stop, and handles data in JSON format and supports full text queries and geospatial queries. Cloudant NoSQL DB is an operational data store optimized to handle concurrent reads and writes, and provide high availability and data durability Cloudant provides a RESTful API to create, read, update and delete documents Reading a document: Cloudant's RESTful API makes every document in your Cloudant database accessible as JSON via a URL; this is one of the features that make Cloudant so powerful for web applications. Each document in Cloudant has a unique _id field which can be used to retrieve it. To retrieve it via the API, simply append the document's id to the URL of the database. For a document of _id foo in the mydb database the GET URL to retrieve the document would look like this GET Insert a document: Documents can be inserted into Cloudant individually or in bulk. To insert documents you have the option to provide a unique value for the _id field. If the document to be inserted doesn't define a _id value, one gets assigned on insert. If you define a _id for your document up front you need to make sure that the _id isn't already in use. If it is, the insert will fail Code examples Insert via CURL Command curl -d '{"season": "summer", "weather": "usually warm and sunny"}' -X POST

45 -H "Content- Type:application/json" Response {"ok":true,"id":"590e2bca76c09882e37dea534b000be3","re v":"1-0af5e64fe24d262db237b9f14046f490"} If you want to set the _id when you insert, you can do it in two ways: POST and PUT Set the _id via POST POST the document with the _id in the document body: Command curl -d '{"season": "summer", "weather": "usually warm and sunny", "_id":"foo"}' -X POST -H "Content- Type:application/json" Response {"ok":true,"id":"foo","rev":"1-0af5e64fe24d262db237b9f14046f490"} Set the _id via PUT Or PUT the document, specifying the _id in the URL: Command curl -d '{"season": "summer", "weather": "usually warm and sunny"}' -X PUT -H "Content- Type:application/json" Response {"ok":true,"id":"bar","rev":"1-0af5e64fe24d262db237b9f14046f490"} Update and delete documents: The _rev field gets added to your documents by the server when you insert or modify them, and is included in the server response when you make changes or read a document. The _rev is built from a crude counter and a hash of the document and is used to determine what needs to be replicated between servers, and if a client is trying to modify the latest version of a document. For this reason updates need to send the _rev token to be able to modify a document. It is important to note that _rev should not be used to build a version control system, it s an internal value used by the server and older revisions are transient, and removed regularly. The code or command line to update a document is the same as to insert, just be sure to include the _rev in the document body. As you might expect deletions are done by using the DELETE HTTP method. There are some cases where firing a DELETE might not be possible so you can also delete a document by adding _deleted to the document and update it. This is especially useful for bulk operations, where many documents may be created, updated or deleted in a single

46 HTTP operation. As you'll be removing the document you can delete the rest of its contents, apart from the _id, _rev and _deleted fields. If you leave other fields they will be in the documents "tombstone", this can be useful when replicating or validating document edits Code examples To delete a document you need its _id and _rev, the easiest way to get the _rev for a known document _id is to issue a HEAD request against the document: Get the _rev Command curl -i -X HEAD Response HTTP/ OK X-Couch-Request-ID: 89d9d456 Server: CouchDB/1.0.2 (Erlang OTP/R14B) ETag: "2-e4b98cc0fc2a181e4eb26f8ad41fa5fe" Date: Mon, 04 Jun :47:15 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 113 Cache-Control: must-revalidate Delete the document CouchDB sets the ETag to be the document _rev (which is handy for caching purposes). Now we have the _id and _rev we can delete the document with: Command curl -X DELETE oc_rev] Response {"ok":true,"id":"[doc_id]","rev":"[doc_rev]"} Verify deletion Command curl Response {"error":"not_found","reason":"deleted"} Delete via PUT You can also delete a document via a PUT by adding the _deleted attribute to the document: Command curl -d '{"_rev":"[doc_rev]", "_deleted":true}' -X PUT Response {"ok":true,"id":"[doc_id]","rev":"[doc_rev]"}

47 Verify deletion Command curl Response {"error":"not_found","reason":"deleted"} REFERENCE: ents Cloudant allows the creation of indexes via the use of MapReduce Secondary indexes, or views, are defined in a map function, which pulls out data from your documents and an optional reduce function that aggregates the data emitted by the map. These functions are written in JavaScript and held in "design documents"; special documents that the database knows contain these - and other - functions. Design documents are special documents that define secondary indexes. A sample design document with MapReduce functions { "_id": "_design/name", "views": { "view1": { "map":"function(doc){emit(doc.field, 1)}", "reduce": "function(key, value, rereduce){return sum(values)}" } } } The naming convention for design documents is such that the name follows _design/ in the _id. This code defines view1 for the design document name. Design documents can contain multiple views; each is added to the views object. REFERENCE: ews-mapreduce Cloudant Query provides a declarative way to define and query indexes Cloudant Query is a declarative JSON querying syntax for Cloudant databases. Cloudant Query wraps several index types, starting with the Primary Index out-ofthe-box. Cloudant Query indexes can also be built using MapReduce Views (where the index type is json), and Search Indexes (where the index type is text). If you know exactly what data you want to look for, or you want to keep storage and processing requirements to a minimum, you can specify how the index is created, by making it of type json.

48 For maximum possible flexibility when looking for data, you would typically create an index of type text. Indexes of type text have a simple mechanism for automatically indexing all the fields in the documents. A sample json document to create a query index: { "index": { "fields": [ make"] }, name": make-index, type": json } Once the query index is created, the index may be searched using a selector which is also written as a json document. Selectors are conceptually similar to a SQL statement s WHERE clause. An example selector to return documents with the make VW with model year 2000 or later: { selector": { make": VW, year : { $ge : 2000} } } Cloudant Query provides two api endpoints, _index and _find that are used to manage indexes and perform queries against them using selectors. REFERNECE: uery Cloudant Sync simplifies large-scale mobile development Cloudant Sync enables you to push database access to the farthest edge of the network mobile devices, remote facilities, sensors, and internet-enabled goods, so that you can: Scale bigger Enable client apps to continue running off-line Cloudant Sync allows mobile and distributed apps to scale by replicating and synching data between multiple readable, writeable copies of the data in other data centers, and even on mobile ios and Android devices. This is much easier

49 and more cost efficient than growing a single, central database to handle all data collection. Cloudant Sync allows you to create a single database for every user; you simply replicate and sync the copy of this database in Cloudant with a local copy on their phone or tablet (or vehicle, sensor, appliance, etc.). This can reduce round-trip database requests with the server. If there s no network connection, the app runs off the database on the device; when the network connection is restored, Cloudant re-syncs the device and server. Some of Cloudant s largest mobile developers have scaled into the millions of databases Manage instances of IBM Bluemix data services: Cloudant NoSQL Database. SUBTASK(S): Create Instances of the Cloudant NoSQL Database Service Select Data and Analytics from the Services section of the Bluemix Catalog. Click Cloudant NoSQL DB Provide Service and Credential names and click Create Manage instances of the Cloudant NoSQL Database service Once an instance of the Cloudant NoSQL database service has been created in IBM Bluemix you can use the provided web interface to administer the database. A set of hands-on steps are provided to show some key concepts of managing the Cloudant NoSQL DB service. Launch the Cloudant NoSQL administration tool Connect to the landing page of your instance of Cloudant NoSQL database service by clicking on its service tile from the Bluemix Dashboard: Click on Launch when the services Landing page appears:

50 a. Create a database From the Cloudant Administration Tool click on Create Database, enter the name that you want for the new database and click Create. Note that the must start with a lowercase letter and contain only the following characters: o Lowercase characters (a-z) o Digits (0-9) o Any of the characters _, $, (, ), +, -, and / You ll be taken to the administration screen for the new database. b. Add data to an existing database From the home page of the Cloudant Administration tool click on the link for the database that you want to administer:

51 Click on the + icon next to All Documents and select New Doc from the context menu: A new JSON document appears with a single attribute name _id. This is the unique identifier for your new document. You can accept the generated value or put it your own. Add the additional fields to the document. When you re done click Create Document to save the changes. c. Edit documents in an existing database From the home page of the Cloudant Administration tool click on the name for the database that you want to administer. Click on All Documents, a summary of the documents in the database appears on the right:

52 Click on the pencil icon to edit the documents and then make your required changes. Click Save Changes to save your changes. d. Clone existing documents From the home page of the Cloudant Administration tool click on the link for the database that you want to administer. Click on All Documents, a summary of the documents in the database appears on the right: Click on the pencil icon of the document you want to clone.

53 Click on Clone Document in the document editor: You ll be prompted accept a system generated unique id for the new clone or to provide a unique id of your choice: Change the ID to something unique (or accept the generated one) and click Clone. You ll be taken to a document editor with the clone of the original document which is identical to the original (except for the _id and _rev fields): e. Perform a simple query of all documents in an existing database From the home page of the Cloudant Administration tool click on the link for the database that you want to administer.

54 Click on All Documents, a summary of the documents in the database appears on the right. To see the complete documents, click on Options, select Include Docs and click Run Query: All fields in all your documents will appear View and Create New Credentials for the CloudantDB instance Select the Cloudant NoSQL DB service from the Services view.

55 Select the Service Credentials screen and use the View Credentials dropdown to view the credentials of an existing user, or click the New Credential button to create a new user Credentials are provided in JSON format. The JSON snippet lists credentials, such as the API key and secret, as well as the connector information for the service Replication of Cloudant databases Cloudant replication is the process that synchronizes ('syncs') the state of two databases. Any change which has occurred in the source database is reproduced in the target database. You can create replications between any number of databases, whether continuous or not Replication takes place in one direction only. To keep two databases synchronized with each other, you must replicate in both directions Replications may be created in two ways Adding a replication document to the _replicator database. These replications are resumed automatically after a node restart A replication can be started by POSTing a JSON document describing the desired replication directly to the /_replicate endpoint. Replication jobs created this way are not resumed if the node they run on is restarted A replication document has the following format: Field Name Required Description source yes Identifies the database to copy revisions from. Can be a database URL, or an object

56 Field Name Required Description whose url property contains the full URL of the database. target yes Identifies the database to copy revisions to. Same format and interpretation as source. Does not have to be the same value as the source field. continuous no Continuously syncs state from the source to the target, only stopping when deleted. create_target no A value of true tells the replicator to create the target database if it does not exist. doc_ids no Array of document IDs; if given, only these documents are replicated. filter no Name of a filter function, defined in a design document. The filter function determines which documents get replicated. Note that using the selector option provides performance benefits compared with using the filter option. You should use the selector option where possible. proxy no Proxy server URL. query_params no A field containing key:value pairs, for use in filter function.

57 Field Name Required Description selector no Provide a simple filter to select the documents that are included in the replication. Using the selector option provides performance benefits compared with using the filteroption. More information about selector is available here. since_seq no Sequence from which the replication should start. More information about since_seq is available here. use_checkpoints no Indicate whether to create checkpoints. Checkpoints greatly reduce the time and resources needed for repeated replications. Setting this to false removes the requirement for write access to the sourcedatabase. Defaults to true. user_ctx no An object containing the username and optionally an array of roles, for example: "user_ctx": {"name": "jane", "roles": ["admin"]}. This is needed for the replication to show up in the output of /_active_tasks Configuring Cloudant access roles Users and API keys may be configured with granular access roles with the following capabilities: Role Description _reader Gives the user permission to read documents from the database.

58 Role _writer Description Gives the user permission to create, update, and delete documents (except design documents) in the database. _admin Gives the user the ability to change security settings, including adding roles. _replicator Gives the user permission to replicate a database, including creating checkpoints. _db_updates Gives the user permission to use the global changes feed. _design Gives the user permission to read design documents. _shards Gives the user access to the /$DATABASE/_shards endpoint. _security Gives the user permission to read from the /_api/v2/db/$database/_security endpoint At a minimum, in order to replicate a database a user or API key must have both the _reader and _replicator role Users and API keys with the _admin role inherit other roles. REFERENCES: Describe the IBM Data Connect Service for Bluemix. SUBTASK(S): Summarize the capabilities of IBM Data Connect

59 The IBM Data Connect service in Bluemix allows you to identify relevant data, transform the data to suit your needs, and load it to a system for use. IBM Data Connect is available from the Data Connect service dashboard. In IBM Data Connect, you begin by finding the data that you want to work with from data sources like IBM Cloudant NoSQL DB and IBM dashdb. You use metrics to better understand your data quality and identify areas to improve. To improve the data quality, you work with a sample of the data and apply shaping actions such as sorting, filtering, and joining. You can apply the actions to the full data set and load the data to destinations such as Cloudant NoSQL DB. Actions are defined and processed through Activities. Once an Activity is created, it may be used to set up recurring shaping and copy actions and the Activity control panel includes a display of the current run status. IBM Data Connect supports the source and target combinations in the following table. All of the supported targets are compatible with each source. Sources Targets Amazon Redshift Amazon S3 (CSV files) Amazon S3 (CSV files) IBM BigInsights HDFS (CSV files) Apache Hive IBM Cloudant NoSQL DB (See Note 2) Cloudera Impala Hortonworks HDFS Hortonworks HDFS IBM dashdb IBM Cloudant NoSQL DB IBM DB2 IBM dashdb IBM Object Storage for Bluemix IBM DB2 IBM Pure Data for Analytics IBM Informix IBM SQL Database IBM Object Storage for Bluemix IBM Watson Analytics IBM Pure Data for Analytics Microsoft Azure SQL IBM SQL Database Microsoft SQL Server Microsoft Azure MySQL Microsoft SQL Server Oracle MySQL PostgreSQL on Compose Oracle Softlayer Object Storage Pivotal Greenplum Teradata PostgreSQL PostgreSQL on Compose Salesforce.com Softlayer Object Storage Sybase Sybase IQ Teradata

60 Perform common tasks using IBM Data Connect Once a data set is connected to in Data Connect operations can be applied at the table level or the column level. Several shaping operations are supported. Here are some of the supported operations: Blank out Converts the string in the column to null. Ceiling of number Returns a number's nearest integer of greater value. Example: The ceiling of 2.31 is 3. The ceiling of is -2. Change the timestamp value Changes the timestamp in a column by a specified number of years, months, days, hours, minutes, seconds, and milliseconds. Each part of the timestamp can be independently advanced or set back. You can modify the timestamps in the selected column by up to 101 years earlier or later. Collapse white spaces Collapses multiple white spaces to a single white space. White space characters are spaces, tabs, line feeds, carriage returns and form feeds. Concatenate string Appends a user-specified string to the value in a selected column Before you can access your on-premises data sources with IBM Bluemix Data Connect, you must add a secure gateway, and connect your on-premises network location to it. Adding the gateway To connect to a secure gateway, you must install the Secure Gateway client on an on-premises computer that has free network access to all your on-premises data sources. Connecting to the secure gateway You must have the Secure Gateway client installed on an on-premises computer that has free network access to all required on-premises data sources. To connect to the secure gateway, use one of the following methods: If the on-premises computer is running the Linux or Mac OS operating system, it is recommended that the Docker software container system option be used to connect to the secure gateway.

61 If the on-premises computer is running the Windows operating system, it is recommended that the IBM Installer option to connect to the secure gateway be used. Configure the secure gateway access control list Follow the instructions in the Secure Gateway documentation to add the on premise database server and port to the access control list Data Connect has a Data Load REST API that allows applications to move data from sources to targets. The Data Connect Data Load REST API involves the following concepts: Activity Defines a single Data Connect task. Details about the request and response payloads that are used to create an activity are provided in the Data Connect Data Load REST API Reference. For Data Load activities, your app can create an activity and then run the same activity multiple times. Activity run The execution of an activity. You can monitor the status of runs of Data Load activities. An application using the Data Connect Data Load REST API needs the correct credentials for a specific instance of the Data Connect Service to successfully call the API. The following is the recommended procedure to get the Data Connect Data Load REST API credentials in an application: i. Bind the instance of the Data Connect service to be used to the application ii. Lookup the credentials for the service instance in VCAP_SERVICES environment variable. For example, after you bind an instance of the Data Connect service to an application, the VCAP_SERVICES environment variable will contains values similar is structure to the following: { "DataWorks_Gen3": [ { "credentials": { "userid": "bluemix_be06eb35-260d-454b-a353-1b c3", "password": "btqcymmdiay", "url": " },

62 } ] } "syslog_drain_url": null, "label": "DataWorks_Gen3", "provider": null, "plan": "Starter-GA", "name": "Data Connect-d1", "tags": [ "data_management", "ibm_created", "ibm_release", "ibm_dedicated_public" ]

63 Section 6 - Cloud Application Security 6.1 Understand how to configure external authentication using IBM Bluemix web applications with the Single Sign On service (SSO) SUBTASKS: Describe the Single Sign On Service available in IBM Bluemix IBM Single Sign On for Bluemix is an authentication service that provides an easy to embed single sign on capability for web applications. The service may be bound to multiple Bluemix applications to provide a common authentication service. Applications call the SSO service through an OpenID Connect compatible client implementation The SSO service can leverage a number of identity sources including an existing enterprise directory with SAML, popular social identity sources such as Facebook, LinkedIn and Google or you can create your own cloud directory The SSO service acts as an authentication broker for multiple identity sources. Identity Sources are collections of users, each collection is identified as a realm. The supported identity services are the following: Cloud Directory: this is a basic LDAP in the cloud that can be populated with simple username/password authentication credentials and a few other user attributes. Social providers: currently supporting Facebook, LinkedIn, Google, and GitHub These very commonly used identity providers allow your application to authenticate users and obtain identity information including an address. Enterprise directory identity repositories: this integration uses SAML post single sign on. The on-premise website authenticates users (acting as the identity provider) and then uses SAML to securely transmit that identity information to the SSO Service instance, which is acts in the role of a SAML service provider. A virtual appliance is

64 available to implement an authentication portal to an LDAP server if one is not already configured in the enterprise Integration requires the implementation of an authentication callback When adding the SSO service to an application, only a few steps are required. At a high level, the developer performs the following actions: Add the Single Sign On service to the dashboard Select the identity source(s) to configure Configure settings for identity source Bind SSO service to application and access integrate tab to download Node.js module ( if using Node.js ) Insert integration code into application (implementing callback method URL) o Node.js and Java samples provided, others use an OpenID Connect compatible client library Provide authentication callback URL and specify one or more configured identity sources for the application to use through the service integrate tab REFERENCES: _information 6.2 Configure an application to use SSL with a custom domain. SUBTASK(S): Understand how to create a custom domain in IBM Bluemix For Cloud Foundry apps and container groups, you can use a custom domain in the URL of your application instead of the default Bluemix system domain of mybluemix.net As a pre-requisite to creating a custom domain that will be publically accessible for your application, you must have or acquire ownership of registered internet domain name Domains provide the URL route that is allocated to your organization in Bluemix. To use a custom domain, you must register the custom domain on a public DNS server, configure the custom domain in Bluemix, and then map the custom domain to the Bluemix system domain on the public DNS server After your custom domain is mapped to the Bluemix system domain, requests for your custom domain are routed to your application in Bluemix. You can create and use a custom domain in Bluemix by using either the Bluemix user interface (via Account -> Manage Organisatons), or the cf command line interface.

65 6.2.2 Obtain a wildcard SSL certificate for the custom domain based on a private key A certificate is a digital document that binds a public key to the identity of the certificate owner. This enables the owner to be authenticated Bluemix supports the following file types: PEM (.pem,.crt,.cer, and.cert) DER (.der or.cer) PKCS #7 (.p7b,.p7r,.spc ) A Private key is an algorithmic pattern used to encrypt messages that only the corresponding public key can decrypt. The private key is also used to decrypt messages that were encrypted by the corresponding public key Setup a route for a Bluemix app that uses the custom domain and configure your DNS so traffic is routed to your app Specifically, you need to add a CNAME record that maps your domain to the hostname of the Bluemix router. The hostname will vary based on the region your app is deployed to US South (secure.us-south.bluemix.net), London (secure.eugb.bluemix.net), or Sydney (secure.au-syd.bluemix.net) Upload an SSL certificate for your custom domain. Click the Upload Certificate Icon to display the Upload Certificate dialog:

66 Choose your certificate file by clicking the browse button and then click UPLOAD. If the upload completes successfully, the dialog will go away and you will see the icon in the SSL Certificate column is now a green ribbon. At this point, you should be able to access your app using https (assuming your DNS was configured correctly). And, if you look at the certificate details in the browser, you should see your certificate instead of the default certificate for mybluemix.net Configure and manage trusted client access.

67 When working with an SSL protected domain, enabling the option to request a client certificate allows access to an application on the domain to be limited to specific clients Upload a client certificate trust store file to define the client-side certificates that can access the domain. REFERENCES: Securely handling credentials for APIs and other application services. SUBTASK(S): Write applications to use credentials for APIs and application services by reading from the application environment Acquire credentials for Bluemix managed services through binding to a Cloud Foundry runtime or Container and reading VCAP_SERVICES Store API keys and endpoints for other external services as userprovided services and bind the user-provided service to the application Don't embed API keys or other credentials in code or other supporting files for an application Avoid the use of credentials in URLs when implementing REST API endpoints to prevent leaking information through service logs Accept credentials such as username/password or API keys in a POST body or as a cookie in a request header REFERENCES: Understand capabilities to secure application data in IBM Cloud SUBTASK(S): Describe capabilities and use of IBM Bluemix Key Protect service IBM Key Protect is a cloud-based security service that provides life cycle management for encryption keys that are used in IBM Cloud services or customer-built applications. Key Protect provides roots of trust (RoT), backed by a hardware security module (HSM) Key Protect provides a centralized system to view, manage, and audit your encryption keys. Audit your keys and access restrictions to keys to ensure the security of your resources. You can monitor API calls to Key Protect with Access Trail Key Protect provides a REST API that can be used with any programming language to store, retrieve, and generate keys Describe capabilities of dashdb sensitive data reporting

68 The dashdb web console includes a sensitive data reporting feature that detects and monitors sensitive objects in the dashdb data warehouse, such as credit card numbers and US Social Security numbers To run and view reports that identify columns that contain sensitive data and provide information about connections and activities that access the sensitive data, select Monitor > Sensitive Data in the web console Understanding IBM DB2 on Cloud encryption capabilities with native encryption DB2 on Cloud supports encryption through the DB2 native encryption feature to protect data at rest With native database encryption, the database system itself encrypts the data before it calls the underlying file system to write that data to disk. Native database encryption is suitable for protecting data in cases of either physical theft of disk devices or privileged user abuse To create an encypted database in the default instance using the default keystore, issue the CREATE DATABASE command specifying the ENCRYPT parameter: > create db mydb1 encrypt REFERENCES: Section 7 - Using DevOps toolchain to develop and deliver cloud applications 7.1. Describe the capabilities of IBM Bluemix Continuous Delivery toolchains SUBTASK(S): Explain the benefits of adopting Continuous Delivery More frequent, smaller releases Changes are easier to deploy Changes are easier to roll back Time between concept and rollout is reduced Focus is on delivering features Less complexity to manage for each release Describe Continuous Delivery Continuous delivery (CD) encompasses the DevOps build, test, and deploy phases of developing and deploying software A toolchain is capable of continuously generating deployable, tested software, even if feature-incomplete.

69 Toolchains enable development organizations to standardize and scale their continuous delivery processes You can create a toolchain in two ways: use a template to create a toolchain or create a toolchain from an app Toolchains automate the process of constructing new dev, test and prod environments Toolchains treat infrastructure as code The following Continuous Delivery Templates are provided: Microservices Secure container Simple Cloud Foundry Simple Cloud Foundry toolchain with DevOps Insights Simple container toolchain Describe select tool integrations for IBM Bluemix Continuous Delivery toolchains Github Eclipse Orion Web IDE Bluemix Delivery Pipeline Sauce Labs Pager Duty Slack DevOps Insights Compare continuous integration to continuous delivery tools Continuous integration requires frequent code deliveries from each developer Builds are run continuously but the test and deploy phases are not encompassed by CI A CI project maintains multiple code branches CD supports the 12factor practice of maintaining Dev/prod parity REFERENCES: cd/ Understand capabilities for source code management for IBM Bluemix Continuous Delivery toolchains. SUBTASK(S): Describe the types of Git repositories you can use with the IBM Bluemix Continuous Delivery toolchains Existing GitHub repo New GitHub repo Explain how to configure GitHub to manage your source code Configure GitHub integration as you are creating a toochain

70 Add a GitHub integration to an existing toolchain Provide authorization to allow Bluemix Continous Delivery toolchains to access your GitHub account Understand common Git actions and their corresponding commands Fork a GitHub repository so that you can contribute changes through pull requests. This action is performed from the web UI at GitHub or other repository manager Create a new empty repository or reinitialize an existing one locally git init Clone a GitHub repository to create a local copy of it git clone <source repository URL> Connect a forked GitHub repository to the original repository as an upstream remote to syncronize changes from the original repository to the fork. git remote add upstream <original repo URL> Add changed files from a local clone to the index git add <file(s)> Commit changes to the repository (performed after all changes are added to the index) git commit Syncronize a remote repository with the local one by sending updates git push Join two or more development histories together git merge Track and resolve issues in a GitHub repository using bisect and blame Use binary search to find the commit that introduced a bug git bisect <subcommand> <options> Annotates each line in the given file with information from the revision which last modified the line. git blame <file name> REFERENCES: Develop and deploy cloud applications using IBM Bluemix Continuous Delivery and code editors SUBTASK(S): Develop and deploy applications for Bluemix continuous delivery locally and synchronize with the repository using Git commands Use a local code editor like Eclipse IDE or Atom text editor to edit code Use Git to synchronize with the source code repository Identify the correct syntax to use to connect to your Git repository Identify the correct syntax for using the git pull command Identify the correct syntax for using the git push command Develop applications using the Eclipse Orion Web IDE

71 The Web IDE provides content assist, tooltips, previews, validation, and syntax highlighting for JavaScript, HTML, CSS, and Markdown files. Describe the steps required to save and submit changes Demonstrate how to use the file navigator to create, rename, delete and manage files and folders Understand how to edit a file in the editor pane Deploy applications using the Eclipse Orion Web IDE Explain how to deploy an app from your workspace. From the workspace, you may customize deployment using the launch configuration. From the launch configuration, you may customize the region, organization, space of a deployment. The launch configuration can also be used to customize the application hostname, domain, services to bind from the target space and other properties typically set in the application manifest file Describe how to use Git commands to synchronize your IDE workspace to a Git repository If you store your code in a Git repository that is hosted by IBM Bluemix DevOps Services, you can work with code in a Git terminal or in a web IDE. If you work on a local workstation, you can use Git terminal commands to edit the contents of your Git repo When you work in the Web IDE, both your reference repository and workspace are hosted on the cloud. To view

72 the changes that you made to the reference repo that is stored outside of the workspace, you must sync with the repo. In the Web IDE Git menu, click SYNC. Sync combines the fetch, rebase, and push commands. Using Git buttons in Web IDE to perform specific actions separately: a. fetch - Downloads objects and refs to the workspace from the origin repository b. rebase Update the active branch in the workspace to the current state of the reference repo and reapply commits in your workspace. c. push Update the reference repository with commits made to the active brance in the workspace Use Live edit mode and debug Node.js applications using the WebIDE. In the Eclipse Orion Web IDE (Web IDE), in the run bar, click Live Edit. Live Edit allows you to quickly preview changes to Node.js applications running on Bluemix. When you update your code with Live Edit turned on, you can refresh your web application's browser window to see those changes reflected seconds after you make them. REFERENCES: Describe how to use Delivery Pipeline to manage continuous integration and continuous delivery SUBTASK(S): Explain how to configure the Delivery Pipeline Click the tile for Delivery Pipeline to view the pipeline and configure it Add additional integrations Explain how to Add and configure a stage. Specify the input for the stage and configure at least one build job Explain how to Add a job to a stage. Select Job Type and Environment Properties Explain how to run a stage Explain how to include settings to manage configuring ongoing execution in cases of job failures including options to stop or continue if a job fails Run Conditions: Select whether or not to Stop running a stage if a build or deploy job fails If this job fails, prevent other jobs from running and mark this stage as failed Explain how to manage continuous integration for delivering to a build Jobs in stages are run based on the stage trigger options

73 A build stage may be triggered from a change to a source code repository or configured for a manual run If you want to trigger the pipeline to execute when you push changes to your GitHub or GitHub Enterprise repository (repo), you must configure GitHub or GitHub Enterprise for your toolchain before you define the stages for your pipeline. Each stage can take input from only one of the GitHub or GitHub Enterprise repos that is associated with your toolchain. The input to the pipeline stage must be set to the Git URL for the repo Manage continuous delivery Explain how to automate builds and deployments Explain how to request manual or on-demand builds and deployments. To run a stage, click the Start button To cancel a running stage, on the stage, click View logs and history. In the list of jobs, click the running job's number and then click CANCEL. You can also cancel jobs individually by clicking a job and then clicking CANCEL, or by clicking the Stop icon next to a job on its stage.

74 REFERENCES: s.html#deliverypipeline html

75 Section 8 - Managing a running cloud application 8.1. Understand scaling concepts for a Cloud application and steps to scale an application in IBM Bluemix. SUBTASK(S): Describe the difference between vertical scaling and horizontal scaling Vertical scaling is achieved by increasing the resources available to an application instance Vertical scaling increases the resources available to an application by adding capacity directly to the individual nodes for example, adding additional memory or increasing the number of CPU cores Horizontal scaling is achieved by increasing the number of application instances Horizontal scaling is often referred to as scaling out. The overall application resource capacity grows through the addition of entire nodes. Each additional node adds equivalent capacity, such as the same amount of memory and the same CPU. Horizontal scaling typically is achievable without downtime Understand how to manually scale applications through the IBM Bluemix dashboard The IBM Bluemix Dashboard supports both vertical and horizontal scaling through increasing the amount of memory and increasing the number of instances of an application runtime. Both techniques can be applied to the same application: You can either scale out (increase resources) or scale in (reduce resources) using the IBM Bluemix dashboard.

76 Understand how to automatically scale applications in IBM Bluemix using the Auto-Scaling service with its scaling policy fields and opt options such as: available metric types for runtimes, breach duration, and cooldown period The Auto-Scaling service has control panels to define scaling policy, view metrics, and view scaling history. A scaling policy is based on thresholds for various metrics such as Memory, JVM Heap, Throughput, and Response time. The breach duration in the policy defines how long a threshold may be exceeded before a scaling event is performed. The cooldown period in the policy is how long to wait after a scaling event before monitoring for exceeded thresholds. REFERENCES: Perform load testing on Cloud applications using simulated loads and describe the benefits of load testing SUBTASK(S): Perform load testing on cloud applications Load testing determines the capability of a Bluemix application to handle amount of users (load) on your website, app or API. Run tests to ensure that your application remains available during critical times. Determine how your system will perform when subjected to a given load Load Test Iterations include a baseline, and further tests to evaluate if performance can be increased. Baseline testing is the initial performance evaluation to be performed under typical load and without application scaling or service tuning.

77 Several third party services such as Load Impact and Blaze Meter are available in the Bluemix catalog for performing application testing. These tests provide insights on performance and can also show if horizontal scaling is responding when the application is under stress Creating user scenarios A virtual user scenario corresponds to a set of actions within the application and can be captured interactively or defined in a script language of the specific load testing tool. These should be based on a typical use-case of a user accessing the application Defining virtual user load for a test The virtual user load run against an application can be focused on investigating different aspects of performance. Measure response time for the application for a specific number of active users. For this type of test, the user workload is ramped to a steady state level and then held for a period time to gather response time statistics. Determine peak scalability of an application. In this test the workload is increased in steps and held constant, or a series of test are performed each with a higher number of simulated users. A key metric such as the performance of a page providing user login or catalog display is monitored to ensure it does not exceed required levels Analyze results from load tests When a load test completes, tools provide graphical and tabular output of information to review. Graphs from load testing will show observed metrics like response time and number of simulated users, graphed as a function of the time into the load test:

78 Green dots show the virtual user (VU) load, and blue dots the duration of time for a user scenario to complete. In the example shown, there is no strong correlation between the response time and the number of active users. This can be interpreted as the application response time not showing sensitivity to the quantity of simulated users for the duration of the test. When reviewing results, it is critical to verify that all application responses are successful and not showing error codes. An application generating HTTP 404 or 500 errors may appear to show a quick response time, but it is not operating correctly Describe benefits of load testing Cost-savings: performing adequate load testing (through application tuning and capacity planning) saves you the trouble of making unnecessary investments later Builds confidence: Load testing assures you that your website/app/api is capable of handling heavy traffic, even before going live. And it will continue to do so until further notice More time for innovation: A skilled developer free from routine manual tasks, such as performance testing, is a resource capable of contributing real business value innovating in ways that less development time simply can t achieve Contrast automated testing with manual testing. Automation allows testing to happen quickly, repeatably, and on demand. REFERENCES:

79 8.3. Explain various methods to monitor an application. SUBTASK(S): Monitoring availability of Cloud Foundry applications hosted on Bluemix Availability Monitoring service helps DevOps teams ensure their applications are always available and meeting user expectations for response time as they roll out continuous updates. The service, which is tightly integrated into the DevOps toolchain, runs synthetic tests from locations around the world, around the clock to proactively detect and fix performance issues before they impact users Describe the abilities of Availability Monitoring Service Availability Monitoring Service provides ability to set alerts on critical events of the application that is hosted on Bluemix or anywhere in the world. Figure Alerts Application owners can set to receive alerts by . Slack, SMS or by Push notifications on issues of the application before they impact users.

80 Synthetic Tests Application owners can set two different types of tests 1. Test to monitor load time and availability 2. Test a specific behavior of a website through scripting. In the Manage tab of the Availability Monitoring service, click on the Add New Test icon to set up a test. The tests can be added from Monitoring details dashboard Figure 2 Figure 3 Here you have option to set up a Load Time test or a Scripted Behavior.

81 Monitor Load Time and availability You can set up to monitor the load time and availability of any webpage REST API Bluemix app App hosted anywhere. Figure 4 Scripted behavior

82 Figure Monitoring details In the Manage tab of the Monitoring and Analytics service, click on the See Monitoring Details icon to see monitoring details as below: Availability and Status Figure Alerts

83 Figure Activity Figure Response Time

84 Figure Availability Figure 10

85 Using Availability Monitoring as an Unbound vs Bound Service If you are monitoring only non Bluemix applications then you can just use a instance of Unbound Availability Monitor service Bluemix applications can be monitored by Availability Monitor service that is bound to application or Unbound Application Monitor service Describe the Monitoring and Analytics service for Cloud Foundry applications Monitoring and Analytics service is always used as bound service of a Bluemix application. Monitoring your app enables you to see and control your app deployment. For stable operations of your deployments on Bluemix platform, you want to detect problems promptly and determine causes efficiently. To accomplish this objective, keep troubleshooting in mind when you design your apps, and use services or tools for monitoring and logging when your app is deployed to Bluemix. Describe the abilities of Monitoring and Analytics service. With monitoring, you can accomplish the following tasks: Availability of the bound application

86 Collect and monitor performance information for app instances, and check whether they are functional. Gain insight on application operations, for example, detect the potential bottlenecks or when upgrades are required.

87 Estimate resource usage and charges Describe monitoring and logging capabilities of IBM Bluemix Container Service Monitoring and logging data is automatically available for containers from the dashboard without additional configuration Monitoring data includes memory used, cpu used and network traffic Log data is collected from STDERR and STDOUT for the application running in the container. Any log data that is stored as files in the container are not presented in the dashboard

88 REFERENCES: #avmon_about_c Debug a Cloud application running on IBM Bluemix

89 SUBTASK(S): Use the Bluemix logs console of a Cloud Foundry application for viewing error messages from a running application or from the staging process To leverage the logging feature, navigate to one of your Cloud Foundry apps in the Dashboard. In the left sidebar menu, click the logs tab to view the Logs console. This shows the same log output that you would see if you typed in bx app logs appname --recent into your terminal Lookup Bluemix error message ID to find more information about how to resolve the problem Using tracing and dumps to debug Bluemix errors during Cloud Foundry app staging The Cloud Foundry environment records fine-grained informational events for debugging. You can use this log to troubleshoot buildpack execution problems. To generate data to the buildpack.log file, you must enable buildpack tracing by using the following command: cf set-env appname JBP_LOG_LEVEL DEBUG buildpack.log This log file records fine-grained informational events for debugging. You can use this log to troubleshoot buildpack execution problems staging_task.log This log file records messages after the major steps of the staging task. You can use this log to troubleshoot staging problems Debugging command execution when using the IBM Bluemix Container Service With the Cloud Foundry plug in for IBM Bluemix Container Service, you can enable debug mode for individual commands to see the HTTP request that is being made and the response that the request gets Use either the -v or --verbose option before the command: cf ic v <command> <options> Debugging applications using the Cloud Foundry CLI command Tailing logs when you deploy apps Explain how to use the cf logs command