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.
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.).
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.
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.
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.
Dan Toczala's Blog 