- Windows Azure: Getting started with AppFabric
- Windows Azure AppFabric: Service Bus
- Windows Azure AppFabric: Access Control
Wednesday, March 30, 2011
Windows Azure AppFabric Videos
Found some interesting videos on Windows Azure AppFabric. Here are some short 10-15 minutes introduction videos to AppFabric:
Monday, March 28, 2011
Windows Azure AppFabric
Most people when they look at Windows Azure (WA), will assume that it is only suitable for new developments and would think that their existing systems will need to be completely re-written to leverage on the platform. That is an inaccurate thought but I can't blame them because most of the focus around WA were surrounding the Roles, the Storage and SQL Azure - painting a picture that it is a "new way of developing apps".
The truth is, WA does provide support for existing systems to slowly move to the cloud and provides a good platform for hybrid (cloud + on-premise) solutions. This is achieved through Windows Azure AppFabric - which in my opinion is given very little attention probably because it something that is not so easy to explain and doesn't have a local development environment.
The AppFabric comes with 2 very useful services today - Service Bus and Access Control. The third feature, Caching, is on the way with other features following suit later. If we have existing on-premise services that we would like to expose to partners, external systems, remote branches or mobile employees, we can leverage on the Service Bus. It provides a neat way to traverse through firewalls to create a relay between service consumers and service providers. The technology enabling this is simply a couple of Windows Communication Foundation (WCF) bindings.
The other component, the Access Control, allows us to secure our applications and endpoints with claims-aware federated security.
Therefore, if you want to expose some of your application's services to the external world without all the infrastructure investment, you can easily do it with Windows Azure AppFabric. (In fact, you can write some services on your PC at home and use AppFabric to connect to it wherever you go).
P.S. Take note that Service Bus charges by connections.
The truth is, WA does provide support for existing systems to slowly move to the cloud and provides a good platform for hybrid (cloud + on-premise) solutions. This is achieved through Windows Azure AppFabric - which in my opinion is given very little attention probably because it something that is not so easy to explain and doesn't have a local development environment.
The AppFabric comes with 2 very useful services today - Service Bus and Access Control. The third feature, Caching, is on the way with other features following suit later. If we have existing on-premise services that we would like to expose to partners, external systems, remote branches or mobile employees, we can leverage on the Service Bus. It provides a neat way to traverse through firewalls to create a relay between service consumers and service providers. The technology enabling this is simply a couple of Windows Communication Foundation (WCF) bindings.
The other component, the Access Control, allows us to secure our applications and endpoints with claims-aware federated security.
Therefore, if you want to expose some of your application's services to the external world without all the infrastructure investment, you can easily do it with Windows Azure AppFabric. (In fact, you can write some services on your PC at home and use AppFabric to connect to it wherever you go).
P.S. Take note that Service Bus charges by connections.
Sunday, March 27, 2011
Securing Windows Azure Assets
There are several things that comes to my mind when thinking about the stuff that needs to be secured on Windows Azure. At the infrastructure level, I am sure it is well-taken care off by Microsoft data centers and there are tonnes of whitepapers that we can find in the Microsoft Global Foundation Services website to read about it.
On the application level, we would still need to practice standard security principles such as encrypting our sensitive data, hashing passwords, using HTTPS for transport where applicable, impose proper authentication and authorization mechanisms in our applications and securing any WCF end-points that we are exposing from Windows Azure. Some people may assume that cloud solutions are either a silver-bullet to their security problems or they are very insecure because "everyone can access it".
There is no difference at the application-level. Cloud or on-premise, proper security practices should be in-place. I realized that from interactions with people, the main concerns of security are usually the infrastructure and application, However, there is a tiny concern that most people seem to overlook. The weakest point to our Windows Azure assets is neither the infrastructure or application, it is the Windows Live ID that is used to login to the Windows Azure Portal. Yup! The same ID we used for our Live Messenger and XBOX Live.
If the Windows Live ID is compromised, an attacker can easily delete services, change certs, hi-jack administrative control, block access to data or just provision extra instances to bomb your credit card (Luckily, the default maximum instance is only 20). It is very common that organizations will either use the Infra Manager's or CTO's Live ID for Windows Azure. This is somewhat dangerous because the Windows Live ID is a personal thing and we are unsure whether the Live ID is compromised (i.e. clicked on those "Hey! Here is a picture of you" links in Live Messenger).
Therefore, I would suggest creating a separate "Company Windows Live ID" for your organization, tie the credit card to that ID and entrust it with the person who is in-charge of deploying the applications. This Windows Live ID should not be used for e-mail, chat or even XBOX :p
P.S. Remember to change the password of the Windows Live ID when the person changes role or no longer works for the company.
On the application level, we would still need to practice standard security principles such as encrypting our sensitive data, hashing passwords, using HTTPS for transport where applicable, impose proper authentication and authorization mechanisms in our applications and securing any WCF end-points that we are exposing from Windows Azure. Some people may assume that cloud solutions are either a silver-bullet to their security problems or they are very insecure because "everyone can access it".
There is no difference at the application-level. Cloud or on-premise, proper security practices should be in-place. I realized that from interactions with people, the main concerns of security are usually the infrastructure and application, However, there is a tiny concern that most people seem to overlook. The weakest point to our Windows Azure assets is neither the infrastructure or application, it is the Windows Live ID that is used to login to the Windows Azure Portal. Yup! The same ID we used for our Live Messenger and XBOX Live.
If the Windows Live ID is compromised, an attacker can easily delete services, change certs, hi-jack administrative control, block access to data or just provision extra instances to bomb your credit card (Luckily, the default maximum instance is only 20). It is very common that organizations will either use the Infra Manager's or CTO's Live ID for Windows Azure. This is somewhat dangerous because the Windows Live ID is a personal thing and we are unsure whether the Live ID is compromised (i.e. clicked on those "Hey! Here is a picture of you" links in Live Messenger).
Therefore, I would suggest creating a separate "Company Windows Live ID" for your organization, tie the credit card to that ID and entrust it with the person who is in-charge of deploying the applications. This Windows Live ID should not be used for e-mail, chat or even XBOX :p
P.S. Remember to change the password of the Windows Live ID when the person changes role or no longer works for the company.
Saturday, March 26, 2011
Windows Azure Pay-as-you-go Explained
A friend of mine asked me the other day "Pay-as-you-go in Windows Azure means that if I left my applications there and nobody use it, there won't be any charges - Right?". I am sure most of us would have a thought like that when we first hear the term - Pay-as-you-go (or Pay-per-use).
The answer to that question (at the time of this writing) is - "Nope, you will be billed!!!"
Pay-as-you-go in this context simply means "We are paying to use Windows Azure's services" and not "We only pay when our customers use our service (or applications)". The easiest way that I like to use to explain Windows Azure's charges is to use the Car Rental example. When we rent a car, we pay for the rental services and regardless of whether we park the car at our garage or take it for a spin, we still need to pay for the rental service (as long as we have the car).
Therefore, in Windows Azure's case, as long as we have services deployed onto it, we will be billed for them. In fact, we will have to delete our services if we don't intend to use it. This should help avoid getting surprises in our credit card bill.
Expanding on the Car Rental example, we can also use it to explain this - "Why is it that we paid for the service but still get charged for data transfers and transactions?" Answer: "That's because when we rent the car, we still need to pay for the fuel." ^_^
Note: You will also get billed for staging instances! Therefore, remember to decommission your staging instances after testing to avoid having a shock in your credit card bill. *HeHe*
The answer to that question (at the time of this writing) is - "Nope, you will be billed!!!"
Pay-as-you-go in this context simply means "We are paying to use Windows Azure's services" and not "We only pay when our customers use our service (or applications)". The easiest way that I like to use to explain Windows Azure's charges is to use the Car Rental example. When we rent a car, we pay for the rental services and regardless of whether we park the car at our garage or take it for a spin, we still need to pay for the rental service (as long as we have the car).
Therefore, in Windows Azure's case, as long as we have services deployed onto it, we will be billed for them. In fact, we will have to delete our services if we don't intend to use it. This should help avoid getting surprises in our credit card bill.
Expanding on the Car Rental example, we can also use it to explain this - "Why is it that we paid for the service but still get charged for data transfers and transactions?" Answer: "That's because when we rent the car, we still need to pay for the fuel." ^_^
Note: You will also get billed for staging instances! Therefore, remember to decommission your staging instances after testing to avoid having a shock in your credit card bill. *HeHe*
Subscribe to:
Posts (Atom)