IBM Cloud Certification

OpenWhisk: Action Runtimes

*Action Runtimes*: You can develop in JavaScript, Swift, Python and Java, or create a Docker container with your application code in another language. Develop your code in the Bluemix web-based interface, or with your favorite development IDE and use the OpenWhisk CLI to upload it.

IBM Cloud SaaS portfolio

*Business Process as a Service* - Rely on BPaaS tools to manage specific industry solutions that streamline efficiencies, unify business processes and enhance customer experience. *Social Business*: Increase innovation and accelerate decision making by unifying human capital to build high-functioning communities. *Analytics*: Facilitate better decisions, increased efficiency and faster innovation across the enterprise by delivering the right data to the right people more effectively and economically than ever. *Digital Commerce* - Leverage the power of the cloud to drive more meaningful interactions with customers and suppliers across every facet of the value chain: buy, market, sell and service. *Smarter Cities*: Flexible, cost-effective SaaS solutions grow with a city's demands and deliver the powerful data needed to efficiently manage resources and make informed, proactive decisions. *Security*: Making IBM's expertise in network, systems and application security available in an on-demand subscription model through the Cloud.

Core IT: Benefits

*Core IT Benefits* - As stable and customizable as the customer wants - the only main limitation is cost. - Necessary for certain solutions (eg. transaction processing) - Houses a lot of the investments most companies have already made.

Core IT: Time Commitment

*Core IT Time Commitment* - Typically takes weeks to setup an environment and deploy an initial app - Have to maintain hardware and software as well. Dedicated staff necessary.

Domains

*Domains* provide the base part of a route on the Internet for an application. All organizations have access to shared system domains. Organizations can also define their own custom domains based on Internet domains that they have registered as a Public Internet Domain. In order to be able to use a custom domain that your organization owns, you need to add the domain to your Bluemix organization and then update the public DNS to use a CNAME record to direct traffic for that domain to the Bluemix secure endpoint for the region where your application is running

bx cli: Push an application to Bluemix

*Usage* bx app push APP [-b URL] [-c COMMAND] [-d DOMAIN] [-i NUM_INSTANCES] [-m MEMORY] [-n HOST] [-p PATH] [-s STACK] [--no-hostname] [--no-route] [--no-start] - The bx app push command in allows you deploy and start your application in Cloud Foundry - Command line options will take precedence over values that are specified in the application manifest file. - Anything not specified at the command line will be taken from the manifest, and if not specified there, from bx cli defaults. There's a few important options to note: -b lets you specify a custom buildpack by name or url. -c is used to specify how to start the application --no-route - don't map a route to the application. --no-start - upload application bits, but don't stage or start the application *Example:* bx app push my-app -c "node my-app.js"

Log in to Bluemix

*Usage*: bx login [-a API_URL] [--apikey API_KEY | @API_KEY_FILE_PATH ] [--sso] [-u USERNAME] [-p PASSWORD] [-o ORG] [-s SPACE] *Arguments* *API endpoint*: This is the URL of the Cloud Controller in your Cloud Foundry instance *API key*: Alternative to user name, password, and org *SSO flag*: Needed when using an enterprise ID federated with IBMid *Org*: The organization where you want to deploy your application. *Space*: The space in the organization where you want to deploy your application. *Example:* bx login -a https://api.ng.bluemix.net -u [email protected] -p XXXX -o [email protected] -s dev

Bluemix: User provided services usage scenarios

*User-provided* services are used in two scenarios. - By adding a set of service credentials to an external service as a user-provided service. Then when the service instance is bound to the application, the credentials will be in VCAP_SERVICES like other services. - Enabling the use of an external logging service. Protocols in addition to syslog can be specified if needed depending on the external log service including syslog over tls or https.

Bluemix Compute: Bare Metal

- *Bare Metal* servers give leading Cloud performance and full control of all aspects of the compute to the developer. - It's housed in your IBM Cloud data center of choice, located in one of over 40 locations worldwide. This allows you to place your compute and data close to customers for maximum performance and address any necessary concerns over data locality. - Bare metal servers can be ordered in a number of configurations for CPU, memory and storage. Compute assist GPU options are also available. - Typically, applications with the most sensitivity to performance and capacity are matched with the bare metal server offering. - This is the most powerful Infrastructure as a Service offering in IBM Cloud.

OpenWhisk on IBM Bluemix

- *IBM® Bluemix® OpenWhisk* is a distributed, event-driven compute service it runs application logic in response to events or direct invocations from web or mobile apps over HTTP. - Events can come from Bluemix services or outside sources. - In this model, developers focus on writing only the application logic, creating actions that are executed on demand, incurring charges only for active CPU usage - No need for explicit scaling steps like adding servers or instances, and no paying of hourly charges for servers when they sit idle

Infrastructure as a Service (IaaS)

- *Infrastructure as a Service* was the cloud's initial answer to the need for faster deployments, faster environment setup, etc... by abstracting the infrastructure from the customer. - It manages infrastructure resources in a resource pool, with self-service provisioning, rapid elasticity, and as measured services. - Server Virtualization in the enterprise data center alone does not accomplish this dynamic vision and characteristics. - Only when infrastructure resources are provided and managed as a set of capacity services, can the data center be treated as a true software-defined environment

Bluemix deployment models

- *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.

Spaces provide isolation within an organization

- *Spaces* provide a mechanism to collect related applications, services, and the users that can collaborate on the resources. - An *organization* can contain multiple spaces. All Cloud Foundry applications and most created catalog services in Bluemix are associated with a space. - Some services, like the Secure Gateway service only need to be created once in an organization and can be used by applications in multiple spaces within the organization. - A user *must* be a member of an organization before they can be added as a member of a specific space. - In order to create applications, a user *must* be a member of a space and be assigned the developer role.

Quota defines organization resource limits

- A *quota* represents the resource limits for the organization and defines the number of services and the amount of memory that can be allocated for use by the organization. - Any applications or services in a space of the organization contributes to the usage of the quota. - The quota is assigned when the organization is created in Bluemix Public.

Routes

- A *route* is the URL that is used to direct requests to an application. - A route is a combination of domain name and hostname that is specified when an application is pushed. - In example route myapp.example.com, myapp would be the host and example.com is the domain. - Unless a custom domain is specified, Bluemix uses a *default shared domain* in the route to your application, for example, mybluemix.net.

OpenWhisk: 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 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.

OpemWhisk: 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*.

Bluemix region: a defined geographical territory

- A Bluemix region is a defined geographical territory that you can deploy your applications to. - Each Bluemix region is independent from other regions. - You can select the region that is nearest to your 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 or personal information locality issues.

Buildpacks

- A buildpack is a collection of scripts that prepare your code for execution on the target PaaS. - A buildpack gathers the runtime and framework dependencies of an application and packages them with the application into a droplet that can be deployed to the cloud. - Buildpacks are automatically selected when the application is staged for deployment - The buildpack model addresses the complexity of runtime composition for modern applications.

Bluemix Infrastructure: Key Resources

- A dedicated bare metal server, custom configured to your spec - A Virtual Machine - Off server Storage Options: NAS, SAN, Object storage - A private or hybrid cloud model with direct links to your enterprise data centers - Hardware Firewalls and Load Balancers - IP addresses, subnets, VLANs

bx cli: Manage Domains and Routes

- All domains are mapped to an org. - Domains can be shared or private. - Shared domains are registered to multiple orgs while private domains, or owned domains, are registered to one org. - A Cloud Foundry instance defines a default shared domain that your application uses unless you specify a different domain. *Commands for managing domains*: bx app domain-create — Create a domain. bx app domain-delete — Delete a domain. bx app domain domain-cert-add - Add an ssl certificate to a domain *Commands to manage routes*: bx app route-create - create a route (form of hostname.domain) bx app route-map - map a route to an application bx app route-unmap - remove a route from an application bx route-delete - delete a route.

Roles and permissions: Space Level

- At the space level, managers can add users to the space and manage roles within the space. - A user does not need to have any Organization role assigned in order to be a *manager*, *developer*, or *auditor* in a space. - Space *developers* can create, delete, and manage applications and services within the space. - Both space *managers* and *developers* have access to *VCAP_SERVICES* environment variable for an application within a space. - *Auditors* can only view content in the space, and do not have access to service credentials associated with applications in the space.

Bluemix Infrastructure: Services

- Backups - Vulnerability scans - Object Store, Monitoring - Messaging service - Content Delivery Network (CDN) - Email delivery service - Anti-virus software - DNS entries

Application runtimes and buildpacks

- Bluemix Cloud Foundry *application runtimes* are provided through *buildpacks*. - A *buildpack* is a collection of scripts that prepare your code for execution on the target PaaS. - It gathers the *runtime* and *framework* dependencies of an application. - Then, it packages them with the application into a *droplet* that can be deployed to the cloud.

IBM Bluemix Infrastructure Virtual Servers

- Bluemix Infrastructure uses VM technology to provide it's virtual server offerings. Virtual servers can be made available in a much wider range of sizes and mix of CPU and memory configurations since they are configured as software on the hypervisor. - Each virtual server has three networks, management, private network within the cloud and public Internet. - Additionally, Bluemix Infrastructure has two hypervisor tenancy models that you can choose from for each server: *Virtual Server public* & *Virtual server private*.

Buildpacks installed on Bluemix

- By default, when an application is staged, a buildpack is *automatically selected* based upon the *artifacts for the application*. - For Liberty, this could be just a war or ear file, or a server.xml file, for Node.js, the presence of a package.json file is used. - The buildpacks are matched by position order, with the lowest number buildpack being used for the runtime of the application. - To override and specifically choose a buildpack, you can use the -b option to the application push from the CLI, using either the name shown for the buildpack or a URL to a git repository with the buildpack to use. - Buildpacks also have default runtimes, if a runtime default changes, this may affect your application, so it is a best practice to specify the desired runtime version along with other application dependencies. *Buildpacks cache dependencies*. Typically a current level and two prior levels are available. If an application requests a runtime version that is not available in the buildpack, the deployment will fail.

Cloud Foundry applications key components

- Cloud Foundry applications run inside a container architecture supported by a specific language runtime and surrounded by all the infrastructure necessary to host the application. - Cloud Foundry applications provide a good architectural fit for developing web applications, RESTful APIs and API-based Mobile Backends. - Applications can be self contained, or consume services from the Bluemix catalog or external services and APIs - They can be accessed using REST/HTTP and web socket protocols, allowing the Bluemix infrastructure to easily provide horizontal scaling of applications through a request routing layer. - As a developer, for deployment and other management tasks you interact with and control your application through either the Bluemix Web UI, or a Command Line interface.

Cloud Foundry apps on IBM Bluemix

- Cloud Foundry is an open platform as a service, providing a choice of clouds, developer frameworks, and application services. - Cloud Foundry makes it faster and easier to build, test, deploy, and scale applications. - It is an open source project and is available through a variety of private cloud distributions and public cloud instances. - The open and extensible nature of Cloud Foundry means developers will not be locked into a single framework, single set of application services, or a single cloud.

IBM Bluemix Container Service

- Containers enable you to build your app in any language, with any programming tools. - A container is created from an image, which is a read-only template that includes all dependencies and component that the application needs to run. - Each container is an isolated and secure application platform, separated from any other processes running on the host. - Applications in containers can run anywhere: development workstations that are running OS X, Windows or Linux, servers that are running Ubuntu and other Linux server platforms. - Containers can help you build high-quality portable apps quickly and without a lot of hard work.

IaaS: Time Commitment

- Customer sets up and manages OS, Middleware, and Runtime - these still take at least a matter of days to setup and reach an initial deployment - Maintenance/upgrades necessary as well

Twelve Factor: 2. Dependencies

- Explicitly declare and isolate dependencies. - Typically platform dependent, for example, npm, bundler, or Liberty feature manager. - Never rely on or assume systemwide dependencies. *Bluemix Cloud Foundry*: buildpacks manage external dependencies during staging.

Roles and permissions: Organization Level

- For an organization, there is a *manager*, *billing manager* and *auditor* role. - The *manager* 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. - The *billing manager* can view runtime and service usage information for the organization on the Usage Dashboard page. - 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.

Application buildpack types

- IBM provided and supported runtimes (blue IBM logo on the runtime tile) - Community buildpacks from the Cloud Foundry open source community (green Community logo on the runtime tile). - You can specify your own buildpack/runtime when using the CLI to push an application.

PaaS: Time Commitment

- Minutes to initial deployment - developer can handle everything on their own - Maintenance and upgrades of Platform and Infrastructure handled by service provider

IaaS: Benefits

- Networking, Storage, Server, Vitualization managed by service provider. - Most customizable cloud offering - Solutions where`customizability of OS, Middleware, or Runtime needed.

Bluemix Infrastructure (Softlayer): Architecture

- One platform for on the cloud for public virtual servers, private virtual servers, and bare metal servers - Unified systems management & rich API - Technology-neutral platform, use built-in or bring your own hyper-visor - Support for broad range of operating systems, virtualization platforms

IBM Bluemix Container Service capabilities

- Provides a private container registry that allows you to store your images on the cloud with the controls to ensure no one else can access them. - As soon as you deploy new containers, you gain insight into the CPU, memory and network utilization per container, as well as access to the latest log messages. - For single containers, it is trivial to request an IP address and assign it to a container using Bluemix. After fully testing the app in your container, you can bind a public IP to it and access the app on the Internet. - The *Vulnerability adviser* reviews container images in the Bluemix container registry for security issues. It evaluates OS package currency and also policy settings (e.g. root ssh login enabled) and provides a report allowing the developer to investigate issues. - Containers use an *ephemeral storage model*, with a temporary copy-on-write layer created at container application startup. - Container Volumes allow you to provide persisted storage to one or more containers running in a cluster. - Data persisted in a volume can be be backed up and restored through the cli

Cloud Foundry architecture: Key Components

- Router - Authentication - Cloud Controller - Application Execution (Cell) - Blob Store - Service Brokers - Message Bus - Logging and Statistics

PaaS: Benefits

- Setup your environment and deploy apps quicker than any other offering - Service provider manages the Infrastructure AND the platform... operating system security patches, firewalls, and all of the rest as well.

Bluemix command-line interface

- The *Bluemix CLI* extends the capabilities of the Cloud Foundry (cf) CLI and includes a set of sub-commands that are customized for managing your applications on Bluemix. - Commands help you manage applications, services, managing your, orgs, spaces, users and api keys. - The Bluemix CLI is modular and can add extra functionality through install-able plugins.

Cloud Foundry Arch: Application Execution (Cell)

- The *Cell* manages application instances, tracks started instances, and broadcasts state messages. - Application instances live inside *Garden* containers. - Garden manages isolated, ephemeral, and resource-controlled environments. - Containerization ensures that application instances run in isolation, get their fair share of resources, and are protected from noisy neighbors.

Cloud Foundry Arch: Cloud Controller

- The *Cloud Controller* is responsible for managing the life cycle of applications. - When a developer pushes an application to Cloud Foundry, the Cloud Controller stores the raw application bits, creates a record to track the application metadata, and creates a *staging task* for a Cell to execute and then a *long range process task* for running one or more instances of the application. - The Cloud Controller also maintains records of organizations, spaces, services, service instances, user roles, and more. - Application availability is coordinated by the nsync, BBS, and Cell Reps components. - The nsync component stores the desired number of instances (Long Range Processes) in the BBS and the BBS monitors report of actual instances from the Cell Reps.

Cloud Foundry Arch: Message Bus

- The key components for communicating in the Cloud Foundry Diego system is the *Bulletin Board Service (or BBS)*. - Cloud Foundry uses HTTP/S to communicate between components and stores frequently updated information in the Diego Bulletin Board Service (BBS) and long-lived control data in Consul. - The NATS Message Bus is used by the router-emitter to broadcast routing tables to the Router.

Cloud Foundry Arch: Logging and Statistics

- The metrics collector gather metrics from the components. - Operators can use this information to monitor an instance of Cloud Foundry. - The application log aggregation streams application logs to developers.

IBM Bluemix Cloud Foundry application architecture

- Using Cloud Foundry open source technology, Bluemix provides control where it's needed to application developers through a Platform as a Service (PaaS) offering. - The goal is to simplify the delivery of an application by providing services that are ready for immediate use and managed hosting capabilities to enable deployment at scale. - With the broad set of services, runtimes and APIs in Bluemix, the developer gains control and flexibility, and has access to various technologies, from Watson for cognitive, internet of things and data science. Bluemix provides the following features: - A range of services that enable you to build and extend web and mobile apps fast. - Processing power for you to deliver app changes continuously. - Fit-for-purpose programming models and services. - Manageability of services and applications. - Optimized and elastic workloads. - Continuous availability.

What are the twelve factors?

1) Codebase - One codebase tracked in revision control, many deploys. 1-1 relationship between app and code repo; use packages for shared code 2) Dependencies - Declared and isolated (no system wide dependencies) 3) Config - Store config in the environment (not in constants in the app) 4) Backing services - Treat backing services as attached resources. Can be attached and reattached without affecting code 5) Build, release, run - Strictly separate build and run stages 6) Processes - Execute the app as one or more stateless processes. State shared via external services; no sticky sessions! 7) Port binding - Export services via port binding. In deployment, a routing layer handles routing requests from a public-facing host name 8) Concurrency - Scale out via the process model 9) Disposability - Maximize robustness with fast startup and graceful shutdown 10) Dev/prod parity - Keep development, staging, and production as similar as possible 11) Logs - Treat logs as event streams 12) Admin processes - Run admin/management tasks as one-off processes

Bluemix boilerplates

A *boilerplate* is a template for an application available through the Bluemix catalog. Each boilerplate includes an associated *runtime environment*, some *sample code* and includes some *predefined services* for a *particular domain*. The Bluemix catalog includes Boilerplates that show you how to make a simple web application that interacts with a Cloudant NoSQL Database using a few different programming language runtimes. There are also Boilerplates for Internet of Things, MobileFirst and the Watson Personality Insights service. Boilerplates provides a quick starting point for customization along with a way to see how Bluemix services can be used.

Bluemix managed services

A *service* is a application extension that is used over a network. Bluemix has a catalog of over 130 services available for your application. The service provides functionality that is ready-for-use by the app's running code. Services in the catalog come from IBM, third parties as commercial offerings and open source communities. You can even create your own services in Bluemix by implementing the Cloud Foundry *Service Broker* API. Bluemix simplifies the use of services by provisioning new instances of the service, and binding those service instances to your application. The management of the service is handled automatically by Bluemix.

Container group scaling and high availability

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 availability zone in one Bluemix region, be spread across multiple availability zones and even configured in different availability zones in two regions.

Routes: blue-green or red/black deployment

A route can be associated with one or more applications, which will result in traffic being sent to the applications in a round-robin fashion. This technique is used as part of a zero-downtime deployment, often called blue-green or red/black deployment.

Dockerfile

A text document that contains all the commands or instructions to build the application image for container. These are read-only templates.

Codebase: Bluemix continuous delivery toolchains

A toolchain is a set of tool integrations that support development, deployment, and operations tasks. Tool integrations with the source code repository and delivery pipelines can drive multiple deployments from a single repository.

Virtual Machine

A virtual machine is a software implementation of a machine that executes programs like a real machine. Within the virtual machine (VM) is the application and a complete operating system, running on virtualized hardware that is provided by a hypervisor. The hypervisor separates the virtual machine from the host, and allocates resources as needed. Many VMs can run simultaneously on a single host system. The guest OS might not be the same as the server of host OS.

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 to events from Bluemix and third party services using a trigger.

Cloud Foundry Arch: Service Brokers

Applications typically depend on services such as databases or third-party SaaS providers. When a developer provisions and binds a service to an application, the *service broker* for that service is responsible for providing the service instance.

Roles and permissions: Account Level

At the account level, there is one owner user, who has full control of the account, all other users associated with the account are members, who may be assigned roles and associated permissions at the Organization and Space level.

Twelve Factor: 4. Backing services

Backing services - This is about treating backing services as attached resources. They may be running on the same machine, they may be running on different machines, they may be running in third party servers. You need to effectively treat these as attached resources that are easily and cleanly bound. bx service bind (After doing bx service create)

Bluemix: Compute Options

Bluemix gives the developer a wide range of IaaS and PaaS compute options. - Bare Metal - Virtual Servers - Containers - Cloud Foundry Applications - OpenWhisk

IBM Bluemix (PaaS) offerings

Bluemix provides a range of compute deployment options in a Platform-as-a-Service model. These PaaS services are based open-standards, providing a cloud-based platform for building, managing, and running applications of all types (web, mobile, big data, new smart devices, and so on). In addition to these compute models, Bluemix brings a full suite of cloud services to one place, such as API management & Integration, DevOps, IoT, Cloud integration, Big Data and Analytics, Security and Watson to enhance development experience and provide enterprise capability. So whether you're creating apps for the web, for mobile, IoT or for Big Data, Bluemix can help you build them smarter and get them to market faster... We will introduce detail Bluemix capabilities in later on through the course.

Twelve Factor: 5. Build, release, run

Build release and run. Strictly separate the build and run stages. CF creates all the components required to run the actual application on the CF platform, and does this during application staging to immutable container image.

Bluemix Compute: Cloud Foundry Applications

Cloud Foundry Applications run apps using a supported runtime, with explicit binding of managed services to applications. Developers push code artifacts to Cloud Foundry that are then packaged and executed with built-in support for horizontal app scalability.

Services in Bluemix

Cloud Foundry defines two classes of services. Both of these are scoped to a specific org and space. These services can be bound to Cloud Foundry applications and also used by other compute types within Bluemix through integration features of those compute platforms. One type is *managed services*. These you will find in the Bluemix catalog and are developed by IBM, third parties, and you can also create them using the *Cloud Foundry Service Broker* API. A second and important class of service is the *user-provided* services. It's a way to "bring your own" API or service to your Bluemix environment.

Twelve Factor: 8. Concurrency

Concurrency factor is about scaling out via the process model. A 12-factor app is designed to be composed of one (or more) stateless processes. When a process or instance reaches resource capacity of the VM, the application scales by adding another instance, or horizontal scaling. Microservices architectural style takes this a step further by splitting up a monolithic application into components of different functions allowing independent horizontal scaling of a particular component. Bluemix: CF applications can be scaled manually using cli or Web UI and also automatically using the auto-scaling service. Containers use scalable container groups or kubernetes autoscaling.

Twelve Factor: 3. Config

Config - What we want to do is store the configuration alongside the specific application deployment. Things like where my particular database lives in test versus production; those are also changed as you go along but are tracked effectively.

Docker container lifecycle

Container *images* are built using a *Dockerfile*. - The container Build Engine pulls the base image from the source image repository based on the instructions in the Dockerfile. - It completes other steps from the Dockerfile including copying the application code into the container image. - Completion of the build results in image being stored local to the build engine. - Next, the image is pushed to a registry, which serves as the container image repository for storage and sharing. This could be a public registry like *Docker Hub* or an enterprise private registry. - To create a running container, the docker engine on the server, or other hosting environment, pulls the image from the container image repository, creates a copy-on-write (union) filesystem layer for use by the running application. - All changes to this filesystem are *ephemeral* and are discarded when the container is destroyed.

Docker container image

Container images are composed of a series of layers, each one corresponding to a change to the filesystem or other command. Loosely, you can think of an image corresponding to an element of the application stack, one layer for operating system, another layer for tools and runtime, another layer for application code, another layer for dependencies and so on.

Bluemix Compute: Containers

Containers give maximum portability across environments, developers create application or microservice and package in a Container and then deploys to a server that could be on-premise or in the Cloud

Traditional on-premises: core IT

Core IT represents everything you own and manage in your data centers. This is still a critical part of enterprise IT. Core IT doesn't lend itself to the experimental nature of development appearing in the cloud/app revolution

Twelve Factor: 9. Disposability

Disposability is about maximizing robustness with having fast start up and graceful shut down. In a nutshell, it means that processors should start almost instantaneously. When you shut them down, there should be no house keeping or extra work that you have to do. They just go away. Graceful and quick shutdown can take a different approach to this depending on the component. - For a web process receiving a SIGTERM, it should stop listening on the service port, and then handle any outstanding requests before exiting. - A worker process can take any incomplete work and return it to the queue.

12 factor: config example

Example for a hypothetical Java Liberty Cloud Foundry application Application read info stored in VCAP_SERVICES and uses the service. The code remains same but the info in the VCAP_SERVICES would change between dev, test or prod. Facilitates the statement "...the codebase could be made open source at any moment, without compromising any credentials." http://12factor.net/config

Twelve Factor: 7. Port binding

Export your services via port binding. This is in alternative as to depending on an external web service, like Apache or Tomcat to handle incoming requests. A 12-factor app is completely self-contained and binds as a service to a network port. When running locally, a 12-factor application will bind to the workstation port and be accessed with a url like http://localhost:3000. On Bluemix Cloud Foundry - the application will bind to the port, and the Bluemix perimeter will route incoming traffic to the application instance or instances. As a result, an application that is developed and tested locally can work seamlessly on IBM Bluemix without any code changes. This concept isn't restricted to http and web sockets, most network services embrace the concept of binding to a port (even a non-standard port) and accepting requests with their respective protocols.

Manage organizations from the Bluemix dashboard

From the Bluemix dashboard, your current region, organization, and space are shown. To edit your organization and it's members, select Manage > Account > Organizations. All organizations that are grouped within the current Account are shown. You can select an organization to see the details of that organization and see the list of spaces. You can select Edit Org to bring up the panel to manage Users, Domains and view quota use in the organization. There's also an option to change the organization name. The expanded view shows the Users of the organization and their organizational roles. User roles are also assigned at the space level to allow them to view access as specific space and manage applications within the space.

Bluemix managed service-related commands

Here are some of the most common *bluemix service* CLI commands. *offerings* - display all services available from the catalog, with the service name, the plans available (e.g. lite, standard, professional) and a short description *list* - display the provisioned services in the current organization and space *create* - create a new service instance of specified type, plan and the name to use for the service in the space *bind* - link (or bind) a provisioned service to an application *delete* - remove a provisioned service instance from the space

IBM Marketplace

IBM Marketplace is an online store and catalog where service providers (IBM or Business Partners) can publish their cloud services, and consumers (also called clients) can purchase these services. IBM's marketplace contains a variety of Software as a Service products that can be up and running within minutes of ordering.

IBM Bluemix: Kubernetes Orchestration

In the spring of 2017, IBM announced the availability of Kubernetes orchestration in the IBM Bluemix Container Service. Kubernetes provides an open platform for managing Containers in deployments that combine simple scaling, rolling updates of container images, private container networking for services and the ability to expose applications to the internet through a number of ingress and port services options.

Implement omni-channel using backend for front-end (BFF)

In this application, the clients access the application microservices through an API Gateway. In the reference implementation, this capability is provided by API Connect in Bluemix. This gateway component supports Oauth, allowing authentication for API requests. The Web and Mobile app invoke their own backend Microservices to fetch data, we call this component BFFs following the Backend for Frontends pattern. In this Layer, front end developers usually write 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.

Twelve Factor: 10. Development and production parity

Keep your development, staging, and production as similar as possible. Avoid the "works on my machine" problem... This ties into agile software delivery, continuous integration, and continuous deployment type of concepts. You want them to be identical, especially concerning dependencies and backing services. In Cloud Foundry, Bluemix spaces provide separation within the same organization for an easy way to accomplish separation when hosting. They also provide a logical place to implement separation of duties which is a very common application security requirement.

bx cli: Application Loggregator

Loggregator is the user application logging subsystem of Cloud Foundry Loggregator collects events from the Cloud Foundry environment components and also standard out and standard error from the application running on the runtime. The cli provides commands that allow you to • Tail application logs. • Dump a recent set of application logs from the buffer. • Continually drain their application logs to 3rd party log archive and analysis services (by adding a user-provided service for the log endpoint) Usage: bx app logs APP_NAME [--recent]

Twelve Factor: 1. Codebase

One codebase tracked in revision control, many deploys.

Bluemix Compute: OpenWhisk

OpenWhisk provides a server-less platform to support Functions as a Service where code snippets are run as a result of events. This gives a stateless model where you pay for only the compute you consume. No application start/stop required.

Organizational elements within Bluemix

Organizations Spaces Users, roles, permissions Quotas Domains Routes Regions

Software as a Service (SaaS)

Software as a Service, or SaaS, is place where software providers share IT resources such as application software /services between customers to enable self-service, rapid elasticity, and pay-per-use pricing. Contrasting with IaaS and PaaS, Software as a Service, the consumers of these solutions are often Line of Business rather than IT or developer, driven choices. Everything is managed by the provider - and there's no need for end users to manage infrastructure, servers or even purchase and install software.

Bluemix Cloud Foundry app commands

Some of the most common bluemix app CLI commands. *push* - deploys the current (or specified) directory contents to Bluemix as an application *list* - display the applications in the current organization and space *show* - provide health and status of all instances of the app, displays CPU usage, memory usage, local storage usage *env* - displays current environment variables for the app *logs* - display log stream. runs in one of two modes, continuous tail of the current log stream of display of the recent log buffer contents.

Ref impl: web and mobile application with micro-services

The *architecture center* includes code examples and deployable projects for reference implementations. 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. The example code for this application contains both an Angular-based web application and a native iOS application. The application components are written in Java using SpringBoot

Cloud Foundry Arch: Blob Store

The *blob store* holds: - Application code - Buildpacks - Droplets

IBM Cloud Garage Method

The IBM Cloud Garage Method combines industry practices including IBM Design Thinking, Lean Startup, agile development, and continuous 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, tool chains, architectures you need to be successful.

Cloud Foundry Arch: Authentication

The OAuth2 server (the UAA) and Login Server work together to provide identity management.

Platform as a Service (PaaS)

The concept of composable solutions in a Cloud Environment, which consists of finer grained services that can be recombined to create new capabilities, is a key element of the cloud. Composable environments can contain cloud services, which bring together operational, development, application, database, and third-party services - all with embedded monitoring and manageability capabilities.

Cloud Foundry Arch: Router

The router routes incoming traffic to the appropriate component, usually the Cloud Controller or a running application on a Cell.

Application staging and deployment

The sequence of events is this: 1) At the command line, the developer enters the directory containing the application and uses bx app push command. 2) The bx CLI tells the Cloud Controller to create a record for the application. 3) 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. 4) 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. 5) The Cloud Controller stores the application package in the blobstore. 6) The cf CLI issues an app start command. 7) 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. 8) The Diego Cell streams the output of the staging process so the developer can troubleshoot application staging problems. 9) 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. 10) 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. 11) Diego schedules the application as a Long Running Process on one or more Diego Cells. 12) The Diego Cells report the status of the application to the Cloud Controller.

Web application reference architecture

This diagram illustrates the architecture components of a web application. Not every web application requires all of these components, but some components and functions are present in every web application. It all starts with a user, which could also be a user agent or application acting on behalf of a user. 1. A user or user agent sends a request to a specified URL 2. Edge services provide capability to deliver content and include DNS, CDN, firewall, and load balancer 3. The security layer manages confidentiality, integrity, availability and compliance as required for the business needs of the web application 4. 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 5. Application servers return resources (normally some form of web content) based on the user's request 6. 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. 7. Caches are used by the web application server to speed the return of appropriate content and associated data to the user. 8. File repositories store and manage data that the application server can request. 9. 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 formats, and ensures that secure reliable messaging is used appropriately. 10. 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. 11. Enterprise applications include applications that accomplish business goals and objectives that may interact with cloud services. 12. Response from the web application is returned to the user over the Internet via the edge services.

Twelve Factor: 11. Logs

Treat your logs as event streams. This is very important. Without correct telemetry in your environment you have no idea what is going on and when complex issues come up that can be hard to fix and understand. A 12-factor application doesn't worry about log files, instead, it writes all events as an *unbuffered* stream to *standard out*. This allows the environment hosting the 12-factor application to collect and store events from all application instances in a scalable and consumable fashion. In Bluemix, this stream is picked up by the *Loggregator*. For analysis - Bluemix provides *logmet*, based on an ELK stack for *short term* log analysis needs. For *long-term*, you can configure a CF application to send logs to a *3rd-party service*.

bx cli: Horizontal Scaling

Use bx app scale <appname> -i INSTANCES to horizontally scale your application. Bluemix will increase or decrease the number of instances of your application to match INSTANCES. *Example*: bx app scale myApp -i 5

bx cli: Vertical Scaling

Vertically scaling an application changes the memory limit or disk space limit that Cloud Foundry applies to all instances of the application. Use bx app scale APP -m MEMORY to change the disk space limit applied to all instances of your application. MEMORY must be an integer followed by either an M, for megabytes, or G, for gigabytes. Example: bx app scale myApp -m 512M Example: bx app scale myApp -m 1G It's also possible to scale the local disk space for an application with the -k option

Virtual server public

Virtual Server be on a hypervisor with multiple tenants.

Bluemix Compute: Virtual Servers

Virtual Servers and VMWare increase efficiency and allow the developer manage just the OS, middleware, data and applications and VM operations like start and stop.

Virtual server private

Virtual Servers configured on a single-tenant hypervisor

Twelve Factor: 6. Processes

We want to execute the app as one or more *stateless* processes. This is probably one of the most important things to keep in mind when you're trying to build a truly scalable, distributed, cloud ready application *statelessness*. Because there is no state within those particular processes, if we lose a process, it doesn't matter because the traffic is automatically and seamlessly routed to other processes in the environment that can handle that work. CF Garden Containers - no clustered memory, no shared FS.

Organization: the grouping methodology for users in Bluemix

Within an account, you can manage organizations and spaces, including user access to the account and organization from the Web UI or the CLI. *Organizations* facilitate the logical grouping of project resources in the following ways: - You can be the owner of your own organization, and you can also be the member of other organizations. - You can group a set of spaces, applications, services, domains, routes, and users together in organizations. - You can govern the access to the resources of organizations on a per-user basis. After you create the organization, you will be automatically assigned *Organization Manager* permission, which enables you to edit the organization name, delete the organization, and create spaces in the organization. When you delete an organization, all the spaces, applications, and services within the organization are deleted.

Twelve Factor: 12. Admin processes

You should run your administrative or management tasks as one off processes. Do not create admin processes that may be repeated many times that aren't well encapsulated as code themselves. It's very important to create a separate process, even if it's a one off process that will do the particular task. Bluemix: Use separate single-shot admin processes bound to the same services as the application.