I’m Having an Issue on IBM Cloud Part 1 – Why Can’t I Create Anything?

By: Daniel Toczala

Note: This is the first blog in a series of blogs that I am co-authoring with Paula Williams, as part of an “I have an Issue…” series on the IBM Cloud.  These blog posts will cover how to deal with common issues and roadblocks for users of the IBM Cloud.

I like helping my IBM Cloud customers, and I like dealing with the technology.  Every new technology (and even established technologies) have a learning curve.  My goal in writing this series of articles is to help you more quickly conquer that learning curve with respect to the IBM Cloud.

Typical Issues That People See

Some typical issues that users experience when working with the IBM Cloud will often be with respect to their services.  These could be one of the Watson services (like Watson Conversation or Watson Discovery), or maybe Cloud Object Storage, or a DB2 or Mongo database.  The issues that people will typically experience fall into one of two categories:

I’ve Created Something That I Cannot See

These situations have you going out and creating an instance of a service, but now you just can’t seem to figure out how to find it or how to get to it.  It’s almost as if we have decided to hide it on you.

In these situations, it is best to first figure out WHERE you are on the IBM Cloud.  Look in the upper right corner of your browser window.  As soon as you log into the IBM Cloud, you’ll see something like this:

Finding the area you are working in on the IBM Cloud

That text in that small black block tells you WHERE you are.  It tells you the account that you are operating in.  Clicking on this box you can CHANGE where you are looking.  Confused yet?  Maybe we should step back a bit….

You have an ACCOUNT and IDENTITY on the IBM Cloud.  Your IDENTITY from an IBM perspective is typically an email address, which is also your IBM ID (for our example let’s assume that mine is tox@acme.com).  It has the same username/password as your IBM ID (which you might use for things on ibm.com).  You might even have a Federated ID, where we use your company email address/identity and your company authentication mechanisms.  Some things to remember when looking at your IBM ID:

  • Just because you have an IBM ID, doesn’t mean that you have an IBM Cloud account.  You will need to register for an IBM Cloud account. While both the IBM Cloud and ibm.com both use your IBM ID, they are DIFFERENT domains.
  • When you sign up for your IBM ID, use a valid email address as your user ID.  You will need to VALIDATE your account by responding to an email that is sent to (you guessed it!) your user ID.  So in my case I cannot sign up for an IBM ID at tox_is_awesome@acme.com (unless I have convinced my corporate IT folks to give me that email address).

Now let’s get back to finding those cloud resources that we created.  Once you see what context you are in, you will have a better idea of what you can EXPECT to see.  Since I am an Acme Co. employee, I have been added as an approved user of the Acme corporate account.  What does this mean?  Well the Acme corporation created a different account, a corporate account, associated with a service account called IBM_Cloud_Admin@acme.com.  This account has a subscription which provides it with a set amount of “credits” for IBM Cloud services, which it burns down over time.  Since I am a member of this account, I can create IBM Cloud services in this corporate account, and their costs get assigned to the corporate account.  IBM Cloud services are billed based on where they are LOCATED (logically), and not based on who created them.

So now you hopefully have a better feel for how your account fits into the grand scheme of things, maybe you can find out WHERE that Watson service that you created is located, by looking at the various different contexts that you operate in.

Advanced Developer Note: Your IBM ID is based on an email ID.  So I have an IBM ID for tox@acme.com, but I also have one associated with my personal email address (tox_is_awesome@freebiemailcorp.com). I use my acme.com account for doing my regular work, and I use my personal email based ID to do open source work.  That account is a trial account (or maybe I even attach my personal credit card to it), and I am careful not to rack up big charges on the account.  I use it for doing simple little things in the cloud environment.

I Cannot Work With Something I Created

These situations are a little different.  You are able to create some service, but you are then unable to access it.  Either the service is broken, or down, or just not responding to your repeated attempts to use it.  Or maybe you can see a service but you just cannot create it.

So let’s go back to that tox@acme.com account.  First of all, you need to check and make sure that the account that you are attempting to create a service in is able to pay for that service.  If the account has a credit card associated with it, which guarantees payment for cloud services used, then the account is referred to as a “PAYGO” (short for pay-as-you-go) account.  People who use things like GitHub and other SaaS based services should be familiar with this model.  If the account has prepaid for services, via an IBM Cloud subscription, then it is referred to as a “SUBSCRIPTION” account.  Either “PAYGO” or “SUBSCRIPTION” accounts can create any type of service.  Your personal account might not have a guaranteed payment method, like my tox_is_awesome@freebiemailcorp.com account.  In that case you have a “TRIAL” account.  “TRIAL” accounts can create lite (or no charge) instances of most services on the IBM Cloud.  TRIAL accounts will not be able to create more robust versions of those services until they either become “PAYGO” or “SUBSCRIPTION” accounts.

So let’s get back to our example.  My tox_is_awesome@freebiemailcorp.com account is a “TRIAL” account (I’m not paying for anything!), but since I am an approved user of the IBM_Cloud_Admin@acme.com account (which is a “SUBSCRIPTION” account), I can create non-lite service instances within THAT account.  There is one hitch…. I have to have PERMISSIONS granted to me to be able to see particular logical areas of the Acme IBM_Cloud_Admin account.

What Are These “Logical” Areas?

There are two different types of logical areas where IBM Cloud resources can be created.  Each is based on a different security model. 

The Cloud Foundry security model uses the concept of Organizations (called “ORGs”) and Spaces.  These “Orgs” and “Spaces” live in a hierarchal model, with a single Org hosting one or more Spaces.  The administrator/owner of an IBM Cloud account will create these Orgs and Spaces, and will assign people various roles in each org/space.  These roles determine what a user can do within that particular logical environment.  You need to make sure that your account has access to the orgs and spaces that you need to work in.

The IBM Access Management (IAM) security model is based on Resource Groups.  Each resource group may have a series of Access Groups associated with it, and these Access Groups can be used to provide fine-grained access controls and role management.  You need to make sure that your account is enabled to do what is needed for the resource groups that you need to work in.

You can learn all about Orgs, Spaces, Resource Groups, Access Groups and best practices for organizing your IBM Cloud account by reading my blog post entitled, Getting Started Right on the IBM Cloud.

Advertisements

Getting Swagger API Pages for Watson APIs

In the past couple of weeks, I have seen a few comments from my customers complaining about the lack of “sufficient” API documentation for the various Watson API’s. I used to like to point my customers to the Swagger API documentation, but I can’t seem to find it anymore. So I asked some of my fellow IBM folks if they knew where these pages were. They didn’t know, they just had some vague notion that they were no longer supported.

I miss those Swagger API pages – so I found out how to get them. The IBM development teams no longer host these pages, but you can generate them for yourself, whenever you want, but just following this short little guide.

Go Ahead – Get That Swagger

Step 1 – Figure out which API you want to generate a Swagger page for. Go to the IBM Cloud catalog, and select the service that you want to see. For the purposes of this example, I’ll go and look at the Watson Assistant service.

Step 2 – Get to the API Documentation page by clicking on the link titled View API Docs – as shown below.

Step 2a – You can skip all of this hassle by just going to the IBM Cloud API Docs page, and then selecting the specific API documentation page that you are looking for (which in our case is Watson Assistant v1). This is much quicker – and easier to bookmark and remember.

Step 3 – You are now on the Watson Assistant API (V1) page. Look for the ellipsis in the white text portion of the UI, as shown below, and click on it. Save a version of the API by selecting Download OpenAPI Definition. This will download a JSON file to your local machine.

Step 4 – Open a new browser window, and go to the web-based Swagger editor.

Step 5 – In the Swagger editor window, select File -> Import File. Then select your recently downloaded Watson API JSON file (from Step 3).

You can now look at the Swagger API version of the Watson API documentation. This allows you to see all of the API calls for the service, along with the various parameters, and the responses. It also allows you to try to use the interface in an interactive manner. Pretty nice!!

Building on the Cloud – Some Guidelines for App Development on the Cloud

Sometimes I post about things where I have done some work and provided some deep thought, and I want to share my knowledge. Sometimes I just “pass things along”, when I find something that is technically solid and useful. This post is more of a “pass it on” post.

Many of my customers are beginning to seriously think about doing “Cloud Native” development in 2019, based on the questions that I get asked. When I say “Cloud Native” development, I am referring to the development of projects that are built on the Cloud, and produce applications and (micro)services that live on the Cloud. This isn’t about moving server workloads to the cloud, it’s about new development efforts.

These customers are asking me about tooling, approaches and techniques for doing software development on the Cloud. I would often point them to some of my blog posts on how to organize your IBM Cloud environment, or to something good on microservices. One other good site, which I thought was more popular, is the 12 Factor App guidelines.

The 12 Factor App site has a nice simple write up which reminds you a bit of the Agile Manifesto. It has 12 factors which you can see, and each has a short and quick description of what is important about that factor. it’s definitely worth a look – it takes a grand total of about 15 minutes to read through the whole thing. Some of the factors are more development focused (like Config and Codebase), some are operations focused (Dev/Prod parity and Build/Release/Run), and others are more architectural (Dependencies and Concurrency) in nature. The important thing to remember is that ALL project participants should be aware of, and know the importance of, each one of the factors.

So if you are one of those organizations that are looking at making a serious impact with Cloud Native development this year, I strongly urge you to take the time to read the 12 Factor App guidelines and let me know what you think. Then feel free to ask me how to accomplish any of these things in the IBM Cloud.

Watson Text to Speech – The Costs of Personalization

I tend to write these blog posts to share interesting things that I have learned when working with our customers.  Just this past week I have had 2 or 3 blog worthy events happen, so I hope to be publishing these posts at a brisker pace in the coming months.

This week I had a customer that is using the Watson Text to Speech service.  They are using it to do short utterances, things like street names, addresses, and city names.  The utterances are relatively short.  They told me that they had no idea how they were being charged for the service.

This particular customer has a focus on producing a positive customer experience.  No tinny, mechanical voice for this customer!!  They are tweaking the speaking voice and customizing it, using SSML (Speech Synthesis Markup Language) to modify and “humanize” the synthesized speech from the Watson Text-to-Speech (TTS) service.  You have the ability to modify things like the emotion used in the speech generated (called expressive SSML), to more basic things like the pitch and glottal tension (and yes, I had to look up the definition of glottal tension).  The typical curl call that they use looked similar to this:

curl -X POST -u apikey:*****************************--header "Content-Type: application/json" --header "Accept: audio/wav" --data "{\"text\":\"<speak><voice-transformation type=\\\"Custom\\\" breathiness=\\\"35%\\\" pitch=\\\"-80%\\\" pitch_range=\\\"60%\\\" glottal_tension=\\\"-40%\\\" >$text</voice-transformation></speak>\"}" --output $finalFile "
https://stream.watsonplatform.net/text-to-speech/api/v1/synthesize?voice=en-US_MichaelVoice"

So this curl command will ask for some text (referenced by the $text parameter) that will have breathiness set to 35%, pitch at -80%, the pitch range set to 60%, with a glottal tension of -40%.  I’m sure that someone played with these values, before settling on this combination.  It’s a great way to customize the sound and the tone of your automated speaking responses. 

How Does This Impact Cost?

 The cost of doing something like this will vary, and this is where I learned how some small changes can have a HUGE impact on the costs associated with your Watson solution.  The basic price for using the Watson TTS service is $0.02 per thousand characters.  There are some interesting things to keep in mind here.  Whitespace is NOT counted, so only count the non-whitespace characters.  Also, remember that the voice customizations and everything between the “<speak>” and the “</speak> ” are included in this count.

Now let’s assume that the text being converted was a home address, something like, “9 Marine Drive, Round Rock, Texas 78681”.  Let’s also assume that the user is being referred to by name.  There will also be some other text (a meter reading, a service interruption, etc.) as well, informing the end user about something about to happen near their home address.  We want to figure out the monthly costs for something like this if we estimate that we’ll build and issue 100,000 of these notices in a month.  A sample utterance might sound/look like this:

“This message is for Dan Toczala.  We are informing you of a service interruption tomorrow morning at 9 Marine Drive, Round Rock, Texas 78681.  Please call us at 1-800-123-4567 if you have questions.”

Breaking It Down

Your application can look up the customer name and address, and build this entire text string for each individual event, and then submit each one to the Watson Text To Speech service.  Your typical call would look like this:

curl -X POST -u apikey:*****************************--header "Content-Type: application/json" --header "Accept: audio/wav" --data "{\"text\":\"<speak><voice-transformation type=\\\"Custom\\\" breathiness=\\\"35%\\\" pitch=\\\"-80%\\\" pitch_range=\\\"60%\\\" glottal_tension=\\\"-40%\\\" >This message is for Dan Toczala.  We are informing you of a service interruption tomorrow morning at 9 Marine Drive, Round Rock, Texas 78681.  Please call us at 1-800-123-4567 if you have questions.</voice-transformation></speak>\"}" --output $finalFile "
https://stream.watsonplatform.net/text-to-speech/api/v1/synthesize?voice=en-US_MichaelVoice"

For the purposes of this discussion, we’re going to just focus on the “payload”, or the part in the data section of the curl command.  The part that impacts what your costs are.  So this chunk:

<speak><voice-transformation type=\\\"Custom\\\" breathiness=\\\"35%\\\" pitch=\\\"-80%\\\" pitch_range=\\\"60%\\\" glottal_tension=\\\"-40%\\\" >This message is for Dan Toczala.  We are informing you of a service interruption tomorrow morning at 9 Marine Drive, Round Rock, Texas 78681.  Please call us at 1-800-123-4567 if you have questions.</voice-transformation></speak>\

Now in this example, we count ALL non-whitespace characters inside of the quotes.  We have 336 non-whitespace characters.  Multiply that by 100,000 notices in a month, and I get a rate of 33,600,000 characters a month.  Apply the TTS cost of $0.02 per thousand characters, and you get a final monthly cost of $672.

Now let’s see what happens if we change the way that we think about this.  What if we quit customizing so much of the voice?  Then we would end up with something looking like this:

<speak><voice-transformation>This message is for Dan Toczala.  We are informing you of a service interruption tomorrow morning at 9 Marine Drive, Round Rock, Texas 78681.  Please call us at 1-800-123-4567 if you have questions.</voice-transformation></speak>\

So for the non-customized example, we have 225 non-whitespace characters.  Multiply that by 100,000 notices in a month, and I get a rate of 22,500,000 characters a month.  Apply the TTS cost of $0.02 per thousand characters, and you get a final monthly cost of $450.  Customizing my voice could be looked at as a cheap way to have an impact on customer satisfaction (it’s only $222 a month), or a really expensive way to do this (it’s about 49% more expensive than the base translation).  Remember, it all depends on how you want to look at things.  I suggest focusing on your problem and the overall costs of your solution.

Now let’s look at a final example.  In this example, we’ll keep our customized voice, but we’ll try to stop converting the same text over and over again.  What if our message was built in a way that minimized what needed to be converted each time?  What if we converted a basic message once, and the rest of the customized part for each customer?  So we could do this for each customer:

<speak><voice-transformation type=\\\"Custom\\\" breathiness=\\\"35%\\\" pitch=\\\"-80%\\\" pitch_range=\\\"60%\\\" glottal_tension=\\\"-40%\\\" >This message is for Dan Toczala, who resides at 9 Marine Drive, Round Rock, Texas 78681</voice-transformation></speak>\

And then follow that with this “standard” section which we would only need to convert once (for a one time cost of fractions of a cent):

<speak><voice-transformation type=\\\"Custom\\\" breathiness=\\\"35%\\\" pitch=\\\"-80%\\\" pitch_range=\\\"60%\\\" glottal_tension=\\\"-40%\\\" >We are informing you of a service interruption tomorrow morning. Please call us at 1-800-123-4567 if you have any questions.</voice-transformation></speak>\

So for the modified script example, we have 244 non-whitespace characters.  Multiply that by 100,000 notices in a month, and I get a rate of 24,400,000 characters a month.  Apply the TTS cost and you get a final monthly cost of $488.

Final Conclusions

So let’s look at all of these options together:

ApproachCharacters /
Msg.
Characters /
Month
Monthly
Cost
% Change
Basic
22522,500,000$4500%
Full
Customization
33633,600,000$67249.3%
Modified
Customization
24424,400,000$4888.4%

Looking at things in this way helped us make a rational decision on what things really cost, and helped us look at ways we could maximize our impact and minimize our costs.

P.S.  For those of you who were patient enough to read through this entire article, you can save yourself even more by removing the <speak> and </speak> tags.  These are assumed by the Watson Text To Speech service, so you can omit using them and save yourself 15 characters per message.  For the purposes of this example, that would reduce the monthly cost of each of the above approaches by $30 a month.

Enabling Your IBM Cloud Users To Submit Support Tickets

Every once in a while I have a customer ask me a simple question, or bring me a simple problem, and I don’t know the answer for it.  So I make sure that I understand the question, and then I go off and find out the answer for them.  Sometimes these answers are simple, and sometimes these answers SHOULD be simple, but they are not well known.  Today I ran into one of those situations, and thought it would be good to share it.

The Problem – Users Cannot Open Support Tickets on IBM Cloud

My customer is relatively new to the IBM Cloud, let’s call them the Acme Corporation.  They have a subscription with a corporate account (ibmcloudadmin@acme.com).  One of their users (Sally@acme.com) goes into the account and is doing some work with an instance of Watson Assistant.   She runs into some odd behaviour and wants to open up a support ticket.   If you look in the upper right of the browser UI, you will see that she is in the proper context (ibmcloudadmin@acme.com).  When she tries to open a ticket, it tells her that she has Basic Support, and when she attempts to submit the ticket she gets an error dialog that says, “You do not have ticket add and view permissions”.  So what do we do to fix this?

The problem is that our user (Sally@acme.com) does not have permissions to open tickets for the account in question (ibmcloudadmin@acme.com).  

Solution #1 – Add Sally to the Account With Infrastructure Access

The first solution to this is to add Sally’s account (Sally@acme.com) to the list of users with access to the ibmcloudadmin@acme.com infrastructure resources.  This needs to be done by the account administrator, who will need to be logged in as an account administrator/owner.

You can now do this by inviting Sally as a new user, using the Invite New User page (part of the normal user management on the IBM Cloud).  When you do this, you will want to be sure to give Sally a “Basic User” role for her Infrastructure access (see the picture below).

Make sure to give your user “Basic User” permissions for Infrastructure Access

This will allow Sally’s account to create support tickets while working in the context of the corporate IBM Cloud account.

Solution #2 – Change Sally’s Infrastructure Access

The other thing that can be done is to modify the Infrastructure permissions assigned for Sally’s account (Sally@acme.com).  This also needs to be done by the account administrator, who will need to be logged in as an account administrator/owner.

You can do this by following the steps outlined here.  First, start by looking at the list of tickets for the account.   

You can do this by following the steps outlined here.  First, start by looking at the list of tickets for the account.  From the Menu bar, select Support -> View Tickets.

Then you will want to get a list of the users who have access to the infrastructure available in the IBM Cloud, so select Account -> Users -> User List.

Now in that list of IBM Cloud infrastructure users, you will want to find the users that you want to give the ability to submit support tickets, and you will select Edit Portal Access.  This will take you to the IBM Cloud Infrastructure portal access dialog for that particular user.

Once the portal access dialog comes up in the browser, make sure that you have selected the correct user, and then give that user permission to add, edit, view, and search thru support tickets.  Your screen should look similar to what you see below.

Conclusion: You need to give your users the ability to submit support tickets

The IBM Cloud has a finer-grained access, role, and permission model with the move towards resource groups and IAM.  Part of this finer-grained access is the ability to allow your users to submit, view, search, and edit support tickets.  Make sure that you get your users set up correctly the first time – so you can avoid these issues in the future.

Getting Started Right on the IBM Cloud

Note: This post was initially published here as Bluemix and Watson – Getting Started Right, on this site.  That article is also on developerWorks, as Bluemix and Watson – Getting Started Right. This blog post repeats a lot of that content, with some updates for new capabilities and functionality.  It was most recently updated on July 8, 2019, as I added links to some great content that readers pointed out to me, that I felt compelled to share.  Please forgive the duplicated content…..

In my role as a Customer Success Manager, I often talk to customers who are new to the IBM Cloud platform and the Watson services.  Often I will spend a good hour or more talking to customers and answering questions about the best way to get started with the organization of the IBM Cloud environment, and some of the more operational concerns around cloud and cognitive development.  Since I find myself answering these questions over and over, for over two years, I figured it would be good to update this blog post so I can easily share this information with even MORE customers.  It also helps me remember all of the important things when I do talk on the subject.

Getting Started on IBM Cloud

Signing up for IBM Cloud is easy, all you need to do is supply a valid email ID which will be associated with the IBM Cloud account.  This is fine for YOU, but what about your ORGANIZATION?  When setting up an IBM Cloud account for your company or organization, it is best to use a functional ID (some teams call them service accounts) associated with your company.  Just keep in mind that the IBM Cloud will be sending out automated emails to this account (warnings about service usage, services being deprecated, new services available, and other things).  Make sure that you choose an email address that is monitored by someone, so you don’t miss any important notifications.

I KNOW it takes a little longer to set up a functional account within your company, and that it is a pain to go through the paperwork to justify it, but not having your IBM Cloud account tied to an individual will save you A LOT of time, effort and frustration in the future.

Learning the Cloud Concepts

This is a good spot to pause for a second, and take time to understand some of the basic cloud concepts that will impact how you organize yourself on the IBM Cloud.  Looking at this picture may help:

Orgs, Spaces and Resource Groups

The box in the upper left is my IBM Cloud Account, and this should be associated with a functional ID.  This is the functional ID and email address where you will receive communications from the IBM Cloud team.  It is also the Account which has access to EVERYTHING underneath it.

Next, there are two blue boxes for the Organizations, which represent different functional organizations (or projects) within the larger IBM Cloud Account.  Even though the different Organizations reside in the same parent Account, the resources within those Organizations can have their visibility limited to only resources within that Organization.

At this same conceptual level are the two Resource Groups.  These Resource Groups serve as the “home” for a variety of different infrastructure and IBM Cloud services.  Access to these Resource Groups can be given on an individual basis, or can be assigned through the use of Access Groups.  If you want to learn more about Resource Groups, Access Groups, and the IBM Access Management (IAM) system, read this great post on Getting Started with IBM Cloud IAM.

The ovals below each Organization represent Spaces.  A Space can be thought of as an individual development environment, or development area, for the development of a cognitive application.  Access to these environments is controlled by assigning people one of three roles at the Organization level, and one of three roles at the Space level.

Finally, at the base level, are the various IBM Cloud Services, which are deployed into either spaces or resource groups.  These can be Watson based services (like the Watson Assistant service), infrastructure services (like the Virtual Server service), or other IBM Cloud capabilities (like the Weather or Blockchain services).  Services essentially “live” within a particular Space or Resource Group, and the charges associated with a service are calculated and billed against the IBM Cloud Account.  These charges are broken down by Organization/Space or Resource Group, for your own internal billing and tracking purposes. The IBM Cloud documentation on Account Hierarchies does a great job describing all of the above and has a great diagram describing the relationships between all of these things.

Getting Organized on the IBM Cloud Platform

We’ll assume that you took my advice, and have a generic corporate ID (like IBMcloud@acme.com) that is your IBM Cloud account.  Now let’s get organized to support the development efforts of your organization on the IBM Cloud platform.  I’ll give you a “default” setup that you should use as the basis for your strategy in setting up the IBM Cloud Platform, and I’ll indicate options you have and why you might use those options.

I do this from the command line, using the IBM Cloud command line interface (CLI).  I heavily use the IBM Cloud CLI in my tool referenced by the Administering Your IBM Cloud Account article.  For the purposes of this article, we want to create some new Organizations within our account, and we also want to create some new Resource Groups.  Some of our projects may be hybrid projects, and may use services supported by both models – so we need to have associated areas.  In this case, we’ll create working areas (which include organizations/spaces and resource groups) for the Tau project and the Epsilon project.

Note: We introduce some naming conventions here that are important to note.  Here are our naming conventions:

  • Organizations -> <project_name>_ORG
    • For our example, the three organizations our three projects would be: Tau_ORG and Epsilon_ORG
  • Spaces -> <project_name>_<environment>_SPC
    • For our example, the Tau_ORG might have spaces called Tau_Dev_SPC and Tau_Test_SPC.
  • Resource Groups -> <project_name>_<environment>_RG
    • For our example, the Tau_ORG would have the following resource groups associated with the spaces above: Tau_Dev_RG and Tau_Test_RG.
  • Access Groups -> <project_name>_<environment>_<usertype>_AG
    • For our example, we might create the following access groups for our Tau_Dev_RG: Tau_Dev_Admins_AG, Tau_Dev_Managers_AG, Tau_Dev_Develop_AG

Here is what our command line looks like:

# Set the IBM Cloud API endpoint
ibmcloud api api.ng.bluemix.net
#
# Login to IBM Cloud, with -u username -p password
ibmcloud login -u IBMCloudAcct@acme.com -p "mypassword"
#
# Create new Organizations for Tau, Epsilon and Phi
ibmcloud iam org-create Tau_ORG
ibmcloud iam org-create Epsilon_ORG
#
# Print a list of all of the Organizations for this Account
ibmcloud iam orgs

The first command sets the API endpoint.  The second command gets you logged in.  The next two commands create your new organizations, and the last command lists all the IBM Cloud Organizations for your account.  Check out the Getting Started with the IBM Cloud CLI documentation for more details on the various CLI tools and commands available to you.  You will now see a listing of all of your new Organizations, along with your default organization.

Why set up these separate organizations on the IBM Cloud Platform?  For a few reasons:

  1. It helps keep the work organized and segregated.  With these in place, and once we get spaces set up, we can limit user access to only certain areas.
  2. It allows us to see usage and billing details by organization.  I can see exactly what each organization (or project) is using, and how much of my total bill each project is responsible for.

Also keep in mind that these IBM Cloud Organizations are just a way to organize your IBM Cloud infrastructure.  After reading the guide, you may decide to go with IBM Cloud Organizations that break up areas based on the roles of your users, the environments being supported, or specific lines of business within your organization.

Getting a Subscription

To this point in our setup of the IBM Cloud for the fictional Acme Corporation, we have assumed that you have used a “free”, or “trial”, tier of services.  These give you enough resources to figure out what you would like to do on the IBM Cloud and allow you to build small demo applications based on the IBM Watson services.

Now since we are talking about doing “real” application development work, we’re going to need more capability than these trial and free versions of the services provide.  That means that you will need to spend some amount of money to host these various services and capabilities.  Check out this nice overview of the various IBM Cloud Account Types to get an idea of your options.  The capabilities and limitations of these options differ, so it is important that you understand them.

For our fictional Acme Corporation, we have decided to go with the popular subscription option.  To begin the process of getting a subscription, you will want to follow the directions on how to obtain a subscription on the account types page.  Make sure that your subscription is associated with the right IBM Cloud account (the one with the functional ID, remember that?).  Once you get your subscription, you will get a “code” that needs to be entered – make sure that you enter it in while logged into your Functional ID (we’re using something like IBMcloud@acme.com).

Now that we have our organizations all set up, and our subscriptions associated with the correct projects within the fictional Acme Corporation, it’s time to set things up for our development teams.  I understand that some readers are working for smaller, more nimble organizations.  You may be fine with doing things in an ad-hoc manner, and that may actually be the best working model for you.  What follows is a broad outline of what larger organizations, seeking a better separation of duties, control of environments, and implementation of a more standard software development lifecycle and DevOps culture will want.

We begin with our IBM Cloud Account and our IBM Cloud Organizations.  For our purposes here, we will focus on just one of our fictional Acme projects, the Tau project.  You begin by creating Spaces for each project.  To begin, you need to find out what environments each project will need.  Most will need a development environment, a test environment, and a production environment (at a minimum).  Some projects will want support for additional environments.

For each project, go out and create the appropriate Spaces for the project.  Spaces need to have unique names.  For the Acme Tau project, we create support for two initial environments  – called Tau_Dev_SPC and Tau_Test_SPC.  We realize that we will need to build a production environment, but we’re not quite ready for that yet, so we can do that later.

Now lets use the IBM Cloud CLI to go and create the spaces that we need (Note: This can also be done interactively from the IBM Cloud UI – but I know that you are interested in automating this, so I will focus on showing a script using the CLI):

This results in an environment within the account which looks like the diagram below.

# Set the IBM Cloud API endpoint
ibmcloud api api.ng.bluemix.net
#
# Login to IBM Cloud, with -u username -p password -o organization
ibmcloud login -u IBMCloudAcct@acme.com -p "mypassword" -o Tau_ORG
#
# Create new Spaces within the Tau_ORG organization, 
# and within the Epsilon_ORG organization
ibmcloud iam space-create Tau_Dev_SPC -o Tau_ORG
ibmcloud iam space-create Tau_Test_SPC -o Tau_ORG
ibmcloud iam space-create Epsilon_Dev_SPC -o Epsilon_ORG
#
# Create related Resource Groups for Tau_ORG and Epsilon_ORG
ibmcloud resource group-create Tau_Dev_RG "Trial Quota"
ibmcloud resource group-create Tau_Test_RG "Trial Quota"
ibmcloud resource group-create Epsilon_Dev_RG "Trial Quota"

You can double-check your results either from the IBM Cloud CLI  (using the “ibmcloud iam spaces” and “ibmcloud resource groups” commands), or from the IBM Cloud dashboard.  This merely sets up the structure for your teams, the individual teams will need to populate these spaces and resource groups with services to make them useful.  As an IBM Cloud administrator, you should not have to do this.  The creation of any needed services should be left to the individual project teams.

Getting Everyone Else Onboard

So now that you have your projects and environments all set up, you are ready to go.  All that you have to do now is get your developers and other stakeholders into the environment.  The first step is to get your staff to register for the IBM Cloud and to get their own accounts.  I STRONGLY suggest that your force them to register with their company email addresses.  It will make things easier for you to administer things as time goes on.

Note: Another reason that I STRONGLY suggest that your force users to register with their company email addresses is that most of my customers decide to federate their identities – meaning that they then will log in and authenticate with their corporate credentials (john.doe@acme.com, with the Acme password) for the IBM Cloud.  It allows you to do all sorts of great things – for more details see my GitHub page on IBM Cloud Onboarding.

After your team has registered, you can invite them to the correct IBM Cloud Spaces and IBM Cloud Organizations.  So once again we will use  the IBM Cloud CLIand send the invitations that we need (Note: This can also be done interactively from the IBM Cloud UI – but I know that you are interested in automating this, so I will focus on showing a script using the CLI):

This gets your users added to the proper organizations and spaces.  Some important things to keep in mind when assigning organization roles and space roles to your users.

  • Give everyone OrgAuditor for their ORG_ROLE.  This allows them to see what is going on at the organization level, but doesn’t allow them to change anything.  The only exceptions to this are the people who do administration of the organization (your IBM Cloud Administrator), and handle the billing associated with the organization (often the IBM Cloud Administrator as well).
  • Space roles are a bit different.
    • SpaceManager: This role can invite and manage users, and enable features for a given space.  You may want to give this to the development lead for the Development spaces, the test lead for the Test spaces, and your operations leader for the Production spaces.
    • SpaceDeveloper: This role can create and manage apps and services, and see logs and reports.  Give this role to developers in the Development spaces, but you probably don’t want anyone with this role in the Testing and Production spaces.  This allows you to maintain the stability of these environments (no code changes).
    • SpaceAuditor: This role can view logs, reports, and settings for the space.  This is used for people who might be interested in the development efforts in a given space – but not requiring access to change anything within the space.
# Set the IBM Cloud API endpoint
ibmcloud api api.ng.bluemix.net
#
# Login to IBM Cloud, with -u username -p password -o organization
ibmcloud login -u IBMCloudAcct@acme.com -p "mypassword" -o Tau_ORG
#
# Send invitations to the various team members within the Tau project
# arguments are: USER_NAME ORG_NAME ORG_ROLE SPACE_NAME SPACE_ROLE
ibmcloud iam account-user-invite john_smith@acme.com Tau_ORG OrgAuditor Tau_Dev_SPC SpaceDeveloper
ibmcloud iam account-user-invite jane_doe@acme.com Tau_ORG OrgAuditor Tau_Dev_SPC SpaceDeveloper
ibmcloud iam account-user-invite tom_tester@acme.com Tau_ORG OrgAuditor Tau_Test_SPC SpaceDeveloper
#
# Create access groups, and then assign team members
# to various access groups
ibmcloud iam access-group-create Tau_Dev_Admins_AG -d "Tau Dev environment administrators"
ibmcloud iam access group-user-add Tau_Dev_Admins_AG john_smith@acme.com
#
ibmcloud iam access-group-create Tau_Dev_Devs_AG -d "Tau Dev environment developers"
ibmcloud iam access group-user-add Tau_Dev_Devs_AG john_smith@acme.com
ibmcloud iam access group-user-add Tau_Dev_Devs_AG jane_doe@acme.com
#
# do the rest of your projects and users in a similar manner
...

You will probably want to automate this, or provide a self-service capability, so people can easily request access to the environments that they need.  If you’re not sure where to start with this, then go and read my post on Administering Your IBM Cloud Account – A script to help, it has a link to a GitHub repo with some Python scripting that will do some this for you.

Herding the Cats

At this point we have our IBM Cloud environments set up, and we have our users added into the environment where they need to be, with the access that they require.  Our fictional Acme environment looks a little something like this:

You’ll note that we now are showing the infrastructure resources (like virtual machines, file storage, block storage, object storage, etc.) being deployed from the IaaS account which is linked to your IBM Cloud account.  We haven’t spend a lot of time focused on this, as these resources are typically created on an as-needed basis – and they have a different set of concerns and networking and access concerns.

Each of our projects now has the ability to control access to their IBM Cloud areas, and can effectively isolate their various environments.  Each is free to use whatever promotion process and DevOps tooling they prefer, or they can utilize the IBM Cloud Toolchains and the IBM Cloud Continuous Delivery service.  I strongly suggest that you use a DevOps solution which addresses ALL parts of your development process, regardless of where they reside.

There are some important things to consider when thinking about the topic of DevOps in conjunction with the IBM Cloud and the IBM Watson services.

  • Watson services where you do not provide any training data (Document Conversion, Language Translator, Personality Insights, Tone Analyzer, Text-to-Speech (TTS) and Speech-to-Text (STT) ), can be deployed to additional Spaces (or Resource Groups) and do not need to have their data migrated from one environment to the next.  Keep in mind that on occasion the versions of the API and underlying services may increment, so you will want to control which API endpoints are used for these services.  (Note: If you have customized either Text-to-Speech or Speech-to-Text, then these services will need to be migrated from environment to environment.)
  • For Watson services with training data (Conversation, Discovery, Natural Language Classifier (NLC), Retrieve & Rank (R&R), Natural Language Understanding (NLU), and Visual Recognition), you will need to deploy these to environments and migrate their data.  There is currently no mechanism in place to copy service instances from one Space (or Resource Group) to another.  This has some very real implications beyond the operational aspects.
    • For services like Conversation which support an export/import functionality, it means that you can choose to do your training through the REST API, or interactively through the tooling provided on the IBM Cloud.  When you are ready to move an instance from one environment to another, you export from one environment, and then create a new instance in the target environment, and import your data.
    • For services like Discovery, which do not have an export/import capability, you should resist the temptation to train “by hand”, and instead have a script (or series of scripts) that can be used to train your system.  In this way, you can more easily create/recreate an instance of the service.

Conclusion

This should give you enough of an overview, and offer you links to enough information, so that you can begin using the IBM Cloud platform to develop cognitive applications with confidence.  Technology changes rapidly, so if you see problems with this basic approach, or have some best practices to share, please reach out to me.

Good Reference Materials

  • My Slide Deck – a slide deck that highlights many of these concepts.
  • IBM Cloud command line interface (CLI) – The reference page for the IBM Cloud specific CLI.  Please use the IBM Cloud commands and not the Cloud Foundry equivalents, to ensure smooth operation of your Cloud environments.
  • IBM Cloud Onboarding Landing Page – a community maintained landing page with links to proven articles and technical content that is useful for teams just getting into the IBM Cloud.
  •  Administering Your IBM Cloud Account – A script to help – has a link to a GitHub repo with some Python scripting that will do some basic administrative operations for you.  Also logs the commands so you can HOW to do things from the IBM Cloud CLI.

IBM Cloud Content, Charges, and Delivery for Developer Teams

Note: I updated this a day or two after the original posting, as people sent me some good links to other resources that I wanted to share.

I have been getting this question constantly for the past month, and I have to do a presentation on it for one of my customers, so I figured that it is probably a good topic to share with a wider audience.  I am going to talk about how IBM Cloud customers can organize, manage, and use the IBM Cloud to develop applications and services, which they then can deliver to their customers.

First the Basics

First we need to cover the basics.  I have discussed the basic organization of an IBM Cloud account in my earlier post, “Bluemix and Watson – Getting Started Right” (Note that the IBM Cloud used to be called “Bluemix”).  In that article, I show you the basic organization of an IBM Cloud Account, it’s Organizations, and the Spaces underneath those organizations.  Most of our customers will organize their Accounts/Organizations/Spaces along the lines shown in Figure 1.

Figure 1 – A Typical Enterprise Account Structure

Note that right now there is no support for the concept of an Enterprise Account (or a parent of multiple IBM Cloud accounts), but when that capability DOES become available, I would see it being used as shown in the diagram above.  Now let’s look at what happens when you begin a project.

Launching a Project

When launching a project, you need to determine a few different things.  The most important piece is to figure out what KIND of a project you have.  I will divide projects into 4 major categories for the purposes of this conversation, and they are:

  • Internal Projects – projects that are done by your software development teams, and provide systems/applications for your organization.  This includes internal POCs, and other “exploratory” and “innovation” work.
  • Product Projects – projects that are done by your software development teams, that provide systems/applications that you market and sell as a product.  These products/services are then exposed or delivered to your customers.
  • Hosted Projects – projects that are done by your software development teams, that provide systems/applications that you host and maintain for a single customer.  This may also include products where you host unique copies (instances) for different customers.  Think of your favorite SaaS product.
  • Turnkey Projects – projects that are done by your software development teams, that provide systems/applications that you finish development on, and then deliver to your customer.

These project types are all going to require slightly different deployment and work environments.  The setup for each of these is based on the type of project, and the way that you need to react to and handle a couple of basic limitations that you need to be aware of.

The first limitation we will call the Billing Endpoint limitation.  It’s pretty simple, the bill for your Cloud services goes to the account owner – and nobody else.  So you need to be aware of the charges to any given account, how you will handle those charges (what one entity will pay for them), and how you will pass those charges along to your internal and external customers.

The second limitation is the Resource Portability limitation.  This one is pretty simple too.  You cannot “move” or “relocate” a service from one organization/space to a different organization/space in the IBM Cloud.  In order to move something from one environment to another, you need to recreate that service in the new environment in the same way that you did in the first environment.  This forces us to be disciplined in our software development – and brings us to our next section.

Importance of DevOps Tooling

The resource portability limitation means that we need to be able to recreate any cloud resource instance in some type of automated manner, in any environment we choose.  This demands a solid change management strategy, and solid DevOps tooling that can create the services and applications in your various IBM Cloud environments.

One way to do this is to use the DevOps Toolchains that are available on the IBM Cloud.  These toolchains are easy to use.  You can customize them to use tools that are “Cloud native” on the IBM Cloud, or you can use your own tools and processes.

A healthy Cloud development and deployment environment is strongly dependent on the DevOps environment that is supporting it.  Tools, standards, and automation can help development teams follow better engineering practices, and can help you deliver projects and products more quickly.  If you’re unfamiliar with DevOps, I suggest you Google it and read some of the stuff from Gene Kim, Sanjeev Sharma, Mik Kersten or Eric Minnick.

So keep in mind that setting up a DevOps framework and some administrative automation for your Cloud should be one of the first things that you do.  Investments supporting the automation of projects will pay huge dividends, and allow your teams to easily launch, execute, and retire projects in your Cloud environment.

Handling Projects

So now that I have convinced you that you need to invest some time and effort building up your DevOps capabilities on the Cloud, let’s get back to the main question of this blog post.  “How do I organize projects and content, and handle the financial aspects for these projects?”.

Handling Internal Projects

Internal projects are organized in the same way that I discuss in my earlier post, “Bluemix and Watson – Getting Started Right“.  The account level is a subscription owned by the Enterprise, and projects are run as Organizations in the Account, and the Spaces under those organizations represent the various different environments supported by a project (like development, test, QA, staging, production, etc.).

Figure 2 – Internal Project Organization

This project is going to be developed internally, and it will be deployed internally.  So our need to separate the “billing” is only from an internal perspective.  Since we can see billing at the organization and space levels (see Administering Your IBM Cloud Account – A Script to Help), it should be relatively simple to determine any chargebacks that you might want to do with your internal costs.

You’ll use the DevOps capabilities we discussed earlier to quickly establish the automation of continuous integration/continuous delivery (CI/CD) capabilities.  Teams can do development and can set up pipelines to deliver their project to staging environments, where operations teams can test the deployment and deliver to production environments.  This environment is straightforward and simple because we don’t need to worry about billing issues, and we don’t need to worry about visibility or ownership issues.  Things get more interesting with our other project types.

Handling Product Projects and Hosted Projects

Product and Hosted projects are organized in the same way, even though they are slightly different types of situations.  In these cases I recommend the use of a second IBM Cloud account.  The established Enterprise account that is already established (as described in the section on Internal Projects), should continue to be used for the development of this project.  This project is going to be developed internally, and we will track costs internally.  So our need to separate the “billing” from an internal perspective.  Since we can see billing at the organization and space levels, it should be relatively simple to determine any chargebacks that you need to do for this project.

Figure 3 – Hosted Project and Product Project Organization

You will still have development and test spaces for your project, but you will NOT have production, pre-production or staging areas.  You will use your DevOps capabilities to deliver your project to a different account/organization/space.

In the case of a product that you are hosting for general usage, you will deploy to a specific IBM Cloud account that has been created for the express purpose of hosting production versions of your product (or for the deployment of Kubernetes clusters that are running your product).  Your operations team will have access to this account, and these production environments, ensuring a separation of duties for your deployed products.

In the case of a product that you are hosting for usage by a specific customer, you will deploy to a specific IBM Cloud account that has been created for the express purpose of hosting production applications for that customer. Your operations team will have access to this account, ensuring a well defined set of duties for your hosted products.  This approach also allows you to easily collect any billing information for your customer.

Handling Turnkey Projects

Turnkey projects are organized almost exactly the same way as a hosted project, with two simple differences.  Just like a hosted project, you will need to create a new IBM Cloud account for the work being delivered.

Figure 4 – Turnkey Project Organization

The first big difference is that you are going to either have your customer own the new IBM Cloud account from it’s creation, or transfer ownership of the account to your customer.  Make sure that you are clear about who owns (and pays for) the various environments, and the timing of any account reassignment.

The second difference is that the new account may have more than just production spaces – since your customer will need development and test spaces to be able to do maintenance and further development of the application or system being delivered.

Things To Remember

Now that we’ve covered how to organize content and environments for project delivery, it’s time to remind you about some of key details that you will need to remember to make sure that your IBM Cloud development efforts go as smoothly as possible.

  • Make sure that you have a solid DevOps strategy.  This is key to being able to deliver project assets to specific environments.
  • Make sure that you have solid naming conventions and Administrative procedures.  These should be automated as much as possible (just like your DevOps support for development).  For some guidance on setting up roles and DevOps pipelines, check out some of these best practices for organizing users, teams and applications.
  • Know how you will set up your project – since this will have an impact on the contracts and costing that you have for your IBM Cloud hosted project.