Tag Archives: SLA

If you've sat across a table from me when I am poked gently I'll often bring up the topic of the need to behave in a way that doesn't detract from the nature of your responsibilities in computing. What I mean by that is that designing any platform or architecture should have the effect on a developer / architect / sysadmin to generally earn their keep and to stand up to be counted. It's the one time in a project where the program manager or project lead can honestly do nothing else other than hope and trust that the right people are in situ towards ensuring that the processes and controls, both paper and network/software based are equal in measure to his/her task of getting to deployment.

There is a need now, not later, to think about how Cloud impacts on your ability to satisfy the needs of audit processes. Luckily, companies tending to work with networks and deployments utilising Open Source components, especially supported Red Hat stack components have a general understanding of the need of how platforms need to be constructed and managed. You take your average Linux sysadmin / architect and you put him in a technological boxing ring with his Wintel adversary and my money isn't on the guy wearing the colour co-ordinating shorts and vest and the Technet subscription being declared victor. I often find, and this isn't a new phenomenon that your average Linux professional has a tacit understanding of not just his or her platform but also everything that impacts on it. I've seen sysadmins wince from across a table in project meetings when the network guy starts talking about upstream network problems because they're already thinking logfile size and CPU utilisation before the guy has even finished talking. There is a palpable sense of pride and responsibility for most Open Source architectured platforms due to the rite of passage to get them there in the first place when faced with adversarial opposition and the "nobody ever got sacked for buying Microsoft" mantra. Not that theres anything remotely wrong with Microsoft Windows as an environment, it's just a very closed mindset towards engineering that drives the development and evolution of the platform that makes little to no sense to many of us in Cloud or datacentre centric operations. Bit like being given a burrito - told to eat it and not being allowed to see what's inside it. Personally I'm a bit fussy when it comes to stuff I consume hence I make a living out of Open Source.

So when I start talking about audit in Cloud, theres an automatic assumption that I'm going to bang on about SAS 70 and the fact many providers in the Public space use it as a get out of jail free card when it comes to their approach to audit response and service level based liability. I'm not going there, there are 101 articles you can grab and reports from WebCPA to Gartner and all points west that will give you balanced industry views from seasoned commentators.

My focus is on specific things that we can do as individuals in Open Cloud to make the impact of audit less of a drain on company resources and management cycles whilst also allowing it to proceed smoother and to learn from both sides of the fence as to what you can sometimes do better. I've talked already in previous blog articles here about the Cloud Security Alliance (CSA) Cloud Control Matrixes (CCM). If you didn't look you should, it's free and it will give you a grounding at the developer and platform provisioning level of controls you should be using and documenting - or if you're already installed, retrofitting. I'm a big supporter of CloudAudit.org which last year published it's API specification which in a nutshell means a public Cloud provider to be able to publish detailed information to a defined namespace to allow proper queries to assist with audit and GRC (Governance Risk and Control) requirements. The fact that they went away as a body and also built a range of rock sold compliance packs which target specific governance types, e.g HIPAA, PCI-DSS, ISO27002 etc and by reflection upping the ante with the marketplace by highlighting differences between vendors. So theres a gap here, a gap that can be filled by the roadwarrior journeyman with his RHEL / RHEV installation building out his cloud to be able to document, based on his or hers tacit understanding. An understanding or realisation of both the global build out of your cloudy endeavours to have time to build attestation reporting and flexible approaches to security and audit as part of 24/7 ops not waiting for your CFO or FC to send you an email to tell you that next week you're under audit. If you are smart, an early OpenShift or JBoss exponent then you'll not disagree with me when I say we give you the tools to ensure audit is a 24/7/365 normality not a tickbox in time to satisfy governance.

The great news for you, if at this point you're getting concerned is that the Red Hat University is running courses on Cloud and also security and virtualisation security that will prepare you to be that man/woman of steel.

Do not get into the liablity argument with project managers. Liability being thrown out as a buzzword by some analysts is hardly something thats new to what we do as an industry. It probably matters more in a hybrid / public world where you're having to accept an Amazon / Verizon / Rackspace or whoever is your partner to maintain and build out as well as support locally from an app dev environment - each having their own level of documented controls and risk appetites / Service Level Agreements.

Anytime you outsource any business process be it payroll, be it estates management etc you introduce an element of risk. The same risks you can argue is just as pertinent to hand cranked platforms you build internally to support BAU activities. Just at least in your datacentre you can go and pull ethernet / fibre out and hide in the restroom till everyone goes home before you venture out with an iso image nervously to resolve the problem. In the Cloud there is no virtual restroom 🙂

Understanding your risks, setting a risk appetite, using proper automated tools and platform technologies such as OpenShift, JBoss or the soon to be released CloudForms and working out your application blueprints, environments then your business is going to enjoy a more relaxed and shorter audit by virtue of you owning your own destiny and understanding application and platform lifecycle in Cloud. If you outsource to a Cloud provider, especially one where a follow the sun plan takes centre stage to their operations it makes auditing harder and also your descriptive synopsis of the related costs and problem to your CEO and CFO that much more of a bind to deliver. Cloud could be argued to bring in the concept of a chain of liability where a Cloud provider may have other third party vendors in situ to suit your stack - do you have visibility of that - or do you have the right to even know that ?

Is working more openly sounding more attractive by the second ? Outsourcing by its very nature is tricky especially when negotiating liablity and access to audit required functions. I can see you pointing at the screen and saying "This was the same in managed hosting" and I'd agree to a point the only difference was you had more ability to sit down with your provider and work out terms of reference and access for audit. In Cloud with the majority of leading vendors you actually stand to release them from that responsibility unless you understand how to engage or the ecosystems that you will rely on.

Red Hat are your technology partner. The clue is in the word partner - not provider - partner. We have built Cloud Foundation Pathways to help you get through this minefield, backed up by training and support and also the ability to work with us towards making those steps to audit friendly Cloud deployment that doesn't stop you going to work or shackle you from innovation.

Engage with us, Experience why we're the number one at what we do in the number one fastest growing industry on the planet. Building the next house of Red Hat on solid foundations and being the compute and node building blocks that are the bedrock of Cloud. Open Cloud.

Today Red Hat launched it's Enterprise roadmap for Platform as a Service to the press and analysts. It's been a labour of love for a long time internally with our teams and management working intensively to put together a structured offering that really could hit the market offering a value proposition and a lifecycle for enterprise customers.

OpenShift is a game changer in Platform as a Service (PaaS). If you historically look at the definition of PaaS it's been shrouded in the architectural frameworks, scalability and application / source syncing challenges that present a raft of APIs and behaviour changes to developers that you could perceive as less than friendly - or that doesn't meet your or my own definition of open. Certainly it's not the greatest experience when faced with a new stack it presents you with a list of service definitions, frameworks and capabilities.

OpenShift is different. For starters theres a message here for the analysts and technology press - it's written by developers - for developers. Please don't lose focus on the importance of this. Theres a reason why the popularity of OpenShift since we launched it last May 2011 has been somewhat stellar. We're providing an end user experience of being able to focus on what matters - your code. Removing the handcuffs and the shackles and allowing people to get to work faster not worrying about the VM's, or the change control and how to get servers online and built etc. A gentle cursory search of the Twittersphere will drown the average researcher in plaudits from the development community who have realised a three stage push to Cloud really is redefining how you can just take leaps and bounds into the ecosystem.

Let's not over egg the pudding here. This blog isn't a marketing stall that sets out to look purely down the gun of the Cloud technologist and to aim Red Hat flavoured solutions scattergun style. What we're doing is fundamentally different, to concentrate on a paradigm shift that offers you an application platform in the Cloud whilst managing the stack for you - automating the painful stuff that hinders technology growth and slows down the rate of application development and Cloud provisioning. As I said before developed by developers for developers to deliver the capabilities they need whilst also tacitly improving the developer experience in the process. As we get to a point in the technology curve where Cloud matures it becomes even more obvious that the solutions we describe right now, that we're making available today, are THE ecosystem of choice not the simple automation of a providers framework or clutch of badly documented APIs.

Click the image below to maximise it to full size for easier reading and understanding

The fact that we come from an Enterprise background with RHEL the supported prizefighter out there in the Linux environments globally then it's screamingly obvious that once you lift the hood of OpenShift you see all the goodness, strengths and maturity of RHEL underneath. The support for standard operating and development environments as well as all the ultra tenacious stuff that the analysts in Cloud now realise is the kingpin - the major benefits of faster application scaling, better higher efficiency by the virtue of OpenShifts ability to support two tier multi-tenancy from the get go. For the bean counters that means you're reducing your costs out the box. Proper portability of applications and development environments, industry leading security by virtue of control groups as well as sVirt and SELinux out the box (security as aspect of design not by retrofit) and heres the magic sauce, the multi-tenancy capability at the Operating System tier not at the virtualisation layer unlike other offerings out there.

As you move to embrace a true hybrid Cloud model you have to acknowledge as technologists that your support frameworks and application model will have to stretch to conform to different models with different hypervisor types, SLA's enforced on you as end user adopters still expected to offer the same level of service and conformity to your users and customers. OpenShift as part of its design specification had a core realisation that if you develop an application for PaaS you were going to be in a situation where there would be flux on the part of everchanging underlying hypervisor or provider technologies. Minimising the adverse effects this would have on PaaS environments in hybrid cloud therefore became a design factor. To be able to maintain service regardless of operating environment and to maintain security and segregation in multi tenant environments and move it away from the underpinning virtualisation layer. Down to basics if you think of a battlefield planner who has to come up with a fabric that will cope and perform to the same level no matter how hostile the weather or the neighbourhood in a conflict zone then OpenShift is the body armour of choice for the Cloud soldier going into battle.

Bryan Che is the Product Marketing Manager and thought leader at Red Hat on all things Cloud, an MIT graduate and an amazing font of knowledge when it comes to virtualisation, Cloud and reinventing how we need to embrace change. He has contributed an article today which explores further how the development eco system and our JBoss core strengths can scale to handle multiple applications and multi tenancy in Cloud. Follow this link to read the article, and while you're there check out his other Tenet's of Cloud articles which are thought provoking and a great armoury for you to keep personally as you tackle objections and shape your own path in Cloud.