Search Site
Topics
RSS Feed

Entries in cloud computing (16)

Wednesday
Jan132010

Bursting CPU's and Distributed Applications

I wanted to call out a specific post I just read. The reason is the because it highlights a very specific area of cloud computing that often seems little understood. That is, CPU Burst-ability.

http://www.thebitsource.com/2010/01/11/rackspace-cloud-servers-versus-amazon-ec2-performance-analysis/

I'll say that I've had this conversation dozens of times with various people and it's nice to see someone took the time to really do a good study. They really went all out to test under various conditions, times of day, different servers on the same platform, and compare apples to apples about as much as is possible. One of the sage things in the report is this gem, "Typically it is best to test specific applications to get a true measure of performance..." That is so very, very true for many reasons. I wish they had time to do the test on the Joyent platform as well. It's similar in it's CPU burst-ability but under the hood it's quite different. Info I provided about this was the subject of a couple of blog posts a while back here. For example, their platform uses 8 cores whereas Rackspacecloud uses 4 cores. Amazon, as far as I know, doesn't allow you to burst at all your CPU allocation is a hard cap which is quite different from RackspaceCloud, Slicehost, or Joyent.

Lastly, people forget and I keep saying ad nauseum, how you write the app means everything as to how well it will perform on the cloud. Generally speaking, adopting many of the ideas and processes around development of distributed applications is key.  But, this is also a very foreign concept to the bulk of developers I've worked with over the years.  This fact, how you write the application matters, is true pretty much no matter what cloud you deploy on and intimately tied to how well you automate certain operations tasks as well. Anyway, I know I've been a quite blogger lately. I simply have too much work to do to blog often with my startup. But, hopefully I can get back into the groove sometime soon.

Wednesday
Sep092009

LegalCloud.net is hiring

My company, nScaled/LegalCloud.net has a job posting is on craigslist.  We recently added to our sales team and now need to add to the existing technology team.


Enterprise Cloud Computing Startup + Sr. Systems Administrator (sausalito)
http://sfbay.craigslist.org/nby/sad/1366310094.html

Cheers!b

Kent

Wednesday
Aug192009

LegalCloud in the context of the NIST Cloud Computing Definition

The NIST model of cloud computing is composed of five essential characteristics, three service models, and four deployment models. I thought it would be interesting to do a quick write up of how LegalCloud.net fits into the v15 NIST definition of cloud computing.  It's a model I certainly support, but do find a bit inaccessible to newcommers to the cloud at times.  But, that will change over time.  What follows is some information about how LegalCloud.net, a real life cloud computing service, fits into the NIST model.

Service Models:

LegalCloud is an IaaS model cloud. We are specifically delivering data center infrastructure to law firms on a globally.

In the not so distant future there will be PaaS and even possibly SaaS opportunities associated with and deployed by LegalCloud and it's partners.  There are many possibilities.

Deployment Model:

LegalCloud is a Hybrid Cloud composed of both community and private types.

Our Community is Law Firms and only law firms. This focus allows us to uniquely and completely address the needs of our clients.

As a Hybrid cloud, we provide both on-premise and off-premise services for our customers that bridge the gap between their own facilities and the cloud facilities we manage as is appropriate and necessary.

Essential Characteristics

The LegalCloud console (1.1), which is in Alpha at the time of this writing, is the tool that our clients use to 1.0 LegalCloud Console Default Viewself-provision servers in any of our globally distributed data centers. For the first time publically I’ve included a couple of small screen shots from our staging environment. The things they provision are networking, compute, storage, and a few other related things. The storage components in particular are interesting because they can be further dynamically provisioned and grown (or shrunk) on-demand.

The resources that clients provision via our console are from pools of resources. In our case they are not truly location independent as we must provide a certain amount of auditability. But, they are deployable in various geographies.

Rapid elasticity is primarily a function of programmatic interaction w/ API based controls. We will not have API access for our first release. But, we most certainly will layer it in over time. Now, which one to pick?

Our console in association with something we call a pod manager is essentially a part of a distributed monitoring tool that allows our clients to keep an eye on what’s going on for key metrics in their pod.1.1 LegalCloud Global Servers View

LegalCloud has an currently uncommon “broad network access” model. It’s production environments are only available to clients via secure VPN technologies or private lines (point to point or MPLS). We do not allow general access via the internet at large. Period. Within legal cloud all clients, while they do share some infrastructure, they do not co-mingle their data/networks.

That wraps up my comparison of how LegalCloud can be fitted to the NIST cloud computing model.

What’s next?

What is missing from the NIST model today, if it belongs there at all, are the security aspects. I have seen what is likely to be important and solid work going on around an initiative called A6. It discusses Audit, Assertion, Assessment, and Assurance API. This is also now known as A6. There is a great amount of discussion going on in this arena and I’m looking forward to analyzing LegalCloud relative to the A6 API as it matures.

So,  as soon as possible, I will write about the other issues around security related concerns and some of the issues that matter to our clients around varous A6 stated concepts.

 

Tuesday
Aug042009

LegalCloud.net Update: Enterprise Cloud Computing for Law Firms

Today Mark and I ran a webinar on Total Data Protection for Law Firms and have posted it to our video stream.

I wanted to do a quick post this morning to discuss this since it is almost entirely my focus these last few months.

Total Data Protection is the name of our Enterprise Class Hybrid Cloud Computing service that provides the ability for any Law Firm to provide business continuity for their enterprise compute workloads no matter where they are by leveraging our software stack and Private/Community Cloud deployments throughout the world.

In that definition of Total Data Protection I used some deployment model terms from the NIST definition of Cloud Computing; draft v14.  To review, those deployment models are:

Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.

Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting).

LegalCloud.net is a true Hybrid Cloud as it is a combination of Private and Community and provides services both on-premise and off-premise.  It is shared by an organization, that organization is the aggregate of all Law Firms.  If you are not a law firm, you can't use LegalCloud.net.  Period.

We are working very hard to address all the common concerns about enterprise cloud computing.  We specifically address things like auditing, compliance, network security, data security, transparency, data location and the legal Issues surrounding it.

We have other products related to or complimentary to Total Data Protection on the way and in testing.  We'll be deploying our client facing console, a really cool distributed Rails (on the front) and Java (in part of the backend) application, in a very short few weeks to the first clients.  Clients will be able to deploy Total Data Protection, Active Servers, and Provision storage in our globally distributed data centers through this interface.  Our first release will not have a clent facing API unfortunately, but we're trying not to boil the ocean you know.  However, I have started working on this by studying the best of the available API's out there and expect to move forward on specification and early development stages soon.  Of course, the API will not be public, it'll only be available to members of our cloud commnity; law firms.  But, that is the point in our case.

When I started nScaled I never imagined I'd be building a cloud quite like this one.  But, it's exciting to be sure.  My blogging certainly has taken a hit but that's okay I suppose.  Over time I'll be able to blog more and more about the various things we've been doing.

Kent now returns to his usual daily program of coffee, phone calls, infrastructure, and sales calls... 

---Kent Langley, CTO, www.legalcloud.net by nScaled, Inc.

Sunday
Aug022009

Using Curl to Access the Rackspace Cloud API

I've been playing around w/ the Rackspace Cloud API quite a bit. Then, today I got an email from a reader of this blog asking me how it works more or less. So, I thought I'd post a couple of the examples I've been using. In the absense of a fancy GUI to control cloud servers I've simply been using Curl and writing little shell scripts to get the job done.

Authentication Request

curl -D - \
  -H "X-Auth-Key: youneedtoputyourownauthkeyhere" \
  -H "X-Auth-User: acctusr" \
  https://auth.api.rackspacecloud.com/v1.0

Authentication Response

HTTP/1.1 204 No Content

Date: Sat, 25 Jul 2009 15:44:07 GMT
Server: Apache/2.2.3 (Mosso Engineering)
X-Storage-Token: 8gc00ld-a77r-6548-eq58-5nb5hsrv9876
X-Storage-Url: https://storage.clouddrive.com/v1/MossoCloudFS_8gaserd-65q3-5dfas-8888-c66e9987r953
X-Auth-Token: aq9beanS-d75c-9135-ed78-4bs3chse9135
X-CDN-Management-Url: https://cdn.clouddrive.com/v1/MossoCloudFS_d96e4c99-85ej-2pol-7777-v33e9135e669
X-Server-Management-Url: https://servers.api.rackspacecloud.com/v1.0/928875
Content-Length: 0
Connection: close
Content-Type: application/octet-stream

These aren't real tokens so you can't use them yourself of course. You need to get your own, which is exactly the point. Once you have successfully received your own response then you can move on to actually using other API calls to do things with the API. Here is a cloud servers API example using curl again.

Listing Your Account Limits

curl -D - \
  -H "X-Auth-Token: aq9beanS-d75c-9135-ed78-4bs3chse9135" \
  https://servers.api.rackspacecloud.com/v1.0/928875/limits

That will output something that looks like this:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
vary: Accept, Accept-Encoding
Set-Cookie: JSESSIONID=D6DBBE0BE05C4559BC71E6F851501575; Path=/v1.0
Cache-Control: s-maxage=1800
Last-Modified: Sat, 25 Jul 2009 15:51:26 GMT
Content-Type: application/json
Content-Length: 657
Date: Sat, 25 Jul 2009 15:51:26 GMT
X-Varnish: 1753447558
Age: 0
Via: 1.1 varnish
Connection: keep-alive

{"limits":{"absolute":{"maxTotalRAMSize":51200,"maxIPGroupMembers":25,"maxIPGroups":25},"rate":[{"value":25,"unit":"DAY","verb":"POST","remaining":25,"URI":"\/servers*","resetTime":1248537086,"regex":"^\/servers"},{"value":10,"unit":"MINUTE","verb":"POST","remaining":10,"URI":"*","resetTime":1248537086,"regex":".*"},{"value":600,"unit":"MINUTE","verb":"DELETE","remaining":600,"URI":"*","resetTime":1248537086,"regex":".*"},{"value":3,"unit":"MINUTE","verb":"GET","remaining":3,"URI":"*changes-since*","resetTime":1248537086,"regex":"changes-since"},{"value":10,"unit":"MINUTE","verb":"PUT","remaining":10,"URI":"*","resetTime":1248537086,"regex":".*"}]}}

Here is a very simple bash shell script you could use for the Authentication example above:

#!/bin/sh

curl -D - \
  -H "X-Auth-Key: 5115a48a9ca852bc266ea3e7bc8805e7" \
  -H "X-Auth-User: nscaled" \
  https://auth.api.rackspacecloud.com/v1.0

I know that there are at least a couple of companies with growing support via their cloud management platforms quickly adding Rackspace Cloud functionalities.  So, while I have to hack around with curl today I suspect that in short order it might get easier.

Cheer!

Kent

Friday
Jul242009

Sending E-Mail from the Cloud

Some cloud computing IaaS services let you send mail and others do not.  This fact can make sending email from cloud hosted applications challenging or at least require more 3rd party systems outside your cloud.  This post is about using Rackspace Cloud Servers and being able to send mail from your application servers or as an SMTP relay.  That is a possibility on Rackspace Cloud Servers.

I've been doing a good bit of work with Rackspace cloud servers for the last few months for various projects.  Rackspace does let you create and properly apply DNS settings to a cloud server for the purpose of sending mail to clients.  This is nice in many cases as it allows you to avoid setting up an espensive server elsewhere or using a 3rd party relay service.

Be aware that there are any number of things I have left out or not discussed here. This isn't really meant to be a thorough how to article. This is just an overview showing something that is possible.

Here are the very high level steps and links to some of the pertinent resources you'll need.

  1. Launch a Server from your manage.rackspacecloud.com portal
  2. Install and Configure PostFix on that server.
  3. Set your DNS Records
    1. SPF -Sender Policy Framework. You cannot skip this or your mail will not get delivered.
    2. Reverse DNS - This resides on the Rackspace side.  You cannot skip or mail will not be delievered.
    3. MX - This is done at your DNS server/provider.  Mandatory as well.
  4. Check your firewall settings, there are firewall issues to consider
  5. Send Mail happily from that server, or do a little more work and set it up as a relay server for your environment.  But, make sure you're not an open relay please!!

Random thoughts while I was typing this post:

  • $0.015 per hour to start for this service! No per message pricing.
  • If you start getting busy you can resize the server using the GUI resize tools
  • If you're using some of the beta IP grouping features you can build an HA service easily
  • Integration of cloud files for log storage should you wish to keep them
  • Support is available and solid. They will help you if you need help. They mean it when they say they are fanatical about the support thing.
  • If you want to get some monitoring on this (or other) boxes, use munin. Works great.

That is all for now.  Enjoy!