Software delivery with even less friction

I’ve talked before about the joys of continuous software delivery before.

Well, I’ve been building a couple of micro sites recently and thought it would be nice to try out a few new technologies and techniques.

Firstly, I’ve built them with HTML5 and the Twitter Bootstrap framework, there’s a very good tutorial here. Bootstrap provides a combination of CSS and Javascript to make building a clean, responsive site without having to worry about cross browser compatibility.

We use TeamCity and Octopus Deploy for another much larger site. For micro sites I think that Octopus is overkill. A large complicated deployment workflow isn’t necessary for a simple micro site. Octopus really comes into its own when you need to deploy to a large web farm, or you need a workflow prior to releasing the website into production.

I thought I’d give Appharbor a go. Appharbor is a newish form of web hosting. They host your website as you’d expect, but they’ve also integrated source code control and source code building into their offering.

All you need to do is create an ASP.Net website project, initialize your git repository then push it to Appharbor. Your website is then built, any tests are executed and then, if you’re green, the website is deployed.

Appharbor is focused on the .NET space. Windows Azure offers a similar, though more expensive, option. Other languages have similar services available like heroku and brightbox.

One major lesson learned. Your tests need to give you a high degree of confidence that your site will work in production. Your tests are your only gate keeper stopping you from deploying a broken site. So, if your tests are green, the site had better work.

I’ve aimed for 100% code coverage with the tests and have managed to achieve 94.41%. The other 5 odd percent is the code calling the API of a third party website. Tough to test code talking to externals, so I manually test that code. Not ideal but I can live with it.

The micro sites in question are a C# Weekly launching early next year and the same for F# Weekly due a little bit later.

The visuals on the sites are a little bit minimal, but everything does work.

Google Chrome OS from a sys admin perspective

What does Google’s recent announcement that it is getting into the operating system business tell us from a sys admin perspective?

For a start whatever effects it will have are some way off. Chrome OS isn’t due to be released until the second half of next year. It is amazing how much fuss a company like Google can generate with a single press release. Chrome OS doesn’t exist yet, and won’t exist for another year and yet here we are all talking about it like we’ve never seen a Linux based NetBook OS before.

The main thrust of Google Chrome OS seems to be to strip everything out except the web browser. A kind of back to basics operating system predicated upon applications being in the cloud where all you need to play is a modern web browser and an internet connection.

From a sys admin point of view that sounds great, all I get to do is give everybody a dead simple laptop with a dead simple operating system running on it, hook it up to the internet and then let the users log into their cloud applications. I’m not responsible for the cloud apps, so my responsibility ends at the router. Somehow I doubt things will work out like that.

Until the manageability of all those nice cloud based applications is resolved I can’t see how NetBooks and their ilk, based upon Chrome OS or otherwise, are going to take off as workhorse PCs in even small/medium sized organisations never mind enterprise level.

Elastic clouds with elastic bills

I mentioned this in a comment over on John M Willis ESM Blog. I thought it deserved a post all to itself because I think it’s important.

One anxiety I have with hosting my websites is the bill I need to pay each month. There are many many hosting options out there, all with their own particular risk characteristics.

With the advent of on-demand cloud offerings like Amazon EC2 there are lot of new options. One of the characteristics of cloud offerings is easy scalability. Scalability does have a problem though, because your bill will scale too.

The main thing that attracted me to my current hosting provider was the capped bill. I effectively lease a virtual pipe into my server through which all of the traffic passes. If the traffic exceeds the capacity of my pipe, then some of the requests start failing. Whilst that isn’t ideal, it is better than the alternative, and I can always buy a bigger virtual pipe.

Say I get a denial of service attack on my site or my site gets hacked and used to do spam emails or launch a DoS attack, am I going to be presented with a whopping great bill at the end of the month? Happened to us when we were at Rackspace when we paid for the bandwidth we used over the standard 100GB threshold. We were presented with a large bill because a server we were in the process of decommissioning got hacked and used to send spam.

The cloud vendors need to provide a range of options that make billing more manageable and predictable.

How will cloud computing change network management

The big selling point with cloud computing is that computing capacity grows and shrinks depending upon the load being put upon it. You typically only pay for CPU (by the hour) and storage (by the month) you actually use.

If your website enjoys a sudden surge in traffic, by appearing on the front page of slashdot for instance, then extra servers will be provisioned automatically. Once the peak load passes and more normal traffic levels return, the extra servers are automatically de-provisioned.

How will cloud computing impact upon network management?

Service oriented monitoring

Cloud computing makes network and server infrastructure invisible. A large part of existing network management is involved with making sure that the network and server infrastructure is working properly.

The focus of network management in a cloud environment shifts away from managing infrastructure to managing service availability & performance.

One of the big sells of cloud computing is not only outsourcing the provision of a scalable, enterprise grade network, but also the necessity to manage it as well.

Root cause analysis will effectively come down to ringing your cloud vendor’s tech support team. Instead of your painstakingly planned network management system tracing the root cause of your outages, you’ll be relying upon your cloud vendor’s painstakingly planned network management system instead.

Standard cloud instrumentation

Your cloud vendor provides detailed usage statistics of your cloud through the cloud vendors management portal. In order to use this information in your own network management system you need it to be available in a format that can be read from your network management software.

Many network management systems have fine extensibility mechanisms so that you could wire up your network management system to use your vendor’s instrumentation.

A better solution would be for a standard to emerge that all cloud vendors implement. Not very likely given the diverse offerings in the cloud computing market. Amazon EC2 has little in common with Google Apps for instance.

The more likely scenario is that a winner will emerge eventually and that will become the de facto standard. Looks like Amazon at the moment, but I wouldn’t underestimate either Google or Microsoft. Microsoft in particular have a good deal to lose if they don’t allow Microsoft centric web developers take seemless advantage of cloud computing.

Configuration management

One of the major issues with compute clouds is the process of configuration management of the software image to be deployed. If the software running in the cloud has a bug, then I need to be able to revert to a previous image or upload a new one quickly.

In addition, controlling when new software is deployed is likely to be very important. I’m sure you don’t relish waiting around for an off peak time period to upload new software, it would be useful to have your network management system to do it for you.

Whilst configuration management is a function of network management, few tools outside of the big 4 are able to do it.

Managing the cloud in the cloud

The obvious place is to put your service oriented monitoring in the cloud right alongside your application. Whilst such an approach will work most of the time, what happens when your cloud vendor’s network dies? All of the major cloud vendors have had network outages so it isn’t a theoretical risk.

An alternative to deploying your own monitoring solution could be to use one of the many vendors promoting SaaS based online monitoring solutions. Whilst that is probably going to be a more robust solution, it may be difficult to know precisely how the vendor has deployed their solution. What if the vendor is using the same cloud computing vendor that you have chosen? Then it won’t be any better than deploying your own monitoring solution in the cloud.

One of the side effects of managing in a cloud world is that vendors will need to be more open about their infrastructure arrangements. If your management vendor is using a cloud then they need to be open about it.  Otherwise, when the 800 pound gorilla of the cloud computing space inevitably develops, there may be a danger that both management and managed services use exactly the same infrastructure.

Clouds are made of data centres, right?

Compute clouds are going to be housed in data centres, big ones too and lots of them. That’s good news for the enterprise network management vendors because those data centres are going to need managing.

People running small & medium sized data centres are likely to be the people most attracted to cloud computing. Therefore, there is likely to be a consolidation away from the small and medium data centres to large data centres. The only people who’ll be able to justify the cost of running a small or medium data centre are those with specialist requirements that cannot easily be accommodated using a cloud based solution.

It is hard to see the transition as anything other than party time for enterprise vendors. Open source enterprise vendors will be in a very good position to win new customers. The transition to cloud computing is a once in a lifetime disruption causing a lot of cloud vendors to look for new, more flexible tools to help them manage their new, ultra-flexible infrastructure. In addition, the new cloud vendors are utilising open source software extensively in building their offerings, so they will be more amenable to open source based network management solutions.

Conclusion

Cloud computing is very much in its infancy. Clouds in their current form are likely to appeal to companies who would otherwise have opted for shared or virtual machine hosting in the case of Google Apps or one or more dedicated servers in the case of Amazon EC2. In either case, neither would be in the market for network management systems.

The next wave, when the early adopters have ironed out the problems,  will be from companies replacing small or medium sized data centres with a compute cloud. These companies will still require a management system, but one tuned to managing in a cloud environment not a data centre environment. They’ll need to monitor the services they are providing and manage their interaction with the cloud.

On the other hand, the cloud computing vendors themselves will require full blown enterprise grade network management systems. A great opportunity is being presented to the more nimble vendors, able to quickly fine tune their products to the particular requirements of the cloud vendors. The open source, enterprise oriented network management vendors will find their offerings chime well with the cloud vendors. The cloud vendors are already heavy open source software users.