Knock the predominantly proprietary protagonists in Redmond at
Call it ‘transition’ to cloud or call it ‘migration’ -- or call it ‘oh goodness, how the hell do we take our previous approach to boxed-type on-premises software and transition to cloud services?’ as you prefer. The reality is that the (often apparently urgent) need to now shift software deployments into cloud frameworks is keeping plenty of software executives up at night.
If we accept that growth in cloud-based Software-as-a-Service (SaaS) is expected to continue at 20 percent each year through to 2018 (when the global market could reach nearly $85 billion) then it’s clearer to see why cloud has become an imperative. But forget cloud flexibility, agility and OpEx model cost savings for a moment. Moving to cloud can involve the serious re-architecting of a firm’s software model as it throws up all sorts of questions over how, when and where existing legacy software should be updated.
Isn’t legacy software working just fine?
Does all legacy software need to be migrated to cloud anyway? Should a firm now consider its software development with a unified codebase for both on premises and cloud, or have a separate one for each? Should core software application development methodologies now be changed because of the move to cloud? Should software be re-architected or re-factored ‘as new’ for cloud? There are a lot of questions here.
McKinsey & Company ’s white paper ‘From box to cloud: An approach for software development executives’ has this advice which might form part of the secret sauce recipe we are looking for here, “A deliberative process begins with a careful consideration of which codebase type, architecture modification and cloud infrastructure is most appropriate. Then -- to ensure successful execution on the choice made -- software executives will need to make several commitments regarding the scope of the product, the approach to development, and the allocation of resources.”
Microsoft is now talking quite openly to detail how cloud migration can work -- and the above linked report does cover many of the ingredients. The company itself has dogfooding experience of transitioning from (and yet still balancing with) the use of the
Cloud has a different cadence & culture
Brian Harry is a Microsoft corporate vice president working as the product unit manager for Team Foundation Server and Visual Studio Online. Harry explains that transforming a sizeable development team from ‘classic’ software development practices to Agile cloud development is something he talks about a lot. Microsoft’s approach to cloud migration hinges around understanding the cloud has a different cadence and culture.
“The problem I see development teams experiencing very often is that when they go to the cloud, they try to do the same thing but just do it faster -- from requirements to testing to software application roll out and so on. But just shrinking programmer workloads down and trying to do it faster doesn’t work,” said Microsoft’s Harry. He suggests that a deeper cultural shift to new development cycles is needed. “What I did with my team was move from a point where we developed on an 18th month cycle to one where we got it down to six-months, but this wasn’t enough. So I told my team we were going to ship every week! Now we now ship Visual Studio Online every three weeks and things are settled. Forcing this mental shift was important,” he added.
Looking at the actual story with Microsoft Team Foundation Server, the product started out as an on-premises piece of software back in 2005 and began its migration to cloud half a decade later some time in 2011. Harry explains how he tasked his team with taking the original codebase and doing a proof of concept process to port it to the cloud. Although this initial port was by no means exhaustive, it gave the team what they needed to know (and the impetus) to develop the fully-blown cloud product which became Visual Studio Online.
How cloud software is actually different
“The full development process took perhaps a year… and then, ultimately we did the flip-over from developing first for on-prem to cloud first. But hey, let’s remember that as much as 90% of the code base is the same. What differs with this cloud product are aspects of identity -- this is always a key difference when firms are looking to build new cloud application structures. Input Output channels will also differ and (logically) the way we treat storage will also change in cloud. For our on-prem world, all storage is stored in Microsoft SQL Server. But Windows Azure storage is cheaper and structured differently,” said Harry.
What Microsoft is underlining is the fact that some software application components are as good as identical in the cloud when compared to their on-premises counterparts. But, crucially, the shape of the implementation of the two pieces of software are completely different at the back end -- often due to factors such as cloud elasticity and its ability to dynamically allocate processing and storage resources as needed.
So should programmers rip and replace to start again for cloud, or look to make slow strategic migrations?
Microsoft’s Harry reminds us that software engineers are a self-assured bunch who like to think their way is best. They like to start over and do something even more radical than re-factoring an application so that it is taken apart to transform it to the cloud.
The issue we face is that developers think that every unimplemented application is perfect… and every working application is flawed. But Harry says he has tried to temper that notion and get his team focused on the migrations that Microsoft had committed to perform. He advocates evolution over revolution in all scenarios.
Will cloud software be as good as, or better?
The question you are probably (we hope) asking by now is, will cloud software be as good as or better than its on premises ancestors.
“If you’re asking me should we aim to build the minimum viable product in cloud or shoot for feature parity? The question, I think, comes down to what Microsoft did with Team Foundation Server and Visual Studio Online. So right now we don’t have so-called ‘feature parity’ with our on-prem product… but (and here’s the really important part) at the same time, there are at least as many features in our online product that don’t exist on-prem. It may very well be that new features in cloud end up replacing the old ways we used to do things completely. That’s still evolution rather than revolution in my book and natural selection for product features is a good thing,” said Harry.
Microsoft’s openness at this part of its developer coalface is both insightful and encouraging. You don’t pull the wool over programmers’ eyes anyway, so you certainly don’t do it with the core Application Lifecycle Management product that they use every day. This may not be a complete recipe book for cloud migration, but Microsoft is offering us a taster and it’s served warm from its own plate so that can’t be bad.
