Accenture Technology Labs Blog

Please use the trackback ping URL provided below:

Or you may also right-click and copy the link address/location/shortcut from your browser to copy the URL to your clipboard. You can then paste this in the appropriate field within your blogging application.

Opportunity Eco-System

Published: Jun-26-10

By: Sewook Wee

Good news from the infrastructure cloud, such as Amazon’s EC2 and S3 services. At the price of $100, you have a cluster with 1000 servers in your hand for an hour. Data center and server configuration? Done. Management and maintenance? Done.

So, the question is “what are you going to do with it?” Now, it’s time to sit back and think about what we couldn’t do before, and what we can do now with this elastic infrastructure cloud.

Many have already discussed applications with seasonal load. For example, you don’t need to target your web server farm’s size to peak load any longer. Rather, you can build an elastic web server farm that automatically scales its capacity following the traffic demand. Or, your company must generate a quarterly forecast that requires a business analytics application with computing power equivalent to a hundred servers. Because you only run it four times a year, three hours each, you couldn’t financially justify purchasing 100 servers for that purpose only. Now, with the cloud, twelve hours multiplied by 100 servers is only $120. (Yes, network bandwidth fee and so on will make it more than $120, but still much better than buying 100 servers.)

Anything else?

I want to introduce the Opportunity Eco-System. This is a place where the software provider and the user can meet safely. It is hosted in a public cloud. Before we get into details, let’s take a look at a typical setup scenario.

Scenario

Bob is a manager in the quant department of an investment firm. His job is to determine a target price of a mutual fund by running sophisticated pricing algorithms. Like yesterday, Bob received an email that advertises AccuPricer, a new pricing engine. Bob has three strategies: 1) investment is all about taking a risk for bigger return! Try’em out! 2) When it comes to IT, “don’t change until it breaks!” or 3) wait 6 months and see what the reaction from early adopters are. None of them are optimal strategies, though.

Opportunity Eco-system for users

Users can try out new software on pre-configured virtual machines. Yes, you have a practically unlimited resource pool; try multiple softwares from multiple vendors at the same time. Remember “at the same time”, not “one-by-one.” In this way, You can give a new offering a chance without interrupting your current workflow. At the first phase, you can consider the new offering’s workflow as a “what-if” scenario. The Opportunity Eco-system makes this flow seamless.

Now, you are running multiple options for one task in parallel to using the cloud. Therefore, you want a comparison metric for various reasons. First, Bob needs to choose one of many results from many engines, as his target price should be one number. Second, Bob may want to draw a conclusion from many results using a “voting scheme” or an “averaging scheme.” Even in this case, Bob may not want to give even weight to all sources until they obtain Bob’s confidence. Lastly, after Bob tries out the new engine several times he may want to filter it out if he is not satisfied with the engine. Otherwise, a year later he will be running more than 100 engines all at once, quickly burning out his IT budget. The Trial Eco-system provides an interface where you can setup your comparison metric objective (accuracy, time, cost, etc.,), and collect statistics for comparison. It is interesting that sometimes “accuracy” cannot be scored in real time. If a software engine is to predict a future value of one property, we can tell the real accuracy at the time when the future arrives. Trial Eco-system provides a future-feedback feature that collects the real value at future time and updates the credibility of the engine.

So, what should Bob pay for? Bob pays for the usage-based license for engines he chose. Trial Eco-system is responsible for monitoring usage, billing, accounting, as an uninterested third party. Note that Bob already purchased a site license for some pricers like SosoPricer, and it’s not reasonable to pay extra license fee for the SosoPricer Trial Eco-system edition. Trial Eco-system enables BYOL (Bring Your Own License) feature so that Bob doesn’t need to pay extra.

Trial Eco-system for software providers

Software providers are another crucial party of the Trial Eco-system. Unless the Trial Eco-system can invite most of the market leading providers into the system, the user’s choice will be limited and the whole system will collapse. The Trial Eco-system lowers a market entrance barrier for software providers. It provides a standard virtual machine image with security features to protect their proprietary software and accounting features for license fee charge. Moreover, it organizes a standard framework so that many of the comparable tools from vendors can fairly compete with each other.

Vision

With Trial Eco-system, from now on, Bob will get a promotional email like this:

“We are pleased to introduce AccuPricer, our new pricing engine. More than 100 customers already tried it out, and 80% of them experienced better results from AccuPricer (see chart 1). To compare the performance of AccuPricer to what you have now, click this link. By subscribing today, you will get AccuPricer $100 credit that is equivalent to a 30 day license.”

Bob clicked the link to allow Trial Eco-system include AccuPricer to his parallel pricing engine list. Still, he does exactly the same thing as he did before to run pricing calculation – he presses the “Price it” button. AccuPricer then runs in parallel with SosoPricer and 4 other engines in Bob’s list. At the end of the day, Trial Eco-system sends him a report that shows the statistics of all the engines in his list. The report shows that AccuPricer performs pretty well. After a month of consistent high performance, Bob and his team decide to make AccuPricer official and discontinue their SosoPricer subscription.

Read Article

Link to post () | Comment (0) | Trackback URL |

Amazon cloud security best practices

Published: Jun-16-10

By: Huan Liu

Many of our clients are interested in migrating to cloud, but all of them are concerned about security. I wrote before that a cloud is more secure than one's own data center. Following on that thread, today I will focus on a set of security best practices you can follow to enhance your cloud security even further. Since a lot of our clients are evaluating Amazon cloud as a potential choice, I will focus on the best practices in Amazon cloud, but the principles should apply to other clouds as well.

1. Check before connecting.

Since a cloud VM (virtual machine) is outside your firewall, you have no control on the path to reach it. For example, it is well known that one can hack DNS servers. Just a few months ago, china's largest search engine Baidu suffered a DNS attack. So it is likely that your VM could be hijacked too. One best practice is to always check your VM's signature before connecting. Amazon instances generate a random SSH server key on boot up. This SSH server key can be obtained by querying Amazon's (secure) API for the console output. This key from the console output should always be checked against the SSH key reported when you SSH into your VM. To ensure the best practice is always followed, for our clients, we wrote a wrapper around a SSH client, which automatically checks the key before connecting. You can quickly code up something like ours.

2. Encrypt as much as you can.

You should always use SSH or SSL to connect to your VM, which encrypts all traffic. In addition, you should encrypt your data to guard against hard disk theft or inappropriate hard disk disposition. On a Linux OS, this is easy to do because you just need to install an encrypted loopback file system. On Windows, there are a number of products you could use to encrypt.

3. Wipe when you quit.

As an added precaution, you should wipe out the encrypted loopback file when you shut down your instances. This will prevent the most determined hackers from trying to decrypt your bits, if they got a hold of your file, for example by stealing the hard disk. When you shut down your Linux instances by calling Amazon's API, the proper shutdown procedure is invoked. All you need to do is to hook into the shutdown script and wipe out the hard disk in the process. In our experiments, we find that there is enough time to wipe out about 7GB of data before your instance is just killed. That should be long enough for you to wipe out the most critical section so that no one can reconstruct your bits.

4. Stand all by yourself.

One key difference between cloud and your internal data center is that your VM may sit next to some strangers' VM on the same physical hardware. Even though hypervisor isolation has been robust so far, there is always the concern that a vulnerability could be discovered someday and your VM may be hacked by the neighboring VM. One solution is to launch a VM onto its own hardware all by itself. We analyzed Amazon's cloud hardware configuration recently, and concluded that there are two types of instances that occupy the whole physical hardware. Since Amazon does not have any capability to online migrate your VM to another hardware, you can be sure that your VM is standing all by itself. You will receive an email notification if Amazon needs to change the underlying hardware, which happened to us recently.

5. Open to only those you trust

Amazon offers a powerful software firewall, called Security Group. You can have any many Security Groups and as many rules per Security Group as you want. You should use Security Group to lock down access to your application to as narrow a list as possible. For example, if you enable SSH access, you should open port 22, but make sure you only open to the IP addresses from where you will access it. Never open it to the whole world (i.e., 0.0.0.0/0) unless your application is public facing.

Because the fine grain control a cloud offers you, if you follow the above best practices, you can be sure that your application is more secure if hosted in cloud than hosted in your own data center.

Read Article

Link to post () | Comment (0) | Trackback URL |

WebScalar - A prebuilt fault-tolerant auto-scaling web server farm in the cloud

Published: Jun-04-10

By: Huan Liu

One of the success stories of cloud is around a startup company called Animoto. The company's website was hit hard when they became famous, but, by running on top of Amazon cloud, they handled the onslaught gracefully. As the traffic increased, they scaled their infrastructure from roughly 50 servers to a peak of 4000 servers. The story demonstrates the power of using cloud -- dynamically scaling based on usage. This is particularly important for web applications where the number of users fluctuates unpredictably, not only through the application life cycle, but also throughout the day.

In comparison, in a traditional infrastructure, you have to provision a fixed capacity because it takes too long to provision additional capacity. In a couple of client projects that I have seen, people grossly over-provision for what they need because it is better to be safe than sorry. As a result, they pay way more than what they should pay, sometimes orders of magnitude higher.

The order of magnitude in infrastructure cost savings alone should convince you that cloud is the right way to go. But, I have to break the bad news to you that you cannot simply drop your application in cloud and expect it to scale all by itself. Although there are many solutions out there now, it is difficult to determine which solution works the best for your application and which solution is the most robust. As a proof, I visited Animoto's website recently and I was surprised to find that their website is down (see below). Apparently, even the cloud poster child did not get it right completely, at least the failure handling part.

What solution out there should you choose if you decide to host your web application in the cloud? Obviously, you can build it on your own. I have talked about how to choose a load balancer in the cloud, but it is just a start. You still need to figure out how to add auto-scaling capabilities and fault-tolerant capabilities. Instead of designing a new solution from scratch, you can leverage an Accenture's pre-built solution.

I would like to introduce WebScalar -- a prebuilt platform developed by Accenture which can host any web applications. WebScalar is auto-scaling, which means that servers could be brought up/down depending on traffic demands. It is also fault-tolerant, any single point of failure is repaired automatically. For example, if the load balancer fails, an active standby load balancer immediately takes over. At the same, a new standby load balancer is spun up to protect against future failures. Lastly, WebScalar also has a set of load balancing modules that could be plugged in. Depending on your application profile, we can plug in the optimal load balancer for your need. This demo is a capture of the monitoring front end which shows the status of the moving parts in the systems, including the load balancers and the web servers.

WebScalar is free of charge to our client teams, and it is typically used in a larger cloud application migration project. If you have an interest using this solution, you can reach out to your client director or to us directly.

Read Article

Link to post () | Comment (0) | Trackback URL |

Return to Blog

Subscribe to RSS | Help

About the Author

The Accenture Technology Labs blog will feature the opinions and perspectives from the very people that are driving innovation today for Accentu...

Read Full Bio