PaaS, Feelin the Waters

You don’t know what you don’t know. period.

What is the best way to find out what you don’t know? Doing it!

I have been on several engagements implementing OpenShift and most companies completely underestimate the amount of commitment needed to implement it successfully.

What is/should be the #1 goal of setting up a PaaS in your data center? The people and system(s) that need/want to use your services. If you don’t have customers that are interesting in using your services a PaaS solution probably isn’t a wise investment for your team. Intuitive right? Well most of us would like to think so, but more often than not leaders get caught up in the shiny new thing. Heck, I’m guilty of it. Whenever a new software tool comes out I’m all over it. It’s cool and exciting.

What is wrong with cool and exciting? Noting, absolutely nothing. Actually it is the grease that keeps our technical innovation moving. There is a problem though when someone blindly says, hey i just saw this new shiny thing that may work for us, so lets go ahead and fully implement and invest a lot of time and energy into this new thingy. While you can clearly see where I’m going and this is intentional, this sort of silly thing happens all the time.

Now, we talk PaaS. So, given my basic example from above, for talented IT teams there shouldn’t be an issue to standing up a new service or providing a new tool to the business. The problem is PaaS is not just “a” service . It is a multitude of services all working together in concert. And those services are all layered on top of different tooling and technologies. To configure, manage and maintain said services the administrators need to be fluent in each of those technologies and unless your team has some exceptionally clever people expecting them to pick up and run with this is foolhardy.

Okay, suppose we have a team of exceptional people, current with the latest tools/technologies what next? Good question. Well we would ask what are we (PaaS) doing here? What is PaaS making more efficient or services it will be replacing or creating? Suppose PaaS will be doing all of the above. Sweet! Are there plans for transition/decommission/migration plans for existing services?

It all boils down to expectations. The goal with something like this should be to test the waters and understand the commitment that is needed for running a successful PaaS. With that said, set expectations low. Not that you should expect the tool to not work as intended, but don’t jump in the water until you know what your jumping into.

Here are the steps I would follow if I were consider a PaaS environment for my data center (if I owned/lead one):

  1. Justify need; establish use cases. This may be directly related to current and recurring needs/issues/complaints.
  2. Define stakeholders
  3. Review personal resources (developers,administrators,testers, security, network, etc); technical specialties, workloads and adaptability.
  4. Pick a simple use case to test the waters
  5. Require all requirements needed for use case
  6. Perform PaaS bakeoff and pick product
  7. Hire consultants:
    1. Roadmap
    2. Installation
    3. Best Practices
  8. Evaluate lessons learned and plan forward

With this approach there is limited risk to over committing resources (financial, personal and otherwise) and allows time to set appropriate expectations as far as roll out, adoption and sustainability.

 

 

Advertisements