From the session Architecting Cloud Services at the PDC 2008. Not only which design consideration you might want to take, there’s also a lot of more in-depth information about how Windows Azure works is designed.
Yesterday I blogged about the announcement of Windows Azure, and the insight of Azure comes more and more clear. The SDK it out so the information is dropping in step by step.
I think Windows Azure is more then just a Cloud Service. It’s remote hosting. All your applications which do something with the Web, can be hosted in the cloud.
The bold and underlines remarks are questions I try to answer later on, because these question I have as well.
I’m sorry that this blogpost seems a bit ‘stacato’ they are almost a direct note of my sessionnotes.
A nice thing about Windows Azure is that it does ‘eat you own dogfood’ , for example the storage service makes use of Windows Azure.
So what are characteristics of Cloud computing?
- Scale-out not scale-up
- Add and remove capacity on demand
- Pay for what you use as you go
- Automation is key to reducing cost
Windows Azure goal is to automate life cycle as much as possible
- As a developer you develop your service, then you get your Azure service provisioned, after that Azure helps you to pick up your code.
Like:- Mapping and deploying to actual hardware
- Network configuration
- Maintain goal state:
- Monitoring (Done by Azure)
- React to events
- Service model Guides Automation
- Describes service as distributed entities
- Authored by service developer
- Configured by service deployer
- Logical description of the services
- Same model used for testing and production
- Where is development / test / staging (user acceptance test environment) / production?
WJC: As far as I can see at this moment there’s only staging and production.
- Where is development / test / staging (user acceptance test environment) / production?
- Same model used for testing and production
- Describes service as distributed entities
- Windows Azure Service Model elements
Just a bit like WCF these are the elements which needs to defined in some sort of way.- Service
- That’s the set of roles, groups and channels
- Role
- Group
- Endpoint
- Channel
- Interface
- Contract?
- Service
Update domain dictate the order of how the updates are being, this gives you the control which what to and when to update. Even rollback en rollforward.
Dynamic Configuration Settings
- There is no registry for services
- Application configuration settings are declared by the developer (declarative) and can be set finally by the deployer
- System configuration Settings
- Pre-declared, same kinds for all roles
- Assigned by the system.
Windows Azure Automation
- Fabric Controller (This is the brain of the system)
- Maps declarative service specs to available resources
- Manages service life cycle starting from bare metal
- Maintains system health and satisfies SLA
- What’s special about it?
- Model driven service management
- Windows Azure push button deployment
- This is a an almost automated process, there’s some manual intervention needed, for example assign the fault domains and the update domains
- It’s can send an message back when an update failed and will rollback.
There’s a medium trust code access policy.
Windows Azure is designed highly available.
- Network redunded designed
- Services are deployed across fault domains
- Load balancers route traffic to active nodes only
A thing to think about is how Microsoft is going to manage updates on the cloud servers. In some cases it might happens that an update depreciated some code of you. At this moment only security patches are being applied. But I’m very curiously about the strategy for updating.
The roadmap:
Windows Azure PDC release:
- Automated service deployment from bare metal
- Subset of service model simple set of service templates
- Changing number of running instances
- Simple service upgrades or downgrades
- Automated service failure discovery and recovery
- Hardware management
2009+:
- Expose more of underlying service model
- Richer service lifecycle managing
Design considerations when developing a Cloud hosted Service / Application
Characteristics of Cloud computing
- Scale-out not scale-up
- Add and remove capacity on demand
- Pay for what you use as you go
- Automation is key to reducing costs
Cloud services design considerations
- Failure of any given node is expected
- View each node as a cache
- State has to be replicated
- No one-time install step
- Application need to reinitialize on restarts
- Do not assume previous local state is available
- You have to create some sort of state management, because you can’t do any asumptions on in
- Configuration changes due to load or failures
- Handle dynamic configuration changes
- Services are always running
- Service rolling upgrades/downgrades
- Services must handle data schema changes
- Services are built using multiple nodes/roles
- Document your Service Architecture
- Document your communication paths of elements
Other wise nobody doesn’t what where, why and how.
- Services can grow very large
- Careful state management at scale is needed
- Some should be available as standard with Azure.
- Careful state management at scale is needed
Benefits of adhering to Windows Azure Design Point
What does Azure does for you?
- Windows Azure manages services not just servers
- Tell it what you want and it will automate the details
- Please show me more of that 🙂
- System manages services, nodes and network
- Tell it what you want and it will automate the details
- Automates service life-cycle management
- Consider where to focus on
If your service becomes big, what is better / more cost effective. Invest in usage or just scale-our.- But this is also very depended of the pricing model Microsoft is going to have.
So this is again really a lot of information, but it sounds promising, blog ya soon 🙂