Showing posts with label saas. Show all posts
Showing posts with label saas. Show all posts

Saturday, November 8, 2014

Cloud Computing: Strata

Ph. D. Julio Fernandez Vilas
¿Any comments? jfvilas@gmail.com

There is no standard definition of what "Cloud Computing" is, and two reasons are responsible for this lack:
  1. There are different implementation models (infrastructure, application, software ...), so there is no precise definition.
  2. b) There are very multifarious offerings providers, so that a strict definition would not include all offerings.

But if I had to define what Cloud Computing is, I would choose the definition included in Wikipedia (read the interesting Wikipedia entry here):
"Cloud computing Relies on sharing of resources and coherence to Achieve Economies of scale, similar to a utility (like the electricity grid) over a network. At the foundation of cloud computing is the concept of Broader Converged Infrastructure and shared services. " The figure below is a good graphic illustration of generic architecture of cloud computing, where we can observe 3 clearly defined levels:


Here we can see the main "three flavors" of cloud computing offerings, infrastructure as a service (IaaS) platform as a service (PaaS) and application (it stands for "application software") as a service (SaaS). In the market and specialized press we can find other types of cloud offerings, focused on specific areas of technology, Security as a Service (SECaaS), Storage as a Service (STaaS), etc., but ultimately, any offering cloud will be framed in any of the three categories we've mentioned:

  1. Infrastructure (IaaS) refers to the possibility of consuming infrastructure services in the cloud, such as computing power, storage, connectivity, etc. At this level, management done by the customer (subscriber) is performed at virtual machine level or storage unit (LUN) level, for example, while the provider of infrastructure services (provider) is responsible for "only" managing the hardware (plus all related concepts to the cloud, such as scalability, high availability, etc.).
  2. Platform (PaaS). When a client wants to get rid of costs and tasks associated with the management of the infrastructure (machine maintenance, procurement of space, bandwidth allocation, etc.), he has the option of using services in a “platformed” mode, where the level of management that must been made by the subscriber is much lower than the one a provider to does. In this model, the client focuses on the development of applications, in fact the real solutions to their business problems. As an example, in Azure platform, it is possible to develop a .net web application and deploy a packetized version to a cloud server without installing anything. Here is Microsoft itself who is responsible for configuring and managing machines and application servers, clients only have to worry about generating deployable software packages on the platform. At this level of the cloud computing stack is where you would frame the old ASP's (application service providers).
  3. Software / Application (SaaS). At the highest level of services providing in the cloud we find Software as a Service. It is easier to understand, since it is the stratus that we find closest to the business needs, and therefore farthest from the technical stuff. It can be easily understood with these examples: Office 365 or Gmail.

Thursday, October 23, 2014

Cloud Application Layer Part III - Up & Down

Ph. D. Julio Fernandez Vilas
¿Any comments? jfvilas@gmail.com

Let's recall now the concepts of public cloud and private cloud, which are easily understandable if we really understand the relationship between the Internet (public) and (private) Intranet. When a company uses the public cloud, and then publishes services internally in the organization using the same technologies, i.e., in a private cloud, the company is acting as both a client consuming cloud services and a provider that offers services to its own iT services.

This is important when assessing the costs, as it will allow the consumption billed individually, affecting a business unit costs associated with the services they use.

Moreover, we must consider that the company is a living entity, constantly changing, and the fact of offering services from a cloud, whether private or public, is a key factor in making changes to services. That is, we endow the company a considerable amount of flexibility, since domestic service consumers do not know whether such services are being offered from inside or outside the organization.

In a last step in the adoption process of cloud technologies it is very important to have bothered to make a good design of services consumed in the form of a private cloud. If the design is good, the migration to a cloud service can be done easily. It is important to focus on a key concept for this migration to the cloud be done easily: STANDARDIZATION.

We need to design our private cloud services so that they are compatible with the public cloud. When we talk about compatibility or standardization, it is important to have a clear understanding of the layer of cloud technology we are focusing. For example, if we are thinking about IaaS, we have to make sure we use only x86 architectures, we are restricted to Windows and Linux, standard virtualization technologies, iSCSI, etc.

If you are thinking in SaaS (cloud email, for example), which is standardized is functionality. That is, we can migrate our on-premises platform (Exchange, Lotus, etc.) to an email platform in the cloud (Gmail, Outlook.com, etc. ..), provided that it assures me that the functionality that I will get on the new platform is at least the same as I have on the current platform. We should note that in the SaaS projects we will always find a CAPEX amount in the project corresponding to migration.

And all this in terms of going up to the cloud. And what about going down from the cloud? If we have taken into account everything said so far, the download process (or even transfer to another provider) is exactly the same. Remember that we are talking about going up to cloud from a starting point that assumes we are already working on private cloud.

Monday, October 26, 2009

Cloud Applications Part II (aka Cloud Computing Definition #3)

In previous post we’ve coined the first cloud computing definition. Remember it, please: “A cloud application is a computer application developed using a standard computer language that can be run on different platforms. One or more resources used by a cloud application are networked resources accessible via Internet. In addition, resources used by cloud applications are exposed via standard interfaces and protocols and should be interchangeable.” Now, let’s continue talking about networked resources.

Networked resources
This is one of the main differentiators between a “classic” computer application and a cloud application. Cloud applications use resources that can be reached through Internet. These resources are offered by different companies at different prices and, of course, different service levels.

Please, at this moment, think of a networked resource as something similar to a web service but with a lower abstraction level.

When someone decides to build a cloud application, one of the first steps in the development he must perform is to decide which of the resources needed for building the application will be bought from an external company and which of them will be used as part of an in-house strategy. I’ll explain it.

Suppose you are developing a web application to support a student registry in a XXI century school, where all students’ works and exams are digitalized and stored as part of its academic files. Now just think of a simple CRUD application (Create, Read, Update and Delete). The following list could be a typical shopping list for that kind of application:
  • Servers to host and execute web application.
  • Database storage for storing records that will be created and accessed online from the application code.
  • Plain online storage for storing pictures related to students. This storage must be online, since web pages include pictures of the “objects” the application manages. Since we plan to have lots of digitalized data, we discard the use of blobs.
  • Plain offline storage for backup and restore purposes. Let’s assume a weekly backup of the whole database and filesystem-like storage (digitalized exams and works).
You can run the application in your server farm at your datacenter or conversely you can sign a contract with an ASP (Application Service Provider) to host your web application (this could be considered a cloud service).

What to do with the database? You can use your in-house relational database or, thinking about cloud computing, you can use relational cloud storage to store your data.

The same decision must be taken for the plain storage for storing digitalized info from students and weekly backups.

Anyway, all the services you buy from a third-party provider (instead of using your datacenter resources) must have a very clear contract and a corresponding SLA including minimum service levels offered and penalization for running under that minimum.

Please keep in mind the student registry sample, since in next posts I will refer to it.

The relational database, the online storage, the offline storage is what I call networked resources, since the can be accessed from the application wherever they are stored. Please note that we don’t care about SAN, NAS or SQL. For the moment, we are caring only about having a resource and accessing, we are assuming we have a standard platform-independent way of accessing and using precious mentioned networking resources.

Note: We will come back to this point (deciding between in-house or cloud strategy) in future posts when we will expand EMC’s “private cloud” definition from infrastructure level to application level.

Standard Interfaces and Protocols
Although it has been mentioned before, I wish to remind you that the most commonly used mechanisms for performing remote invocation standard uniquely inside each native platform (DCOM on Windows, remoting on .net or EJB on Java). The only real standard platform-independent mechanism that can be used in remote invocation is Web Services, which means SOAP over HTTP. So, it is clear that standard platform-independent mechanisms (like SOAP or REST) is the only recommended way for accessing networked resources.

Interchangeable
Yes, I sad interchangeable, but, at this moment, it is only a desire, or just a dream. We will go back to this complex issue in the future, after discussing Amazon, Windows, Google and others’ cloud strategy.

Summary
Finally, I wish to publish my first Cloud Application Stack.

Sunday, October 18, 2009

Cloud Applications Part I (aka Cloud Computing Definition #3)

Ph. D. Julio Fernandez Vilas
¿Any comments? jfvilas@gmail.com

According to previous posts, the cloud computing (CC) stack has been reduced to just a single cloud computing block (ooops, zip time?). Remember, as stated in first post, cloud services are in fact what I call web 1.5 (just typical web applications), and cloud infrastructure is something that could be defined as “virtualization revisited”, that is, Infrastructure as a Service (IaaS).
So, we must now focus on cloud applications. What is a cloud application? The first possible definition is: “A cloud application is a computer application developed using a standard computer language that can be run on different platforms. One or more resources used by a cloud application are networked resources accessible via Internet. In addition, these resources are exposed via standard interfaces and protocols, and they should be interchangeable.”



Computer Application

Let’s analyze this statement. First of all: “computer application” is a vague term used here to define an application able to run on a client desktop platform (let’s say Windows, Linux, MacOS…) or any connected or loosely connected thin device. Thin device is generic term that includes lots of devices like PDA’s, cell phones, notebooks, wifi- or Internet-enabled devices, like a DS, a Wii, a PlayStation or an Xbox, for instance.

On the other side, a web application is also a computer application, with the difference of running on a server instead of doing it on a client device like the ones mentioned before.

It is very important to note that when we talk about an application here, we are really referring to an application that can be used by end users or other applications. This is a very important matter to take into account, because, as we will discuss in future posts, cloud applications will be the basis for cloud companies, companies targeted in offering value-added applications (VAA).


Standard Computer Language

This is a tricky term to define without hurting somebody. Firstly, one can think in C# (or just .net) or java when the word “standard” arises referred to a computer language. But what is really a standard? If we accept a standard is something broadly used, something that has been used for a long time, we must agree that COBOL, C or RPG, for instance, are standard computer languages.

A very important thing to take into account here is the way applications are developed when they need to access external resources. Web services (and SOAP, and REST, and whatever you need) is the standard when talking about calling or accessing a remote service. This means, as everybody knows, that, nowadays, the standard in remote invocation is SOAP. I didn’t forget DCOM, RPC or EJB, but all of them are platform-dependent, and I don’t take them into consideration when the word “standard” is the key factor.
Although it is normally unknown to a great number of developers, COBOL (or even PL/I) is still used in assurance, stock exchange, airlines, banking, financing, etc., this means that most of the money in the world is managed and transacted using languages and platforms designed in early 60’s. Is this bad? No, absolutely no. In fact, trust me, COBOL or PL/I running on IBM mainframes can very easily call a web service and, of course, they can also easily act as a web service provider.

What does all this means? Web services are the standard in remote invocation, for new and antique languages.


Different Platforms

As stated before when talking about what a computer application is, a cloud application should be able to run on any known platform. There are several categorizations that can be applied to the word “platform”. Firstly, a platform can be defined by a hardware architecture, an Operative System and a computer language. From this point of view, the following list contains several possible platforms:
  • IA64, Linux, PHP (a typical LAMP machine, for example).
  • IA64, Windows 2008 and .net (Winforms or ASP.net applications, for instance).
  • S390, CICS, COBOL (typical COBOL-CICS-DB2 mainframe application).
Another possible classification for platform can be client/server. That is, a cloud application can run in client platform (Blackberry, Symbian, Windows (7, CE, Mobile…), OSX, Linux…), or in a server platform (Linux, Windows, z/OS, AIX…).

Typically, a server platform cloud application can be used in one of two different ways:
  1. As a web application, clients use cloud web application as a traditional web application, accessing it by using its browsers.
  2. As a cloud resources provider. That is, the cloud application uses cloud resources and then is offered to new customers as new value-added clouded resources, once again VAA.
To be continued…