The Future of Azure is Azure Stack!

image

image

I realize that the title above might be a bit controversial to some. In this blog post I will attempt to defend that position.

The two diagrams above, taken from recent Microsoft public presentations,  symbolically represent the components of Public Azure and Private Azure (Azure Stack).  If you think that they have a lot in common you are right.  Azure Stack is Azure running in your own data center.  Although not every Azure feature will be delivered as part of Azure Stack at its initial release (and some may never be delivered that way because they require enormous scale beyond the reach of most companies) , it is fair to say that they are more alike than they are different.

Back in 2012 I wrote a blog post on building cloud burstable, cloud portable applications.  My theses in that post was that customers want to be able to run their applications on local hardware in their data center, on resources provided by cloud providers and/or even resources provided by more than one cloud provider. And that they would like to have a high degree of compatibility that would allow them to defer the choice of where to run it and even change their mind as workload dictates.

That thesis is still true today.  Customers want to be able to run an application in their data center. If they run out of capacity in their data center then they would like to shift it to the cloud and later potentially shift it back to on-premises.

That blog post took an architectural approach using encapsulation and modularity of design to build applications that could run anywhere.

The Birth of Azure

A bit of additional perspective might be useful.  Back in 2007 I was working as an Architect for Microsoft and I came across what would eventually become Azure. (In fact that was before it was even called Azure!) I had worked on an experimental cloud project years before at Bell Labs called Net-1000. At the time AT&T was planning on turning every telephone central office into a data center providing compute power and data storage at the wall jack.  That project failed for various reasons some technical and some political, as documented in  the book The Slingshot Syndrome. The main technical reason was that the computers of the day were minicomputers and mainframes and the PC was just emerging on the scene.   So the technology that makes today’s cloud possible was not yet available.  Anyway, I can say that I was present at the birth of Azure.  History has proven that attaching myself to Azure was a pretty good decision. Smile

The Azure Appliance

What many do not know is that this is actually Microsoft’s third at tempt at providing Azure in the Data Center. Back in 2010 Microsoft announced the Azure Appliance which was to be delivered by a small number of Vendors . It never did materialize as a released product.

Azure Pack and the Cloud Platform System

Then came Windows Azure Pack and the Cloud Platform System in 2014 to be delivered, also in appliance form, by a small number of selected vendors.  Although it met with some success, is still available today, and will be supported going forward, its clear successor will be Azure Stack.   (While Azure Pack is an Azure-like emulator built on top of System Center and Windows Server Azure Stack is real Azure running in your data center.)

Because of this perspective I can discuss how Azure Stack is Microsoft’s third attempt at Azure in the Data Center and one that I believe will be very successful. Third times a charm Smile

Azure Stack

The very first appearance of Azure Stack was in the form of a private preview, and later a public preview: “Azure Stack Technical Preview 1”.  During the preview it became clear that those attempting to install it were experiencing difficulties, many of them related to the use of hardware that did not match the recommended minimum specifications.   

Since Azure Stack is so important to the future of Azure Microsoft decided to release it in the form of an Appliance to be delivered by three vendors (HP, Dell & Lenovo) in the Summer of 2017.  According to Microsoft that does not mean that there will be no more technical previews, or that no-one will be able to install it on their own hardware.   (It is generally expected that there will be additional Technical Previews, perhaps even one at the upcoming Microsoft Ignite! conference later this month.) It simply means that the first generation will be released in controlled fashion through appliances provided by those vendors so that  so that Microsoft and those vendors can insure its early success.

You may not agree with Microsoft (or me), but I am 100% in agreement with that approach.  Azure Stack must succeed is Azure is to continue to succeed.

Bill

Posted in Azure Stack, Cloud, Cloud Computing, Microsoft Azure, Windows Azure | Tagged , | 2 Comments

Microsoft Virtual Academy’s new more agile approach to Azure IT Pro training.

image

Microsoft Virtual Academy is launching a new series for IT Pros that will be delivered in smaller replaceable chunks that will be more consistent with how Azure Features are delivered, rather than long recorded units that are obsolete by the time they are released.  This will be a more agile approach.

They have already released several samples published today (I understand that some of the demos will be added later):

They made the point in the launch event today that that the Azure Active Directory unit was made obsolete last night by the move of Azure Active Directory into the “Current” portal from the “Classic” portal. They will replace that unit and re-release it soon. Just one example of their new agile approach.

Although this series is for “IT Pros” I suspect that they will take the same approach for Developers soon if this works out.

Bill

Posted in Microsoft Azure | Tagged , , | Leave a comment

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 , , , , | 7 Comments