What does SAP HANA have in common with an old car ?
UPDATE 15.05.2018
THIS BLOG IS NOW OUT OF DATE
PLEASE CHECK THIS BLOG FOR THE LATEST NEWS
Good Evening SCNers,
thought of the day, what does SAP HANA have in common with an old car ?
Let’s put it another way, what does a regular modern family car have that SAP HANA does not have ?
Read on and find out.
My first car, when I started driving it in 1990, was already thirty years old ! It could be started with a handle on the front.
The petrol gauge. We all know this from cars old and new, every car has a fuel (or petrol) gauge.
The petrol gauge, even in a new car does not do much, all the petrol gauge tells us is how much petrol we have left at any point of time.
This is how the petrol gauge looked in older cars:
and this is how the petrol gauge looks on modern cars:
In the last 60 years the car petrol gauge has not changed very much has it, it still
does the same simple task, telling the Driver (the Administrator) at any point in time how much petrol capacity is left.
In the old days, in a car with only the petrol gauge to work with, the Driver (Administrator) of the car had to use experience and knowledge to try to understand,
from the available remaining petrol(let’s call this capacity), and based upon the current driving style (let’s call this usage),
just how far could the car continue being driven until it would run out of petrol (capacity to continue) ?
And then, the Administrator (Driver) had to figure out where and when to take petrol (get more capacity), to get more petrol capacity before the car would run out of petrol. In which case the car would cease to function and the Administrator (Driver) would have to walk along the road with a can of petrol.
And this was not an uncommon sight in the past and still happens to some people today.
So what does this have to do with SAP HANA ?
In the days before the InMemory databases, if a database ran out of capacity (disk), a Unix
Administrator could just run a few commands and voila there would be more disk space, more
capacity for the database. Consequently, capacity monitoring in disk based databases was set
to generate alerts at 30% capacity remaining available, 20% capacity remaining available, 10% capacity remaining available,
with each threshold of remaining available capacity there was enough time to extend the disk space.
This is similar to cars in the 90’s giving a red light is the petrol tank was running low on fuel
as an alert for the Driver (Administrator) to take more fuel.
In the days of disk based databases we didn’t need to know so much how fast the database
was growing because we were able to add more disk capacity so easily and quickly.
Now back to SAP HANA.
In the SAP HANA world:
. capacity is Memory/RAM
. and Memory/RAM is not like disk space,Memory/RAM is made up of blocks or Server Nodes and therefore to a certain extent much more finite than Disk
. And more worryingly, extending Memory/RAM or ServerNodes is not as quick and easy as extending disk space and for ServerNodes if new ones need to be purchased can have a lead time of months !
And so in the SAP HANA world, we need to understand:
. how much remaining memory capacity we have available – the classic old fashioned car petrol gauge
. our current memory usage rate based upon historical growth patterns – how much memory are we consuming per month, gb/month
. from the above two items, for how many months at the current growth rate gb/month we can run before we run out of petrol/memory
. since we know how long it will take to add more memory capacity, either memory modules or more nodes, at what point in time do we need to trigger the order for capacity based upon the current usage, capacity left, and growth rate ?
. And then try to figure out that lot with Multiple Tenants which have different usage and growth rates
But we don’t have any tools from SAP to do this ! Yes we have the HANA 2.0 Cockpit but it is too little.
The modern car dashboard
These parameters, these days are pretty much standard equipment in modern family cars, we have:
. The petrol gauge telling us how much petrol we have left
. The analytics telling us based upon historic usage analysis of the driving style, what the current usage is in litres/100km or miles/gallon
. The predictive analytics telling us based upon the current usage style and historic consumption how far we can drive before we will run out of petrol
It looks like this:
and then, one step further, if we are really lucky we have a navigation system connected to the predictive analytics which will tell us where the next petrol station is within range of our petrol capacity:
So what does SAP HANA have in common with an old car, with SAP HANA today the Administrator is pretty much working with only the fuel gauge to understand how much available memory capacity there is in the HANA system.
We need SAP to get the SAP HANA Administrator tools to the same standard as we have come to take for granted in modern cars.
We need a dashboard which tells us:
. How much available memory capacity there is today at a Node level and across all Nodes
. What the current memory consumption rate is by Tenant, by Node and across all Nodes,based upon historical growth from the last months in GB/Month
. We need to know at the current consumption rate when Individual Nodes and across Nodes the HANA System will be out of capacity, at the current consumption rate in GB/Month, for how many more months can we run before we hit the wall
. We need to be able to tell the dashboard how long it will take to procure more capacity so that the dashboard can Alert us trigger the procurement of more capacity within time – like in the car when the car goes beep and says you need to take more fuel within 90kms
. And the cherry on the top, wouldn’t it be nice if the SAP HANA System gave us recommendations on the layout of the Tenants across the ScaleOut Server Nodes, where to put which Column and Row Stores to get the optimum utilization of the available HANA Capacity across the Nodes
. And the second cherry would be, you remember this blog about SAP HANA Tenant Mobility well imagine if the dashboard had a view of all of our Production (or whatever layer of the landscape) MDC enabled HANA Systems and could give us recommendations which Tenants to combine and host together and where based upon usage rates and growth rates, how cool would that be
To conclude:
Managing growth and capacity in the disk based database world was really easy peasy.Today in the in-memory database world managing growth and available capacity needs a lot more thought and has infact become a science.
What are we doing, we’ve developed complex Excels and are using those as our predictive analytics dashboards, because so far the tools from SAP haven’t provided what we are looking for.
Dear SAP please have a think about the above and see if it would be possible in future generations of the SAP HANA product to have these Administrator features.
Whatta you think ?
Andy.
p.s. there will be a special kudos if you can figure out which car the modern dashboard photos are taken from
Nice weblog, enjoyed the analogy.
Nice Audi Q7 by the way.
Hi Tony,
ok, you won the prize - kudos, it's the previous generation Q7 - amazing how you got that.
Andy.
I understood clearly ,about HANA basics
Nice read this 🙂 I wondered what people use to manage this issue of not knowing when these 'nodes' of memory are full, surely there has to be something in place!
Hi Mo,
that’s a great question and I’d love if other people who have the same challenges will share how they keep the capacity situation under control in this thread, we can all learn from each other
Andy.
When I saw the title "What does SAP HANA have in common with an old car" my first reaction was: "Salesmen?" 🙂 Was expecting already a comment along the lines of "that's why SAP offers Cloud, so that you don't have to worry your pretty little head about this".
My husband and I have the same model car but his is 2001 and mine 2006. Not super-new, clearly, but mine has nice "predictive analytics" that tells you not just how much fuel is left but also how many miles it is expected to last. In this way I know whether I need to take the first exit from a freeway or have a chance to make it to the favorite gas (or "petrol" lol) station where I can get 3 cents off with a loyalty card. Rather convenient and that is also why my next car will likely be the same model again.
So are you saying such tools are not available in HANA? That's a bummer...
Jelena.. I had the same reaction but clicked the link as I saw you liked the blog
Andy - thanks for the analogy. If only all Basisy type activities could be explained in such a way 🙂 I can see such apps being built and made available... for cloud platform.
I promised a comment and here, albeit super late, here it is.
The analogy you chose is nice and especially relevant to SAP products, as we have a history of loving our cars and using them in our own story-telling.
And I do agree that the problem scenario you described, is likely a common one, especially for on-prem HANA users. So, yeah, for single customer landscapes a tool like the one you describe is doable, I suppose.
What I'm wondering though, is rather if that sort of procurement really is what everyone will be doing in say 5 years time. The whole cloud offerings with DB as a service thing seems to become more and more popular.
One aspect of capacity planning that wasn't mentioned and that hasn't changed as much with HANA is that of CPU capacity and throughput. How to predict that the new product is a top-seller and your system has to cover 300% load during holiday season?
The approach of taking historic data and extrapolating into the future sort of implies that the business "tucks along". That's doable in Excel and that's about the same level you get from your car, I guess. Or does it take into account that you're driving at peak hour through a contention zone where you are likely to stop and go much more often than this morning, where you managed to catch the "green wave" and glide through?
How about telling you, whether or not it's cheaper to only put in fuel for $10 at this petrol station and then fill up for a better price 30km down the route?
Don't get me wrong, I think the assistant functionalities would be great to have.
I just think that I'd probably liked it better if I could just use capacity as I go and pay within a predefined frame.
After all, a DBMS is a commodity-like service, similar to utilities or telco services.
Hi Lars,
all good points, what I am going to say now, I say from the experience of doing SAP at Fortune 100 companies, I mean extra large SAP Landscapes, I’ve never done SAP at smaller customers.
Cloud
Cloud is the fashion, of course we all have to look at it. Some business applications only run in the Cloud, eg SuccessFactors, SAP IBP, so that’s a no brainer, those go to the Cloud.
Of the business applications, let’s stay with SAP applications for now, of the ones which can run on premise or on the cloud, where to host them ? If you’re a Fortune 100 company, with a state of the art datacenter, and in the absence of either a Cloud First, or Cloud Only strategy, and you have the choice host an application in your state of the art DC or on the Cloud which one do you go for ? If we look at the financials, from what I have seen so far SAP HEC is no cheaper than On-Premise. And in the absence of a financial advantage, since I already have the Operations, the Processes, the Teams&People, the Capacity in place on premise, why would I move an application to the Cloud if there is no commercial advantage and my company doesn’t have a strict Cloud strategy ?
Many companies either haven’t yet written their Cloud strategy, or are in the process of writing it.
A Cloud strategy will be a living organism, updated on a regular basis as things go forward and will achieve amongst other the following, set out the company’s vision for the Cloud and also at any point in time the decision matrix/process for new demands to be decided where to host them Cloud or on premise.
As most companies haven’t yet written or implemented a Cloud strategy, and in the absence of a strong CEO or CIO insisting that everything goes to the Cloud, and in the absence of the HEC offering any financial incentive which would motivate a company to move away from on-premise and implement all of the Operations and Processes for running applications in the Cloud then I don’t see a massive accelerated migration to the Cloud.
Hence yes it is nice academically to think of the database as a service in the Cloud with nothing for the customer to do or worry about, in practice there are many more dimensions at play.
Regarding CPU which correct wasn’t mentioned, because until now the CPU/Memory ratios even on premise for HANA hardware was fixed and dictated by SAP, it is a fantastic step in the journey to maturity of the HANA product that with TDI Phase 5 the customer will be able to choose the CPU/Memory ratios as communicated by Addi Brosig in the following blog
TDI Phase 5: New Opportunities for Cost Optimization of SAP HANA Hardware
On-Premise in the large customers, CPU work loads, peaks and troughs has been handled by having the Unix Teams build systems with the capability to assign resources on the fly to where it is most needed. The largest SAP customers will be running on premise SAP systems on Servers which have pools of CPU and Memory and where configurations and rules have been setup to automatically enable eg upto 300% of capacity on the fly when needed.
To wrap up, Cloud is interesting and it is on everybody’s radar, and unless we are at a company where Cloud is First or Cloud Only, then the Cloud Strategy is not a black and white question, but a business ROI etc question and currently, especially from the HEC I have not seen the ROI argument being more attractive than on premise.
Maybe that will change in the coming years and going to the Cloud will be less of a decision and strategy and more of a no brainer.
Let’s see, and when it all makes sense, then DB as a service will be nice. In the meantime we need the tools.
Andy.
p.s. to add, regarding...
The approach of taking historic data and extrapolating into the future sort of implies that the business “tucks along”.
In the Basis Team we don't have the view from the CEO's seat, and all we want to know is when to order more capacity, with Oracle it was easy just add disk, with HANA we need to buy more servers and this has lead times. Since there are many attributes which can make different Tenant DB's in different HANA systems grow at different speeds and at different times, eg BW Operations Team misses to cleanup unneeded operational data, eg the company does a merger or acquisition, etc etc then often in the Basis Team we are following without the view from the driver's seat and the more tools we can have to ensure that everything is working properly the better.