Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re:And it's gonna rain (Score 1) 83

by KingMotley (#49567011) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

Just out of curiosity, I fired up a D14 VM and loaded SQLIO on it. It came back with 253713 IOPs. If you got less than one, you were doing something very very very wrong. BTW, there is no reason to load SQL server of any type on the machine as SQLIO doesn't use it, so uh...yeah.

Did you set up a VPN to your local machine and then test how many IOPs you get to your local machine over a network share? LOL.

Comment: Re:And it's gonna rain (Score 1) 83

by KingMotley (#49566907) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

As for AWS vs Azure performance, I'm not sure how you were testing but based on your "expert" opinions which are sorely misinformed, I'm guessing you did something really boneheaded. A P3 instance is set to give a minimum of 735 IOPS every second. So if you were getting less than one, I'd say that was a problem with the user. We use Azure to run our production sites and haven't seen anything of the sort you describe.

On Azure, SQL databases can be connected to from anywhere, any IP. There is no firewall at all.

Uh, no. You have to explicitly allow IPs in. Here's a link to "Azure SQL Database Firewall": https://msdn.microsoft.com/en-...
If you don't understand firewalls, there is a pretty picture if you scroll down. The first step "SQL Database Firewell" is a server-level IP firewall. Yes, the configuration is stored in the database, but that has very little meaning, it could have been stored in a .CFG file just as easily. Unless you are about to say that IPTABLES is insecure because it needs access to the filesystem to read it's .cfg file too. The filtering isn't done in SQL, ROFLMAO.

I've never tried a D14 VM with enterprise installed, but if you were getting poor performance, I'm guessing you did something extremely boneheaded like try to put the database on a remote drive instead of the local SSD.

Comment: Re: And it's gonna rain (Score 1) 83

by KingMotley (#49566797) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

You obviously know nothing about networking or the slammer worm because it affected the discovery/locator service on port 1434, not 1433, and yes, I know networking very well, thank you.

You might as well say the next time there is an http exploit all the web servers in the world are going to get hosed. Maybe we should put all web servers behind our firewalls to be safe. LOL.

Comment: Re:And it's gonna rain (Score 1) 83

by KingMotley (#49561035) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

Staged publishing on Azure is limited to 5 slots, not 2. But you are correct, it doesn't scale out to 200 slots. However, in Azure, you pay for the first slot, the additional 4 are free, while the same isn't true in AWS.

As for SQL performance in Azure, I can't make an exact comparison, but you always have the option of running your own SQL server if you don't like the SQL Service. And even the cheapest Azure plan gets your point in time backup/restore, although the amount of time increase as you change service levels (basic - 7 days to premium - 35 days) and the cost of a P1 database is roughly half that of a single "db.m3.xlarge" instance on AWS ($465 vs $968.40), and the price gets worse from there. Multi-zoned databases on AWS are basically full cost, while on Azure (called GEO-replicas), they become cheaper. Then tack on some more if you care about provisioned IOPS (which comes free with Azure, as all tiers are allocated that way), and you've quickly turned up a huge bill for the same performance from Azure.

As for AWS RDS being the "full" version of SQL Server, I suppose that is true if you only need the functions in SQL Standard (Amazon doesn't offer enterprise). Unfortunately, we use features only available in enterprise (like being able to enlist indexed/materialized views in queries automatically), and AWS RDS service doesn't support that while Azure does -- so your "full" version is less "full" than than your "not-full" version of Azure's SQL service. Amazon's RDS is limited to 1 replica, vs 4 in Azure (we don't actually use this, yet) as well.

As for the "slammer" idea, that is quite funny, when the exact opposite would be true assuming there still exists vulnerabilities in the Service locator service. Azure likely doesn't use the same code, while AWS does, so they would be more likely to be hit than Azure *IF* another vulnerability exists, but good job bringing up a 13 year old irrelevant vulnerability into the discussion.

Comment: Re:And it's gonna rain (Score 1) 83

by KingMotley (#49560505) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

I might be mistaken, but according to what Amazon's description of RDS, they don't support read replicas of MSSQL.

Using Read Replicas, Amazon RDS for MySQL, PostgreSQL, and Amazon Aurora...

You can with Azure. You can also run your own SQL server if you prefer that as well, and you can set up VPNs and wall off sections, and even use your own local SQL server for fault tolerance (or performance of other local processes). I haven't seen anything you mentioned that you can't do in Azure (minus perhaps having a direct connect to their azure cloud -- but I haven't checked into that eitehr). It's just more difficult to set up with AWS.

Comment: Re:And it's gonna rain (Score 1) 83

by KingMotley (#49548137) Attached to: Amazon's Profits Are Floating On a Cloud (Computing)

It's a hell of a package that makes things like Microsoft Azure look like a joke in comparison

I found the exact opposite, but we are mostly a Microsoft shop. Working with Azure was dead simple, including setting up auto-scaling (Which wasn't offered by Amazon, at least when we were looking), so that our website scales up during peak times, and drops back down during the quieter times, automatically. It also ahs staged publishing which we use a lot, and the ability to switch our public website between any of the multiple slots INSTANTLY with no downtime is also a very big plus. Again, something we couldn't do with AWS at the time we looked.

Publishing directly from Visual Studio is nice (Not offered with AWS -- except via FTP which does a complete site upload instead of only differences).
Automatic SQL Backups and rollbacks to point in time is also dead simple in Azure, but I'm not sure it is even possible in AWS outside buying an enterprise SQL Server license and managing it yourself.

Everything else we looked at was either better at Azure or the same between the two with the exception of their CDN, which I found better at Amazon than Azure at the time. As that wasn't a requirement for us, it was a pretty simple choice (even though we have both Azure and AWS corporate accounts). Our other departments that are java & PHP based prefer AWS however.

Comment: Re:Google: Select jurors who understand stats. (Score 1) 349

by KingMotley (#49545581) Attached to: Median Age At Google Is 29, Says Age Discrimination Lawsuit

The context is US employees. The majority of employees are in the US. Name your country with a significant number of Google employees in which Google routinely hires people who do not speak an official language of that country, please.

And what exactly is the official language of the US? Before you answer, perhaps you should look it up.

Comment: Re:Google: Select jurors who understand stats. (Score 1) 349

by KingMotley (#49545489) Attached to: Median Age At Google Is 29, Says Age Discrimination Lawsuit

I can't agree enough with this. How can this guy be expected to EVER master any (computer) language if he hasn't even mastered the basics of the English language after how many years? Computers change fast, and if you can't go from knowing nothing to being very very good in a language in a matter of a few months, you simply aren't very good.

This is now. Later is later.

Working...