Search results matching tags 'Windows Azure' and 'SQLU'

SQL U Class 3 – Objections to Cloud Computing

BuckWoody — Fri, 01 Apr 2011 12:46:18 GMT

Class Description:
This Cloud Computing course at SQL University explains the Distributed Computing paradigms used by major vendors, and covers information useful to the data professional for implementing proper architecture designs.

Pre-Requisites:
General computer programming data development terminology, industry experience in at least one of those disciplines

Instructor and Bio:
Buck Woody – Bio available at: http://buckwoody.com

Class Detail:
In this class we’ll focus on:

· What cloud computing is

· Where it can be used

· How it applies to you and your organization

Each day there will be a lecture, along with homework for the next class session. There will be a comprehensive final exam – it’s contained primarily in your work environment!

Class 3 – Cloud Computing – Objections to Cloud Computing

Welcome to the third class in SQL University on “Cloud” computing. If you haven’t had a chance to take a look at class one yet, you may want to switch to that post and learn about the definition of cloud computing, since I’ll be using those terms today.

In computing’s short history, we’ve moved from a centralized model (mainframes and large datacenter systems) to a distributed set of computing (LANs and WANs). We’ve worked quite hard over the last couple of decades moving away from the mainframe, to owning the systems and infrastructure where we run our code.

The “cloud” however, is a kind of return to centralized computing, at least as far as control of the underlying systems applies. So it’s natural, especially at the non-architect level of IT, to question parts of the cloud paradigm. Most often there’s a misunderstanding that an organization should take all of the on-premise infrastructure and code and move it to “the cloud”. This would be a mistake. Distributed Computing systems like Windows and SQL Azure are well suited to certain situations (see class two) and not as well for others.

There are, however, some legitimate concerns about moving to a Distributed Computing environment. And there are some equally valid responses. In today’s class I’ll address the three primary objections I’ve heard most often.

Paradigm Shift

“I’ve spent 20+ years moving to direct-connected computing. When I hear “Cloud” I think I need to replace everything I have, a very daunting task mixed into my already busy day.”

The answer to this concern involves two areas – computing history and technical vision. As I mentioned earlier, we have moved from a centralized model once before – in fact, I hear the exact same concern there – to a distributed LAN environment. Now the industry is moving to a more centralized model using a Distributed Computing paradigm (some computing on-premise, some in an IaaS, some in PaaS, others in SaaS), and there is some inertia to get over for it to take hold.

It’s also important to think about the vision of computing, and its purpose. If the goal is to control hardware and install operating systems, then on-premise only is a good way to go. But that should be a means to an end – the goal should be to enable the organization with technology. After an honest, thorough investigation, perhaps one of the cloud paradigms makes sense for a certain application. In that case, implement that application and move on to the next investigation. Many shops have already done this with things like Payroll or web services. They simply use a SaaS for that.

Security

“I know my own security. I control the process from end-to-end, and my data is within my four walls. If I put my programs on the web I’m faced with the client, network, and vendor’s levels of security. That’s just too big a risk.”

Probably the most frequently asked question (at least directly) is about security in the cloud. And it’s a valid concern. When data leaves your organization, you need to be certain how it will be handled and who will have access to it.

There are several ways to think about this issue. The first is to understand your data, and which parts of it require high levels of security. If a particular datum requires a very high level of security, you can simply use a hybrid approach and not put the data in the cloud at all. You can make the result of the data (such as a “Yes, customer charge is approved”) or a result (101.12) back to the calling cloud application. This is possible in Windows Azure using the Application Fabric, and in fact is at use in many locations.

Another approach is to deeply encrypt the data prior to sending it to a Distributed Computing system. There are code factories that do this, appliances and other hardware devices that allow you to encrypt and decrypt data prior to transmission. Many ATM machines use this paradigm.

The final thought here is that security is in three parts in a Distributed Computing environment: The facilities and hardware, the operating system and environment where the cloud provider runs, and the code you write (in the case of a PaaS solution). I discuss these areas further in this learning plan: http://blogs.msdn.com/b/buckwoody/archive/2010/12/07/windows-azure-learning-plan-security.aspx

Performance

“We’ve worked really hard tuning everything from the hardware to the network to get our programs running this quickly. There’s no way the web can handle that kind of speed”

This concern is completely true – if the architecture of the application doesn’t change. The basic premise for a Distributed Computing system is that you should always try and co-locate the data payload close to the computing resources. In Windows Azure, you can choose where your data store is, and a wise choice is often to co-locate the code and the data.

Once again, making the selection for the proper application to move to the cloud is essential. If you plan to import and export terabytes of data each day to support a Business Intelligence system, then the latency question becomes a bigger issue. If, however, you can locate all that data in the cloud to begin with, process it there and deliver a much smaller report on a screen, the problem is mitigated. It all goes back to design and application candidates.

Even with large sets of data, caching, trickle-feeds and so on can also work in your favor. There is more on this topic specifically addressing SQL Azure here: http://blogs.msdn.com/b/cbiyikoglu/archive/2010/01/05/evaluating-application-performance-and-throughput-in-sql-azure.aspx

Reading Assignment:

Along with the references shown above, check out “The Case Against Cloud Computing” at CIO Magazine: http://www.cio.com/article/477473/The_Case_Against_Cloud_Computing_Part_One

SQL U Class 2 – Use Cases

BuckWoody — Wed, 30 Mar 2011 14:03:46 GMT

Pre-Requisites:
General computer programming data development terminology, industry experience in at least one of those disciplines

Instructor and Bio:
Buck Woody – Bio available at: http://buckwoody.com

Class Detail:
In this class we’ll focus on:

· What cloud computing is

· Where it can be used

· How it applies to you and your organization

Each day there will be a lecture, along with homework for the next class session. There will be a comprehensive final exam – it’s contained primarily in your work environment!

Class 2 – Cloud Computing – Class Two, Use-Cases

Welcome to the second class in SQL University on “Cloud” computing. If you haven’t had a chance to take a look at class one yet, you may want to switch to that post and learn about the definition of cloud computing, since I’ll be using those terms today.

When many technical professionals hear about distributed computing, they begin listing the reasons it won’t work in their environment. This comes from comparing a certain feature or process that they currently use, and don’t find a corollary to from a particular cloud offering. The misunderstanding comes from a perception that a cloud vendor expects an organization to switch whole-cloth from one technology to another. But this is not the case. To help with this issue, the first place to start is with where a new technology fits. For instance, when you introduce an RDBMS into your environment, no one expects that you will no longer store data in anything other than an RDBMS database. It’s simply another option that is used only where it fits.

A distributed computing environment is no different. It is not intended (nor should be intended) to replace an entire on-premise environment. Latency, private data, and many other issues preclude this from being a good choice. There are, however, instances where a distributed computing system works well. In general, these use-cases involve the following broad advantages:

· Scalability (up and back down)

· Defined Billing

· Abstraction from the platform and below

Note: I’m describing only a PaaS solution here (see the previous class for more information on this term) and not SaaS or IaaS. Those have different use cases.

Let’s take a quick look at each of these, and then define the particular use-cases that seem to make the most sense in a PaaS distributed Computing Environment.

Scalability (up and back down)

In the case of a PaaS solution (such as Microsoft’s Windows Azure) the system adds or subtracts computing power on-demand. In the case of Windows Azure, you can programmatically code the system to watch counters of your choice (computing power, logons, sessions, etc.) and add more computing power or storage. Your code must use a “Stateless Computing Model” for this to scale seamlessly, but this paradigm is not vendor-specific or even specific to the cloud, so the code is portable even back to your on-premise systems if you change your model away from a cloud provider at a later time. Conversely, you could code this way on-site and either move to the cloud or even expand the on-premise footprint of your application into the cloud as needed – this is called “bursting”.

An important consideration is the ability to scale back down after you scale up. Some vendors require that you retain the resources you request for a certain period of time, so make sure you vet those conditions with your particular cloud vendor source.

Defined Billing

A PaaS distributed computing paradigm is “pay as you go”, meaning you will be charged a mixture of compute, bandwidth and storage units. There are methods of estimating these costs (See the reading below), and ensure that the costs meet the objectives. From a use-case standpoint, defined billing is ideal because the cost burden can be directly applied to the business unit that wants the application (meaning IT does not have to carry that budget) or those situations where user activity generates revenue, such as a sales website. In other words, you pay more for when you’re using it, but you’re (theoretically at least) making more money because it is being used.

Abstraction from the platform and below

This use-case actually defines PaaS. In other distributed computing paradigms such as IaaS, you have to install and patch an operating system and platform, create and maintain your own scale-out architectures, and determine your own High-Availability strategies. In a SaaS environment you simply use the service provided by the cloud vendor. In PaaS, however, you write applications and store data, and do not control the operating system, platform, runtimes and so on. You simply focus on the application code and the data.

To put this more simply, if you type “setup.exe” or “./setup” then you’re looking for IaaS – if you open Visual Studio or Eclipse, you’re looking for PaaS - if you log on, do some work and then log off, you’re looking for SaaS.

Specific Use-Cases

I’ve described these use-cases in more depth in the links below. A general list of where distributed computing works well are the following:

Windows Azure Use-Cases
Elastic Scale - Bursting workloads up and down in use patterns	http://blogs.msdn.com/b/buckwoody/archive/2011/01/18/windows-azure-use-case-elastic-scale.aspx

Agility - The ability to quickly develop and deploy an application	http://blogs.msdn.com/b/buckwoody/archive/2011/01/25/windows-azure-use-case-agility.aspx

New Development- Code option for new applications	http://blogs.msdn.com/b/buckwoody/archive/2011/02/08/windows-azure-use-case-new-development.aspx

Web-Centric Applications - Applications that are developed for a web paradigm	http://blogs.msdn.com/b/buckwoody/archive/2011/02/14/windows-azure-use-case-web-applications.aspx

Hybrid Applications and Data - Applications and data that need to be both on-premise and in a distributed environment	http://blogs.msdn.com/b/buckwoody/archive/2011/02/22/windows-azure-use-case-hybrid-applications.aspx

High-Performance Computing - Applications that require multiple processing nodes, such as scientific, research or financial data (also known as Technical Computing)	http://blogs.msdn.com/b/buckwoody/archive/2011/02/28/windows-azure-use-case-high-performance-computing-hpc.aspx

Infrastructure Limits - Inability or unwillingness to add more physical computers to the environment	http://blogs.msdn.com/b/buckwoody/archive/2011/03/08/windows-azure-use-case-infrastructure-limits.aspx

Fast Acquisitions - The ability to quickly migrate a newly acquired business to the current computing environment	http://blogs.msdn.com/b/buckwoody/archive/2011/03/15/windows-azure-use-case-fast-acquisitions.aspx

The key is to examine what you do today in your computing environment, and decide which of your applications fit any of these patterns. For those that match the pattern, begin an Architectural Design Session (ADS) that defines how that application would be architected in a distributed computing environment, and whether the costs and benefits merit a closer investigation. Most of the cloud vendors have the ability to help you perform an ADS, either through a consultation or whitepapers and the like.

Reading Assignment:

One of the core tenants for developing in a distributed computing environment is to use Stateless Programming. In effect, using an HTTP server involves stateless programming, but people have added session state, ActiveX programming and the like and gotten away from it. But for scale, it’s critical that you code in this manner. This is a very old reference, but a good starting place to discuss this topic: http://www.adiscon.com/iis/isapi005.htm

SQL U - Cloud Computing - Class 1

BuckWoody — Mon, 28 Mar 2011 13:17:43 GMT

Pre-Requisites:
General computer programming data development terminology, industry experience in at least one of those disciplines

Instructor and Bio:
Buck Woody – Bio available at: http://buckwoody.com

Class Detail:
In this class we’ll focus on:

· What cloud computing is

· Where it can be used

· How it applies to you and your organization

Each day there will be a lecture, along with homework for the next class session. There will be a comprehensive final exam – it’s contained primarily in your work environment!

Class 1 – Cloud Computing Defined

Welcome to the first class in SQL University on “Cloud” computing – although we’ll soon dispense with that term. First, why have a class in this discipline in a data-centric location like SQL University? Isn’t this class series dedicated to data?

Yes it is – and in fact, this is a perfect place to talk about distributed computing. At the end of the day, whether we’re talking about SQL Server or Windows Azure, it’s all about data - taking it in, processing it, storing it, computing against it, and returning it to the user. And of course we’ll spend some time on SQL Azure, Microsoft’s “RDBMS in the Cloud” along the way.

Let’s start out by defining a few terms. “Cloud” has become such a diluted term that it’s become synonymous with “Internet” or “Web”, but I’ll still use it throughout this series so that we stay consistent. To be more technically accurate, however, I’ll use the term “Distributed Computing” as a synonym. What that means is that the computing functions – at a high-level: input, processing, storage, output – are performed on multiple, intermittently connected systems. This brings up the concept of “Stateless” coding – something that might require a little explanation.

Take a single system running code as an example. Assume that on your laptop you run a game program. Your system marshals together the CPU, Disk, Network and most importantly, memory to do the work. As your game turns left, the CPU directs the graphics to show that result, and the memory stores where you are at that microsecond. Freezing that moment in time, you’re looking at the “state” of the program. It is declared to be a “state-ful” program, because if you turned off the computer, the memory would be refreshed and you would lose your place in the game. In fact, you would lose the fact that a game was running at all. You’d have to start over.

Contrast that with a “state-less” program. You might even have that game again – but in this case, the code that runs might exist on more than one computer. And instead of saving where you are in the game just in memory, the “state” could be stored in a file that all of the computers can access. So now if one goes down or is too busy to respond, another identical copy of the program itself can reference the file and continue working.

Of course, for this to work, there are two further areas to consider. One is that you have to handle the fact that the user needs to be re-directed to another computer. This can be handled by placing a load-balancing redirector to answer the user, and it decides where the packet of data goes. In Windows Azure, this is handled for you. Secondly, you need to deal with the latency introduced by storing state on a file instead of in memory. So as you can see, not everything goes to the cloud. But there are workarounds, mostly involving thinking in queues or messages. The combination of these and other computing strategies is a process called “Stateless Computing”, and it involves hardware and code. I’ll include references to this in the “Homework and Reading Assignments” section below.

The next part of the definition of cloud computing is the way it is used. While many vendors (and even open-source projects) offer “cloud” computing, it’s important to understand exactly what they are talking about. The industry has created three broad categories that we agree to use for discussing a distributed computing environment.

Infrastructure as a Service (Iaas) – Abstracts the hardware layer, most often by hosting a Virtual Machine (VM) or drive storage.

This paradigm is useful for “canned” or pre-packaged applications that require a “setup.exe” process. Scale, High-availability and operating system licensing and maintenance are your responsibility. The vendor handles the hardware for you. Microsoft offers Windows Server, Hyper-V, and System Center for our IaaS offering, your responsibility is obtaining a hardware hosting service for those software platforms.

Software as a Service (SaaS) – Abstracts away everything. It’s a software package you access without installing anything.

This paradigm is useful when there is a specific need that the software provides, and you do not have a high customization need. Microsoft offers Office 365, Exchange and other services as a SaaS paradigm.

Platform as a Service (PaaS) – Abstracts away the hardware, Operating System, Scale, and to some degree High Availability and Disaster Recovery.

In this paradigm you write or re-write portions of your code to simply run somewhere else. Conceptually your code runs on a single, massive, adaptable machine, although there is of course hardware, software and management happening underneath. Microsoft Azure is the offering we use to allow you to port or write .NET and other languages (such as Java and C++) and then simply deploy that code to Windows Azure.

Using a PaaS has some unique benefits – such as programmatic scale (you can seamlessly add more power or storage based on counters you watch or create), resiliency, global reach and so on. Since you pay for what you use, the cost structure is completely different – and can even be shifted to the business unit that asks for the increase in power or speed. Code does not have to change based on scale. Microsoft has resiliency built-in to the platform, so no management of the operating system, patching or licensing is required.

Another benefit is that the compute, storage and even a service-bus offering can be used together or even separately. This allows a great deal of flexibility, and even has the potential to “federate” your on-premise systems into the cloud, or even from company to company, all without having to set up a VPN or compromising your security structure.

The end result is that a PaaS solution, while requiring some re-architecture, provides benefits such as scale and adaptive billing that go beyond immediate needs, depending on your ability to change the code in your solution. It should also be noted that a PaaS solution is one of the few that allows you to migrate to the cloud in an iterative fashion – parts of the application can be migrated as time, resources and other factors dictate.

SQL Azure is a PaaS solution as well. It’s simply a SQL Server system running in the same datacenters as Windows Azure. Under the covers it maintains the hardware, Operating System, patches and so on, and runs an Instance of SQL Server. You have a longer connection string, and it uses SQL Server authentication only, but other than that you connect to it and use like you would an on-premise database server. There are differences – some of the features found in SQL Server aren’t available in SQL Azure, the sizes of the databases are more limited, and you start at the database level – not the instance level. In the reading assignments below I’ll show you more information about that.

In the next class, we’ll cover the use-cases for Distributed Computing. It’s not for all situations, but does fit others extremely well.

Reading Assignment:

For a general overview of cloud computing architectures using Windows Azure, check this link: http://blogs.msdn.com/b/buckwoody/archive/2010/12/21/windows-azure-learning-plan-architecture.aspx

For more information on SQL Azure, check this link: http://blogs.msdn.com/b/buckwoody/archive/2010/12/13/windows-azure-learning-plan-sql-azure.aspx