Tag: cloud storage

Windows Azure Web, Worker, and CGI Roles – How They Work

This is a write up I’ve put together of how the roles in Windows Azure work.  As far as I know, this is all correct – but if there are any Windows Azure Team Members out there that wouldn’t mind providing some feedback about specifics or adding to the details I have here – please do add comments!  🙂

Windows 2008 and Hyper-V

Windows Azure is built on top of Windows 2008 & Hyper-V. Hyper-V provides virtualization to the various instance types and allocation of resources to those instances. Windows 2008 provides the core operating system functionality for those systems and the Windows Azure Platform Roles and Storage.

The hypervisor that a Hyper-V installation implements does a few unique things compared to many of the other virtualization offerings in the industry. Xen (The Open Source Virtualization Software that Amazon Web Services use) & VMWare both use a shared resource model for utilization of physical resources within a system. This allows for more virtualized instances to be started per physical machine, but can sometimes allow hardware contention. On the other hand Hyper-V pins a particular amount of resources to a virtualized instance, which decreases the number of instances allowed on a physical machine. This enables Hyper-V to prevent hardware contention though. Both designs have their plusses and minuses and in cloud computing these design choices are rarely evident. The context however is important to know when working with high end computing within the cloud.

Windows Azure Fabric Controller

The Windows Azure Fabric Controller is kind of the magic glue that holds all the pieces of Windows Azure together. The Azure Fabric Controller automates all of the load balancing, switches, networking, and other networking configuration. Usually within an IaaS environment you’d have to setup the load balancer, static IP address, internal DNS that would allow for connection and routing by the external DNS, the switch configurations, configuring the DMZ, and a host of other configuration & ongoing maintenance is needed. With the Windows Azure Platform and the Fabric Controller, all of that is taken care of entirely. Maintenance for these things goes to zero.

The Windows Azure Fabric Controller has several primary tasks: networking, hardware, and operating system management, service modeling, and life cycle management of systems.

The low level hardware that the Windows Azure Fabric Controller manages includes switches, load balancers, nodes, load balancers, and other network elements. In addition it manipulates the appropriate internal DNS and other routing needed for communication within the cloud so that each URI is accessed seamlessly from the outside.

The service modeling that the fabric controller provides is a to map the topology of services, port usage, and as mentioned before the internal communication within the cloud. All of this is done by the Fabric Controller without any interaction other than creating an instance or storage service within Windows Azure.

The operating system management from the Fabric Controller involves patching the operating system to assure that security, memory and storage, and other integral operating system features are maintained and optimized. This allows the operating system to maintain uptime and application performance characteristics that are optimal.

Finally the Fabric Controller has the responsibility for service life cycle. This includes updates and configuration changes for domains and fault domains. The Fabric Controller does so in a way to maintain uptime for the services.

Each role has at least one instance running. A role however can have multiple instances, with a theoretically limitless number. In this way, the Fabric Controller, if an instance stops responding is recycled and a new instance takes over. This can sometimes take several minutes, and is a core reason behind the 99.99% uptime SLA requiring two instances within a role to be running. In addition to this the instance that is recycled is rebuilt from scratch, thus destroying any data that would be stored on the role instance itself. This is when Windows Azure Storage plays a pivotal role in maintaining Windows Azure Cloud Applications.

Web Role

The Windows Azure Web Role is designed as a simply to deploy IIS web site or services hosting platform feature. The Windows Azure Web Role can provide hosting for any .NET related web site such as; ASP.NET, ASP.NET MVC, MonoRails, and more.

The Windows Azure Web Role is provides this service hosting with a minimal amount of maintenance required. No routing or load balancing setup is needed; everything is handled by the Windows Azure Fabric Controller.

Uses: Hosting ASP.NET, ASP.NET MVC, MonoRails, or other .NET related web site in a managed, high uptime, highly resilient, controlled environment.

Worker Role

A worker role can be used to host any number of things that need to pull, push, or run continuously without any particular input. A service role can be used to setup a schedule or other type of service. This provides a role dedicated to what could closely be compared to a Windows Service. The options and capabilities of a Worker Role however vastly exceed a simple Windows Service.

CGI Role

This service role is designed to allow execution of technology stacks such as Ruby on Rails, PHP, Java, and other non-Microsoft options.

Windows Azure Storage

Windows Azure Storage is broken into three distinct features within the service. Windows Azure provides tables, blob, and queue for storage needs. Any of the Windows Azure Roles can also connect to the storage to maintain data across service lifecycle reboots, refreshes, and any temporary loss of a Windows Azure Role.

A note about Windows Azure Storage compared to most Cloud Storage Providers: None of the Azure Storage Services are “eventually consistent”. When a write is done, it is instantly visible to all subsequent readers. This simplifies coding but slows down the data storage mechanisms more than eventually consistent data architectures.

Shout it

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Re: Cloudcamp Seattle

Summary Statement:  CloudCamp rocked!  I got to meet a lot of smart people and have a lot of smart conversations!

Ok, so I probably shouldn’t write the summary statement first, but I’m not one for standard operating procedure.  But I digress, I’ll dive straight into the cloud topics and the event itself.

The event kicked off with an introduction and lighting talks by Tony Cowan, Mithun Dhar, Steve Riley, John Janakiraman, Margaret Dawson, and Patrick Escarcega.  Margaret and Steve really stood out to me in their talks, I’ll be keeping an eye on any future speaking engagements they may have.

One of the quotes that led off CloudCamp during the lightning talks was, “If you’re still talking about if the cloud is secure…” you’re already behind, out of touch, missing the reality of it, or simply not understanding the technology.  After further conversation though, it really boils down to the most common excuse.  The statement “the cloud isn’t secure enough” translates to “I’ve got my fingers in my ears and am not listening to your cloud talk”.

Margaret Dawson from Hubspan really took a great stance with her lightning talk.  The talk was titled “To Cloud or Not To Cloud” with “Don’t buy the cloud, buy a solution” as the summarized idea.  The other thing that she mentioned during her talk was she likes adding “AASes” to cloud computing, such as “BPaaS”.  I’ll admit I laughed guiltily along with a few dozen others and forgot to note what BPaaS stands for.  Whoops!  🙂

An attempt at creating a generalized definition of cloud computing was also made.  It was stated that we can, as a community, agree on the following definitions of cloud computing.  The definition involved three parts:

  • Cloud computing is on demand.
  • Cloud computing can be turned off or on as needed.
  • Cloud computing can autoscale without issue to handle peaks and lulls in demand.

Another funny statement came from Dave Neilsen (@daveneilsen), CloudCamp Organizer, “I agree, the cloud isn’t right for everyone” to which someone in the crowd jokingly hollered back “You’re Fired!”  The energy in the audience and each of the sessions was great!

After the lightning talks Dave Neilsen led the conference with a cloud panel to field some questions.  A few topics related to this wikileaks thing 😛 came up along with some others.  I tired diligently to take good notes during this time, but it was a bit fast paced and I left the note taking to be more involved in listening.

These activities kicked off the overall event, which then led into everyone breaking out to different sessions depending on topics created by the attendees.  The sessions included (and I may have missed one or two);

  • Open Source Software in the Cloud
  • Best Practices for Low Latency
  • Intro to Cloud Computing + Windows Azure
  • How does a traditional Microsoft Stack fit in Amazon Web Services (AWS)
  • Google Cloud Services
  • What are your personal projects?

As another aspect of this review I wanted to pull in a few tweets that mentioned or had something useful in relation to the #cloudcamp + #seattle hashtags from last night.

…with that, my cloudcamp review is fini.  Hope to see everyone at the next Seattle Cloud Event!

CloudCamp Seattle!

Cloudcamp Seattle (December 1st)
Cloudcamp Seattle (December 1st)

Tomorrow is the big day!  So be sure to come check out CloudCamp Seattle!  We’re going to have a lot of great attendees, some rock star lightning talks and more.  Make sure to get registered ASPA (click on the CloudCamp image above).

Location:
Amazon HQ
426 Terry Avenue North (At South Lake Union)
2nd Floor Conference Room
Seattle, WA 98109

Final Schedule:
6:00pm Registration, Networking w/ Food & Drinks
6:30pm Welcome and Thank yous
6:45pm Lightning Talks (5 minutes each)
Tony Cowan – WebSphere CloudBurst/Hypervisor Editions
Mithun Dhar – Microsoft Azure
Steve Riley – Amazon Web Services
Sundar Raghavan – Skytap
Josh Wieder – Atlantic.net
Margaret Dawson – Hubspan
Patrick Escarcega – “Managing Fear – Transitioning to the Cloud
7:30pm Unpanel
8:00pm Begin Unconference (organize the unconference)
8:15pm Unconference Session 1
9:00pm Unconference Session 2
9:45pm Wrap-up Session
10:00pm Raffle Books: “Host your website in the cloud” by Jeff Barr
10:15pm Drinks at 13coins sponsored by Clear Wireless Internet

NW Cloud
NW Cloud

Local Organizers:
– Jon Madamba of http://www.sawsug.com
– Shy Cohen
– Krish Subramanian of Krishworld
– Adron Hall (Me)
– Dave Nielsen of CloudCamp

Cloud Throw Down: Part 4 – Perspectives on PaaS

 

Amazon Web Services
Amazon Web Services
  

Windows Azure
Windows Azure

Previous Throw Down…

Alright, time for the battle o’ clouds to roll on. In this throw down I’m going to compare platforms from the infrastructure and platform perspective. Windows Azure takes a very distinctive, and unique, Platform as a Service (PaaS) model and Amazon Web Services takes a very Infrastructure as a Service (IaaS) model. Each of these things start at different architectural levels for applications and provide different architectural perspectives. Before jumping into the comparison let’s take a look at what a developer, IT, or network specialist has to consider when building and deploying an application into either environment.  I’ve highlighted the following steps to the specific profession that each model would most likely involve.

PaaS, Platform as a Service development and deployment model

Steps to Begin Building a Web Application or Service Application

  1. Start a Project in your preferred development environment.
  2. Build the code base.  (Such as a web application or service application)
  3. Create the platform web or service role for hosting the web or service application.
  4. Setup the project deployment with the role parameters.
  5. Deploy the project to that location.
  6. Setup an appropriate domain name and point it at the site via nameserver/DNS.

IaaS, Infrastructure as a Service development and deployment model

Steps to Begin Building a Web Application or Service Application

  1. Start a Project in your preferred development environment.
  2. Build the code base.  (Such as a web application or service application)
  3. Start the OS Instance of your choice.
  4. Install and configure the environment for hosting (IIS, Apache, or otherwise).
  5. Setup the project deployment with the role parameters.
  6. Deploy the project to that location.
  7. Setup an IP address or externally accessible addressing for the instance.
  8. Setup an appropriate domain name and point it at the site via nameserver/DNS.

As one can see there are more steps, and with reason, more costs to IaaS than to PaaS.  With IaaS more control and with PaaS less control, but with the lack of control comes lower costs and barriers for entry.  This is most likely, as I’ve heard more than a few times, why Microsoft has pushed the PaaS instead of going IaaS.

So how do each play out in offering the Platform as a Service?

First off, I have to point out that Amazon Web Services doesn’t really offer a PaaS.  So comparing them directly is almost impossible.  In addition, by not offerring a PaaS it sets up AWS at a disadvantage in this realm.  But that being the case, there are 3rd Party Software Companies that offer PaaS Solutions for AWS such as Makara and Heroku.  In addition there is rumor that AWS may be heading for a PaaS Offering soon.

I’ve fought with this topic in regards to AWS & Azure.  It all really comes down to what your point of view is.  So that’s how I’m going to score each of the services.  I’ll layout a point of view (POV), which will be a simple description of the team that is building the cloud software, what the end goal is from the business in generic terms, then layout what would be a higher or lower cost, and finally which would provide the fastest time to market with the least amount of cost.  It’ll be complex on the back end, but I’ll work to lay it out as neatly as I can.

POV:  A Small Business, less than 15 people, working toward a website style SaaS Product.

  1. The team has enough experience and technical skills to develop the product from AWS’s IaaS or Azure PaaS.
  2. The business wants the product out to market in 3 months.
  3. The team & business knows which geographic regions they need to focus on specifically.
  4. The team wants control over instances and has flexibility of server OS, preventing OS lock in. (i.e. they can use Windows or Linux)
  5. Autoscaling must be robust as traffic is expected, hopefully, to skyrocket as the product becomes recognized and available.

In this situation, AWS wins because of items 1, 2, 3, 4, and especially 5.

POV:  A small business, less than 15 people, working toward a website style SaaS Product.

  1. The team has .NET and Windows deployment experience, but minimal experience around networking, hosting, or infrastructure experience.
  2. The business wants the product out to market in 3 months.
  3. The team & business don’t care what geographic region the website is focused in.
  4. The team doesn’t care about server lock in, Windows is fine by them.
  5. Autoscaling and controlling traffic bursts isn’t a high priority for the team or business.

In this situation, Azure wins hands down based on 1, 2, 3, 4, and 5.

POV:  An enterprise team wants to create a high quality code base, utilizing SCRUM with test driven development practices.

  1. The team knows .NET and Java very well and a little bit of networking, hosting, and infrastructure.
  2. The enterprise wants a steady release cycle of tested, highly reliable code.
  3. The enterprise isn’t worried about which OS the team uses.  Windows or a *nix variant.
  4. Autoscaling is irrelevant, as long as capacity can be brought up and down in a timely manner to extremely high counts exceeding 1000+ instances.

In this situation, AWS wins hands down on 1, 2, 3, and 4.

POV:  An enterprise team wants to deploy regularly, maintain their existing .NET stack, and utilize existing SDKs to keep the ramp up time minimal.

  1. The team wants to use a familiar stack based on .NET and use SDKs if available.
  2. The team isn’t concerned heavily with testable code, mostly just have a framework to build around that is familiar.
  3. The business just wants the team to maintain familiarity with what exists in the company already.
  4. The team wants to provide a single sign on (SSO) security implementation, using the cloud if possible.

In this situation, Azure wins easily for reasons 1, 2, 3, and 4.

POV: A Development team is putting together a public facing SaaS application.

  1. The team wants to use whatever product has the best price point.
  2. The team wants a strong enterprise style message bus to provide application messaging.
  3. The business wants to deploy frequently and as soon as possible.
  4. The team doesn’t care if the code is PHP, Java, .NET, or otherwise.
  5. The team will create high quality code, and will build their own testing mocks, stubs, and other elements if need be.
  6. The team doesn’t intend to use the SDKs from either AWS or Windows Azure, they want to keep lock in minimal so are building to services using good design patterns.

This situation is unique, and causes a tie between Azure and AWS for reasons 1 and 2 combined, 3, 4, 5, and 6.

Windows Azure
Windows Azure

Based on these scorings, things might be a little confusing.  I’ll elaborate a bit on some key points in the next entry on AWS vs. Azure.  For now, I’m going to hand the victory to Windows Azure.  The reason is simple, the PaaS perspective, in a little more than 50% of situation where PaaS or IaaS can be used should go with Windows Azure.  In situations where a PaaS is desired then Windows Azure is pretty much the only serious option out there these days.  Simply, Windows Azure just offers a ton of really serious features via cloud services for a PaaS offering.  Stay tuned for the next grand battle between the cloud giants!