BI Server on AWS?

[Quentin]

Hi All,

I'm in a bit over my head (I'm a developer, not an admin), but recently started thinking about the possibility of hosting a SAS BI server on Amazon public cloud.  Is anyone doing this?  (I have seen some posts about VA, but haven't seen EBI mentioned much).  e.g. SAS Cloud, Deploy SAS Software in the Cloud | SAS

So what would that mean?  Instead of buying our own Linux server(s) and dealing with hardware upgrades/scaling/backups/etc we would rent space on AWS?  Then we would license the same (similar) SAS from SAS, and install EBI logical servers on the Amazon cloud?  And after that from a developer point of view connecting a SAS client (EG/SMC/DI Studio) to a SAS server in Amazon's cloud would feel the same as connecting to a SAS server sitting downstairs in our server farm?  And I suppose if we were dealing with medium size data, we would also put some database on AWS as well (SQL server perhaps, if don't need BIG data), so that data and analytics were close together?

Just wondering if folks have done that with BI server, and if it is worth thinking through.  If the costs are comparable (SAS licensing costs and infrastructure costs), seems like life might be a bit easier to let Amazon deal with maintaining the physical severs, scaling storage/computing power when needed, etc.

Thoughts?  Or references to UG papers/presentations/white papers that go beyond marketing?

Thanks!

--Q.

[Kurt_Bremser]

Ask SAS about the licensing. Then start to worry about the technical problems. Don't be surprised if SAS asks a boatload of $$$ or simply njets your proposal.

And:

Your data will reside anywhere (physically). Your data may contain delicate information about customers, suppliers, etc. You may be prevented by law to put such data anywhere else but your own internal servers.

[jakarman]

Theoretical it could be done, call it something as running SAS as SAAS.

The machine costs are not the biggest problem either in house or in the cloud is not making any difference.

In a cloud you have to think about multi-tenancy segregation of duties backup and recovery etc. This part is the one causing all kind of issues with in house solutions because the SAS approach is not aligned with standard IT approaches. This will only cause more issues with an cloud approach as that one is needed to follow far more standardized working methods.

The LAMP stack with WEB-services is success for that reason. Still they have a lot problems (data leakages companies blackouts)

When something started like that, It could be done for learning purposes with all kind of tools first.
If successful going to check if possible for SMB and further.

As Kurt indicated the dependency of SAS is the first big hurdle to take. Licensing and more as a data processing partner is doing a company startup with all legal affairs.

Yes I have been thinking on that to do ...

[Quentin]

Thanks to you both for responses.

I have seen interesting discussions about the data privacy concerns, where there are now use cases on AWS of health care companies storing HIPAA Protected Health Information  on AWS. (see  http://aws.amazon.com/compliance/  ) If the security/encryption is in place for AWS is the same (or better) than the security/encryption for a company's internal servers, then I think this issue is solved.  Have seen people argue that AWS is more secure than many companies' internal data centers.  In fact, where many large companies already sub-contract physical server management to an IT provider, they already have a situation where the important thing between the company and the contractor is the service-level agreement / contract and level of security the contractor provides. So contracting with AWS as a server provider might not be different than contracting with a local server provider (I hope).

Would be interesting to try the licensing discussion with SAS.  Clearly from the link, they have been selling the SAS cloud as an alternative for quite some time.  And now it seems they are supporting companies to host their company SAS servers (at least VA) on the Amazon Cloud, instead of their own hardware.  I would hope the license would be similar (I have never talked $$ with SAS, happily).  That is, the intent is not become a data processing partner and make my company SAS license available to others.  It is simply to say "I want to continue running SAS EBI in my company for the same reasons we have been for X years, but I want to get rid of all the hardware and associated infrastructure / maintenance /scalability costs of hardware and maybe OS."  (Of course, "get rid of the costs" means pass them on to Amazon, if it turns out they can do it better/cheaper/etc.).

--Q.

[Mark_sas]

Support for running SAS software on public cloud infrastructure like AWS falls under SAS Product Support for Virtualization Environments.  Customers have indeed deployed EBI and many other SAS products in AWS.  In the case of AWS, SAS issues Amazon-specific license files, but they are in the standard SID format.

Care should be taken in selecting the instance types chosen for hosting SAS in the cloud.  As with physical hardware, your instances must fulfill the system requirements associated with the product(s) you're deploying.  This includes CPU, memory, and disk space.

Quentin, as you say, there are several other factors like industry compliance and geographic location of data which should also be considered when deploying in the cloud.

[jakarman]

Quentin, always do the reading carefully and understand the topic.  What AWS (Jeff Bezos) is saying there: "AWS also offers a HIPAA-focused whitepaper for customers interested in learning more about how they can leverage AWS for the processing and storage of health information."

This one is telling AWS can deliver the hardware but someone, not AWS, should do the real implementation of a service provider that is SAS-SAAS. That part is not included!    

In the wole list you did not see the ISO27002 being mentioned, that one is the follow up of ISO27001 and the 2 is having the real interesting ones.

At juans proposal I started a collection at: https://communities.sas.com/message/236658#236658 having that link of  ISO/IEC 27002 code of practicehttp://www.iso27001security.com/html/27002.html it are just the headers.But what is mentioned your CEO and net Jeff is responsible for completing this. You cannot get dropped your accountability four your data processing. That may be disappointing as it this part that is that problematic. 

Do you think they are all time up? Look at the outages: Amazon Web Services - Wikipedia, the free encyclopedia The simple approach by AWS is that  they are nor responsible dor all effect on those. You should have done a better design for you service with a spread on several datacenters.

Something going out of control? It still your problem to deal not of that AWS. AWS console breach leads to demise of service with “proven” backup plan | Ars Technica that is how they went out of businesses.

You can check your responsibilities with HIPAA at: Summary of the HIPAA Security Rule (yes it keeps in yours!!)
By the way: I thought you had a good relationship with your IT-staff?

By the way: cheap fast good  (quality) you cannot have all of them at the same time, which one(s) are you going to drop?  

[Quentin]

Thanks again, Jaap.

I realized I pointed to the AWS marketing info.  But was prompted only recently to look into AWS when someone posted that at their recent AWS conference (yes, also marketing), big health care companies presented and said "We are putting HIPAA-regulated PHI data on AWS, because we were able to meet all of the requirements for protecting this data..."  Of course the CEO / legal / regulatory is always responsible for company PHI, not Jeff.  But it makes sense for the CEO to ask "Is it worth it to us to store data on site, in a networked server that we are responsible for maintaining the security, or pay Jeff to do it?".

Of course AWS is not 100% up time, and not hack-proof.  But neither are a company's local servers.  (I suppose once I worked in a company with a dedicated PC safe room  for secure data that had drives in a safe and  no network collection.....)  So we should not compare AWS to a "straw man" of a perfect local server environment.  Could AWS provide better security, better uptime? Equivalent?  Perhaps for some companies.

I remember saying I had a good relationship with SAS Admin. : )   As SAS sits on top of an OS, so does my SAS Admin sit on top of IT staff.     (But in truth, I am lucky to have good IT folks too).

Honestly, the main benefit I am dreaming of from AWS would be quick start up time and quick scalability.    Even though I'm not working with  Big Data now, the idea of having a virtual infrastructure of even just SQL Server and SAS BI which could be quickly scaled according to the needs of projects (and cloned, and distributed on servers around the globe, and...)  is very appealing.   Or you just decide to grow the company's data center(s) so it can support all these virtual machines.  And then you are saying "My company can manage a global server farm better than Amazon" (which may be true at some companies, but probably not all.).

Between cheap, fast (meaning fast start up time and fast scalability), and good, I will happily drop cheap.  I would happily pay for the agility that is promised by cloud infrastructure.

All that said, I'm about 1 week into thinking about cloud.   So please take all of this as just friendly 'net chat.  I'm aware that I know very little, and am describing what I hope cloud SAS might mean for me.  And also, as always, my perspective is that of a developer who likes the *promise* of easy scalability, rather than as an admin or CEO or legal or anybody who is actually involved in making such decisions (and therefore knowledgeable about domain).

Thanks,

-Q.

[Reeza]

I'd be interested in knowing the SAS licensing and the 'scalability' part.

Part of how SAS licenses its server products is by cores/size so I don't know if changing your instances will be that easy.

[jakarman]

Quentin, your answer is one that I am fully in agreement. The way of thinking on advantages and disadvantages leaving the marketing stuff out is the way to go.

I am taking it all as a friendly net chat, what else is life about.  Apologies when you get an other impression.

(Yep, I can be stubborn and heated when felt hurt, not understood, convinced being right.)  

If your are too small for a decent data-center than going fo co-location with managed services at some level is most likely a good option.

Don't forget your IT staff as you will need them even more with that situation. Service management is adding new work with some overhead at both sides.

Going into the cloud is also thinking on multi-tenancy  (shared resources).  A thread can be nice when getting feed-back.

Got one from kevind referring to: http://support.sas.com/resources/papers/proceedings14/SAS289-2014.pdf . That is also a nice one for you although very technical.

" Sharing hardware offers the possibility of lowering the total cost of ownership by sharing resources to increase overall utilization throughout the business day, rather than sizing three discrete environments to meet their respective peak demands, which might be underutilized during part of the business day."

It is the business model for the cloud. For some reason most companies are claiming this goal but are really doing the opposite. Seen virtualization of the OS becoming a goal on his own and people claiming for having rolled out 7000 virtual servers as a success in a banking as core business. In the same time having problems with release management of the running applications (outdated).  

It would always go for a root-cause analyses.

The roll-out of UE is a big success 100.000 downloads deployments. The mentioned paper of  Ken Gahagan is also showing the options to scaling out in several directions as success factor. That way of thinking is however not the normal conducted approach. SAS is sold as needed to run on a single machine for a single application and being installed by a wizard (SDW) maybe causing more problems as it solving. Yes you can do your sales-marketing as types setup or call us for doing that. Degrading the local IT staff to some kind of simian and ignoring all kind business requirements and regulations.  It that is the root-cause it won help to Jeff for solving that in contrary.  

Looking  at all technical stuff it could be that faster for delivery. A more complicated first roll-out is very well acceptable as long you can replicated that easy to other machines.

Cloning (several locations) or with using added grid nodes should be not lasting more as a day (several hours).

Adding an application server the same it should not last more as a day.

Than the most work will go into discussions on need/profit instead of planning and projects of many months.    

Needing more hardware resources is one of those ones within those discussion. With common of the shelf hardware that should be able to be delivered quickly.
The issue you are describing as gone to history.    

[jakarman]

Reeza,  Licensing is an interesting topic. I had some not pretty experiences on this area and with that seen some contracts.

There are 10 situations for are supplier/customer relationship, those are:

- win/win  This is instable equilibrum needing active maintenance. Mechanical equilibrium - Wikipedia, the free encyclopedia

- loose/loose   That is a stable equilibrium. No Sales continiuation of licenses and no profits of using good toolings.

The other two win/lose lose/win are temporary ones shifting to either one of the previous ones. Fraudaleus license usage and overasking prices / selling wrong products will not last for long. The scalability question and licensing is one of negotiations trust  and evaluations.

SAS is not clear on their cost/licenses and contracts. The only mentioned one is SAS/PC, Order SAS® Software: Order Form (renewal at : Buy SAS® Software: Frequently Asked Questions). For all others options they are referring to "contact SAS sales". This is different with other suppliers like Revolution Analytics Alterix several Hadoop suppliers, you can find a pricelist. Still you can negotiate when you are powerful enough as customer.  This approach is on the bad part of SAS habits as mentioned by Gartner and others. It is the same argument as that R-discussion (no license costs, for free).  Going for a SAS SAAS provision you should go for a partner program. Become a Partner | SAS. There you can find: http://www.sas.com/content/dam/SAS/en_us/doc/partners/program-guide.pdf mentioning DSP and ASP. DSP's Data Service Provider and Application Service Providers are not seen as an opportunity by SAS but far more as threats. It is not being included in the MLA. By that is an obstacle for the line of cloud implementations.

For license contracts being negotiated I have seen the following:

- named users (mainly desktop oriented) with a total number. The higher the number as cheaper each one will get.

- Solutions with a total number of users. (often 10-25).The number of machines and capacity being irrelevant.

- machine capacity of the underlaying hardware of the server. This in some categories like A-Z, mostly used as based on mainframe history.

  The is/was extended to unix servers and gave issues as it is not equal to the virtualized logical capacity of the server it is presented to the users.

  = Imagine paying a 10-20 fold for license-costs of machine capacity that is not available to you. It is not only happening with SAS but with a lot of other suppliers.

     It is a penny-wise pound-foolish effect of the virtualization dogma on the OS and Iron level. 

  = Processor sub-capacity licenses where the setinit gets bound to mentioned processor-id's as set by that virtualization.

    This is strange for a multi-tier environment hyper-threading at processors, needing DR plans to be tested/evaluated.   

In US there is a third party that is handling all US government deals. Executive Information Systems, LLC. Those price of the contracts are visible.