So Long New York, Hello Nashville!


If you have been wondering why I haven’t posted in a while it is because I have recently relocated to Nashville Tennessee from the New York area for family reasons.  Doing that has consumed a lot of my time; finding a new job, packing and moving, getting established in the local community, etc.

Now to the reason for this post.  Cloudy In New York clearly does not work for me any more as a blog title now that I am here in Nashville.  So I am sealing off this blog and will be starting a new blog (Cloudy In Nashville of course, what else? Smile) I will continue to post there about “Clouds in General and Windows Azure in Particular” as the masthead says.

For those of you who know me you know that I am a big believer in technical communities having founded or acted as a leader of several user groups over the years, groups such as: the New York Windows Azure Users Group, the New York .NET Developers Group, the New York Enterprise Windows Users Group and the New York Chapter of the International Association of Software Architects.

Despite being pretty busy with the move I have found the time to start up a Nashville Windows Azure Users Group here.  (I told someone lately that I am indeed an “Azureholic” or “Cloud Addict”. Smile)  I will be focusing my time on that group and the new blog going forward.

It’s been great and you have been a great audience, but I really do love it here in Nashville.  You can continue to contact me via Email at wzack@live.com, and by phone at 203 545-2339 (mobile). You can also visit me on LinkedIn and Follow @WilliamHZack on twitter. 

So long,and thanks for all the fish. Winking smile

clip_image001

Posted in Cloud Computing, User Groups, Windows Azure | Tagged , , | Leave a comment

To Cloud or Not to Cloud Part 3–Beating the Showstoppers


At a recent meeting of the NYC/NJ Windows Azure Users Group I presented on the subject of Moving Applications to Windows Azure.  At the end of the presentation I had a slide that covered potential Showstoppers that might prevent moving applications to Windows Azure and we discussed how to get around them.  Some of these were:

  • Fear of change/risk
  • Security of data in transit, at rest & in use
  • Regulatory impediments (SOX, HIPAA, PCI, etc.)
  • Trans-border data issues
  • Coupling to other internal systems
  • Single-tenancy design of existing on-premises applications
  • Unpredictability of costs caused by the OpEx model

Not everything has to be moved to Windows Azure!

First of all, let me shock you by stating that I do not believe that everything has to be, or should be, moved the the Cloud. Smile  There are strong reasons why some applications cannot be so moved. Even in those cases however there may be advantage to moving some application components into the cloud while keeping some application components safety behind the firewall.  In the previous posts in this series I discussed a methodology for selecting applications to move to Windows Azure.  I stated in those posts that the methodology was only a first level approximation to a decision process that could get you started in the evaluation and planning process.

We started the first post in the series by applying the decision process to your application portfolio to determine applications that are Fit For the Cloud.  You will remember that we discussed typical application characteristics to look for.  That post talked about doing this on a whole application basis.  As a first level approximation that might be good to determine the low hanging fruit applications that could benefit from a complete move.  Even in those cases where that is not an option it may still be the case that there may be benefit in moving some application components.

For instance: Lets take the case of an eCommerce site.  Making your product catalog widely available by publishing it in the cloud would seem to be a no-brainer. That would give you maximum reach and scalability.  On the other hand credit card processing might have to reside safely behind the firewall or in the hands of a third-party credit card service provider. (Or maybe not.  There are other interesting potential solutions to this problem.) The same decision process could be applied to your Shopping Cart and other application components. My point here is to think at a more granular level and place application components where they will do you the most good.

Window Azure supports these Hybrid architectures in many ways.  You can build distributed applications involving Cloud and data center resident components using basic PaaS Compute Services such as Windows Azure Web and Worker Roles, PaaS Data Services such as Windows Azure Blobs, Tables, Queues and Drives as well as other PaaS services such as the Windows Azure Service Bus (which allows you to integrate cloud-based resources with other resources behind the firewall), Access Control Service (which provides a secure token service in the cloud that can be used to federate Windows Azure  security with other claims-based security providers), and SQL Data Sync (which allows you to synchronize on-premise SQL Server databases with in-the-cloud Windows Azure SQL Databases) and other very useful Windows Azure PaaS services.

You can also mix and match PaaS services such as those above with the newer IaaS features such as Windows Azure Virtual Machines, Virtual Networks and other IaaS  services that even let you operate as if your cloud storage and compute components were located in a “branch office” in Windows Azure, complete with a Cloud extension of your own Active Directory domain.

To reiterate, Not everything has to be, or should be, moved the Cloud. In fact most of the interesting enterprise level applications in the foreseeable future will be of this Hybrid nature. The Cloud just represents a deployment option for some or all application components. Use it where it makes good business and architectural sense.

With that positioning out of the way lets talk about some of those Showstopper.

Fear of change/risk

When I was at a previous company we used to joke about being in the “payroll continuation program” Smile  No-one wants to loose their job by taking unnecessary risks. However, talking prudent risks in the pursuit of business objectives should be what your job is all about.  To be blunt, those companies that do not pursue new technologies and new ways of doing business run the risk of being left behind by their competitors. Witness what has been happening in the brick and mortar retail store world, video rental world, the publishing industry and others impacted severely by newer technologies such as the Internet and Mobile Computing.  (My high school motto was “He who does not advance  falls behind”. Enough said.)

There are ways to take prudent risks where the cloud is Concerned. And you should be exploring them if your business is to stay relevant.  A very simple process flow for getting into the Cloud safely is described below. In a way it is sort of a Cloud maturity Model.

image

Another thing that I recommend highly Smile is a paper that I co-authored while at Microsoft on the Software as a Service System Development Life Cycle which addresses IT as a service and how to modify the standard SDLC methodology when approaching your first (or subsequent) Cloud opportunity.

Proceed cautiously, but proceed.

Security of data in transit, at rest & in use

Some companies blatantly refuse to allow use of the Cloud in any form. Even those companies however probably do not do their own payroll processing , preferring instead to utilize the service of a “cloud service provider” such as ADP. So in effect they are using “The Cloud” in some way whether they realize it or not.

Once past the blind “No Cloud here”mandate we can look at where Security issues exist and how to mitigate them in order to take advantage of the Cloud.

Security is a matter of providing data security while data is in transit (normally over the Internet), at rest (usually in cloud storage) as well as in use (while being processed in the cloud). Let me state that I am not a security expert but I do know that there are potential ways to insure the security of your data in all three modes.

Data in transit can be, and normally is, secured by SSL/TLS protocols involving Public/Private key encryption.  

Securing data at rest is a matter of either encrypting or tokenizing data such that no personally identifiable information, credit card data, or other sensitive data is at risk.

Securing data in use is concerned with not exposing that data while it is being processed.  That is a bit harder but still there are still ways, for instance, to search and compare encrypted data items without actually decrypting them.

So do  not give up on the Cloud just because you are concerned about Security. Of course you need to proceed cautiously. In the final analysis where Security turns out to be a real showstopper you may still be able to resort to a Hybrid design that keeps the sensitive data behind the firewall while still taking advantage of the Cloud.

Let me close this discussion with a reference to the Windows Azure Trust Center that will tell you pretty much everything that you need to know about Windows Azure where  Security, Privacy, Compliance and Trust are concerned. The Compliance section also addresses the following Showstopper as well.

Regulatory impediments (SOX, HIPAA, PCI, etc.)

It is a fact that regulatory agencies always seem to be living in a previous generation. Smile  When computers first took off regulations were mostly focused on paper record keeping. Now that the Cloud is upon us regulations, in most cases, have not yet caught up with the Cloud. 

Cloud security is a shared responsibility between the cloud service provider and its customers. The Windows Azure trust Center Compliance section (mentioned above) addresses these issues and their current status. The current state of Windows Azure certification (from the Trust Center) is explained in the following table.

image

If you are in the Healthcare industry and are concerned about HIPAA Compliance in particular I highly recommend this white paper from Sogeti USA, Inc. that discusses how to build HIPAA compliant applications on Windows Azure.

Recently the Cloud Special Interest Group of the PCI Security Standards Council also issued a new PCI Data Security Standard (PCI DSS) covering the Cloud.

Compliant solutions do exist, but need to be investigated carefully as regulations and certifications are still in a state of change.

Trans-border data issues

Many countries have strict restrictions about Data  Sovereignty.  In many cases refusing to allow data to be stored in other countries and/or to flow across international boundaries. Although these restrictions seem to be decreasing they are still a factor.  Windows Azure supports Data Sovereignty by allowing you to control the geographic location where your resources are located.

Coupling to other internal systems

One factor that may work against moving an application to the cloud is the case where there are a lot of inter-system interfaces between the application in question and the other systems in your company.  While a bad idea in general this often occurs in practice. Some re-engineering of existing applications to minimize those interfaces may be required. In some cases building a Façade or gateway that reduces the number of interfaces between on-premises and cloud components may be possible.

Single Tenancy design of existing on-premises applications

In the case of moving an application to the cloud one requirement that often comes up is the need to take a single-tenant application that is normally installed in a single customer’s data center and turn it into a service that can then be sold to multiple tenants.  There are, of course, multiple ways to do that and a full treatment is beyond the scope of this blog post.  A lot depends upon the existing architecture of the application and it’s data.  There are three tenancy architectures that can work:

Single copy of the application per Tenant

This is the case where we have an existing legacy applications and we decide to install a cloud resident version of the application and its data for each tenant/customer.  This may seem to be an easy approach but often leads to changes in the codebase to accommodate individual tenant and can lead to having to maintain different versions of code for different customers.

Similar considerations exist on the data base and data storage side of things.  Having multiple data bases per tenant seems simple but can lead to exorbitant costs as the number of tenants increases.  This is not really a very scalable solution.

Multi-Tenant with a common data schema

In those cases where a single user interface can be used to support all tenants you still have to worry about whether there are any application, storage or database customization requirements on a per-tenant basis. (The need to provide different user interface branding for different tenants, called White-Labeling, brings with it a whole additional aspect of complexity. You may have to resort to more dynamically and perhaps database driven creation of your user interface to support that as we did on one project that we worked on.) In many cases per-tenant customization can be accommodated by adding a Tennant-ID to database tables and perhaps adding  some extra user definable fields to the schema to account for minor customization requirements.

Multi-Tenant with separate custom schemas.

If conversion of the application and data require major customization capability you may have to bite the bullet and have a different schema for each tenant. This could be separate tables in the same database or even separate databases.

Azure Specific Database Scalability considerations

Windows Azure SQL Database is a Microsoft managed SQL Server database as a service offering (DBaaS?) that can be used for relational storage in Windows Azure. It is highly compatible with on-premises SQL Server and so it provides a streamlined migration path for moving an on-premises application to the cloud. 

All of the multi-tenancy discussion above is relevant to this service.  One limitation of Windows Azure SQL Database, however, is that it currently has an upper per-database size limit of 150 GB.  Even in the case where you can share a single database between all  your tenants, as discussed above, improved scalability can be gained by spreading your tenants across multiple physical databases. At one end of the spectrum you have the very expensive solution of one database per tenant. At the other end you can have  a single shared database for all tenants.  The latter limits your upper scalability limit to 105GB.

Both of these approaches have drawbacks. There is a middle ground called Database Sharding, as implemented in Windows Azure by Microsoft with their Federations feature. It can be used to spread all your tenants across a smaller number of SQL Azure Databases and handle some of the mechanics of accessing and  maintaining that configuration.  

Refer to Federations in Windows Azure SQL Database for a more detailed treatment of this this subject.

And for more detailed coverage of the subject of Windows Azure Multi-Tenancy you should read the Microsoft Patterns & Practices group blue book: Developing Multi-Tenant Applications for the Cloud.

Unpredictability of costs caused by OpEx model

One of the great features of leveraging the Cloud is that you are no longer required to determine your capacity requirements up-front in order to acquire adequate server, data storage and network resources.  As we discussed in Part 1 of this series this pay-as-you-go model is one of the strengths of the OpEx model as opposed to the classical CapEx model where you are required to budget for the high-water mark of your capacity requirements.  This very advantage, however, can also prove a disadvantage to corporate executives that want to know in advance what your IT costs will be.

The answer is that, despite the change in models, you are still required to do capacity planning and budgeting.  What OpEx gives you is more flexibility to handle unexpected situations and be more responsive when requirements change (either up or down) in an unexpected manner. In particular the scale-down capability, when requirements decrease, is particularly advantageous to save money when capacity requirements decrease temporarily.

Summary

In summary, not everything has to be moved to Windows Azure!  The Cloud just represents a deployment option for some or all application components. Use it where it makes good business and architectural sense. Take prudent business risks and proceed cautiously, but don’t get left behind by your competitors. Smile

Bill Zack

Contact me via Email: wzack@live.com

Visit my Blog: Cloudy In New York

Visit me on LinkedIn

Follow me on twitter: @WilliamHZack

Call me at 203 545-2339 (mobile)

Posted in Application Development, Architecture, Cloud, Cloud Computing, IaaS, PaaS, SaaS, Security, SQL Azure, Windows Azure | Tagged , , , , , , , , , | 1 Comment

Moving Applications to Windows Azure–A Methodology


Earlier this week at the NYC/NJ Windows Azure User Group meeting I presented: Moving Applications to Windows Azure, a live version based on my To Cloud or Not To Cloud blog post series. This was a joint meeting of the NYC/NJ Windows Azure User Group, The New York Enterprise Windows User Group and several other local user groups.

We had a record turnout at the meeting where we covered :

  • Finding an application that is appropriate to move to Windows Azure
  • Deciding how to move it using Software as a Service, Platform as a Service or Infrastructure as a Service
  • What to do about new and legacy applications

We also discussed the decision process for guiding an evaluation and wrapped up by discussing several potential showstoppers and how to mitigate them.

The slides from this meeting are located here. They compliment Parts 1 and 2 of the blog post series together with a hint of a coming follow on post covering Cloud Showstoppers and their Mitigations. Smile

Stay tuned.

Bill

Contact me via Email: wzack@live.com

Visit my Blog: Cloudy In New York

Visit me on LinkedIn

Follow me on twitter: @WilliamHZack

Call me at 203 545-2339 (mobile)

Posted in Cloud, Cloud Computing, Windows Azure | Tagged , , | Leave a comment

To Cloud or Not To Cloud–Part 2


In a previous post we covered a simple decision flowchart for evaluating applications that you might want to move to ”the Cloud”.

We talked about application “fitness” for the Cloud and how to decide which ones in your application portfolio would benefit from the application of Cloud technology.

In that post we covered the branch of the chart that addressed brand-new applications, leaving the more difficult existing applications for later discussion.

The bottom line for a new application, as Bill Wilder so eloquently put it (and with fewer words than I used Smile) was “Use SaaS if you can… else use PaaS if you can… else IaaS (the last resort!)

Migrating an Existing Application

Now lets take a look at migrating an existing application to Windows Azure. This involves the other side of the decision flowchart.

image

Admittedly even this chart is a bit of an oversimplification, but it should serve to frame the discussion.

Two-Tier Web Site with Back-End Relational Database

If your legacy application is a fairly simple two-tier web farm based application backed by a SQL Server (or MySQL) database then the new Windows Azure Web Sites feature might be appropriate. 

This new feature, currently in CTP, allows you to deploy a web site backed by a relational database to Windows Azure. In most cases this is the same application that you might already be running on-premises. 

If, however ,your application is a multi-tier application or uses any unsupported features then there are other considerations.

Not a Two-Tier Application

If your application is a multi-tier application, for instance architected in separate Presentation, Business Logic and Data tiers, then the Web Sites feature is not appropriate. (There is an exception to this rule, however that we will talk about later on.) In that case your choices are modify it to use PaaS or forklift it into the Cloud as-is using IaaS.

Uses Unsupported Features

Even if it is a well-designed two-tier web application there may still be impediments to moving it to Windows Azure using the Web Sites Feature. For instance in the case of a web site that uses a SQL Server database you may have the situation where your application uses some SQL Server features that are not supported by Windows Azure SQL Database  (the new name for SQL Azure) For instance SQL Server features like Full-Text Search, some collating sets, and some other SQL Server features  are not yet supported in Window Azure SQL Database. ( See this comparison of features.)  If that is the case, consider migrating the application using the new Windows Azure IaaS features.  Also, if your application uses any other unsupported features like COM+ then the Web Sites feature may not be appropriate.

Another Windows Azure SQL Database “feature” to be aware of is that there is currently a 150 GB single database size limit in Windows Azure SQL Database. If your database is within that size limit then the Windows Azure Web Sites feature may well be the answer. Of course there is nothing wrong with also migrating your application to PaaS, especially if you plan to start taking advantage of other Windows Azure PaaS services. (We will talk about this in just a bit.

If your current database is larger than 150GB then that you may have to split it up into multiple smaller databases, assuming that is possible given your current database schema. Windows Azure platform provides a Sharding feature to support your doing this but be aware that some database redesign and application modification will probably be required.

If you don’t want to do that then moving the application to IaaS is a possible approach.

There are also other on-premises web site and database features that may not be supported by the Web Sites feature.

Windows Web Sites and Cloud Services Web Role seem to have a lot of similarities so it is useful to understand the benefits of each and when they may be indicated.  There have been a number of excellent blog posts on this subject by Larry Franks and Brian Swan, Shaun Xu and others. This table from Shaun Xu is a good summary to help you decide. If you need a feature that is not supported by Web Sites you may need to use a Cloud Service (Web Role).

 

CLOUD SERVICE

WEB SITE

OS

Windows Server

Windows Server

Virtualization

Windows Azure Virtual Machine

Windows Azure Virtual Machine

Host

IIS

IIS

Platform

ASP.NET WebForm, ASP.NET MVC, WCF

ASP.NET WebForm, ASP.NET MVC, PHP

Language

C#, VB.NET

C#, VB.NET, PHP

Database

SQL Database

SQL Database, MySQL

Architecture

Multi layered, background worker, message queuing, etc..

Simple website with backend database.

VS Project

Windows Azure Cloud Service

ASP.NET Web Form, ASP.NET MVC, etc..

Out-of-box Gallery

(none)

Drupal, DotNetNuke, WordPress, etc..

Deployment

Package upload, Visual Studio publish

FTP, Git, TFS, WebMatrix

Compute Mode

Dedicate VM

Shared Across VMs, Dedicate VM

Scale

Scale up, scale out

Scale up, scale out

Another good introduction to Web Sites, together with an overview of how to create one is this one by David Pallmann.

Other Considerations

That about covers our exploration of the decision flowchart for now. As I said earlier in this series even this is somewhat of an over simplification but it is useful to help tease out some of the major considerations in moving applications to the Windows Azure Cloud.

After the first post in this series I received a number of excellent comments via multiple internet channels which I summarized in the comments section of  that post. Next time we will cover some of those comments in more detail and also talk about hybrid solutions that combine Windows Azure Web Sites with other Widows Azure services such as Service Bus, Caching, Windows Azure Storage and other Cloud Service role types such as the Cloud Service Worker Role.

Bill Zack

Contact me via Email: wzack@live.com

Visit my Blog: Cloudy In New York

Visit me on LinkedIn

Follow me on twitter: WilliamHZack

Call me at 203 545-2339 (mobile)

 

Posted in Uncategorized | Leave a comment

To Cloud or Not To Cloud?


 

image

That is the question. Right now a lot of companies are struggling with the decision as to how (or if) to take advantage of public Cloud technologies such as those provided by Windows Azure, Amazon Web Services and other public Cloud platforms. Clearly there are advantages to be achieved by appropriate use of these technologies, however it is not totally clear as to what applications (or parts of applications) can and should be moved to the Cloud.  On one hand there can be great cost and scalability advantages. On the other hand there are questions of security and Internet latency to be dealt with. So the question is: What applications (if any) can and should I take to the Cloud? And what are the decision criteria for when and how to do it?

A lot has been written both pro-and-con about the Cloud lately. In fact so much that it can be very confusing for a first time potential user.  In order to help you making the decision I have provide a modest flowchart-based decision process for deciding when and how to move applications to the Cloud. (Note If you are not familiar with Cloud terminology please refer to the publication: NIST SP 800-145, The NIST Definition of Cloud Computing for an excellent introduction.It is important to understand that terminology because there is a lot of hype surrounding any new technology such as the Cloud.)

(There are a couple of fun expressions in Net-Speak: IMHO (In my humble opinion) and IMNSHO (In my not so humble opinion. What I am putting forth in this series of blog posts falls into one (or both) of those categories. Smile

You should also be aware that this flowchart covers the considerations at a fairly high level and that there are a lot of sub-decisions that you will have to take into consideration when making your choices. Hopefully, however, this will give you a good start on a process.

Since this will be a series of blog posts discussing various decision points in the flow you can also play along and try to infer what I am about to say about the flowchart in future posts.

Although a similar decision methodology could be produced for any public (or for that matter private) Cloud platform this one will be based on Windows Azure. Although I have architected and built applications based on Amazon Web Services as well as Windows Azure, Windows Azure is the platform that I know best having been a Windows Azure Subject Matter expert while at Microsoft.

The following flowchart is a high level mapping of the decision process that one could go through in making decisions and executing your Cloud strategy.

image

Select an application from your portfolio

The first task before us is deciding which application to move to the Cloud. This could be an existing application or one that hasn’t even been developed yet. First we need to determine if it is “fit” for the Cloud. This is very important because , although there are significant cost and other advantages to leveraging the Cloud it is also possible that choosing the wrong application could be more expensive for you in the long run.

Is it Fit for the Cloud?

There are several typical workload patterns that lend themselves well to a Cloud solution. These workload types have been well documented by Microsoft, Amazon and others.

On and Off workloads

You have batch job processing which might be required to be run at periodic intervals.  The capacity required to support running the job might be needed only during those intervals and be wasted for the rest of the time. Why pay for idle capacity that you are not using?

Workload that is Growing Fast.

You may have an idea which could turn out to be the next Facebook. Or it could be an idea whose time has not yet come. There is no way to know whether it will be successful or not. Why acquire the hardware capacity necessary to support you application at scale when you can contract for resources on a pay-as-you go basis and scale them up or down as required.

Unpredictable Bursting:

With this type of workload you may suddenly find yourself “discovered” by the world and need to scale up to meet the sudden demand. An increase in demand could also cause a decrease in performance if you cannot scale up quickly.  On the other hand, if the peak demand is not sustained over a long period of time then scaling down might be just as important as scaling up.

Predictable Bursting

With predictable bursting we have the type of workload that is subject to periodic peaks and valleys. It could be an ecommerce site that is hit hard during the Christmas season and less so during other months. Or the periodicity could be on a monthly, weekly or even daily basis.

What if none of these patterns fit?

Even if the application does not fit these characteristics it may still be appropriate to take advantage of the Cloud by implementing a Hybrid combined Cloud/On Premises solution. My friend Bill Wilder who is a Windows Azure MVP in Boston and the author of the excellent Cloud Architecture Patterns book has suggested that my decision methodology could still be applied to each layer/tier of an application architecture. That could be appropriate where, for instance, some parts of an application may not be able to be moved into the Cloud because of security, regulatory or other reasons. It is possible that some parts of the application may have to remain safely behind the firewall while other parts can still take advantage of the Cloud.

Implementing a new application?

Assuming that you have decided that the application under consideration is one that should be moved to the Cloud the first major decision that you are faced with is whether it is a new application that can take full advantage of the Cloud or an existing application that my or may not be easy to move to the Cloud.

Even for a new application that has not yet been written there are three choices to make.

 

image

1. If the application is fit for a Software as a Service (SaaS) solution and there exists a commercial service that can satisfy the requirement then simply contact for the service. That is the simplest approach because you have no development to do and no infrastructure components to maintain. The service provider does it all.

2. If the application is not amenable to a SaaS solution then the next thing to consider is whether it is appropriate to develop it using the Platform as a Service (PaaS) services provided by your favorite Cloud provider, in our case Windows Azure.

3. Finally, if none of those approaches are appropriate then you can always implement it using the Infrastructure as a Service (IaaS) capabilities of the Cloud provider.  Since you can do pretty much everything that you can do on premises in the Cloud using IaaS that can be your final and all inclusive choice.  (Note: Obviously that is a bit of an over simplification since there are other factors introduced, both positive and negative, by implementing an application in the Cloud vs. on premises.  For instance, latency over the internet is usually a negative factor and the high degree of scalability available in the Cloud vs. on-premises is a positive factor. But as a first level approximation it is  good start.)

(Note: If you are not familiar with Cloud terms such as PaaS, SaaS, IaaS please refer to the NIST publication referenced above for an excellent introduction. It also covers many of the Cloud-related terms that you will come across when dealing with the Cloud.)

What about an existing application?

Now the fun begins, because there are a lot of decisions to make and a lot of design points to consider. While you are waiting for the next post in this series here is some homework. Take a look at the rest of the flowchart and try to anticipate what we will be covering. Smile

image

(To be continued next week)

Bill Zack

Posted in Architecture, Cloud, Cloud Computing, IaaS, PaaS, SaaS, Windows Azure | Tagged , , , , , , | 1 Comment

Windows Azure 2.0 at the New York Code Camp


 

A few months ago I did a blog post on delivering my Azure 2.0 talk at the Hartford Connecticut Code Camp.

With Windows Azure things move fast (Internet time anyone? Smile) and I recently did another (updated) version for the New York City Code Camp run by the New York City .NET Developers Group (of which I am also one of the leaders).

image

 

You can find the updated deck from that presentation here.

Bill Zack

wzack@live.com

Posted in Architecture, Cloud, Cloud Computing, IaaS, PaaS, SaaS, SQL Azure, User Groups, Windows Azure | Tagged , , , , , , , , | Leave a comment

Introducing the New Windows Azure at the Hartford Code Camp


On Saturday June 23rd I presented an updated version of my Windows Azure 2.0 Platform Overview at the Hartford Code Camp.  Since there were quite a few major Windows Azure announcements on June 7th this was a major update of my existing presentation.  In fact I was updating it until the night before the presentation. Smile

image

A Link to the Windows Azure 2.0 Platform Overview presentation deck is included above. This deck is one that I have been evolving and updating over the last 4 years as Windows Azure has been evolving and reflects my current understanding of the features now in the product.  That includes old standbys such as Cloud Services (Web and Worker Roles), Storage (Blobs, Tables, Drives and Queues), and SQL Database (the new name for SQL Azure)  as well as the new Web Sites, Virtual Machine and Virtual Networking Infrastructure as a Service (IaaS) features and Linux support. 

The presentation also has some good references to get you started learning about Windows Azure.  In particular I want to draw your attention to the new Windows Azure Training Kit which was just released last week. 

Bill Zack

image

Posted in Application Development, Architecture, Cloud, Cloud Computing, Event, IaaS, Linux, PaaS, User Groups, Windows Azure | Tagged , , , , , , , , , | 1 Comment