You show it to your boss. Bada Bing Bada Boom!
This is very timely, because the boss has just come out of a meeting with IT finance. He’s got a big problem justifying the cost of running the company’s website for $2M / year. He’s also pounded daily by business, because he has been unable to meet the availability and performance SLAs despite spending a lot on the infrastructure... So, you’ve just given him a brilliant idea. He checks with Legal, and asks you to look into moving the website to the Cloud.
As an experienced architect, you lift up the hood to take a good look inside the WebApp. You familiarize yourself with the code, dependencies, packaging, etc… After your analysis, you break down the options as follows:
Options | Pros | Cons |
| Option 1: Move the application as is | Quick | Inherits the issues that already exist with the application The performance of the application may just marginally improve due to the application architecture & implementation |
| Option 2: Re-factor the application; then move | Potentially fixes some of the application issues Potentially fixes some of the application infrastructure issues | Takes more effort than option 1, and requires more time May introduce some dependencies on the target Cloud Will probably require learning a few new things |
| Option 3: Rewrite à Redesign/rewrite the application | Full application refresh: New application & infrastructure architecture & design, and implementation Removes the implementation constraints that existed in previous options thereby allowing to leverage/offer new capabilities (i.e. social computing) | May be more involved than the previous options (time, cost) |
In option1, you settle on an infrastructure as a service (IaaS) provider, and just move the application as-is over. Unfortunately, the issues that had already existed with the application will be all propagated (i.e. poor image loading / bundling, deprecated code, unsupported utility jars, packaging). However, in option1, you’ll be able to reduce the infrastructure and operations costs dramatically, and improve SLAs (i.e. availability, auto-scaling) quickly without a lot of efforts.
In option2, you’d still subscribe to an IaaS. You will have the opportunity to clean up the application a little. You might even re-factor the application to use Cloud services (i.e. persistence layer). If time permits, you might even make some changes in the infrastructure in term of content caching & media delivery (i.e. CDN). With this approach, you will have an opportunity to make quick, incremental improvements to the existing application without spending too much money.
In option3, you might consider an IaaS or a PaaS. In this context, the selection is primarily dependent on the application requirements, control over the infrastructure, execution environment customization, etc
With option3, the approach may range from just rewriting the application using its existing design to complete re-implementation. In the case of just rewrite, it can be very straight forward and relatively quick (using the right frameworks, reusing existing components and graphics, etc). The disadvantage is that you’re constraint by the original design, and will not be able to introduce any enhancements or new capabilities.
With redesign/rewrite approach, you’ll need more time to design the solution, but you’ll be able to introduce new capabilities.
So, here is a diagram to summarize:
The Time axis is self-explanatory. It reflects effort and costs. The Value axis is an indicator of business value. That ranges from cost-effective & enhanced IT service delivery to offering new business capabilities and possibilities.
I am leaving some details out, but you get the idea. Let me know what you think. Tell me about your experience.
No comments:
Post a Comment