Skip to Content

In my quest to understand DevOps and how it applies to the SAP world, I attended #PuppetCamp in Dublin on 6th July, I went with an open mind and looking forward to learning about some cool and exciting technology – what I did not expect was to feel like a luddite and be disappointed at the lack of progress many SAP customers have made in cross-pollinating ideas from other IT systems.

I spent most of the morning learning an entirely new taxonomy around the Puppet application, which is an OpenSource tool under the Apache 2.0 software license. This was obviously a steep learning curve, and I will not pretend to have understood all of it. The most eye opening experience for me was at the breaks, talking to the people who are building, configuring and deploying end to end solutions using Puppet as their automation engine.

Screenshot-Puppet-Enterprise-datasheet.pdf-1_medium.png

As you can see from above, Puppet uses a master and agents on the individual systems. It can be used to manage the following aspects of the system

  • Configuration
    • O/S
    • File Systems
    • Database
    • Application
  • Landscape documentation and discovery
  • Deployment and build

Whilst I was at lunch I had the most eye-opening conversation with a systems admin at an e-Commerce firm, this is a paraphrased conversation

Random guy at lunch – ” So how many hosts do you manage with Puppet”

Me – ” Actually I am just starting out with Puppet, what are you using it for”

” Well we use it for landscape management of around 400 servers”

“That’s pretty chunky, how many people?”

“There’s 7 of us in the team”

“Seriously?”

“Oh yes, we have automated lots of functions, and we’re pretty stable now, but enhancement and improvements”

“There’s only 4 of you, how does that translate into a workload”

“Well we have great monitoring and deployment tools – if we hit an issue on an application server, instead of spending 2 days troubleshooting it, we just run a script and rebuild it with the latest stable build, same thing if we need a new server”

“I like that idea, if we need another application server, we have a lot of hoops to jump through in many places.”

“Well forget that, how long would it take to build once you have the tin?”

“Without change approval, it would take a day or two of a person doing the O/S install up to application level manually”

” No automation, everything is done manually?

” Yep, pretty much”

“That sucks, as far as I am concerned, my job is to nearly put myself out of a job”

In that single conversation, I realised how far behind the curve many SAP customers are – it was a disappointing realisation.

We exist in the world of Enterprise software, there is a Twitter hashtag #ENSW which many SAP people contribute to, but I have detected an undercurrent of ‘these technologies exist in the Web world which is not really enterprise class or they do not run the business in the way SAP does’. Let me answer that, perhaps perceived, slight – these technologies are used by companies like Google, Amazon, RackSpace, they ARE enterprise class and they do run businesses in flexible/agile ways that SAP landscapes find difficult to match, why that is anyone’s guess.

My challenge to my sapadmin and devops brothers and sisters, at the risk of mixing up my metaphors – lets get outside of our SAP sandbox and cross pollinate from other areas of IT. SAP is evolving into an incredibly open platform which can be extended functionally to enhance business processes – why not administration processes.

What do you think – leave a comment

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Martin English

    Hi Chris,

      I don’t know if you’ve seen this, from Hugh Macleod of GapingVoid fame, before.

    I think the evil bunny appeals to me πŸ˜†   Anyway, I’ve tried to use it as a combo ‘cube grenade / guiding principle’ ever since I first saw it (4 or 5 years ago ?). In short, if  the business decides they can find someone who does our job faster or more efficiently or cheaper (i.e. ‘better’, and guess who defines ‘better’ …), they have no obligation to support (i.e. employ or pay) us. In fact, whether or not the business holds you accountable, you owe it to them (and your bank account) to push forward where you can…

    Unfortunately, sometimes you’re dealing with a major culture issue, rather than individuals. For example, I know of at least one large-scale site (running ERP / BW / CRM / SRM / Portal / PI, with plans to go BW on HANA by july next year…) where CTS approvals are still manged on paper forms (apparently the ‘auditors insist on it’ !!).

    One of the challenges is that while you can automate and streamline your processes in a stealth mode, once you start touching on anything done outside your team, even within the IT department, you need to become a salesperson. Sometimes this is just a matter of educating people, but other times you are dealing with a real disconnect between ‘the speed of the process’ (5 business days for the internal team to provide a virtualised server) and today’s reality (logon to amazon web services or rackspace or ninefold or lots of others and hit ‘start instance’).

    I’d love to hear about or from any ‘enterprisey’ IT people who have been able to break through that disconnect, and how they did it.

    thanks

    (0) 
  2. Emmanuel Rousselle

    Really interesting post πŸ™‚ .

    I recently looked at Puppet as a possible way to reduce the burden to deploy and manage SAP systems where I work. My experience is that for new projects SAP is often viewed as an expensive proposition or taking too long to implement. It means that alternative platforms are chosen instead of SAP. I was interested to see how Puppet could be used to speed the deployment of new SAP environments, and facilitate operations once in production.

    During that process I found that it was difficult to get to the information about what the platform exposes to make “SAP devops” possible (automating deployment, etc.). The preferred tool to manage SAP systems is Solution Manager or SAP LVM, and if you want to “roll your own solution” little is there to help you build something rock-solid within a reasonable amount of time.

    I have been involved in the implementation of Solution Manager 7.1 and while it’s an improvement over 7.0, we did not find that it was a tool that would make a huge productivity difference for Basis work. It also doesn’t address the provisioning side of things, for that you would have to use LVM for a partial solution (which is yet another landscape to maintain).

    So while Solution Manager and LVM have improved and cover some of the needs to make productivity gains in provisioning and operations of SAP systems, they are not sufficient to support a “devops” approach. And the Basis technical information that would be required to build a production-grade in-house solution to complement SolMan and/or LVM is hard to find or doesn’t exists.

    As a consequence it is hard to compete with platforms that can fully leverage devops tools like Puppet.

    To get out of this situation SAP would need to be a lot more transparent about the tools available to enable “SAP devops” and accept that SolMan and/or LVM will never be able to fill all the needs of a devops approach. Tools used for installation or support packs could also be adapted to better support a “lights-out” approach.

    As for the “selling” of a devops approach, if you can demonstrate with hard facts that you were able to automate and streamline tasks without the need of huge resources, management will buy-in.

    (0) 
    1. Martin English

      Emmanuel Rousselle wrote:

      So while Solution Manager and LVM have improved and cover some of the needs to make productivity gains in provisioning and operations of SAP systems, they are not sufficient to support a “devops” approach. And the Basis technical information that would be required to build a production-grade in-house solution to complement SolMan and/or LVM is hard to find or doesn’t exists.

      As a consequence it is hard to compete with platforms that can fully leverage devops tools like Puppet.

      To get out of this situation SAP would need to be a lot more transparent about the tools available to enable “SAP devops” and accept that SolMan and/or LVM will never be able to fill all the needs of a devops approach. Tools used for installation or support packs could also be adapted to better support a “lights-out” approach.

      As for the “selling” of a devops approach, if you can demonstrate with hard facts that you were able to automate and streamline tasks without the need of huge resources, management will buy-in.

                         

      Agree completely with this – For comparison, SAP may be the core business functionality, but even in a complex environment you’re “only” looking after a hundred or so servers. By comparison, your entire infrastructure will typically comprise hundreds more servers. Since Solution Manager as a complete IT management solution doesn’t cut it outside SAP systems, it is not taken seriously by the infrastructure teams.

      The answer is to open Solution manager up via API or REST, so that products like Puppet (for devops), BMC Patrol (for monitoring / measuring) can read and write to Solution Manager.

      hth

      (0) 
      1. Emmanuel Rousselle

        Martin English wrote:

        The answer is to open Solution manager up via API or REST, so that products like Puppet (for devops), BMC Patrol (for monitoring / measuring) can read and write to Solution Manager.

        Providing a standard API access to SAP tools that can be used in landscape management is an excellent idea.

        A standard REST API (defined as HTTP/HTTPS+JSON) would go a long way to enable the “devopsification” of SAP. It would have to cover:

        • Solution Manager (including the Transport mechanism, after all devops is used to enable continuous integration and deployment)
        • SLD
        • The SAP host agent and startsapsrv (they already have a SOAP interface, but for consistency sake and simplify maintenance, a standard REST API would be needed)

        I’d also say that SAP should resist going against the flow. I can already see the company using ODATA for this type of REST API. The problem is that ODATA may be an “open protocol” but it is very much just a Microsoft + SAP play with poor support outside of these communities and is very likely to stay that way. Across the Web, REST API means HTTP(S)+JSON, which has its drawbacks, but so does ODATA.

        It goes without saying but complete, up-to-date and accessible documentation is necessary for those APIs to succeed.

        (0) 

Leave a Reply