When we started our first meeting with one of the customers, two IT persons were on it. When it was decided - we go for a cloud, true satisfaction was expressed on their faces - At last, we give up all this maintenance burden to someone else.
It was just a beginning...
Clearly, main benefit of moving out the server from the office supposed to be a maintenance. IT staff no longer need to do anything they usually do to service the instance. Which is what:
- Hardware Maintenance and Repair
- Power Supply - stable of course
- Internet bandwidth to the server
- Security of the hardware
- Protection from external attacks
- Application Maintenance (upgrades, fixes etc.)
When we actually deployed the server on the cloud, Azure cloud, more challenges appeared.
Issue Number One. Performance.
When you have a server box, you know how many CPUs are there and literally how much time it takes to add 2 plus 2. And anytime you try to add 2+2 it will always take the same time to get a result, we are expecting some consistency, right.
But when we are on the cloud, especially on Azure, mechanics of this one is such that it uses Virtual Machines, without assurance on performance consistency.
Here is what Azure team states:
"At the present time the SQL Azure Service Level Agreement guarantees Uptime Service Levels but does not guarantee Performance Service Levels, for example the Service Level Agreement does not contain any provision that guarantees a certain level of throughput or ability to accommodate any particular level of workload. ....“At this time, although there are availability guarantees with SQL Azure, there are no performance guarantees. Part of the reason for this is the multitenant problem: many subscribers with their own SQL Azure databases share the same instance of SQL Server and the same computer, and it is impossible to predict the workload that each subscriber’s connections will be requesting.”"
You see, the server, hardware server, sitting on that cloud, don't forget cloud is actually a data center on the ground, well, that server, is hosting many virtual machines, and not always we have a luxury to know how many as it is defined by the cloud provider. Then, what happens when all these users or "Guests" are starting to do something with the CPU or hard drive on that hardware server, well obviously it gets slow. So we can not expect the same time for execution of our statement at any point of time. This is terrible thing, especially for ERP, where end users expect low latency on response and constant performance characteristics.
Issue Number Two. Backups.
Cloud does not allow to make a backup neither for the server itself - bare metal backup, simply because the servers on cloud are clustered and backed up in a special way, and if failed will be restored by provider. But most importantly - we can not make a backup of a Database. By design. The reason mentioned by cloud architects was - if we allowed it, most of the Internet traffic will be eaten by those backups transferred from the cloud to client premise, therefore we restrict the backup, by design. The only way to "backup" database was running a script that will copy all the tables to remote database. It was not a backup but rather copying the information in different format. Well the idea of backup is to keep a file, just in case if user enters something wrong we can restore the backup and problem will be settled. Cloud do not have it.
Issue Number Three. Men in Black (i.e. Internal Audit)
That was the most weird issue I ever had in my ERP implementation life.
When Internal Audit came and heard about the cloud - they started asking questions.
Can we see the server, where is it? - No you can not it is on secured premises and Microsoft does not allow anyone to come to their data centers.
Does it comply with special requirements for hosting - We can't know that as Microsoft does not provide any documentation on that.
How secure is the data center, can we check - No you can not, we do not even know the exact address of MS hosting centre.
What happen if server crash? - Well its not on premise server, its on the cloud, meaning its clustered it can't crash, even if the whole cluster crashes they have a backup and will restore it.
Who provides SLA and what is the up time - Here we have SLA from Microsoft, seemed to be OK.
Do you have a mirror server to run in case main one dies - We can have one but it will cost double as it must sit on the cloud - see post about the backup - we can not keep server on premise because its a cloud one so we have to pay twice for the cloud mirror.
How protected is the access to the server - Well it uses HTTPS so its protected
Can it be hacked - well everything can be hacked, but it is extremely difficult to do.
Plus lot of standard questions they ask even about on-premise installation.
It all makes me thinking that the main stopper for the cloud systems now is not a user any more. User wants to get rid of the hardware, move it to the cloud. But rather, old fashioned audit rules that were created to be satisfied by on-premise requirements, and yet to be adjusted to cloud reality of today.
All the best,
Sergey.
No comments:
Post a Comment