Cooking with Bluemix

One topic that is causing quite a bit of talk and controversy is BlueMix.  I am surprised by the number of people who are well aware of BlueMix, yet have no idea about the power and strategic implications of BlueMix for the long term.  For many people, it was either second hand knowledge that they had heard from somebody, or just initial reactions to the slideware that they had seen.  Many people have only seen the (now infamous) Twilio BlueMix demo.

That demo is really good at showing one thing – how can I get changes and new functionality developed and deployed into the market quickly.  It shows the raw speed with which you can use DevOps services, and composable applications, to bring functionality quickly to your customers or stakeholders.  Unfortunately, it is a short demo, and so some of the more strategic implications of the platform have not been properly presented or understood.  I have my own BlueMix demo, which I show YOU how to set up and run for yourself.  My demo is very “geek focused”, and tends to focus on the development tools and the usage by developers.  So my demo is pretty limited too.  What is really needed is some plain talk on what strategic advantages the BlueMix platform can give to an organization.

Here’s my quick list of strategic capabilities that BlueMix can give an organization:

• The ability to rapidly build custom applications that use common services and interfaces.  The components available to a user of BlueMix for constructing their application range from a variety of development tools, from an IDE, to testing tools, to automated deployment tools.  This allows development teams to use the tools that fit the project, rather than a “one size fits none” approach to having a common development infrastructure.
• It also allows a team to use business services, to provide an application services like location services, mobile capabilities, database storage services, “big data” services, and a host of other things.  A close look at the available services shows a mix of open source services, IBM services, and other vendor services.  These are exposed via stable API’s that an application can interact with.
  • This means that rather than selling products, capability providers will be selling metered capabilities.  You make your service available on the BlueMix platform, and the application development teams use what they want, and pay for what they use.  This is similar to water and electricity usage in a house.  You may indirectly pay for the supporting infrastructure, but you are billed based on the amount of resource that you use.  Using this analogy, our current perpetual licensing would be like charging a home owner for their first five years of electricity usage when they bought the house.
  • This will (hopefully) create an API economy, where service providers expose their API’s, and the market decides which are most useful/applicable.  It might be a good time to buy the www.apitracker.com domain name, because this space could quickly explode.
• The ability to quickly build and deploy, in an automated manner, makes huge economic sense for some organizations.  Why?  Many development shops struggle with maintaining development, testing, and production environments.  They build out QA environments that do not match their production environments, due to the excessive hardware cost and configuration complexity.  Why buy all of that hardware when it sits idle 60, 70 or even 80% of the time?  With BlueMix, applications can be deployed to development and test environments in the cloud, scaled to appropriate levels (the cloud is elastic, you can add resources), used for testing and evaluation, and then DESTROYED.  When it is needed again, it is merely a simple automatic reprovision and redeploy in the BlueMix  environment.  You only pay for what you actually use (notice a trend here?), and the not for idle hardware.
• You also have the ability to easily scale your deployments.  Is your app popular?  Is that popularity causing you headaches because now the server is overloaded and performance stinks?  Just twist a dial, and deploy additional server instances.  Did you over-allocate servers, or memory, or CPU resources?  Then twist a dial and scale your application down.  You only pay for the resources that you use.
• Many organizations currently use virtualized environments to do this, but this environment is unwieldly and requires constant manual intervention.  BlueMix is based on CloudFoundry and OpenStack, which means that deployment patterns and automations are portable.  This gives customers flexibility, and avoids vendor lock in.
• The underlying technologies are based on open standards (like OSLC, HEAT, etc.), so the entire stack is flexible, allowing you to use different technologies without having to do a large “rip and replace” effort.

BlueMix is a young product, and it’s capabilities are being expanded as we speak.  Having BlueMix as a PLATFORM (hence the whole PaaS moniker, or Platform as a Service), means that as new technologies and new business needs arise, services can be developed and then provided to the organizations running on BlueMix.  This “API Economy”, or store of services, can be compared to a kitchen.  BlueMix is the basic plumbing, electricity, and structure.  DevOps services (which provides development tooling and deployment automation) can be seen as a stove.  The basic environment in the buildpacks can be thought of as the sink.  There is the potential to buy a new stove, or change the sink.  You might choose to  use something other than DevOps services, or a different buildpack, but it will have some impact on your meal.  You look into the pantry, and choose the ingredients (services) that you will use to prepare your meal.  You may follow a recipe (the project templates), or you might just whip something up yourself (who needs a recipe for a grilled cheese sandwich?).  You then prepare your ingredients (providing the custom code to bring elements together) using utensils (the Orion IDE), and your stove and sink.  Once the whole process is complete, you have your meal (a finished application).  The only difference is that BlueMix gives you a “magic plate multiplier”, which allows you to cook for one, yet feed one hundred by scaling the size and number of deployment instances.

(Note: IBM seems obsessed with food lately, check out the Watson Food Truck.)

The analogy may not be the greatest, but it does help illustrate what BlueMix does, and it does all of this on the cloud.  Everything is done on the cloud.  No clients.  No plugins.  No extensions.  Just a browser and an active account.

Jazz Moves – Learning the basic steps

Recently I have been getting a lot of email requests from people asking if they can do something “non-standard” with Jazz.  I am going to answer your questions, but I am also gong to tell you WHY you get the answers that you do from our experts.  Here is a sanitized example of a recent email:

Hi Daniel

My name is John Doe. I saw that you wrote an article on the CLM deployment wiki 
on Jazz.net. I have a question that you may be able to help with.

A customer is deploying CLM 5.0 with Oracle and they have a standard practice 
of creating a single "temp" tablespace for a set of applications like our CLM 
suite. Will everything in the CLM suite function correctly if all four CLM apps 
use the same "temp" tablespace or is it necessary for each app to have its own 
temp tablespace as it is described in our documentation?

John Doe

Just because you might be in a rush, I will give you the answer right away.  The answer is,

"Just install it the way it is supposed to be installed.
You CANNOT have all of the CLM apps use the same tablespace."

Now let me tell you WHY you get this answer (and some other seemingly unsatisfactory answers) from our support teams and subject matter experts.

Basic Steps and Stock Answers

I can fire off this answer almost immediately because I know that we have never tested CLM in a configuration where all of the CLM applications share the same “temp” tablespace.  We have enough of a challenge in fully testing all of the various topology permutations, without looking for edge cases that customers will rarely attempt to deploy.  This leads us to the first basic law of software support

Software Support Rule 1: If we did not explicitly test the scenario in question, then we don’t support it.

We’re not trying to be mean, and we’re not trying to make your life difficult.  We just want to save you the time/frustration/energy of trying an approach, or planning on some approach, that just will not work.  So often when confronted with questions like this one, we will rely on Software Support Rule 1, and tell you that you cannot do these types of things.

Now let’s dig down a level.  I honestly don’t know if this would work from a technical perspective, but I know enough about Jazz architecture to make some technical assumptions, and do a little bit of thought on why this still may not be a good idea (even if it might be technically possible).

If I assume that the customer in question has installed the minimum of CLM products (say JTS, CM, QM, and RM), then I have four different applications all sharing the same “temp” tablespace.  Having all of these applications making transactions into this tablespace will cause some requests to this tablespace to queue up, when load becomes heavier.  This will impact the end user performance, as requests are not answered in a timely manner.  Which leads us to the second basic law of software support:

Software Support Rule 2: If it could adversely impact performance, then it is a bad idea

There are some other things that come into play here.  One of the things that we constantly worry about when architecting Jazz deployments is the ability to easily move and administer Jazz resources.  What would happen to this shared temp table during an upgrade?  The upgrade process will often manipulate data in the repositories, if the structure of the data schema has changed.  Having a shared temp tablespace could impact this.

What if I added a second CM (or RM or QM) instance to my deployment?  Would two different instances of the same application still be able to share the “temp” tablespace?  In this case, I can envision where a CM instance might ignore data in the temp tablespace that was in reference to another CLM application, but I doubt that we would have made provisions to validate the identity of  a particular CM instance associated with any of the temp data.

Software Support Rule 3: If it adversely impacts future scalability, then it is a bad idea

So given all of this information, it is much too risky to attempt something like this.  There are potential issues at a variety of different levels.  All of this thinking goes into the simply stated reply of,

Just install it the way it is supposed to be installed.  
You CANNOT have all of the CLM apps use the same tablespace.

Now What Do I Do?

So that gives us our answer, but it doesn’t answer the question of how we can move forward with this particular installation.  Here are some things to keep in mind as you determine which course to take:

• Perhaps the DBA’s don’t understand the Jazz architecture.  They might think that this would be a more efficient use of resources, and easier to maintain.  In the case of the Jazz CLM deployment, it will not be.
• “Standards” get broken all of the time.  Often you merely need to provide a good technical justification for why you cannot adhere to the standard.  Keep in mind the end goal here – providing a more efficient, transparent, and cohesive software development environment.  The goal is not to make the lives of DBA’s and Systems Administrators easier.  We DO want to make their jobs easier, but it is not our primary goal.

Remember that any architecture is a series of tradeoffs.  While we want to conform to existing norms and standards as much as possible, it is not always feasible.  The key here is to make sure that any Jazz CLM solution deployment has a stable and supported architecture, which balances the needs of the software development teams that use the solution.