About
Richard Conway, formerly techierebel, now azurecoder due to his cloud upgrade is an author of several books on development and security, academic and nightmare to work for. After floating around the City of London for 11-12 years he founded the Clarendon Group with Mitch Bulajic (which has surprisingly lasted for 4 years, longer than either of the directors have been able to hold down a job for!) and one other string to their bow is a cloud practice which has successfully completed enterprise development projects and migrations. Along the way Andy Cross, Azure developer extraordinaire, has partnered with us and we now have a formidable company called Elastacloud Limited which is a Microsoft Partner. There are several of us in the UK but we also have an office in Belgrade where we have several talented developers on our books. Feel free to contact us for any quotes or free consultations for Azure work!
azurecoder
Andy Cross
Richard,
Why not use the powershell tools provided and supported by the Windows Azure team?
We are tackling the same problem and currently leaning towards powershell. Thought I’d get your rationale before we go further down our current path.
Also, the things we are running into seem to be tied to Azure itself, not the powershell libraries. Examples:
- Re-creation of a role wont preserve public IPs, have to make sure we only update.
- Can’t externalize environmental configuration from deployment bundles as cscfg is incomplete compared to Web.config
- No AD support means SQL credentials are plaintext
- Etc.
Two questions:
1. Does Fluent Azure provide an easy workaround to this and other issues?
2. Are you running into and solving the same issues?
Cheers,
Saad
.
Saad,
It depends on what you want to do as to what you need to use. WAPP CmdLets are okay. They provide good functional CmdLets that you can pipe and script and create some very complex deployment scenarios. The team supporting them I think are evangelists not the product team but they seem to be very consistent with their releases (at least in the last few months) which is good for a codeplex hosted project! If deployment and or CI is your major concern then I would use Cerebrata CmdLets which are far richer and will involve a lot less work on your part to get up and running.
As far as the problems you cite. Some of them are indeed systemic and the Fabric is a rapidly chaging ecosystem so be mindful that over the three years I have been used Azure I have seen vast changes and the next three years will probably lead to far more.
1. In terms of the fixed IP address per deployment this will depend on your architecture. It’s worth tending to avoid situations where you have this dependency. The most trying form is running into external firewall issues such as tying down a SQL Azure firewall to your deployment IP or any external firewall but reactive scripting can generally get around this. Certainly you can use Fluent Management in this way but you can equally use powershell.
2. Again this depends on how you write your applications and how much change you need in your web.config. Web.config provides a much richer config set with sections whereas .cscfg contains name pair values. In effect it is designed to parallel the same kinds of needs as java prop files. You can speed up the redployment process by designing your own push updates to web.config through a variety of secure means to all running instances or preferably using web deploy (translatable beyond a single instance via web accelerator for webroles by Nate Totten – on github).
3. This is a problem for many people (especially DBAs!).
In terms of Fluent Management it was designed to be an alternative interface where you don’t want or need a powershell host. It’s still very much in beta but the next version (v0.4.0 – it’s evolving very fast these days and will probably be out of beta in a couple of months) will see it enabling RD and SSL for a new deployment with a single line of code (as well as enable a variety of plugins and settings). These are things that you can’t currently do with WAPP CmdLets. It’s really written as a library you can use in a reactive setting rather than a proactive one like you would powershell e.g. bespoke autoscaling, altered rebuild and deployment with different parameters in the .csdef, building of guis around this for ease of feedback so you don’t need to embed a PS host or pipe output.
If you are deploying an application to Azure that needs to be automated then powershell is a good choice although I would opt for Cerebrata over WAPP.
Hope this helps.
Richard
Interesting take and much appreciated.
We have licenses for the Cerebrata tools and have been leveraging other portions. My understanding was that the Azure toolkit was slowly eclipsing the Cerebrata tools. Will have someone look into it.
We asked MSFT about support on the powershell libraries through normal channels and the answer was yes.
Thanks for the insight!
Saad
No problem.
Cerebrata CmdLets are definitely the right choice for CI or deployment in the manner we’re discussing. If you mean the v1.6 SDK by toolkit what’s more relevant are the Service Management and Storage Service REST APIs that the fabric exposes per subscription; both WAPP and Cerebrata are just wrappers on this.
As an example of a functional difference, when you deploy something to a hosted service there are several steps that need to be followed. Each step needs to be explicitly undertaken with WAPP (e.g. create storage account, upload package, create deployment, start deployment). WAPP is a very functional, not task oriented (although the 2.2 update was a step in the right direction) and does not aggregate these whereas Cerebrata views many actions like this a common task so will consolidate the behaviour in a single CmdLet. The fluent management api takes a similar approach.
MSFT are very keen on being seen to back powershell CmdLets for everything they do now but with the best will in the world these are hosted on an open source site and until recently have had fairly infrequent updates. I’m not sure a dedicated team is singularly responsible for this but more likely it is adjunct of a workload that the Wade et al are upkeeping. I might be wrong though either way Cerebrata is more fit for purpose.
All the best,
Richard