SAP has certified the Amazon Web Services cloud as a suitable platform for running production instances of some products. The Amazon cloud is probably the most well known of the Infrastructure as a Service cloud vendors. Before making any sizing decisons or or decisons regarding using AWS for SAP systems, please check the latest version of the Operating SAP Solutions on AWS White Paper (PDF).  This details the special considerations for SAP Systems on AWS, including some Operating System restrictions.

However, there are some other caveats and gotchas that you need to be aware of before putting any system (SAP or otherwise – even your Development, Testing or QA instances, let alone Production instances) in any cloud environment. It is sometimes tempting, even at a very high-level, to think of cloud based infrastructure as a form of what used to be called remote computing, where the datacenter is located some distance from the users, administrators and developers, just much cheaper to use and much quicker to provision. For most parts of an SAP implementation, this does hold true; users connect via NWBC, a browser or the
SAP GUI to a DNS name, and manipulate the information they find – they add to it, update it, share it, regardless of where it’s stored and the computer(s) used to perform the work.

However, this does avoid a key concept of Cloud computing which the idea of commodity virtualisation of everything. So, bearing this in mind, let’s explore some important lessons about Cloud Computing.

Lesson 0: Only the paranoid survive

Andrew Grove was chairman of Intel when he published a business book called ‘Only the Paranoid Survive’. It sounds like an awfully cold way to deal with business colleagues, but when it comes to down to me and the computers, it has been a useful one.

Lesson 1: SLAs Are Meaningless

You can’t compare any kind of hosting services based on their advertised SLAs. Instead, base your comparisons on their response to you and your company’s issues. Regardless of what they say, ‘stuff’ will happen. Yes, Amazon has a service level agreement for EC2 of 99.95% uptime, averaged over the last year. You would imagine that this was set (by Amazon) based on historical information. However, as they say in the financial pages “historical behaviour is not an indicator of future performance”. And when ‘stuff’ happens, where are you in the queue, for personal attention, recompense, or even just a communication of some sort ?

By the way, due mainly to the recent outage, EC2′s uptime over the last year is around 99.5%.

Lesson 2: YOUR Architecture CAN save You from Cloud Failures, but …

Disaster Recovery processes have two major SLAs; the Recovery Time Objective, which is a duration of time (an SLA, really) within which a business process must be restored after a disaster (or disruption), and the Recovery Point Objective which describes the acceptable amount of data loss measured in time. By the way, the O stands for Objective, not Agreement or Mandate (see Lesson 1).

This means that if an instance becomes unavailable to the business, they want a working system within the RPO time, with data loss of less than the RTO. This requires the same thinking and planning that goes into Disaster Recovery planning for an in house system. In turn, this means managing and planning for Disaster Recovery and Data Security, and allowing for the typical requirements of a Disaster Recovery Plan, except with a Cloud twist to them…

• You still need to choose the right infrastructure,
  i.e. Does your vendor have seperate physical locations ?
• You need to manage your view of the infrastructure,
  i.e. How easy is it to transfer backups from one physical location to another ?
• You still need to test the transfer of backup data,
• You still need to test the restore / restart of your system in the alternate location,
• Your vendor may provide alternate physical locations,
  but do you have / need an alternate provider ?
• and so on.

Lesson 3: There is a BIG difference between virtual machines and the hardware.

Things get a little more difficult at the micro level. Fault-tolerant environments are a centerpiece of the cloud hype, but generally, most developers don’t see, and therefore don’t think, about the difference between virtual and physical hardware. The issue with virtual machines (in-house virtualisation or clouds) is that the view from the operating system ends at the hypervisor. You can not see what happens at the metal. Now, for computer systems to work as we have grown to expect, certain things are sacrosanct. This is because without them, there is no guarantee that what we write will be there when we go to read it (this applies just as much to memory as it does to disk).

An example is the sync() or fsync() system call, that instructs the Operating System to write all the data currently in the filesystem buffers, out to disk. Now, in virtual machines, whether or not fsync() does what it should is a bit of a mystery. In fact, there has been suggestions that in particular circumstances and under high load Amazon’s Elastic Block Store, at least according to sources close to Reddit, will happily accept calls to fsync(), saying that the data has been written to disk, when it may not have been.

No amount of virtual architecture is going to save you from virtual hardware that lies.

Lesson 4: You don’t HAVE to put ANYTHING in the cloud.

The general rule is that if the machine / image dies, then you must be able to recover data, or restore the service. If you’re hosting a database server, then it will need to be restored or recovered. On the other hand, an application server is much simpler; just write some configuration files. Once you start looking at it like this, it may make sense for a more risk adverse site to put some server types into the cloud and leave others in the data centre. In short, Virtualisation and Cloud computing is not a universal panacea to hardware resource problems.

Of course, many people would say that “commodity” computing is a misnomer, because servers are not really something that should be commoditized, that a “pick one of four sizes” offering is insulting. To a certain extent this is true, but Cloud computing servers are so cheap that you can build around inefficiencies in some parts of the commodity offering by overcompensating in others.

For example, once people realise how cheap CPU and Memory are on IaaS services, they tend to go at least one ‘size’ higher than they would for an in-house server, and they still see massive savings. Regardless of what the purist thinks, it is becoming much more business-efficient to throw hardware at performance problems than it is to spend time investigating the root cause, which leads into …..

Lesson 5: You still need to tune and manage your systems.

In Cloud computing costs are tied directly to resource usage. The virtues of cloud computing are a double edged-sword; Because
provisioning systems is so easy, you may see developers running a dozen tests at once, instead of one after another, to speed up implementation cycles. This means any inefficiencies in the base systems used for such
testing will be magnified, which will directly impact costs.

Just as importantly, resource usage variations in your production systems will show up directly in the bill. However, the customer or business user paying the bill will want to know why these variations have occured. Are they due to different processing rules, different volumes,
program or system changes ? You want to see a consistent relationship
between the business workload and the resource usage (and therefore
cost). This makes budgeting and planning much easier for the Business,
and provides them with confidence in both the SAP support teams and the
platform.

Lesson 6: It is not enough to be secure….

…you need to be seen to be secure. Amazon already performs regular scans of the AWS entry points, and independent security firms perform regular external vulnerability threat assessments, but these are checks of the AWS infrastructure (such as their payment gateways, user security and so on). They don’t replace your own vulnerability scans and penetration tests. Because it may be mistaken as a network attack, Amazon ask to be advised of any penetration tests you wish to perform.  These must be limited to your own instances.

Being seen to be secure also means using all the features (including the Amazon Virtual Private Cloud) that are referenced in the AWS Security White Paper. This document, which is updated regularly, describes Amazon’s physical and operational security principles and practices.
It includes a description of the shared responsibility for security, a
summary of their control environment, a review of secure design
principles, and detailed information about the security and backup
considerations related to each part of AWS including the Virtual Private
Cloud, EC2, and the Simple Storage Service,

The new AWS Risk and Compliance White Paper
covers a number of important topics including (again) the shared
responsibility model, additional information about the control
environment and how to evaluate it, and detailed information about the AWS
certifications. Importantly, it also includes a section on key compliance
issues which addresses a number of topics that get asked about on a
regular basis.

Summary

There are differences between managing real servers, virtual servers and Cloud based servers. However, much of what is required for SAP landscapes and Implementations is the same which ever platform you use. In fact the BASIS team may be the only people who notice the difference. One of the biggest differences is the perception of control and ownership, because you can’t “hug your server” any more. What are the biggest differences you see, and how do you see them impacting you if or when your organisation starts implementing SAP systems in the Amazon Cloud ?

I recently came across an interesting article on SAP’s SME Solutions – A Guide to the Product Portfolio. It breaks down the four SAP products for SME products by size, functionality, industry coverage, deployment options and cost of ownership.

The most important point the post makes is that there exists a range of SMEs, and that a one-size software solution does not fit all. This leads to some further points worth noting.

The smaller the SME, the less likely they are to adopt complex technology. While there is movement to Linux and open source ERPs (because of the TCO perceptions), when they do get into technology, they tend to select Microsoft platforms (e.g. .Net, SQL Server).

Because of TCO concerns, the smaller SMEs were the first to adopt software as a service (SaaS), and that model continues to gain traction within the SME market. The implication is that any SME strategy must include a SaaS strategy.

Given that its a blog post, the article does a good job of detailing the four SAP products that resulted from the new SME Strategy, albeit at a high-level view. While it won’t answer all your questions, it will give you a good starting point, especially about costs and appropriate products, for your conversation with SAP or your implementation partner,

Now, I may be biased, but I had to start off with this quote from Jon Reed

Before I get to the videos, I want to say that Basis is one of the most neglected areas in terms of SAP career content. Even on SDN, there are way more conversations and forums on development than Basis. This is too bad, as the Basis/NetWeaver Admin role is a vital one to most projects.

No one else is managing your career or your future. If you want more control and choice over where you work and what you do, I recommend you read Jon Reed’s latest career advice and career trends. Jon is an SAP Mentor and his name is probably familiar to you already through his SCN blogs and ASUG and Sapphire presentations. He’s got about 15 years experience in analyzing the SAP career market, and he has worked in SAP recruitment. This all adds up to someone who knows what the SAP job market is looking for, and what makes some candidates more marketable than others.

The white papers Jon created are

• SAP Career Outlook 2010 – Part One: Creating a Winning SAP Skills Strategy for 2010, and
• SAP Career Outlook 2010 – Part Two: Beyond the Social Networking Hype: Achieving SAP Career Visibility

You can also access the white paper on Jon Reed’s website.

However, one thing you will notice is that these particular whitepapers emphasise the functional and developer career paths; there is not much reference to the BASIS or Netweaver Technical Consultant career path. Jon identified this himself in another post, this time on his web site, What is the SAP Career Path for Basis Administrators – NetWeaver Engineers?. He has taken a presentation on the career path for Basis-NetWeaver prosby SAP Mentor Tony de Thomasis of Australia Post (based in part on Jon’s earlier work referred to above) and taped four commentary tracks through Tony’s Prezi slides.

…. just resting on our laurels isn’t going to cut it in this economy – “stronger measures” are required. Part four gave me a chance to share my views on the content as a whole, and why it’s so important to find an SAP career path that combines skills marketability with a passionate, or even soulful, angle.

I used to say I was in BASIS (which is why this blog was called basissap.com). However, many people seem to see this as being restricted to R3 ABAP Administration, with perhaps some particular combination of OS and DBMS skills. Nowadays, regardless of the platform your SAP system(s) run on, BASIS Administrators / Netweaver Engineers need knowledge of their site’s OS / DBMS combination, good windows server administration skills (for managing your TREX, and possibly EP, systems), maxdb knowledge (for your SRM system), etc etc.

With all these skill requirement, possibly including other duties as well (depending on the size of your environment), how do you avoid being jack of all trades and master of none ?

For your own sake, you pick two (maybe three) Core Skills in BASIS or Netweaver and become the local guru in those. This provides security of employment; in other words, you know enough about the SAP core to be valuable to both your current employer, and future employers.

Pick another couple of areas that interest you, but aren’t crucial to your organisation (at least, not yet). Jon refers to these as Edge Skills. They should be skills that are on the horizon, either within the SAP ecosystem, or your organisation. These are the skills that will make you employable in the future.

But what about all the other areas ? In one of my previous incarnations, I was an MVS Systems Programmer. The most important thing I learnt was how to use the manuals (they weren’t online when I started). A key part of this was my own notes – Knowing where to find the official answer or process isn’t always enough, you need to get it working, and sometimes you only perform the process once every couple of years or so, and it is difficult to remember exactly how it works from time to time.

Keeping records of what works and what doesn’t work, especially in relation to your own environment, gives you an edge on those who don’t, and of course, it is nice to know what the real process is (as opposed to what the books say !!).

A word of advice here; do not horde your documentation or knowledge –

• its hard to get moved to the exciting new project if you’re irreplaceable, and
• after all, you’re getting paid to support and help.

It also identifies you as someone who will help, who will answer questions about (or can find out) what really works.

Another way of finding out stuff is experimenting with your own system; an SAP preview system, or one of the New Community Developer Systems. These systems, well removed from the semi production status of the ‘real’ Development and Testing systems, provide scope for you to experiment and develop ideas into implementable services. This identifies you as someone who can bring real value to the SAP Environment, the IT organisation, and your employer in general.

SAP have detected a problem in the spool area which affects all customers in the world regardless of the SAP release and any support package level.

As soon as the retention time of a spool request exceeds 2009/12/31 a wrong date 2100/01/01 is entered during creation of the spool request. As a consequence these spool requests will not be deleted anymore from the spool reorg jobs. Using the default retention period this affects all spool requests on each SAP system in the world created since 2009/12/23.

OSS Note 1422843 already contains the correction instructions and the relevant kernel patches for 3.1 –> 46B (one patch) and 46c –> 7.xx (another patch). There’s nothing for anyone (unfortunate enough to be) running any of the original 2.x systems yet.

It is a little ironic – An old friend and I were discussing Y2K and all that in a general “what were you doing ten years ago ?” manner on New Years Eve. Should I tell her that SAP had a Y2K+10 ?

Dennnis Howlett has covered the implications for PWC (the auditor) in the Satyam fraud . However, I have included his list of links if you want a quick background :

• Satyam Shares Plunge on Scandal
• Satyam chairman resigns amid accounting scandal
• Computer Head Admits to Faking Profits
• Fraud revelations hit Indian computer company
• Satyam accounting scandal could be ‘India’s Enron’
• Fraud revelations hit Indian computer giant

However, what are the implications for the Indian outsourcing industry, SAP in particular. Satyam, like all other outsourcing companies, lives and dies by the quality of its people. Right, now those people are thinking they should move on, before they’re laid off. Satyam’s customers know this and will be getting nervous. If they’re smart, and the logistics make sense, they may even be looking to hire the Satyam people direct.

From Satyam’s perspective, this makes an already difficult position almost untenable. Some people consider that Satyam is unsaleable in its current condition. If it does get sold, expect them to be snapped up at fire sale prices.

More immeadiately, what contingency plans do existing Satyam customers have in place ? Is this an opportunity, in the US and Europe at least, for more familiar names to claw back some business ? IBM, Accenture and CSC all have the cost saving benefits of a global workforce, but also have the perceived benefit of a ‘local’ name.

But what does this mean for the Indian outsourcing industry in general ? My experience is that, even before this episode, customers need far better levels of oversight over both their vendors financial robustness, and the processes governing work quality.

Questions will be asked about the ability of the ultimate provider of services to deliver according to SLAs (both financial and quality), and what is being done by the outsourcer and / or the ultimate provider to enforce financial and QA criteria, given the attention now being focused on this area.

As India’s Enron unfolds, more questions will arise.