My Favorite Azure References

image

  In my “day job” as an Azure specialist I am often asked for Azure references on various topics. Here is a list of some of the most important references that I have been sending out recently:

Sizes for Windows virtual machines in Azure and Sizes for Linux virtual machines in Azure cover the specifications of the VM sizes that you can run in Azure:

Microsoft server software support for Microsoft Azure virtual machines covers what is (and is not) supported running in an IaaS VM:

Cloud Platform roadmap covers what has been recently released and what Microsoft is working on. 

Microsoft Azure and Amazon Web Services covers AWS Compete is a good reference to have if the question of comparing AWS and Azure features comes up.

One additional great resource is the Azure Learning Paths.  Azure is so broad that it is difficult to know where to start learning about a particular service or feature. The Learning Paths are step-by-step flowcharts that guide you through the documentation and videos on about 35 of the Azure services. (Not every service is so documented, but the ones that are are well done.) Highly recommended.

Bill

Posted in Amazon Web Services, Architecture, Microsoft Azure | Tagged , , | Leave a comment

Free Azure!!!

Short note: Microsoft just announced Visual Studio Dev Essentials. You get $25/month of Free Azure for a year.  Smile

Also see Microsoft introduces free resources to help IT pros get started and build their careers in the cloud

Bill

Posted in Cloud, Cloud Computing, Microsoft Azure | Leave a comment

Azure at //Build 2016

The dust has barely settled on //Build 2016; one, of the two premier annual Microsoft conferences: //Build and Ignite!  For those of you who not aware of it these two conferences morphed from two earlier Microsoft conferences.

//Build is the successor to the earlier Professional Development Conference (PDC).  That conference was targeted mainly at developers. It is still primarily for developers.

Ignite! is the successor to the popular Microsoft TechEd conference. It was targeted mainly at IT Infrastructure types.  Ignite! still maintains that focus.

However, in this day and age of DevOps the lines between the two constituencies are blurring quite a bit.  There is often something for each in both of these conferences.

Although Ignite! is scheduled for September 26th in Atlanta this time //Build 2016, held in San Francisco at the end of March, has just passed by.

There were a large number of announcements at //Build 2016.  Here is a brief summary of the ones that I feel are most important to the Azure community. (There were also a  large number of non-Azure related announcements; but I will leave those for someone else to catalog. Smile)

Here is my top 10:

  1. Azure Functions PaaS Preview (Server less computing/AWS Lambda Compete)
  2. Virtual Machine Scale Sets General Availability (Autoscaling without pre-creating VMs)
  3. Azure Service Fabric General Availability (A hyper-scale successor to Cloud Services)
  4. Storage Service Encryption Preview (Encryption for Blob Storage rest.)
  5. IoT Starter Kits & the IoT Gateway SDK
  6. Document DB Mongo API Support Preview (A widely used NoSQL database) 
  7. Import/Export up to 8TB
  8. U-SQL for Data Lake (A new SQL Like language for Big Data)
  9. DevTest Labs enhancements
  10. PowerBI Embedded Preview

There was an excellent Day 2 keynote by Scott Guthrie recorded and available on Microsoft’s Channel 9 video site.  There are also a large number of session videos posted there so that, even though you did not get to actually go to //Build, you can take advantage of them. You can find one on any of the topics above, and more.

Enjoy

Bill

Posted in Application Development, Cloud, Cloud Computing, Event, IaaS, Microsoft Azure, PaaS, Windows Azure | Tagged | 1 Comment

Disaster Recovery: Asking the wrong question?

image

In my role as an Azure specialist I get asked a lot of questions about Disaster Recovery. IMHO they almost always ask the wrong question.

Usually it goes something like “I need Disaster Recovery protection for my data center. I have N VMs to protect. I have heard that I can use Azure Site Recovery either to facilitate Disaster Recovery to my backup data center, or even use Azure as my backup data center.” That is true. Smile

In a previous lifetime I used to work on a Disaster Recovery  testing team for a major New York based international bank. We learned early on two major principles:

1. It is all about workloads since different application workloads have different Disaster Recovery  requirements. Every workload has unique Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Not all workloads are created equal.   For instance email is a critical workload in the typical enterprise. An outage of more than a few hours would affect business continuity significantly.  Other application workloads (such Foreign Exchange Trading, Order Processing, Expense Reporting, etc.) would have more or less stringent RTO and RPO requirements.

2. So it is really is all about Business Continuity. Disaster Recovery is a business case. It is clear that providing perfect Disaster Recovery for all application workloads would be extremely expensive; and in many cases not cost effective. In effect there is an exponential cost curve. So it is all about risk management and cost/benefit.

So where does that leave us?

1. Evaluate your Disaster recovery requirements on a workload by workload basis

2. Plan how to implement it considering the objective of Business Continuity, RTO and RPO.

3. Use Azure Site Recovery to make it happen. Smile

Bill

Posted in Architecture, Buisness Continuity, Cloud, Cloud Computing, Disaster Recovery, IaaS, Microsoft Azure | Tagged , , , | Leave a comment

Web and Worker Roles: What do I do now? Part 2

image

In my previous blog post in this series I made some recommendations for migrating Cloud Services (Web and Worker Roles) to alternative architectures now that Cloud Services are considered legacy and Microsoft will not be spending any further effort enhancing them. Two solutions that I proposed were Web Apps/Web Jobs and Azure Service Fabric.

After that blog post I did receive some interesting feedback:

“We use Web/Worker Roles with custom software installed and a few other things enabled, so we need a bit more customization than Web Apps provide. Further, we do CPU intensive processing on Worker Roles, and as far as I know Web Jobs run on the same Virtual Machines that serve the Web Role instances; which isn’t suitable for us.”

“Azure Service Fabric is great, but I haven’t been able to confidently decide to move our current apps across to it. There are too many unanswered questions, plus a steep learning curve and necessary tooling improvements are needed.”

These are valid comments; that there is a somewhat steep learning curve; that tooling improvements are needed and that there are still unanswered questions; mostly due to the early state of documentation and the ongoing evolution of Service Fabric.

I empathize with the plight of anyone faced with this decision. It is a decision that many of us who have currently implemented Azure applications are facing. If you need that level of customization you should look at migrating them to Azure Service Fabric Reliable Services or, in the extreme, to Single Instance Virtual Machines and/or Virtual Machine Scale Sets. (Single Instance Virtual Machines are Virtual Machines that are not part of a Virtual Machines Scale Set, as discussed below)

The World before Azure Service Fabric and Virtual Machine Scale Sets

Up until the end of 2015 (when it was last updated) this white paper was an excellent guide to choosing the appropriate Compute option for an Azure application. It covered the tradeoffs between:

  1. Web Apps
  2. Cloud Services
  3. Virtual Machines

It even provided a nice decision table for selecting between them. I used this article to guide many Azure developers in the selection of a compute methodology.

Scott Hanselman has been quoted as summing this up as: “Its Web Apps until it’s not, then it’s Cloud Services until it’s not, then its Virtual Machines.” This does not, however, include Azure Service Fabric and Virtual Machine Scale Sets, which did not exist at the time the article was last updated.

What’s changed?

The above document needs an update to add Azure Service Fabric & Virtual Machine Scale Sets. It could also possibly omit Cloud Services since that is now a legacy technology. If course Cloud Services are not going away. They will be supported for some time. So they may want to keep it in.

The white paper mentioned above was updated recently to include Azure Service Fabric in it’s comparison table.  It still has yet to be updated for Virtual Machine Scale Sets.  Even though it was updated to include Azure Service Fabric in the comparison table the body of the report continues to focus primarily on the other alternatives such as:

  1. Web Apps
  2. Cloud Services
  3. Virtual Machines

It still does not list the reasons for choosing Azure Service Fabric over the other alternatives. Hopefully it will be amended again soon to cover more of the tradeoffs in closing between the options; and also to add Virtual Machine Scale Sets.

Remember, before we proceed though that Azure Service Fabric & Virtual Machine Scale Sets are still in preview, but if you are building new greenfield applications or planning to migrate existing brownfield applications to the newer architectures in the near future it is not too soon to start considering them.

Let’s compare the options:

WebApps

These are often compared to Cloud Services Web Roles. They are based on a pool of Virtual Machines running a pool of IIS instances.

  1. Load Balancer automatically created.
  2. Auto scaling provided by the platform.
  3. Microsoft takes care of all patching of underlying Virtual Machines.
  4. Stateless applications.
  5. No Startup tasks. (See Cloud Services below.)
  6. Cannot Remote Desktop into underlying Virtual Machines.
  7. Multiple environments supported.
  8. Tooling support in Portal, Visual Studio, SDKs and other tools.
  9. Well documented with lots of examples.
  10. Management Complexity: easiest if you can fit within its limitations.

WebJobs

Web Jobs are lightweight background workers. They are often compared to Cloud Services Worker Roles.

  1. Web Jobs run in the same Virtual Machines with Web Apps. So they share many of the same resources and can degrade Web App performance.
  2. Load Balancer automatically created,
  3. Auto scaling provided by the platform,
  4. Microsoft takes care of all patching of underlying Virtual Machines.
  5. Stateless applications that are self-healing.
  6. No Startup tasks. (See Cloud Services below.)
  7. Cannot Remote Desktop into underlying Virtual Machines.
  8. Multiple environments supported.
  9. Tooling support in Portal, Visual Studio, SDKs and other tools.
  10. Well documented with lots of examples.
  11. Complexity: easiest if you can fit within its limitations.

Cloud Services

  1. Based on a collection of individual Virtual Machines.
  2. Load Balancer automatically created.
  3. AutoScaling provided by the platform.
  4. Microsoft takes care of all patching of underlying Virtual Machines.
  5. Stateless applications that are self-healing.
  6. Startup tasks: To install software and do other in-the- Virtual Machine configuration tasks.
  7. Can Remote Desktop into underlying Virtual Machines.
  8. Multiple environments supported.
  9. Tooling support in Portal, Visual Studio, SDKs and other tools.
  10. Well documented with lots of examples.
  11. Complexity is moderate, but remember that Cloud Services are legacy.

Individual Virtual Machines

  1. Virtual Machines created one at a time.
  2. Load Balancer: Not automatically provided. Must create one.
  3. Auto scaling with need to pre-create all Virtual Machine instances.
  4. Microsoft does not update these Virtual Machines. You are responsible.
  5. Stateless and Statefull applications, but up to you to manage.
  6. Virtual Machine Extensions for Startup customization.
  7. Can Remote Desktop into underlying Virtual Machine.
  8. Multiple environments are up to you to create and manage.
  9. Tooling support in Portal, Visual Studio, SDKs and other tools.
  10. Well documented with lots of examples.
  11. Complexity is high.

Virtual Machine Scale Sets

  1. Based on a Virtual Machine template used to create several Virtual Machines in a Scale Set.
  2. Load Balancer: Configured as part of Scale Set creation if you use a Scale Set Template
  3. Auto scaling with no need to pre-create Virtual Machines in the set.
  4. Microsoft does not update these Virtual Machines. You are responsible.
  5. Stateless and Statefull applications, but up to you to manage.
  6. Virtual Machine Extensions for Startup Tasks.
  7. Can Remote Desktop into underlying Virtual Machines.
  8. Multiple environments are up to you to create and manage.
  9. Tooling support in Portal, Visual Studio, SDKs and other tools.
  10. Well documented with lots of examples.
  11. Less Complexity than Individual Virtual Machines.

Azure Service Fabric

Note: Comparison with Service Fabric is still difficult because it is in a state of flux and still evolving. And the documentation is evolving with it. However here are some of its characteristics for comparison:

  1. Based on deploying into pre-existing clusters using Virtual Machine Scale Sets and/or Containers. Also will run on premises under Windows Server and Azure Stack as well as on other platforms such as Linux.
  2. Load Balancer automatically provided for the cluster.
  3. AutoScaling (to millions of Transactions per second)
  4. Microsoft does not update these Virtual Machines. You are responsible.
  5. Stateless and Statefull applications that are self-healing. Azure Service Fabric has two application models: Reliable Services (closest to what you have now in your Cloud Services) and Reliable Actors (which could require significant refactoring of your application.). It also includes Reliable Collections for state management.
  6. Virtual Machine Extensions for Startup Tasks.
  7. Can Remote Desktop into underlying Virtual Machines.
  8. Multiple environments are up to you to create and manage.
  9. Tooling support in Portal, Visual Studio, SDKs and other tools such as the Service Fabric Explorer.
  10. Documentation: Still scarce and under change due to the evolving nature of the service. Hopefully this will settle down soon.
  11. Complexity: High. Fairly steep learning curve. But very rewarding. Smile

Recommendations

So, when all is said and done, what do we recommend? That depends on whether you are migrating an existing brownfield application or designing a new greenfield one.

Brownfield applications

These are the most challenging. If it “fits” Web Apps/Web Jobs use that approach. If not, then Azure Service Fabric Reliable Services is the next choice to evaluate. And, just like in the case before where Virtual Machines was always a valid last choice you can choose that approach, however even there you have two options, Individual Virtual Machines or Virtual Machines Scale Sets. And consider using Reliable Collections as an alternative to other existing forms of state management and as an alternative of Azure Storage Queues.

So you can start with a lift-and-shift approach to migration and refactor later to take advantage of micro-services and possibly the Actor Model.

Greenfield applications

Here the sky’s the limit. I would first decide how scalable I want my applications to be. If I expect hundreds or thousands of transactions per second, I would look at Azure Service Fabric Reliable Actor model first. After that I would consider Reliable Services.

If nether of this approaches work for you then maybe Virtual Machine Scale Sets is the architecture to choose. Individual Virtual Machines are probably an option now only for fairly simple architectures that don’t need the scalability of Virtual Machine Virtual Machine Scale Sets. Or for the situation where you have to go above and beyond what the other options provide to roll-your-own architecture.

But remember the Architect’s rule: “It all Depends” Smile

What do you think?

Bill

Posted in Application Development, Architecture, Cloud, Cloud Computing, IaaS, Microsoft Azure, Microsoft Azure WebApps, Microsoft Azure WebJobs, PaaS, Windows Azure, Windows Azure Web Sites | Tagged , , , , | 6 Comments

Web and Worker Roles: What do I do now?

For those of you who may not have noticed PaaS V2 (Azure Service Fabric) was announced a while back. The familiar PaaS V1 Cloud Services based Web and Worker Role architecture is now legacy. They aren’t going away, but Microsoft will not be spending any more development effort on them. PaaS V2 is the future.

So what do I do now? Of course I can keep my Web and Worker Role based applications running as-is or start to migrate to one of two newer architectures:

The traditional architecture of Cloud Services that has been with us since the beginning of Azure normally follows the pattern of a web farm implemented as a multi-instance Web Role which passes data through an Azure Storage Queue (and often) Azure Blobs and/or Tables to a pool of one or more Worker Roles used to do background processing.

image

One natural migration path is to replace the Web Role with a WebApp and the background Worker role with a WebJob.

Azure Service Fabric (currently in Technical Preview) is a newer micro-service-oriented architecture that was designed for hyper-scalability. Many of the Microsoft first-party applications such as SQL Database, IoT Hubs, Cortana, and Document DB are built on this architecture.

image

If you expect to build the kind of application that will scale to support thousands or even millions of users Service Fabric may be for you. Otherwise investigate moving to a WebApps/WebJobs architecture.

Bill

Posted in Application Development, Architecture, Cloud, Cloud Computing, Microsoft Azure, Microsoft Azure WebApps, Microsoft Azure WebJobs, PaaS, Windows Azure, Windows Azure Web Sites | Tagged , , , | Leave a comment

AzureCon Update

[Updated 10-1-2015]

Today at AzureCon Microsoft announced a whole raft of features.  The announcements can be grouped into three categories.

  1. Features that were previously in Preview that have just gone into General Availability
  2. Features that have just entered the Public Preview Stage
  3. Features that will be Previewed in the near future

image

The Category 1 announcements were pretty interesting, but you have probably heard about them before since they have been in Preview for a while. I am not going to  cover them here. Category 2 and 3 are more interesting.

Here is a partial list of the announcements:

And more.  We will have much more to say about these announcement over the coming weeks.

In addition to three announcement packed keynotes there were over 60 on demand sessions which are currently available on the AzureCon site.

Bill

Posted in Uncategorized | Leave a comment