Tag Archives: lock in

A lot of attention this week has been focused on comments made in an interview with Barclays Bank on how their use of Linux allowed them streamlined and focused development environments and how use of Linux and Open Source confirmed their internal strengths to get to first base quicker and faster, saving a huge amount of budget in the process.

Barclays are a thought leader, they're a great company who understand how changing the ethos and supporting their people to deliver the platforms and technologies allows them to be one step ahead of many in the same vertical industry. It's one reason Red Hat work with them and why we put so much effort into supporting their ambitions.

So if Barclays can harness Cloud openly and benefit by association can other businesses use it for transforming not just their architectures but also the underlying ethos that glues IT processes and practices together ? Allowing the adoption of Open Cloud to re-invent or re-imagine what they are able to achieve. Agility has always been a cornerstone of Cloud, elasticity goes beyond availability but also describes methodologies of provisioning to fit both governance and appetite. Using Open Cloud to develop hybrid methodologies to build new structures around your internal capabilities may yet be seen as the smartest move yet for shrewd CIOs facing the ever increasing needs from both internal and external facing customers.

OpenShift has given voice to Red Hat’s ability to work with forward thinking developers at every level across every business vertical. To be able to demonstrate openly with three clicks how you break through existing barriers to Cloud application deployment and management. Tie in JBoss (the underlying glue behind OpenShift) and you have an agile structured development environment world class and ready for application deployment as well as those organisations who are realising that migration from WebLogic and Websphere makes JBoss a more advantageous platform than just being a JRE stablemate.

Barclays aren’t the first, they may be one of the most vocal and supportive, but the world is waking up to the fact that if you are sensible, if you understand business process and bottom line effects on your business – you avoid vendor lock in, and you think Open.

We’ve worked very hard over the last five years to build a solution set of technologies as part of engagement at the customer level to get existing enterprise customers often drowning in older legacy less flexible legacy platforms to start thinking openly. The Red Hat Pathways engagement model is proven to work and is a great starting point when you are starting to consider how you re-imagine and re-focus your business process methodology around harnessing the best of Open Source. This is never more critical when it comes to the decision making around Cloud. The video below gives you a brief snapshot of what it is and how it can be engaged with.

Below you'll also find two more online resources to help you think about why being Open can dramatically increase your agility and flexibility at every level of your business using Red Hat Open Hybrid Cloud.

Red Hat - Get more out of your Open Cloud

Red Hat - Enterprise PaaS

I was stood at GigaOM in Holland last week and got involved in a heated discussion over ITIL as a standard in cloud. Tried to point out ITIL is a framework not a standard. Took mental notes while I was there and the result is this short podcast where I can rant and let off steam. The power of the microphone is sometimes awesome and it let's me educate as well as try to show my enthusiasm for what we're doing here in Cloud.

Also I take time out to talk about the London Developer Day we're hosting at London South Bank University on the 1st November (thats next week !!) so if you haven't registered you need to do so asap right now.

Download the podcast here in MP3 and OGG formats

I fly around a lot for a living, it's as much a pro as it is a con but one of the cool things about having that "downtime" in airport lounges and in the air is time away from noise and time to catch up on reading articles and white papers from across the industry. From sources both open and proprietary and all points east and west of the commercial doctrines that I've spent my working life trying to be more reflective of the realities of being more open and transparent. I often find myself (and I've been known to be frowned at by other passengers) avidly shaking head as I scrawl short punchy rude words across print offs of articles that I've thrown in my flight bag mouthing them quietly as I'm doing it like a idiot savant who just happens to have every gadget known to man accompanying him on a long haul flight. Having a reliance on an iPad and an Android 4.0 ICE 10" tablet hasn't helped as I don't really want to use a third party proprietary app to dump a page to a PDF so I can "read it later" and bookmarking something to read at 38,000 ft doesnt tend to work well without WiFi (most routes I travel don't have inflight WiFi). So I'm back in 1993 technology territory with my highligher pen / marker and a sheath of paper that I try not to confuse with boarding passes (yes I know you can get an app for that - I have one but I'm anal about organisation) and other travel ephemera that I carry.

It was during a period of melancholy catchup on a flight to Finland to talk at a Cloud Tour Red Hat were organising and where I was speaking that I found myself reading three or four various journalists take on what Cloud Application Portability actually was. It's a scary world where if you took their output, broke it down to core essential bullets took out the chaff and the hyperbole that all four disagreed with each other as to the true definition of application portability in Cloud. These are thought leaders so having my own ideas I went away and talked to some of the crew in the Cloud BU at Red Hat.

Now the cool thing about working for any Open Source company is not only are they often meritocracy based organisations but there is no such thing as a wrong answer, only a different methodology or construct to get to a reasoned answer. We just announced our most successful trading year and a $1.13 billion dollar turnover which considering the amount of time the good and the great at Red Hat putting care and conviction into what we do isn't therefore surprising. So I was looking, for a definition, from the movers and shakers at Westford our offices just outside Boston where the engineering pulse of Red Hat has a strong beat. It was therefore more surprising that given I'd read and scrawled over in luminous yellow marker four different takes on portability that those I approached came back with 95% of the same answer even though asked seperately to a man and without knowledge I was consulting with others across a massive business unit.

Taking this counsel aside I then looked into reasoning why so many educated thought leaders whose editorial is enjoyed and respected had their own opinion and direction. None of it wrong by definition but certainly differing paths to a differing conclusion.

It bugged me. It bugged me because some of the editorial and reasoning I read slightly misunderstood portability and took it as re-deploying applications to specific clouds with engineered boundaries and challenges and varying standards. Thats not portability - thats porting in the traditional sense. If you have to make your application fit a variety of vendor SLAs or engineering tenets then you're just adding workload and change control schema into your existing workload and process control management, whilst only slightly avoiding the lock in issue of being stuck with one Cloud Provider partner.

The issues around the lack of Cloud standards and their impact on interoperable stacks in Cloud providers again becomes a moot point if you consider that true portability doesn't start the day you finish your application and then think about where you are going to deploy it and the necessary major modifications or changes you'll have to make to get that to Cloud safely and with confidence and to be able to then deploy it on premise or a local stack or even on another provider. Scalability, the mandatory and additional security controls needed to deploy securely, the ability to orchestrate and to define scripts and provision all then become these parts of the portability piece that then get talked about in hushed tones and added to the project plan as "costs" and a guesstimate made as to how long that will add to the deployment / dev piece. And then start thinking about ongoing slightly different SVN/Git/CVS repositories for slightly varying versions of the same app or package and the necessary security controls and patching controls if you've had to dovetail your apps into a container type Cloud environment.

A journalistic appreciation of the issue that appeared in December then confounded me by making the sweeping statement that the only way application portability would happen is when embracing a PaaS offering from a specific vendor or using a proprietary platform (in this case Stackato). Answering 25% of her own question with 10% of the answer, not necessarily the wrong answer but not one I'm sure a lot of enterprises wanted to read given the fact that doing this right first time out isn't hard as long as you use open standards and technologies to do it.

The annoying thing for me was that a few weeks before the article that made me frown and scrawl rude words on it with a marker pen at 38,000 feet almost spilling my Duerrs and Ginger Ale, a blog article written by a good friend of mine James Labocki  had appeared (@jameslabocki if you want to follow his Twitter feed which I do advise as he's one of our brightest and best Cloud gods). The article gave a short but kickass editorial around portability to the layman and CloudForms, the Red Hat IaaS piece that we've been polishing and getting ready to package for release this year.

At this point I'm going to say if you want to avoid me ranting further on a Friday afternoon and you want to really be able to get the portability piece then I'm going to pass you into the safe care of James whose article you can read here.

Footnote: If you're a journalist wanting to write about portability then I also suggest that you read this post and follow James' blog as he's right on the money and you won't go far wrong using the right sources.

Addendum: I should have posted a link to the authoritative bible on the topic ! - Bryan Che's Tentenet.net started out with a deep dive into the autonomy and power that can be evolved from understanding what we mean by open - feel free to read and share, here's the link.