TSSJS2010: The Cloud Computing Continuum

Bob McWhirter by far gave the best keynote session I’ve seen yet.   His delivery is humorous, he’s got great stage presence, and the slides were very creative.  Furthermore, he was best able to give me an understanding on what the hell the cloud is anyway.

The cloud is the next logical step in application delivery.

First, we jammed some servers in some closets.
Then we did some colo.
After that, we leased some managed servers.

With the cloud, we lease what appears to be servers.

The Cloud Computing Stack

Software as a Service (SaaS) – Abstracts software
Platform as a Service (PaaS) – Abstracts Services
Infrastructure as a Service (IaaS) – Abstracts Hardware

Tenets of the Cloud

  1. Illusion of Infinite Resources
  2. On Demand Acquisition and Provisioning
  3. Someone Else’s Responsibility

Virtualization makes it affordable to make mistakes.  Repeatedly.

The network isn’t all that slow, compared to spinning disks.

Messaging (REST-MQ)
Scheduling
Security & Identity (OASIS)
Computation (Query and otherwise)
Transaction (REST-TX)
BPM
Telephony

It’s a stack of services, instead of a stack of software.

More info at http://cloudpress.org

TSSJS2010: Mission Critical Enterprise/Cloud Application Case Study

Not a good start.   The speaker, Eugene Ciurana, is nowhere to be found.   Apparently he’s on his way.  Hopefully his mission critical apps are more responsive than he is.  😉   He finally arrives out of breath as he was apparently working out at the gym.   After he catches his breath, we begin.

The presentation is about how to design, implement and roll-out cloud/enterprise hybrid applications.   There are a lot of different cloud architectures:  PaaS, SaaS, and IaaS (infrastructure as a service).   Technologies include: ESB, clods, mini-clouds, Java, App Engine, Chef!/Puppet, etc.    Cloud technologies lower your cost:

* Which applications are best suited for cloud deployment?
* Identify the advantages of PaaS or SaaS resources?
* What are the caveats of cross-platform and cross-language integration?
* High-performance alternatives to XML serialization for data exchange?  (i.e., JSON)

What is the Cloud Anyway?
* Platform as a Service (Amazon, Google, Rackspace, etc.)
* Software as a Service (Salesforce.com, Amazon)
* Infrastructure as a Service (IBM, HP)
* Pure-infrastructure (Data centers)

Cloud Services Features
* Quick deployment of prepackaged components
* Uses commodity, virtualized hardware and network resources
* “Pay as you consume”
* Horizontal scalability is achieved by adding or removing resources as needed
* May host full applications or only services
* They could replace the data centre
* Basic administration moves to the application owner
* For the bean counters… it’s an operational expense!
* Assuming sensible SLAs, the ROI is better than for co-located or company-owned data centres (but won’t achieve 4 9s)

Uptime != Availability.   Many factors affect availability: network, storage, process

Hybrid Cloud Architecture

* Many mission-critical systems will live behind the corporate firewall
* The cloud is used for high-load applications and services
* The cloud applications work independentlyof the data center applications, and vice-versa.

Case Study: Video game company with  hybrid cloud application

Objectives
* Stable architecture
* Low cost
* Build scalability whenever possible
* Optimal data transfer rate for all properties

Initially, there were some 8 machines that were running everything: QA, PROD, debugging, etc.   The performance was atrocious!

Phase 1: Scalability

* Introduces a CDN for asset delivery (media, images)
– Amazon S3 for asset delivery
– Reduces load on company servers and bandwidth costs
* Introduces database replication for production environments
* Establishes a continuous integration environment
– Improved build/release process
* Fail-over with traditional database replication techniques

Phase 2: Cloud Deployment
* Web applications move to a uniform technology (.Net)
* The database and stored procedures normalized and optimized
* Applications use common resources via Mule ESB and services
– No more direct calls from apps to database
– Business logic is implemented as stateless POJOs
* Software stacks was best of breed
* Web and other RPC services must coexist
– Different partners use different protocols
* Bandwidth can be expen$ive!
* Data exchange protocols
– clients: custom, XML, JSON
– images: HTTPD, S3
– Cloud-to-HQ: custom, XML/SOAP, protocol buffers
– HQ data center: XML/SOAP, protocol buffers
* Replication strategy: data centre
– The cloud isn’t trustworthy yet
* Deployment involves using an Amazon Machine Image (AMI)
* AMIs need a post-configuration step in a load-balanced environment
* Elastic Load Balancer and Elastic IP limitations

And so it ends.   This session clearly pitched to C-levels (in particular CIOs.)  There was very little meat and substance for Java geeks to get their hands on.   It’s a shame.   Clearly Eugene has a lot of knowledge, but this was just way too high in the clouds (pun intended)

TSSJS2010: Cloud Computing with Scala & GridGain

I’m here at the beautiful Caesar’s Palace waiting to hear more about Scala.   James Gosling’s keynote speech this morning was a bit of a letdown.   I was hoping to hear a visionary speech from the father of Java, perhaps not with Obama’s oratory skills, but nevertheless captivating.   What I got instead was a 60 minute informercial on Sun’s current product offerings.   Yes, Java EE 6 and GlassFish 3.0 are totally slick, and I do like the concept of using annotations for event handling.   That said, I was hoping he would talk more about the future of Java, especially with all the Oracle merger and everything.   Anyway, no-go.   So now I’m here waiting to hear what the hell is Scala and how I can use it.   From what I’ve read, they’re using it at Twitter, so it’s gotta be somewhat scalable, right?  😉

The presentation is broken down with 20% talking and 80% live coding.   Nikita Ivanov, the presenter, has a very good stage presence and I enjoy his direct approach.

We start with the talking part by defining a few terms for us neophytes (including myself!)  What is Grid/Cloud Computing?   A Grid is defined as two or more computers working in parallel.   Grid Computing is comprised of Computer Grids + Data Grids.    The Cloud, meanwhile, is comprised of Data Center Virtualization.  Clouds are the new way to deploy and run grid applications.

Why Grid/Cloud Computing?

It solves problems often unsolvable otherwise.   Google has ~1,000,000 nodes in its grid.   Put another way, it’s about money.   Amazon says that 100 ms latency cost 1% of sales.  Google says that 500 ms latency drops traffic 20%.   In the financial sector, one millisecond costs $4M in currency markets.

GridGain at a Glance

The project was started in 2005 as Java-based Cloud Development Platform:
* Compute Grid (aka, MapReduce)
* Data Grid (aka. Distributed Cache)
* Auto-scaling on the cloud

Scala at a Glance

* Started in 2004 by Matin Odersky at EPFL  (author of ‘javac’ and Java Generics)
* Scala is Post-Functional Language (combines functional and OO approach)
* Fully inter-compatible with Java (runs on JVM, Call Java and called from Java methods)
* Statically typed (Unique and powerful type inference)

Apparently, there’s more use of Scala in Europe than there is here in the US.   A large national French bank already has a dozen Scala projects rolling out.   In the audience here today, only one hand was raised when asked who was using Scala today?

Why Scala?
* Performance largely equal to Java
* Statically typed
* Inter-compatible with Java
* Scalable language

Scalar – Scala-based cloud computing DSL + GridGain 3.0
* Uses Scala
– Functional-impertive
– Runs on JVM
– Reuses 100% Java libraries
* Running on top of GridGain 3.0 runtime

DSL – Domain Specific Language
* Provide simple cloud computing model
* Draws on functional features of Scala
* Dramatically simplifies cloud computing applications

The demo is to build a Scala grid application in 10 minutes!

import org.gridgain.grid.gridify.Gridify
import org.gridgain.grid.GridFactory

object ScalaDemo {
    def main args: Array string {
        GridFactory start

        try {
            say "hello Scala Las Vegas"
        }
        finally
            GridFactory stop true
        }
    }

    @Gridify
    def say msg: String   { println msg }
}

This code automatically deployed the object to the Grid and executed it on one of the nodes!   That’s mindblowing and so cool!   Clearly there’s tons of complexity behind the scenes.   The class definition must be serialized, the grid must be located, some scheduler must identify the node on which the object is to run.   I’m totally blown away by how painless it is to deploy on a grid!

Ivanov proceeded to write a task in about 10 lines of code that split the string into words and dispatched the job of printing those words onto the various nodes.

The same demo was then given using Scalars, which is a GridGain construct.    That got a little more cryptic, in my humble opinion.   Still, it did require less lines of codes to get the job done.   The tradeoff, though, seems to be readability.  You’re slowly creeping into the world of Python, which I’ve never enjoyed because only the original developer can ever make bug fixes.

Still, Scala clearly is pretty slick and it looks like the integration with GridGain in order to parallelize tasks is very easy.   I’ll definitely need to investigate how I can leverage this for risk analysis.