Resultados 1 a 2 de 2
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    [EN] The frustrations of building a Private Cloud

    Andy Barrow
    Feb 22, 2016

    When it comes to cloud there’s rarely a day goes by without a public vs private related story or opinion piece in the press. Most of the time the themes are the same, however a few weeks back Trevor Pott at The Register released a blog entitled ‘Private clouds kinda suck, you know?’ which was right on the money. It’s one of the best I’ve read this year so far. If you haven’t read it, you should:

    Pott's article states that enterprises want to act like service providers; they want to improve change control, create agile cultures, utilise self-service (where possible) and become ‘service oriented’. But what’s stopping them from creating their own private clouds? Do they just ‘suck’?

    At ANS we have been building private clouds for many years, we’ve worked hard to understand what our customer needs from their cloud and we’ve won multiple industry awards for our private cloud work in the process. So here is our perspective:

    Private Clouds are tough to build. It’s as simple as that. It’s not just technically (which we will cover) it’s culturally as well. We’ll go through both.

    Technically, the article states that software on the market (from various vendors) is just poor. I’d agree that this is often true, however in some cases the issue is that the software requires a lot of programming and coding in order to leverage infrastructure API’s. Organisations are often mislead into thinking ‘if I buy this software and services I will have a private cloud at the end of it’. Unfortunately it’s a little more complicated than that.

    While it’s true that there is out of the box functionality that can be leveraged right away from this software, for example: self-service provision of a VM from catalogue, there are many more variables that require configuring. Storage management is a huge task involving: network provision, continuity/backup/restore, platform automation - the list goes on and on. Creating a VM on its own without any surrounding operational services can be relatively pointless and can actually create more work than it removes.

    That simple functionality may be enough to satisfy a development team and if so that’s great. If the goal is to just self-serve a ‘VM’, then you may be happy with simple out of the box functionality. However it really doesn’t do much for operations, it doesn’t transform nor does it create the agile and fast transformative IT department that private clouds promise. In reality it can actually create an even bigger headache. Self- service is meant to improve change control, not make it more complex and unpredictable.

    Much of the hardware infrastructure on today’s market wasn’t designed for automated functions. For example, there are many compute and storage platforms that simply don’t have solid, documented and supportable API’s (if any at all.) They simply weren’t designed to be automated and my predication here is that these hardware platforms are walking dead. Even if they could be automated, do you have REST/JSON/XML/SOAP and Python skills needed for this task? If you have found a service partner it will be difficult to calculate days for the task, as there is so much testing and re-iteration to be done. You need a defined scope of what to automate and many days will need to be spent just scoping out the documentation of the hardware vendors infrastructure you are trying to automate. Then you’ll need to code in best practice to ensure that the code doesn’t break your current operational procedures and destroy something.

    When it comes to upgrades of infrastructure components at any time throughout its lifecycle- how do you check that the API’s still work for every release? This requires spare equipment and a test rig plus all the testing processes. It requires managing, version controlling and development procedures. It’s hard, near impossible, for an already burdened IT department to attempt to skill up in programming and learn along the way.

    Culturally there are a different set of challenges. You need to understand that current ITIL based change control will need to adapt as it now becomes pre-approved and digital as ‘ops becomes code’. You need to accept that it becomes less human centric and therefore the function of traditional ITIL based change control adapts to suit a fast, frictionless and more streamlined process. Private clouds also require IT teams to change their role slightly. Traditional system builders and operators move to the platform layer where there is more value to be created in service architecture. Infrastructure architects change to ‘integration architects’ as they understand the chained events that happen in code in order to deliver the faster cloud like service. The unwillingness of departments to change in some cases means that any vision or goal of becoming a service oriented department, falls flat out of the blocks. Vision and mission statements are pointless, if at the end of the day the team are fixed on speeds and feeds because that’s where the skills are currently and they are unwilling to even try to change. I may have oversimplified here; changing an Enterprise IT department culture is seriously tough, but it doesn’t make the points any less relevant.

    Private Clouds exist to achieve IT speed and efficiency. It’s no good if the business wants to be faster and utilise a service approach and then it takes 2 years post procurement to get something usable and then that ‘under delivers’ on its original promise. There’s many analyst articles that state ‘my private cloud didn’t deliver’ etc. You don’t have to look far for an ‘over promise, under deliver’ case study.

    At ANS we believe a Private Cloud is something you buy, not build. It’s a pre-integrated solution of hardware and software that ships as a unit for use as a private cloud. And this isn't just our opinion, tech analysts Wikibon released an article late last year highlighting the need for a pre-integrated Private Cloud solution and the myriad of benefits they will offer organisations.

    The API work is already done and a release management procedure exists in order to look after upgrades and changes with each version being certified first before it is released as an update to customers. This is our Validate Release Service (VRS). The coding is already tested, validated and is designed to work to best practice. It uses infrastructure that was designed to be automated. It encompasses monitoring, capacity and performance management procedures that work with the system to ensure each component is managed appropriately for its intended cloud use. It is completely standardised and industrial in nature and integrates into your current ITSM system for change control. Don't believe me?

    This is RAPID. RAPID is a factory integrated private cloud with all the above included as part of the system. It is pre-integrated, validated, tested and it ships as a unit from point of order to the customer in 28 days. It encompasses thousands of hours of integration testing at each release and its sole purpose is to help you to innovate and operate, better, faster.

    This is the way to realise value from a private cloud. We believe it is something you buy and use, not build and manage.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Czarknado ‏@pczarkowski

    Cant tell if London underground map or Openstack architecture diagram.

    Tenho que reconhecer que o Openstack alcançou o principal objetivo do projeto.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens