Category: Cloud Speak

The Exciting Nature of SLAs, A Comparison

Ok, I’ll admit a secret.

I haven’t read a single flippin’ SLA ever for cloud computing, hosting, managed hosting or other services. The main reason, is because it doesn’t matter unless you plan on prospectively suing or whining about your own bad architecture at some point. Sometimes, rarely, service is soooooo bad you have to pull out of the service, but generally in the vast majority of situations you can find information regarding the quality of a service. Google, Bing, and Yahoo are your friends when it comes to this. Also don’t forget your own network (you do have a network of people right?) Ask around, look around, read, research and check out anyone your going with. SLAs are a LAST RESORT item and should be treated as such.

Simply, the only thing I want in the SLA is something that covers me if I need to pull my services out of somewhere. Especially with cloud computing services (and I mean real cloud computing services that meet my baseline of geographically distributed, highly available, etc., etc like: AWS (yes I’ve done work with them), Rackspace (collaborated with them), Tier 3 (yes, I work for them), Windows Azure (yup, worked for them too and with their services), Joyent (I’ve actually never touched their services but I know what they are and what they’re capable of, no problem putting them in this category), and a few others.

So I dragged a few SLAs together for a comparo to see if there were many real differences between them. Here’s what I found from the following SLAs.

SLA Comparison Discussion

A great comparison, with grade rating of various SLAs is also available at IT Knowledge Exchange titled “A Tale of Three Cloud SLAs“. I got a few points from there in putting together this blog entry.

Overall it looks like AWS & Windows Azure both have fairly elaborate SLAs at first glance. However the company that really seems to have put together a solid “honor” based SLA is EngineYard’s. AWS & Azure both read like a bunch of lawyers sat around in a big room, that don’t understand anything about computing, and had one engineer throw words out that actually mean something – and then they ran rampant with those terms spliced through a few thousand pages of material. However, to summarize…

Both of their agreements tend to state that if YOU can PROVE that the downtime was caused by them then you can get recouped with service credits for those hours. Note, that it is a remuneration in credits, not in cold hard cash or otherwise. This seems to continue in others that I read too. But let’s loop back around for a second…

What do You REALLY Want?

Do you want an SLA or service? That’s the real quistion. If you want service and you actually have your systems put together well then moving infrastructure to the cloud or platform operations to the cloud is what you want. The fact of the matter, most of the cloud services by Windows Azure, AWS, EngineYard, Tier 3, Heroku, or otherwise have an extremely high uptime. Expectations can EASILY be in the five 9’s range. However, it is up to you to make sure that YOUR SOFTWARE is going to be able to handle that.

The Real Problems…

One issue I have noticed is this expectation that you can put a traditional application in the cloud and then it magically has better high availability and such. This is absolutely WRONG. Cloud services give you the ability to build or expand “SCALABLE” applications to a higher uptime that can’t be achieved easily, or at all, with traditional hosting and data center operations. If you take SAP, Oracle’s Database, SQL Server, Exchange, or other NON-cloud type software and stick it in the cloud you’ll still have the traditional issues to deal with related to vertically designed software. These packages are not, nor were they intended to be run in geographically dispersed, fabric enabled, highly scaled, low cost cloud provisions. They don’t make use of map reduction, query enhancements, node based computing or storage integrity, or other characteristics that cloud computing brings to us.

So the real problem isn’t “is the cloud going to provide X 9’s of uptime…?” the real question is, “Will the software you’ve made, bought, or what to use going to take advantage of the features in the cloud that will allow it to have X 9’s of uptime?”

So really, focus the question around how your software works, not SLAs. That’s my two cents, maybe you still want that CYA in the SLA, but you won’t rest easy because there isn’t a whole lot of recourse if you stick crappy software in the cloud and then it falls over on you. So best of luck, but focus on that software, not on SLAs. Cheers!

Ok, Let’s Get Some Definitions & Operational Models Straight Here! PaaS is NOT…

I just got signed up for Cloud Connect Chicago and started checking out some of the talks. One talk jumped out, being that it is about PaaS Technology. After reading it though I immediately felt the need to straighten out some things that looked misleading. Maybe the presenter (JP Morgenthal) will lay these things out well for the attendees, but at this point I don’t know that. I’m making a point to see this session while I’m at Cloud Connect. I’m curious to see how he lays out the content. Here’s the description for the “Navigating PasS: Your Road Map for Application Development“. Hopefully I’ll see you there!

Platform-as-a-Service (PaaS) has most simply been described as the set of tools above the infrastructure (hypervisor) and contains the applications being served out of the cloud. However, this description covers a large body of resources. Navigating the use of PaaS for application development and delivery requires a very wide understanding of the computing environment and doesn’t fully relieve the user from understanding the infrastructure that is used to operate the PaaS.

Hypervisor + PaaS, You’re Doing it Wrong

First off, the thing that really caught my attention about this session is that it sounds like someone from a very specific company trying to sell a very specific thing wrote this initial description. A PaaS, or Platform as a Service does NOT have to run on an infrastructure hypervisor. It has ZERO association to a hypervisor. All a PaaS should do, ought to be, and generally is regardless who it is made by or who is running it, is a set of software that automates deployment, application distribution to systems serving the application, and generally simplifies the deployment of an application and to some degree databases or data repositories. There is, and should NOT be, any type of coupling, especially any tight coupling, to some hypervisor.

In summary, a PaaS should have zero to do with a hypervisor. It should rely on a simple operating system that has minimal resource overhead and minimal requirements. Take Cloud Foundry or Open Shift. They rely on some of the most capable operating systems, Red Hat Linux (RHEL) and Ubunut LTE to run the PaaS Systems. These are by far some of the best choices in the industry to determine the core of where a PaaS should run. Based on this, it is an operating system, at the core that enables these systems. NOT a hypervisor. If you’re looking to base your PaaS System off of a hypervisor, I’m afraid you’ll have made a severe mistake right off the bat.

Now if you put your Red Hat or Ubuntu OS on a hypervisor, or straight on the metal, you’re fine. Just don’t cross the seperations of concern from the operating system to travel from PaaS to hypervisor. That’d just be…

wrong.

What I Agree With, You Better Understand IaaS

One thing I agree with in the above description and I’m betting JP will put some emphasis on this part of the discussion, is that you absolutely need to have an understanding of your infrastructure that runs underneath your PaaS. There are a multitude of reasons to keep in mind what the infrastructure is doing underneath and how it handles what you’re deploying to your PaaS. Here’s two hugely important topics of concern when you deploy a PaaS into any environment.

  • When an application deploys to multiple instances. What does that mean in your PaaS? Is it on several separate instances? Is it in different geographical areas? Does it go under a different load balancer? How is my database deployed? If you’ve deployed a NoSQL solution, that needs multiple nodes for data integrity, do you know how many nodes are deployed?
  • If I deploy a site to my PaaS, how will it and can it talk to itself or outside via networking? Do I have loop back protection on for security? Will it disallow certain port traffic? What is happening to port traffic and traffic in general?

It looks like the session will cover a lot of these topics. So if you’re looking to attend, I highly suggest checking out JP’s session. I’ll be looking forward to his approach to many of the other topics (check out the site description) such as those I just mentioned along with security, deployment concerns, deploying a single language PaaS (like Apprenda, Cloudbees, etc) and other solutions. In addition to that, I’ll likely be bringing an arsenal of questions, see you all and JP at Cloud Connect!

I Can Talk About It Finally! => Tier 3 Web Fabric Platform as a Service (PaaS)

A couple months ago I shifted gears and started working for Tier 3 on a number of projects. I made this decision for a few reasons:

1. I’m a huge advocate of PaaS (Platform as a Service) technologies. I like what PaaS enables and what it eliminates. Matter of fact I’d say I’m a bull on the technology. I like to learn about, create and build the architectures within platforms. I also love the rather complex back end problems that come up when building a truly powerful, scalable, high end, highly available PaaS. You say, “Adron, Tier 3 doesn’t have any PaaS stuff, it’s an IaaS Provider, this doesn’t explain anything?” Aha! Read on (unless of course you’ve caught the news today… then you already know the answer)

2. I’m a polyglot dev. .NET kind of burned me out a few years back and I dedicated to learning as many other frameworks, languages, and tech stacks that I could. I’ve never been happier with the variety these days. I’ll admit though I still love to use all those years of experience I have with .NET. Indeed, I have a little soft spot in my heart for C#. Tier 3, along with the Iron Foundry Project, has given me the opportunity to work across languages and stacks including Node.js, Ruby, Objective-C and more.

3. I like to build things, advocate for those things and what they can do for you, for dev teams, and in the end what we developers can build with them. Sometimes this might mean I do it myself, sometimes it means coordinating and leading a team (or as I often say of leads, “serving” the team). Right now I’m getting to do a little bit of both and it is indeed fun and really exciting! This brings me to the answer.

The Answer:  Tier 3 now has one of the, if not the most advanced PaaS Environment available today.  Yeah, you can quote me on that. I’m not saying it because I work at Tier 3, I’m saying it because I decided to come work at Tier 3 to help build it. Those of you that know me, know why and where I do things. I have intent behind these decisions.  😉

The Tier 3 PaaS environment officially has more support for frameworks than any other PaaS Provider out there today. Congratulations to the team for getting this out the door! Needless to say, I’m proud to be a part of this team of bad ass devs! Cheers!

What is the Tier 3 Web Fabric?

Here’s a short tour I put together…

What exactly makes up a Web Fabric? We’ve taken Coud Foundry as a core, adding Iron Foundry for full support of all major Enterprise Frameworks and added a fabric over these services to provide an automated seem-less creation of a complete PaaS Environment.

How would you use a PaaS like this?

In an enterprise software and application development shop there is often a break out between development, testing, maybe a UAT (User Acceptance Testing) and finally production. One way to utilize such capabilities is to built a Web Fabric for each of these environments. Once each environment is built, these can then be scaled up or down as needed. Once the environment is done simply delete it. For an environment like UAT or Test, this is one of the most ideal situations to create an environment from scratch, ensuring that outliers don’t affect the testing criteria. How do you build a Tier 3 Web Fabric PaaS? This is the fun part. This process involves a little information and a few clicks, which then will build an entire PaaS environment.

Step 1: In the Tier 3 Control Panel click on the tab titled “Fabrics“. Inside that view, click on “Create Web Fabric“.

Tier 3 Control Panel
Tier 3 Control Panel

Step 2: Fill out the information requested on the screen. The user that you’re creating will be your Tier 3 Web Fabric Administrator. The name becomes part of your URI to access the PaaS API from, and the friendly name below that displays as a description in the control panel. The last piece of information is public or private, the private option limiting access to only VPN users of your Tier 3 Account.

Creating a New Web Fabric
Creating a New Web Fabric

Step 3: Now give it some time. Remember this is not merely a simple virtualized instance of an operating system. What is now happening is a Cloud Foundry environment is being built, Iron Foundry is also added & other enhancements are being applied and built. This then creates an entire Tier 3 Web Fabric that can be used with any of the following tools, languages, and databases.

A few of the languages and frameworks…

  • Ruby on Rails or Sinatra
  • ASP.NET w/ whichever .NET Language, it could be C#, VB.NET, or .NET COBOL if you so felt inclined to build a web application with it.
  • Java w/ Spring and other options.
  • Node.js Nuff’ Said
  • Python

Of course the database services too…

  • MongoDB
  • MS SQL Server
  • vmWare PostGreSQL
  • Redis

These are just a few that are and will be supported in the coming days. The Cloud Foundry base provides a massively powerful core to build off of and extend services and frameworks.

For pushing applications to the Tier 3 Web Fabric, here are some tools to help with that…

vmc-IronFoundry :: This is the same thing as the vmc CLI that is part of the Cloud Foundry Project except that it adds support for .NET pushes from the command line too.

vmc :: this is the default way used by most people working with Cloud Foundry based PaaS Environments.

Eclipse & STS for Java :: this is the extension that integrates into Eclipse.

Cloud Foundry Explorer :: this can be used to view and push .NET applications to the Tier 3 Web Fabric (or any Iron Foundry enabled Cloud Foundry Environment)

Open Source Software, Iron Foundry and More…

In the coming days, weeks, and months I’ll be working with the team here at Tier 3 to drive more capabilities and features. In addition I’ll also be driving the Iron Foundry Open Source effort, pushing to extend what we’ve provided already with the .NET support extension on Cloud Foundry and also more. We here at Tier 3 love the open source community, and we love being part of the community. So with this announcement I wanted to add a big, huge, awesome THANKS to everyone out there passionately involved in and building software that is open source. You all ROCK!

Stay tuned, this is merely the beginning.

Cloud Foundry 1 Year Anniversary & New Bits (Code Included)

Today was the 1 year anniversary for the Cloud Foundry Open Source PaaS Project. For info on what PaaS is, especially related to open source and related to Cloud Foundry check out my 5 part series at New Relic’s Blog; Part 1, Part 2, Part 3.1, Part 3.14159265, Part 4, and Part 5 (which I know, it is really a 6 part series).

Updates, Updates, and More Updates!

Today was pretty cool and jam packed with code & information. There are a load of updates in the Cloud Foundry Repository now.

One of the big parts of the new features released today, isn’t so much a feature, but an entire open source project based around actually building & deploying an entire Cloud Foundry PaaS Environment called BOSH. Here’s my takeaway notes about this project, what it does, and how it can help Cloud Foundry usage.

BOSH (https://github.com/cloudfoundry/bosh.git)

The first thing to do, when learning about and using BOSH is to hit the groups:

What is it?

BOSH is a YAML based Cloud Foundry deployment tool. It provides a way to deploy a multiple image machine into a new Cloud Foundry environment. These images, just basic VMs, are referred to in the BOSH System as Stem Cells.

There is more to learn about BOSH, but for now suffice it to say there is some serious potential in what it enables for building out a Cloud Foundry Environment. Up until now this process was a manual installation effort which would take take a lot of energy and take an long time.

Cloud Foundry Additions?

There are a lot of Cloud Foundry changes that are in the works and a lot that went in. However, from an external point of view, there isn’t a lot of visible changes. No new user interface or anything like that. The biggest changes have been around stability, scaling, deployment, and other core capabilities.

For further information and news on the release, check out some of these write ups:

Cloud 9 IDE ROCKS!

Outside of the Cloud Foundry Project there are other things working toward interoperability with Cloud Foundry and building in features that will help you work against Cloud Foundry. One of those companies is Cloud 9. They’ve enabled single-click deployment via their Cloud 9 IDE.

That’s it from me for now. I’ll have a lot more regarding Cloud Foundry, Iron Foundry, and other projects related to PaaS soon.

Wrapped Up @ The Fort of Awesome, on to the Iron Foundry, and new Tiers…

New update and bits coming up in the near term. I wrapped up my work with AppFog’s Fort of Awesome and am now putting together blog articles & technical material for New Relic these days. They’re an extremely great company with an absolutely stellar team. However you may be asking, “Adron, YOU WRITE CODE ALL THE FREAKING TIME, you’ve got to be doing more than blog entries!!” and you’d be right. These blog entries are more than just opinions and such, I’ll be putting together demoes and some hard core examples of distributed architectures, trending against big data, node.js hackery, and all sorts of other stuff. But there is also my next update below that’s a lot of fun code…

Tier 3, Federated Clouds, and Iron Foundry

I’ve stepped in to take the lead on the Iron Foundry Project (so go sign up and fork it!!) and to work on the stability, governance, and code around Cloud Foundry too! It’s going to be a blast! In addition to that I’m helping to build some cool things at Tier 3. In the near future I’ll have a lot more information regarding what these things are.

At Tier 3 we have a massive Enterprise Cloud Infrastructure offering. It’s a pretty impressive setup, so much so that I’m leading some of the efforts there, so I’m not just saying that! Keep an eye on us too, because we’ll have some very cool things coming up (did I say that already?)  🙂

Cloud Foundry Hackathon PDX, Cloud Foundry Open Tour, and Coder Society

Cloud Foundry Hackathon PDX

The Cloud Foundry Hackathon is on April 14th at Puppet Labs. Check out the Lanyrd Site and Calagator for calendar and RSVP. This is going to be an awesome event which will also be in partnership and extension of some of the work we’ll start at Coder Society on April 7th. So if you’re into hacking on the Cloud Foundry core bits or if you’re interested in hacking on apps deployed to Cloud Foundry come and hack with us. In addition I’ll be putting on two workshops:

  • On Premise, Off Premise Cloud Foundry => We’ll dive into, and get hands on, with identifying and connecting Cloud Foundry Environments regardless of their premise. Removing boundaries, that’s what this is about.
  • Cloud Foundry + Iron Foundry and Bridging the Gaps => Now we’re talking FULL stack across every major stack. Iron Foundry, the missing linq in Cloud Foundry. Adding .NET & having it play nicely with Node.js, Ruby on Rails, and more. We’ll also dive into SQL Server, Mongo, and how to make the best use of RDBMS + NoSQL bits. Making the most of the abilities with PaaS.

Cloud Foundry Open Tour, The PDX Stop

The VMware sponsored Cloud Foundry Open Tour has a stop lined up epic Portlandia! There will be a pretty bad ass crew there of people you’ll want to meet and talk to about Cloud Foundry’s direction, design, enterprise cloud offerings such as Stackato, Tier 3, and others. On twitter, if you don’t follow these people and you’re stepping into the future with PaaS, you should follow them (click their names for their respective twitter account):

…and others, come attend and you’ll get to meet them all. I’ll also be there and you can follow me on twitter too if you want (@adron).  😉

Our good friends from ActiveState will also be there, bringing their awesome Stackato Cloud Foundry based offering! The Iron Foundry Project also just released full support for the Stackato based Micro Cloud Foundry VM with new Micro Iron Foundry bits too.

Coder Society…

Oh yeah, the Coder Society, I’ve got the info on the Coder Society Inaugural meet up announcement coming tomorrow first thing in the morning at 5am. If you haven’t checked out Coder Society yet, hit the site and join the list. No, don’t get up that early, I’m just guessing that’s when I’ll be done with it and click on the publish button!  😉