We are a few weeks removed from TechEd 2012 in Orlando (June 11th – 14th) and I was reflecting on all of the stuff I learned as me and two of my colleagues put together our breakout session titled “How to Move and Enhance Existing Apps for Windows Azure“. The journey we took to come up with this topic was an interesting one. Initially, we were truly thinking purely about Platform as a Service (PaaS) because as a developer this is what has been the most compelling in the cloud. That all started to quickly change as we learned more and more about how Infrastructure as a Service (IaaS) was going to open significantly more scenarios for subscribers.
In fact, our initial outline for the session was not chosen for the event. We had to be willing to evolve our view of what it meant to “move apps” to the cloud and specifically Windows Azure. Our discussions with the Azure track experts gave us some great ideas. This idea of moving from good … to better … to best approaches of moving apps started to make a ton of sense. It was also quickly clear to us that making this story compelling would require some real world case studies and some truly unique implementation demo’s.
Migrating versus Moving
One of the things that had us scratching our head a bit when we first started reviewing our session submission was the desire of the Azure track folks to use the term “Move” instead of “Migrate”. I know this seems subtle but after 2 solid months of researching and preparing for this talk I think I understand why. When you say you are going to “migrate” something there is some perceived work involved. When a flock of geese migrate south for the winter that’s a good bit of work (or at least it looks like it is). When folks migrate between different countries there are lots of logistics and challenges.
Now when you think of the term “move” I think folks have different visceral reactions. Some of you think of moving your house which for most is not a trivial undertaking. It is however something a bit more common and often comes with tons of ways to make it less painful (hiring movers for example). There aren’t any shortcuts when you look at migrating. I realize some of you may be thinking, uh … really … they are synonyms. Yes and No. They are certainly something different and we did embrace this with our session for sure.
Moving Apps to the Cloud – The Good Way
So we’ve settled on the move term and we’re looking to cover what it is that would be considered a “good” approach. This is where Infrastructure as a Service offering fits in and the other term that is being popularized which is “forklifting”. The forklift metaphor works really well for moving apps into an IaaS model. In your head you should hopefully be picturing some large warehouse where a truck has backed in pallets of widgets. Those pallets are simply picked up and put in their expected resting spot. There should be no changes necessary!
This is one of the most critical differences between IaaS and PaaS and it is true of all vendors that have these offerings (Amazon, Microsoft, Google, Oracle, etc..). This was a huge challenge for subscribers that wanted to just get to the public cloud … friction free. I have personally spent the last 2 years attempting to help developers understand how to get to PaaS. It is not simple when you consider all of the complexities of existing applications. IaaS really is the way to do this … it really does feel like a “good” way to start getting to the cloud.
Let me give some more specifics. So far this feels like a bit of an opinion piece. Lets look at three key reasons why PaaS is a difficult first step for an existing application.
1. You need to understand the platform
This is a big deal, whether you’re looking at Windows Azure or Google App Engine or Heroku or Elastic Beanstalk. You have to know the constraints and intricacies of the platform. How does scaling work? Can the platform auto-scale? What are the key constraints? What programming languages are supported? How do updates occur? What level of control and permissions do you have with the local machine resources? How do the diagnostics work? What type of multi-tenancy conditions can occur? Are there APIs to help automate? What features exist and most importantly … what features are missing?
This last question was the catalyst for my demo in the first section of the TechEd talk. Missing platform features plagues all of the PaaS models. It results in developers either abandoning plans to move to the cloud or looking for alternatives like IaaS. My example was the Microsoft Distributed Transaction Coordinator (MSDTC). I won’t go into detail on what that is or why it isn’t supported in Windows Azure PaaS … I’ll let you watch the session for that. Just know that it was not and likely will not be a feature in PaaS so IaaS is the only solution for applications that have a dependency on it. As a side note, I intend to do some deep exploration of the other leading PaaS offerings to see if this is a universal blocker … expect some blog entries in the near future on Google App Engine, Elastic Bean Stalk, and Heroku.
2. You have to really know your application
This diagram below represents the DTC dependent application that we designed to move to the cloud. This application was expected to handle a scenario where the users would greatly benefit from geo-distribution (just a fancy way of saying multi-datacenter deployment … please forgive my Fancy Nancy style of writing this note … I have young daughters 🙂 This application could also use existing platform features to handle central data repository sync so we were about 95% of the way to the cloud and PaaS but we hit a blocker.
This may seem like an obvious thing but with legacy applications there are a number of factors that can decrease the level of knowledge developers have. The first and most obvious one is that they simply haven’t worked on the app in years. There are also situations where the original developers managed to strike it rich and retired to an island somewhere and refuse to take any calls when you ask for help to understand the app. These represent knowledge leaks and they are very common.
3. Your application needed to be scalable and resilient by design
This is by far the hardest aspect and also the one I almost never see in existing applications that we want to move to the cloud. A developer who wrote an application 10+ years ago was not thinking about it going from their on premise 3 server farm to a 50 instance public cloud with no control over the load balancer, server affinity, or application state. Another trap we often fell into 10-15 years ago (not that we knew it was a trap at the time) was that we relied heavily on the ability of hardware to handle our scaling needs. Stated another way, we would be adding CPUs and RAM to solve any scale issue. I am not saying this was the case for every app written by every developer … but not everyone had the foresight to plan for huge scale out options.
Resiliency is another one that no developer (including myself) would have planned for in a legacy solution. Heck, I can remember when I was an enterprise architect I would actually do finger wagging at any developer that wrote retry logic around their data access code. It felt unnecessary in a controlled on premise data center. In the PaaS world it is as important as oxygen for mammals.
Coding for resiliency comes in a ton of flavors. It starts with data access code but then it trickles into any stateful code or workflow code. How do you know your transaction failed and is it idempotent (fancy way of saying replayable). I think I could write a thousand words on resiliency in the cloud … and I plan to … so I’ll cut this off here.
Why are we calling IaaS good? I think it is freaking awesome!
That is a fair statement and those that have been moving apps to EC2 instances in Amazon for the last five years probably agree 🙂 However, there continues to be a lot of overhead with managing a solution that is using IaaS. The primary promise of the cloud is almost always about cost efficiency. Whether it is the Rent vs. Buy example for an elastic scenario or the reuse of world class management and deployment processes and software to handle your application.
If you’re not making an effort to get to PaaS then you are losing out on a lot of good stuff. Servicing of the underlying infrastructure being the most obvious. Rolling out patches to Linux and Windows is a mundane and well understood IT activity. Sticking your apps into IaaS will not get you out of that.
Additionally, consistent management of your infrastructure is one PaaS benefit but what about consistent management of your application? The configuration and the versions of the code? How do you handle app version roll outs on premise? Do you have a 0 downtime (aka no maintenance window) roll out? In some cases this is easy with load balancers and stateless solutions but it gets infinitely more difficult when you start dealing with a ton of instances and a consistent usage demand plus what about those shared resources like the DB, Cache servers, Queues, etc…
I decided to split this into three parts because I knew I had a lot of learnings as I went through creating this TechEd session. This first was about how we settled on “The Good” first step in to the cloud which is moving existing apps into IaaS. The main message here is that this is the start of your journey not the end. If you want the true benefits of the cloud you need to keep pushing yourself to think about all the app containers out there. The economies of it are simply awesome and we start to see that immediately when we move into hybrid IaaS and PaaS working together in a hybrid model. That’ll be the focus of Part 2.