Deploying Production Cloud Applications – A Readiness Checklist

I just had a conversation today with my VP (Rob Sauerwalt – check him out on Twitter – time to do some shameless kissing up to my management team) about a recent internal communication that we both saw.  It was someone looking for a “readiness checklist” for the deployment of an application on the IBM Cloud.  Rob and I both agreed that this seems pretty simple, and we came up with a quick checklist of things to consider.

Now this list is not specific to the IBM Cloud, it’s pretty generic.  It’s just a quick checklist of things that you will want to make sure that you have considered, BEFORE you deploy that cloud based application into a production environment.  I am an Agile believer, so I would suggest that you address these checklist items in the SPIRIT of what they are trying to do, and that you should do what makes sense.  This means that each one of these areas does not need to represent some 59 page piece of documentation.  What you want to do is provide enough information so the poor guy who takes your job after you get promoted, is able to be effective and understand and maintain the application or system.

If you have suggestions about other things that should be on this list, please drop me a line and let me know.  I would love to add them to the list, and make this generic deployment readiness checklist even better.

Production Readiness Checklist

The Basics

⊗ Name and General Description of the Application – this includes the purpose of the application and the number of users that are anticipated to use the application.  Also have an idea of the types of users.  Is it for the general public?  Only for certain roles within our organization?  Is it only for your customers?  Do this in two to three paragraphs – anything more is adding complexity.

⊗ Description of Needed Software/Hardware/Cloud Resources – a list of the needed software packages, and the clou resources needed to run the application.  Do you use third party utilities or libraries?  Do you run on Cloud Foundry buildpacks?  Virtual machines?  Do you use Cloud services for database resources?  Often a high level architectural diagram is useful to help other people understand the system at a high level.  This should be done AS you build – so you can simplify things.  Are your developers using different libraries to accomplish the same thing?  Get them to standardize.  Reduce your dependencies, reduce your complexity, and you improve your software quality.

DevOps Considerations

⊗ Operating Systems and Patching Requirements – do you have specific OS requirements?  Do you require a particular framework to run properly (like .NET, Eclipse, or a particular Cloud Foundry buildpack)?  What OS versions have you tested and validated this application with – and do all of your components need to be on the same OS version?  This becomes important when fixes get deployed to containers, virtual machines get upgraded, and maintenance activities are done.

⊗ Installation and Configuration Guidelines – you should be deploying your application in some automated manner.  So your deployment and promotion scripts should be the only guide that you need…… except when they aren’t.  Take the time and DOCUMENT those scripts – explain WHAT you are doing and WHY, so your application can easily be reconfigured or deployed in different ways in the future.

⊗ Back-up, Data Retention and Data Archiving Policies – let your operations people know what data needs to be archived and retained.  How often do systems need to be backed up?  How will services be restored in the event of a crash?  Explain WHERE and HOW data needs to be retained.  Explain what your DEVELOPMENT teams need to review on a periodic basis.  This can be the biggest headache for development teams, because these are often scenarios that they have not considered.  Backup plans are not sufficient, they need to be executed at least once before you go into production – so you are sure that they are valid and that they work.

⊗ Monitoring and Systems Management – This includes runbooks – what do we need to do while the application is running?  Do we need to take the logs off of the system every day and archive them?  Or do we just let logs and error reports build up until the system crashes?  Should I monitor memory and heap usage on a daily basis?  Should I be monitoring CPU load?  Who do I notify if I see a problem, and what is a “problem”?  (CPU at 50%? CPU running at 20% with spikes to 100%?)  How will this application normally be supported?  You may not have complete information and definition of “problems” when you begin, bu define what you can and acknowledge that things will change as time goes on.

⊗ Incident Management – This details how you react to application incidents.  These could be bugs, outages, or both.  In the case of an outage, who needs to be called, and what actions should they take to collect needed data, and to get the application back up and running.  What logs are needed, what kind of data will aid in debugging issues?  Who is responsible for application uptime TODAY (get things back on track and running), and who is responsible for application uptime TOMORROW (who needs to find root cause, fix bugs, make design changes if needed, etc.).

⊗ Service Level Documentation -This is the “contract” between you and your customers.  How often will your application be down for maintenance?  If your application is down, how long before it comes back up?  Are there any billing or legal ramifications from a loss of service?  Do your customers get refunds – or cash back – when your Cloud application is unavailable?

⊗ Extra Credit – DevOps pipeline – you need to have an automated pipeline for the deployment of code changes into well defined development, test, and production environments.  You need to have a solid set of policies and procedures for the initiation and automation of these deployments.  Who has authority to deliver to test environments?  Production environments?

Software Architecture Considerations

⊗ Key Support & Maintenance Items – the team that built this thing knows where the weak spots are – share that knowledge!  Where does the team know that “tech debt” exists – and how is that impacting your application?  This information will help the teams maintaining and upgrading your application.  They will be able to do this with knowledge about how the application works, and why certain architectural choices were made.

⊗ Security Plan – Everyone is worried about the security of their applications and data on the cloud.  You need to be sensitve to this when deploying cloud based applications.  Your stakeholders and users will want to know that you have considered security, and that you are protecting their data from being exposed, stolen, or used without their knowledge/consent.

⊗ Application Design – This should include some high level description of your use case, a simple flowchart and dependencies.  Give enough detail so someone can easily get started in maintaining your application code, but not so much detail that you waste time and ultimately end up with documentation that does not match the code.

Is That Everything?

That’s not everything, but it is a good minimal list of things that you should have considered and/or documented.  Most applications need some sort of a support plan – who handles incoming problem tickets from customers?  Do you have a support process for your end users?  In your own environments and business context, you may have other things that need to be added to this list.  Do you need to check for compliance with some standard or regulation?  What are your policies for using Open Source software?

So this list is not meant to be exhaustive – but it is designed to make you think, and to help you ensure higher quality when deploying your Cloud applications.

Advertisements

Happy Holidays for 2017

With the end of the year quickly approaching, it is a great time to look back on the past year, and to look forward in anticipation for what is coming in 2018.

2017 was an interesting year.  I saw an explosion in the development of chatbots of various different types.  Some were very simple, others used both Watson Conversation and the Watson Discovery service to provide a deeper user experience – with an ability to answer both short tail and long tail questions.  I saw a huge uptick in interest in basic Cloud approaches, and a lot of interest in containers and Kubernetes.  I expect that both of these trends will continue into 2018.

In 2018 I expect to see the IBM Cloud mature and expand in it’s ability to quickly provide development, test and production computing environments for our customers.  I also expect that more people will become interested in hybrid cloud approaches, and will want to understand some best practices for managing these complex environments.  I am also excited about some of the excellent cognitive projects that I have seen which could soon be in production for our customers.  I also expect that some of our more advanced customers will be looking at how cognitive technologies can be incorporated into their current DevOps processes, and how these processes can be expanded into the cloud.

I hope that your 2017 was a good one, and I hope that you have a happy and safe holiday season.

Hurray for IBM Cloud!! Um, where did my stuff go?

Just went through an issue with a customer, and it’s a somewhat common issue so I figured that I would do a quick blog post on it.

Recently IBM has decided to rebrand our cloud from what we commonly refer to as Bluemix, and we are now referring to as the IBM Cloud.  You may have noticed the changes to the UI, and some new capability (like resource groups!).

Some of these changes have caused some of our customers to “lose” access to some of their data on Bluemix the IBM Cloud (see, even we struggle with the changes in names).  These customers claim that they can not see some of the organizations, spaces and services that they used to have.  DON’T PANIC!.  Your work has not been lost.  What has happened is that as IBM has collapsed things to a single IBM Cloud user (when maybe you used to have a SoftLayer user, and a Bluemix user), you now have access to two different accounts from your IBM Cloud web interface.

Fixing the Issue

So just go and look at your profile in the IBM Cloud UI.  It is the little person icon in the upper right hand corner of your browser.

Now click on the little symbol under Account, and you will notice that you now have access to two different accounts.  Some of your artifacts will be in one account, and others will be in the second account.  You can switch context here in the UI so you can see what is in each account.  Presto!!!  Mystery solved, and now you can go back to being insanely productive working out on the IBM Cloud.

Getting Data from your IBM Cloud GitHub Project

Note: This post is also published on developerWorks, as Getting Data from your IBM Cloud GitHub Project.  Please refer to that article to catch any updates.

I blog when I have to answer questions that I want to more widely share the answers to.  It’s also a good way to remember things before a turkey induced amnesia sets in (it’s a week before U.S. Thanksgiving).

Recently I have seen some questions on being able to get access to the data in an IBM Cloud GitHub project.  I had just completed doing a quick internal activity for pulling information out of a GitHub Enterprise repository, so I figured that this would be simple.  It was…. and it wasn’t.  The IBM Cloud GitHub instance isn’t a GitHub Enterprise deployment, it is a GitLab deployment.  The GitLab API is a little different from the GitHub Enterprise API.  I managed to find a suitable Python package for using the GitLab API, and if you look at the resulting code, it is pretty simple.

So I have created a simple GitHub project (called IBMCloud_GitLab_CSV) that does a quick CSV export of issues from an IBM Cloud GitHub project.  It’s a simple example, written in Python, that you should be able to use and tailor, to fit your specific needs.  I use small Python programs like this to pull the open issues from a variety of projects, and then I can share the resulting CSV files with project managers and PowerPoint producers who want to report on these sorts of things.

If you need this type of capability, make sure to read the README file for this project, which instructs you on how to modify the code to point at YOUR IBM Cloud GitHub project, and tells you how to get an access token for yourself (which the program needs, in order to be able to log into your GitHub project).

If you want to improve on this example, or even create some type of generic tool for doing this type of thing, please join the IBMCloud_GitLab_CSV GitHub project and begin contributing to it.

Watson as a Service

As I have said on earlier blog posts, if I have to answer a question more than once, then it’s probably worthy of a blog post.  This week I had one of those situations, and thought that it would be good to share because it highlights a few points at very different levels.

Last week I was answering a survey posted by a Watson Speech-to-Text user, who was complaining about how confusing everything was.  I found this a bit surprising, as Speech-to-Text is one of the more simple services for developers to work with.  The user claimed that their EasyVSL app was telling them that “Watson wasn’t working”.  So I quickly checked the Bluemix status board, and found that nothing indicated a loss of service availability.  So I asked some more questions and probed a little deeper.

Watson as an Add-On

I found out that the EasyVSL app has a feature which the user can turn on, which will use the Watson Speech-to-Text service.  The user just need to add the service credentials for a valid Watson Speech-to-Text service, and the EasyVSL app will use that Watson service instance to do their speech-to-text processing.  Once I saw this, I walked through creating an instance of the Watson Speech-to-Text service for the customer, and showed him how to get his service credentials, which he then supplied to the EasyVSL app.  Once this was done, Watson was no longer “broken”.

Up until the past few weeks, I had never seen a product use Watson services in this way – as an add-on to an existing capability, where the CUSTOMER needs to provide the Watson service.  In this case, EasyVSL doesn’t worry about paying for Watson services.  If their customers see value in them then they use them and pay IBM directly for the services that they use.  It is a business/operating model that I am beginning to see now.

Advantages and Disadvantages

This type of model has some positives and negatives associated with it, and I think that it depends on your perspective.  As an application provider, it is a positive to be able to let your customers pay for the additional functionality that they want.  If they don’t need advanced cognitive capabilities, then why should they pay for them?  It also allows you to avoid thinking about how your are going to pass charges along to your customers.  If you need to monitor customer usage, track how many times they are using the various Watson API’s, and then figure out some way to pass along the costs associated with them, you will end up spending a fair amount of time and effort developing that monitoring and billing infrastructure (not even considering the adjustments that you will need to make to make your business model work).

From a customer perspective, many of the positives become negatives.  While I like to have a choice as a customer, I do not like having to deal with two vendors billing me for a single service.  I am also not thrilled with the fact that I need to maintain an instance (or multiple instances) of the Watson services.  I am paying money to a vendor so THEY can worry about that stuff.  The other downside is that as a customer, it is not always apparent which vendor I need to call when I have a problem.  That was the issue that I saw this week – the customer that I had helped had reached out for support from both EasyVSL and IBM – and had not gotten very far with either of them.

Future of Watson as an Add-On

I’m not sure if this pattern will become popular, although my gut tells me that it won’t.  Most customers don’t like paying multiple vendors for what they perceive as a single service.  However, I do note that cell phones are now largely unsubsidized in the US, with customers buying their own phones, and then paying monthly for services that those phones use.  In the past, the phones were “free”, and the cost of the phones was “bundled” into the monthly cell phone rate.  So there is precedence for this type of model working.

If you are an app provider, it is critical that you think carefully about your approach to how you use the Watson cognitive services, not only from a technical perspective, but also from a business perspective.  The business model that you choose will have an impact on your development, operations, and your customers.

Multi-Cloud Strategy for Your Future

Those of you who read my posts know that I work for IBM, and that I work in the Cloud and Cognitive spaces.  Recently I have seen some articles on Multi-Cloud Strategies (like this one from the O’Reilly site), and it puzzles me why so many of the things that I see on this topic seem to miss some of the most basic things.  The O’Reilly article simplifies things, and misses some very important points.  I don’t blame them, it’s hard to boil down a complex concept into a blog post that can be read in 5 minutes.  So after explaining this more than once to someone, I figured it was time to write about it.

Getting Started with Cloud Computing

Cloud computing should be thought of as a tool – a tool to squeeze more computing power from a limited budget.  At the highest level it allows a customer to stop buying and maintaining their own sever hardware, and “lease” this capability from a Cloud vendor.  Now there are multiple things that you need to account for: security, availability, service availability (what kind of services are available), reliability, cost, etc.  Due to some of the current limitations of cloud technologies, not ALL workloads are suitable to be moved to the cloud.  There is a lot to understand, and it can be overwhelming.

For this reason, many companies decide to move slowly to the cloud, so they can learn and gain experience as they go.  This is a great way to learn about what is important, learn about the limitations and concerns that you should have, and to get some experience with cloud.  So they select a single cloud provider, and try a couple of pilot projects, moving some portion of their production computing to the cloud.

This is what I would consider a sane and reasonable approach to starting your journey to the cloud.  This approach reduces your risk, and allows you to learn as you go, gaining valuable experience and expertise as your initial projects get deployed.  Your team will understand he capabilities of your initial cloud vendor, both positive and negative, and will begin to become more comfortable with the whole cloud paradigm.  At this point you are not able to leverage the strengths of various cloud vendors, but you don’t really care because you are in learning mode.

Branching Out

Once these initial pilot projects have been completed, you will then branch out to doing some other projects with your original cloud provider, as well as doing some pilot projects with a second cloud provider.  This is the next step on your journey to a true multi-cloud strategy.  This second cloud provider will seem quite strange, they may have some different terminology, different billing, and different capabilities.  At first your teams will not like them, because they are comfortable with what they already know from your initial cloud provider.  Give them time to learn – over time your teams will get a more balanced view of the positives and negatives of the cloud vendors.

At this point you should begin building your own knowledge base of the types of use cases and workloads that work particularly well for each cloud vendor, and you should have some kind of rough order of magnitude way to price workloads that have moved to each cloud vendor.  Your team should also have a much better understanding of cloud concepts, and understand the differences in terminology between the cloud vendors.

A True Multi-Cloud Strategy

Once you have branched out to a couple of cloud vendors, branching out and evaluating additional vendors should be easy.  Your team will be experienced and will understand some of the key capabilities to look for, the things that are important for your organization.  You will be able to intelligently pick and choose between cloud vendors, based on price, capability, reliability, and based on your own experience.  You’ll be able to make well informed decisions based on your use case, the workload, and choose the best cloud vendor for that particular job.  So let’s look at what the positives and negatives of this approach are.

Negatives

  • Time – who wants to wait for two years while your team gets the knowledge that they need?  Why not just pick a single cloud vendor and be done with it?
  • Administration – monitoring and managing one cloud supplier can be a pain – managing 4 or 5 of them can be 4-5 times more painful.

Positives

  • Reduced Risk – your investment portfolio should be well diversified, it reduces the risk you face should one of you investments fail.  Your portfolio of cloud technology providers should be diversified for the same reason.  It allows you to quickly take advantage of new capabilities and technologies, and gives you FLEXIBILITY.  If you remember nothing else from this post – remember this point.  It is what all of the other articles that I see miss – and it is the single most important benefit.
  • Avoiding Vendor Lock In – have a cloud provider that is charging you too much?  If you’re familiar with other vendors, moving workloads between cloud providers can be easy (especially if you use container technology).
  • Best of Breed – giving your business the flexibility to choose a cloud provider that best fits their needs allows you to avoid overpaying for capabilities that might go unused with some cloud providers.
  • Best Practices – each cloud vendor may be strong in a particular area, but your team can generalize these best practices across ALL of your cloud implementations.

So wrapping things up, I think that a multi-cloud strategy IS important.  I strongly believe that the benefits of reduced risk and flexibility far outweigh the costs in terms of time (and patience) and administrative overhead.  It also allows your IT teams to focus on your core business, and pushes many of the “bread and butter” IT tasks off onto the cloud provider.  This allows you to focus and innovate.

Monitoring Bluemix Usage and Spending

Note: This post is also published on developerWorks, as Monitoring Bluemix usage and spending.  Please refer to that article to catch any updates.

I have been spending the summer working with a number of different Bluemix and Watson customers, and one question seems to come up quite frequently.  It has a lot of variations, but it all boils down to this:

“How much of the Bluemix and Watson services am I using, and how can I monitor this?”

This is pretty simple to do, and you can even automate it yourself.  So it’s worthy of a quick blog post.  First let’s start with the interactive monitoring of your usage.

Checking Bluemix Usage

First you’ll need to log into the Bluemix platform, using your IBM ID.  When the main screen comes up, you’ll see account option up in the upper right of your browser.  Click on “Manage”, and your options will look like this:

If you then select “Billing and Usage”, and then select “Billing”, you will be taken to a screen that will show the current status of your Bluemix subscription (if you have one).  It will show how much you have already consumed, as well as how much of your subscription remains.  It should look similar to this:

You can scroll down through this report to see more details.  You can use this same method and select “Usage” instead of “Billing”, and you can see your current months usage and to see the specific usage on any of the available Bluemix services.  There are other things that you may be interested in as well.  Check out the Bluemix Docs on Viewing your Usage for more information.

Automating the Process

You can also see usage (although not billing) information by using the Bluemix CLI (Command Line Interface).  The two commands that you will be most interested in are “bx billing account-usage” and “bx billing orgs-usage-summary”.  A small GitHub project with a command line tool which will dump your account information (using those commands) is called bmxusagetracking.  Go out there and grab the code – and then modify it to suit your own needs.  The script is simple – it should take no more than 5 minutes to grab it and understand what it is doing and how it is doing it.

I am also looking at creating a Python version of this in the same project area – since I know that some of you would much rather do this in Python – so you can manipulate the returned data and make it more useful.  I invite anyone who wants to contribute to the project and improve it, to do so.