7 ms·

Compared to Azure, yes. The IaaS offering on Azure has many, many limitations. It is also very difficult to use. There is no general pool of servers. You have t

by mdeeks 11y ago

Compared to Azure, yes. The IaaS offering on Azure has many, many limitations. It is also very difficult to use. There is no general pool of servers. You have to cram VMs into these groupings called "Cloud Services" which are limited to 50 VMs each. No support for TLS termination on their load balancers. SSDs are currently a "preview" feature and only work on a subset of hardware types. In all fairness AWS had a 4-5 year head start on Azure. Also there are a lot of really exciting things coming down the line for Azure. I don't expect this gap to last long. Competition is good!

btown 11y ago
SSDs, okay. That's something that's legitimately difficult to scale, particularly if you've invested heavily on spinning disks and made assumptions about their performance/reliability. I get that. But no TLS termination? At a company that has invested $15bn on their cloud products and has in-house expertise on the actual source code of one of the most widely-used networking stacks? That's... surprising, to say the least.
- nitramafve 11y ago
  What does the lack of SSL termination mean? We are running many services in Azure which we access using TLS1.2 via the loaf balancer so what would SSL termination add to this?
  - nolok 11y ago
    Wikipedia is short and to the point on this one > An SSL termination proxy is a proxy server that is used by an institution to handle incoming SSL connections, decrypting the SSL and passing on the unencrypted request to the institution's other servers (it is assumed that the institution's own network is secure so the user's session data does not need to be encrypted on that part of the link). SSL termination proxies are used to reduce the load on the main servers by offloading the cryptographic processing to another machine, and to support servers that do not support SSL, like Varnish. http://en.wikipedia.org/wiki/SSL_termination_proxy http://en.wikipedia.org/wiki/SSL_termination_proxy
  - mdeeks 11y ago
    SSL/TLS can only be configured if you use their "Web app" PaaS offering . If you're using plain VMs (IaaS) then there are no options for SSL/TLS. You have to do it yourself on your VMs using haproxy/nginx/stud.
adt2bt 11y ago
One note: Azure SSD backed Storage is now GA. http://azure.microsoft.com/blog/2015/04/16/azure-premium-storage-now-generally-available-2/ http://azure.microsoft.com/blog/2015/04/16/azure-premium-sto...
- mdeeks 11y ago
  Ahh you're right. Last week. Being restricted to the DS instance types is a little bit of a bummer though.
tracker1 11y ago
If you're controlling your azure account through the powershell interface, it's a little better... a lot of things require the beta UI, which isn't so great. That said, I was able to setup a quick little proof of concept web/worker app with node pretty quickly... though you should be aware it is running in a windows host (either 32 or 64bit configurable)... you can include exe/dll's in your package as needed too... I used a git endpoint for deploy, and that worked pretty well. There's apparently a build environment suitable and configured for node_gyp to be able to use. Though imho it's not as flushed out as App Engine, or bits of AWS... I am able to run dokku on a few hosts... Work's account finally came online for the SSD preview about a month ago... it's definitely worth it. There's some mishmash of availability... I kind of like that using blob storage, tables and azure queues is as simple as having a storage account... though the node client is a little lacking in documentation and examples.
- mdeeks 11y ago
  We only run Linux and use Macs. So powershell isn't an option for us. The SDKs for various languages aren't terribly mature either. I don't think any of them except the .NET one are 1.0 yet. Don't get me started on the Beta UI vs normal UI. Some things are only supported in one and not the other and vice versa. I'm constantly being flipped back and forth between the two. Also they are both really unpleasant to use. I get lost a lot.
  - deleted 11y ago
    [deleted]
  - tracker1 11y ago
    It's actually kind of sad that they had a strong initial push to support other languages and platforms, only to let those SDK/API clients wither on the vine so to speak... The github issues on their public repos seem to be mostly unmaintained (several a month or older without an MS representative). On the flip side, there were some issues with connecting to Azure via the node `mssql/tedious` module, which isn't from MS, and a few developers from MS Azure SQL teams stepped up to track down the issue. Learned a bit more about the TDS protocol than I really wanted to that month. It seems to me that MS Azure's development department should either implement a 20-40% time for developers to work on the public stuff and/or documentation as developers desire, or have cowboy teams that do. MS isn't likely to spur more open development efforts as most corporate based projects don't inspire much community involvement. That said, given the choice I might be more inclined to use Joyent, DigitalOcean or Linode for my own stuff... The choice wasn't mine at work, the existing solutions are mostly .Net (some Node) based and Azure was the most pragmatic choice of migration to a hosted solution when that was done almost two years ago. And running anything under Ubuntu VMs with docker on Azure is pretty trivial... Once the next generation infrastracture is in place (a couple months away), it will become easy enough to run anywhere.
ripberge 11y ago
Azure is definitely behind in some regards particularly IaaS. That was not really their strategy for quite a while and it shows. We are using their PaaS now and really like it, much better experience than we had with stuff like elastic beanstalk or cloudformation on AWS. We still used Amazon Email and CloudSearch though. Azure has no email and Azure search is too new for me to trust.
- dummyfellow 11y ago
  Azure email is Office 365 / exchange online
luisrudge 11y ago
ON the other hand, Azure's PaaS offerings are way better than AWS's. No surprise there, since Azure started with PaaS and AWS started with IaaS.
- olifante 11y ago
  I beg to disagree. As I wrote in another thread, Microsoft has not one but two Platform-as-a-Service offerings: - Azure Cloud Services (PaaS) - Azure Websites (PaaS light) Unfortunately, when I last looked at it four months ago, both of them were quite unattractive, at least for Python hosting. First of all, they have no support for automatically installing python dependencies, i.e. no support for pip. If you want to install e.g. django-rest-framework, you have to install it locally and then manually copy the installed files to Azure (with FTP, if I remember correctly). Secondly, they both run Python on a Windows Server running behind the IIS web server. Besides the fact that you will walk along the road less travelled (Django is overwhelmingly deployed on Linux), there is a very concrete limitation: if you want to install binary packages (e.g. PIL or Pillow), you have to manually compile them for Windows (and of course copy them manually to your Azure server). Yuck. If you want to use Azure, go with their IaaS offering (Azure Virtual Machines) and stay away from their PaaS offerings
CoreySanders 11y ago
Yes, the Cloud Services grouping around IaaS VMs wasn't a good idea and is awkward. You can blame me for that. :) Stay tuned next week. We may have some solace for you.

by mdeeks 11y ago

btown 11y ago

SSDs, okay. That's something that's legitimately difficult to scale, particularly if you've invested heavily on spinning disks and made assumptions about their performance/reliability. I get that. But no TLS termination? At a company that has invested $15bn on their cloud products and has in-house expertise on the actual source code of one of the most widely-used networking stacks? That's... surprising, to say the least.

nitramafve 11y ago
What does the lack of SSL termination mean? We are running many services in Azure which we access using TLS1.2 via the loaf balancer so what would SSL termination add to this?
- nolok 11y ago
  Wikipedia is short and to the point on this one > An SSL termination proxy is a proxy server that is used by an institution to handle incoming SSL connections, decrypting the SSL and passing on the unencrypted request to the institution's other servers (it is assumed that the institution's own network is secure so the user's session data does not need to be encrypted on that part of the link). SSL termination proxies are used to reduce the load on the main servers by offloading the cryptographic processing to another machine, and to support servers that do not support SSL, like Varnish. http://en.wikipedia.org/wiki/SSL_termination_proxy http://en.wikipedia.org/wiki/SSL_termination_proxy
- mdeeks 11y ago
  SSL/TLS can only be configured if you use their "Web app" PaaS offering . If you're using plain VMs (IaaS) then there are no options for SSL/TLS. You have to do it yourself on your VMs using haproxy/nginx/stud.

adt2bt 11y ago

One note: Azure SSD backed Storage is now GA. http://azure.microsoft.com/blog/2015/04/16/azure-premium-storage-now-generally-available-2/ http://azure.microsoft.com/blog/2015/04/16/azure-premium-sto...

mdeeks 11y ago
Ahh you're right. Last week. Being restricted to the DS instance types is a little bit of a bummer though.

tracker1 11y ago

If you're controlling your azure account through the powershell interface, it's a little better... a lot of things require the beta UI, which isn't so great. That said, I was able to setup a quick little proof of concept web/worker app with node pretty quickly... though you should be aware it is running in a windows host (either 32 or 64bit configurable)... you can include exe/dll's in your package as needed too... I used a git endpoint for deploy, and that worked pretty well. There's apparently a build environment suitable and configured for node_gyp to be able to use. Though imho it's not as flushed out as App Engine, or bits of AWS... I am able to run dokku on a few hosts... Work's account finally came online for the SSD preview about a month ago... it's definitely worth it. There's some mishmash of availability... I kind of like that using blob storage, tables and azure queues is as simple as having a storage account... though the node client is a little lacking in documentation and examples.

mdeeks 11y ago
We only run Linux and use Macs. So powershell isn't an option for us. The SDKs for various languages aren't terribly mature either. I don't think any of them except the .NET one are 1.0 yet. Don't get me started on the Beta UI vs normal UI. Some things are only supported in one and not the other and vice versa. I'm constantly being flipped back and forth between the two. Also they are both really unpleasant to use. I get lost a lot.
- deleted 11y ago
  [deleted]
- tracker1 11y ago
  It's actually kind of sad that they had a strong initial push to support other languages and platforms, only to let those SDK/API clients wither on the vine so to speak... The github issues on their public repos seem to be mostly unmaintained (several a month or older without an MS representative). On the flip side, there were some issues with connecting to Azure via the node `mssql/tedious` module, which isn't from MS, and a few developers from MS Azure SQL teams stepped up to track down the issue. Learned a bit more about the TDS protocol than I really wanted to that month. It seems to me that MS Azure's development department should either implement a 20-40% time for developers to work on the public stuff and/or documentation as developers desire, or have cowboy teams that do. MS isn't likely to spur more open development efforts as most corporate based projects don't inspire much community involvement. That said, given the choice I might be more inclined to use Joyent, DigitalOcean or Linode for my own stuff... The choice wasn't mine at work, the existing solutions are mostly .Net (some Node) based and Azure was the most pragmatic choice of migration to a hosted solution when that was done almost two years ago. And running anything under Ubuntu VMs with docker on Azure is pretty trivial... Once the next generation infrastracture is in place (a couple months away), it will become easy enough to run anywhere.

ripberge 11y ago

Azure is definitely behind in some regards particularly IaaS. That was not really their strategy for quite a while and it shows. We are using their PaaS now and really like it, much better experience than we had with stuff like elastic beanstalk or cloudformation on AWS. We still used Amazon Email and CloudSearch though. Azure has no email and Azure search is too new for me to trust.

dummyfellow 11y ago
Azure email is Office 365 / exchange online

luisrudge 11y ago

ON the other hand, Azure's PaaS offerings are way better than AWS's. No surprise there, since Azure started with PaaS and AWS started with IaaS.

olifante 11y ago
I beg to disagree. As I wrote in another thread, Microsoft has not one but two Platform-as-a-Service offerings: - Azure Cloud Services (PaaS) - Azure Websites (PaaS light) Unfortunately, when I last looked at it four months ago, both of them were quite unattractive, at least for Python hosting. First of all, they have no support for automatically installing python dependencies, i.e. no support for pip. If you want to install e.g. django-rest-framework, you have to install it locally and then manually copy the installed files to Azure (with FTP, if I remember correctly). Secondly, they both run Python on a Windows Server running behind the IIS web server. Besides the fact that you will walk along the road less travelled (Django is overwhelmingly deployed on Linux), there is a very concrete limitation: if you want to install binary packages (e.g. PIL or Pillow), you have to manually compile them for Windows (and of course copy them manually to your Azure server). Yuck. If you want to use Azure, go with their IaaS offering (Azure Virtual Machines) and stay away from their PaaS offerings

CoreySanders 11y ago

Yes, the Cloud Services grouping around IaaS VMs wasn't a good idea and is awkward. You can blame me for that. :) Stay tuned next week. We may have some solace for you.