Re: Cloudcamp Seattle

Summary Statement:  CloudCamp rocked!  I got to meet a lot of smart people and have a lot of smart conversations!

Ok, so I probably shouldn’t write the summary statement first, but I’m not one for standard operating procedure.  But I digress, I’ll dive straight into the cloud topics and the event itself.

The event kicked off with an introduction and lighting talks by Tony Cowan, Mithun Dhar, Steve Riley, John Janakiraman, Margaret Dawson, and Patrick Escarcega.  Margaret and Steve really stood out to me in their talks, I’ll be keeping an eye on any future speaking engagements they may have.

One of the quotes that led off CloudCamp during the lightning talks was, “If you’re still talking about if the cloud is secure…” you’re already behind, out of touch, missing the reality of it, or simply not understanding the technology.  After further conversation though, it really boils down to the most common excuse.  The statement “the cloud isn’t secure enough” translates to “I’ve got my fingers in my ears and am not listening to your cloud talk”.

Margaret Dawson from Hubspan really took a great stance with her lightning talk.  The talk was titled “To Cloud or Not To Cloud” with “Don’t buy the cloud, buy a solution” as the summarized idea.  The other thing that she mentioned during her talk was she likes adding “AASes” to cloud computing, such as “BPaaS”.  I’ll admit I laughed guiltily along with a few dozen others and forgot to note what BPaaS stands for.  Whoops!  🙂

An attempt at creating a generalized definition of cloud computing was also made.  It was stated that we can, as a community, agree on the following definitions of cloud computing.  The definition involved three parts:

  • Cloud computing is on demand.
  • Cloud computing can be turned off or on as needed.
  • Cloud computing can autoscale without issue to handle peaks and lulls in demand.

Another funny statement came from Dave Neilsen (@daveneilsen), CloudCamp Organizer, “I agree, the cloud isn’t right for everyone” to which someone in the crowd jokingly hollered back “You’re Fired!”  The energy in the audience and each of the sessions was great!

After the lightning talks Dave Neilsen led the conference with a cloud panel to field some questions.  A few topics related to this wikileaks thing 😛 came up along with some others.  I tired diligently to take good notes during this time, but it was a bit fast paced and I left the note taking to be more involved in listening.

These activities kicked off the overall event, which then led into everyone breaking out to different sessions depending on topics created by the attendees.  The sessions included (and I may have missed one or two);

  • Open Source Software in the Cloud
  • Best Practices for Low Latency
  • Intro to Cloud Computing + Windows Azure
  • How does a traditional Microsoft Stack fit in Amazon Web Services (AWS)
  • Google Cloud Services
  • What are your personal projects?

As another aspect of this review I wanted to pull in a few tweets that mentioned or had something useful in relation to the #cloudcamp + #seattle hashtags from last night.

…with that, my cloudcamp review is fini.  Hope to see everyone at the next Seattle Cloud Event!

Top 10 Cloud Predictions by…

Time for a lunch time blog entry…

Information Management put together some cloud predictions for the cloud industry.  Here’s my 2 cents for the key points I picked out.

  • You will build a private cloud, and it will fail.  <  Thank goodness.  Get rid of the whole premise, it’s kind of stupid.  The basis of cloud computing is the almost endless backing of massive funding for massive amounts of systems.  Throw into that mix massively distributed, geographically dispersed locations where the machines are located.  A little contraption in a box thing called “cloud” is bullshit.  Plain and simple, don’t delude yourself.
  • Hosted private clouds will outnumber internal clouds 3:1.  <Good.  The internal clouds – see above comment.
  • Community clouds will arrive, thanks to compliance.  <Awesome!  This is when laws, rights, and other ideals will seriously come to play within the cloud computing space.  Community clouds will have to be transparent in ways that AWS, Rackspace, Windows Azure, and others will never be.  They might not be as robust or feature rich, but it will enable communities and others to utilize the cloud with known rights, liberties, and other notions that aren’t up for debate as they are with the other cloud providers (re: Wikileaks & such)
  • The BI gap will widen.  < BI is PERFECT for the cloud.  BI on current system on relational databases without thinking about NoSQL, Big Data, and other notions is a major problem.  BI will begin migrations to utilizing the cloud or BI will just die and another cloud related acronym will most likely come to replace it.  Real time Business Intelligence is much more readily available with cloud resources than attempting to implement real time business intelligence on-premises.
  • Cloud standards still won’t be here – get over it. < I agree.  I’m over it, and I’m not even remotely worried about it.  Maybe it is because I’m a software developer and I lean heavily on well designed, solid architecture, loosely coupled, SOLID ideals, and other things that would allow me to prevent lock in at multiple levels of usage.  In addition, I know what is what within the cloud, I don’t need some arbitrary standard since the obvious usage patterns are already pretty visible in the cloud community already.
  • Cloud security will be proven, but not by the providers alone. < Cloud security is indeed a shared responsibility.  If one is in the cloud industry though and is still talking about the “cloud being secure”, they’ve not been paying attention.  The security concerns are much less with cloud computing than most on-premises computing.  The biggest security concerns, at the actual software level, are still the same.  These responsibilities are shared, but rest heavily on the shoulders of software developers, architects, and in the same places a company (or Government entity) has previously needed to be concerned with.

Overall I’d love to see two things for the cloud community.

  1. Stop accepting the “Security is a Concern because I’m scared and haven’t been paying attention” and just start implementing.  The reason being is those same people that are kicking and dragging their feet into the future will keep kicking and dragging their feet.  Eventually they’ll either be unemployed or update their skill sets and legacy ideas and step into the future.  They’ll be a contributing part of the community and we can all smile and be happy then!
  2. More significant penetration needs to be made into the Enterprise IT Environments.  I know, some people won’t be needed anymore, but others will be needed for the new applications, tooling, and things that one can do by not wasting resources on physical boxes, excess IT costs, and other now unneeded IT impediments.  IT and business itself needs to realize this, the sooner the better.  The companies that realize this sooner will be able to make significant strategic headway over their competitors.  Those companies that never realize this will most likely wither and be dead within 2-3 years of mass adoption of the cloud options.  Simply, “skate or die”.

CloudCamp Seattle!

Cloudcamp Seattle (December 1st)
Cloudcamp Seattle (December 1st)

Tomorrow is the big day!  So be sure to come check out CloudCamp Seattle!  We’re going to have a lot of great attendees, some rock star lightning talks and more.  Make sure to get registered ASPA (click on the CloudCamp image above).

Location:
Amazon HQ
426 Terry Avenue North (At South Lake Union)
2nd Floor Conference Room
Seattle, WA 98109

Final Schedule:
6:00pm Registration, Networking w/ Food & Drinks
6:30pm Welcome and Thank yous
6:45pm Lightning Talks (5 minutes each)
Tony Cowan – WebSphere CloudBurst/Hypervisor Editions
Mithun Dhar – Microsoft Azure
Steve Riley – Amazon Web Services
Sundar Raghavan – Skytap
Josh Wieder – Atlantic.net
Margaret Dawson – Hubspan
Patrick Escarcega – “Managing Fear – Transitioning to the Cloud
7:30pm Unpanel
8:00pm Begin Unconference (organize the unconference)
8:15pm Unconference Session 1
9:00pm Unconference Session 2
9:45pm Wrap-up Session
10:00pm Raffle Books: “Host your website in the cloud” by Jeff Barr
10:15pm Drinks at 13coins sponsored by Clear Wireless Internet

NW Cloud
NW Cloud

Local Organizers:
– Jon Madamba of http://www.sawsug.com
– Shy Cohen
– Krish Subramanian of Krishworld
– Adron Hall (Me)
– Dave Nielsen of CloudCamp

Cloud Throw Down: Part 4 – Perspectives on PaaS

 

Amazon Web Services
Amazon Web Services
 

Windows Azure
Windows Azure

Previous Throw Down…

Alright, time for the battle o’ clouds to roll on. In this throw down I’m going to compare platforms from the infrastructure and platform perspective. Windows Azure takes a very distinctive, and unique, Platform as a Service (PaaS) model and Amazon Web Services takes a very Infrastructure as a Service (IaaS) model. Each of these things start at different architectural levels for applications and provide different architectural perspectives. Before jumping into the comparison let’s take a look at what a developer, IT, or network specialist has to consider when building and deploying an application into either environment.  I’ve highlighted the following steps to the specific profession that each model would most likely involve.

PaaS, Platform as a Service development and deployment model

Steps to Begin Building a Web Application or Service Application

  1. Start a Project in your preferred development environment.
  2. Build the code base.  (Such as a web application or service application)
  3. Create the platform web or service role for hosting the web or service application.
  4. Setup the project deployment with the role parameters.
  5. Deploy the project to that location.
  6. Setup an appropriate domain name and point it at the site via nameserver/DNS.

IaaS, Infrastructure as a Service development and deployment model

Steps to Begin Building a Web Application or Service Application

  1. Start a Project in your preferred development environment.
  2. Build the code base.  (Such as a web application or service application)
  3. Start the OS Instance of your choice.
  4. Install and configure the environment for hosting (IIS, Apache, or otherwise).
  5. Setup the project deployment with the role parameters.
  6. Deploy the project to that location.
  7. Setup an IP address or externally accessible addressing for the instance.
  8. Setup an appropriate domain name and point it at the site via nameserver/DNS.

As one can see there are more steps, and with reason, more costs to IaaS than to PaaS.  With IaaS more control and with PaaS less control, but with the lack of control comes lower costs and barriers for entry.  This is most likely, as I’ve heard more than a few times, why Microsoft has pushed the PaaS instead of going IaaS.

So how do each play out in offering the Platform as a Service?

First off, I have to point out that Amazon Web Services doesn’t really offer a PaaS.  So comparing them directly is almost impossible.  In addition, by not offerring a PaaS it sets up AWS at a disadvantage in this realm.  But that being the case, there are 3rd Party Software Companies that offer PaaS Solutions for AWS such as Makara and Heroku.  In addition there is rumor that AWS may be heading for a PaaS Offering soon.

I’ve fought with this topic in regards to AWS & Azure.  It all really comes down to what your point of view is.  So that’s how I’m going to score each of the services.  I’ll layout a point of view (POV), which will be a simple description of the team that is building the cloud software, what the end goal is from the business in generic terms, then layout what would be a higher or lower cost, and finally which would provide the fastest time to market with the least amount of cost.  It’ll be complex on the back end, but I’ll work to lay it out as neatly as I can.

POV:  A Small Business, less than 15 people, working toward a website style SaaS Product.

  1. The team has enough experience and technical skills to develop the product from AWS’s IaaS or Azure PaaS.
  2. The business wants the product out to market in 3 months.
  3. The team & business knows which geographic regions they need to focus on specifically.
  4. The team wants control over instances and has flexibility of server OS, preventing OS lock in. (i.e. they can use Windows or Linux)
  5. Autoscaling must be robust as traffic is expected, hopefully, to skyrocket as the product becomes recognized and available.

In this situation, AWS wins because of items 1, 2, 3, 4, and especially 5.

POV:  A small business, less than 15 people, working toward a website style SaaS Product.

  1. The team has .NET and Windows deployment experience, but minimal experience around networking, hosting, or infrastructure experience.
  2. The business wants the product out to market in 3 months.
  3. The team & business don’t care what geographic region the website is focused in.
  4. The team doesn’t care about server lock in, Windows is fine by them.
  5. Autoscaling and controlling traffic bursts isn’t a high priority for the team or business.

In this situation, Azure wins hands down based on 1, 2, 3, 4, and 5.

POV:  An enterprise team wants to create a high quality code base, utilizing SCRUM with test driven development practices.

  1. The team knows .NET and Java very well and a little bit of networking, hosting, and infrastructure.
  2. The enterprise wants a steady release cycle of tested, highly reliable code.
  3. The enterprise isn’t worried about which OS the team uses.  Windows or a *nix variant.
  4. Autoscaling is irrelevant, as long as capacity can be brought up and down in a timely manner to extremely high counts exceeding 1000+ instances.

In this situation, AWS wins hands down on 1, 2, 3, and 4.

POV:  An enterprise team wants to deploy regularly, maintain their existing .NET stack, and utilize existing SDKs to keep the ramp up time minimal.

  1. The team wants to use a familiar stack based on .NET and use SDKs if available.
  2. The team isn’t concerned heavily with testable code, mostly just have a framework to build around that is familiar.
  3. The business just wants the team to maintain familiarity with what exists in the company already.
  4. The team wants to provide a single sign on (SSO) security implementation, using the cloud if possible.

In this situation, Azure wins easily for reasons 1, 2, 3, and 4.

POV: A Development team is putting together a public facing SaaS application.

  1. The team wants to use whatever product has the best price point.
  2. The team wants a strong enterprise style message bus to provide application messaging.
  3. The business wants to deploy frequently and as soon as possible.
  4. The team doesn’t care if the code is PHP, Java, .NET, or otherwise.
  5. The team will create high quality code, and will build their own testing mocks, stubs, and other elements if need be.
  6. The team doesn’t intend to use the SDKs from either AWS or Windows Azure, they want to keep lock in minimal so are building to services using good design patterns.

This situation is unique, and causes a tie between Azure and AWS for reasons 1 and 2 combined, 3, 4, 5, and 6.

Windows Azure
Windows Azure

Based on these scorings, things might be a little confusing.  I’ll elaborate a bit on some key points in the next entry on AWS vs. Azure.  For now, I’m going to hand the victory to Windows Azure.  The reason is simple, the PaaS perspective, in a little more than 50% of situation where PaaS or IaaS can be used should go with Windows Azure.  In situations where a PaaS is desired then Windows Azure is pretty much the only serious option out there these days.  Simply, Windows Azure just offers a ton of really serious features via cloud services for a PaaS offering.  Stay tuned for the next grand battle between the cloud giants!


Cloud Software Architect Necessities

Cloud Architecture is becoming more and more relevant in the software industry today.  A lot of efforts are becoming less about software and more about cloud software.  The whole gamut of cloud technology; platform, service, infrastructure, or platforms on platforms are growing rapidly in number.  The days you didn’t need to know what the cloud was are rapidly coming to an end.

As I move further along in my efforts with cloud development, both at application level and services levels, I’ve come to a few conclusions about what I do and do not need.  The following points are what I have recently drawn conclusions about, that cause frustration or are drawn from the beauty of cloud architecture.

REST is King, Period

When I use REST in this context, I don’t just mean a nice clean URI or “not SOAP”.  I’m talking about the whole entire enchilada of REST Architecture Principles.  A good place to start learning about REST is the Wikipedia Article.  Other key resources to check out include;  Roy T. Fielding’s Dissertation, specifically chapter 5, Principled Design of the Modern Web Architecture, and the O’Reilly Book RESTful Web Services.

REST Architecture is fundamental to the web and the fact that the web is continuous in uptime.  The web, or Internet, doesn’t go down, doesn’t crash, and is always available in some way.  REST Architecture and the principles around it are what enables the web to be this way.  The cloud seeks to have the same abilities, functionality, and basically be always on, thus REST Architecture is key to that underpinning.

Core Development

Currently I do most of my development with C# using the .NET Framework.  This is great for developing in cloud environments in Windows Azure and Amazon Web Services.  The .NET Framework has a lot of libraries that work around, with, and attempt to provide good RESTful Architecture.  However, there are also a lot of issues, such as the fact that WCF and ASP.NET at their core aren’t built with good intent against RESTful Architecture.  ASP.NET MVC and some of the latest WCF Releases (the out of band stuff) are extensively cleaning this up and I hear that this may be sooner than later.  I look forward to have cleaner, bare bones, fast implementations to use for RESTful development in Azure or AWS.

The current standing ASP.NET (Web Forms) Architecture is built well above the level it should be to utilize REST Architecture well.  Thus it creates a lot of overhead and unnecessary hardware utilization, especially for big sites that want to follow good RESTful Practice.

WCF on the other hand had some great ideas behind it, but as REST increased in popularity and demanded better use of the core principles the web is founded on, the WCF model has had to bend and give way some of its functional context in order to meet basic REST Architecture.

Anyway, that’s enough for my ramblings right now.  Just wanted to get some clear initial thoughts written down around Cloud Architecture needs for the software developer.