Service Energy – Complimenting Data Gravity

2 Feb

It has been a while since I posted anything referring to Data Gravity.  While Data Gravity is interesting and can explain many motivations of Cloud Companies and their Data Services, there are other influential forces at work.
Service Energy

What am I referring to as a Service in this case?  Any code or logic that has been deployed by a provider to expose a resource.

Examples include:

  • APIs
  • Message Queues and Buses
  • Automation, Scripting, and Provisioning Interfaces
  • Web Services
  • Many more…

When resources are externalized, this is what enhances the value of Data and helps increase Data Mass and Data Gravity. As a Service is used more frequently, the amount of energy it is emitting increases in our analogy.  The emitted energy has effects just as it would in Physics.  Service Energy has the ability to assist in Escape Velocity as well as increase Data Gravity, all depending on what the Service Energy is doing.
Service Energy shows motivations in Clouds for specific behaviors such as:

Why Salesforce acquired Heroku – (Heroku is indeed a Ruby PaaS, but it was beginning to bring in SERVICES from outside which increased its Service Energy)  Salesforce needs this in the Ecosystem, just like it needed to create Database.com to help increase it’s Data Mass and therefore it’s Data Gravity.

Why Amazon created SQS and SES (These are services that encourage additional consumption of Compute but more so amplifies the amount of data (Data Mass)

It should be noted in the picture above that the Data is made accessible through a service which is why it has Service Energy around it, which should be distinguished from Data Gravity. Remember, Service Energy does NOT attract, but can amplify.

Service Energy also can be used for Escape Velocity.  By properly architecting applications and even Service Oriented Platforms, the Data Mass can be spread across many providers (and even sources inside of those providers).  This provides looser coupling between the App and a specific Cloud, which gives more flexibility.  The trade-off is that this design is more prone to service interruptions, latency, and bandwidth constraints.

There is much more to be said about Service Energy in the future including exploring other effects it has with more IaaS centric solutions.

The Future of PaaS in the Enterprise – The Service Oriented Platform

26 Jan

Anyone who followed Cloud Computing last year watched several changes occur throughout the space.  These changes were happening in the view of what Public, Private, and Hybrid Clouds were defined as, the interest in IaaS solutions in the Enterprise and within Service Providers, and finally a renewed interest in the potential of PaaS.

Currently Public PaaS solutions are focused on core compute functionality and persistent services all of which are being backed by some mix of IaaS (with or without Virtualization, more with than without though).  Why are so many Public PaaS focused on their IaaS underpinnings?  Two reasons come to mind, IaaS is easier for customers and IT to understand and yet generic enough to have the broadest appeal.  This is important in the continuing evolution of the Cloud market as a whole, we need the widest adoption possible early on for any Cloud Platforms to take off.

Now, focusing in on the set of events around PaaS in the past year brings us to the rumors that surrounded EngineYard’s acquisition by VMware (which never happened and now we see that Amazon is working with them on a Ruby on Rails Elastic Beanstalk), Heroku was acquired by Salesforce.com, VMware announced the Open PaaS solution, and Microsoft will fight with anyone who calls Azure anything but a PaaS.  All of this Public facing PaaS news sounds great, but I’m sure you are thinking how does this translate to Enterprise?

I wondered this same thing and began to try to figure out just where it all leads.

What is the Future of Enterprise PaaS?

Public Cloud Services are always different from Private Cloud Services, many people think that Hybrid is something easy but miss the nuances involved with implementing Hybrid Clouds.  I’m not saying that achieving a Hybrid model is impossible, just that there are many hurdles and few have working solutions that seem to address most or all of them.

PaaS in an Enterprise will operate as a Service Oriented Platform.  That sounds like a silky smooth sentence doesn’t it?  But there is substance behind the statement.  Today the most advanced Public PaaS platforms are focusing on generic, on-demand, multi-tenant, infrastructure components, and other core capabilities.  What Enterprises will need for PaaS will be this plus many other services including specialized components such as vertical specific ERP and CRM solutions exposed as services, legacy solutions with service bridges, Big Data service connectors, and many more.  As these capabilities get built and each former “Silo” gets exposed as a service a Platform will emerge.

About the Service Oriented Platform:

Something to understand is that each business is different, it was formed differently and while it operates most likely in a similar fashion to other businesses in that market, it is still different.  This difference becomes even more pronounced when the needs are pushed to IT (Operations and Development).  This would be the equivalent to the Butterfly Effect in IT.

Why does the Butterfly Effect matter for an Enterprise Service Oriented Platform?

Because it means that each Enterprise Service Oriented Platform will be DIFFERENT than all others (maybe only marginally, but still different).  Each service exposed to the ESOP will be a new capability that Devs can leverage as they put together Apps on top of the Enterprise PaaS.

Something that may be important to realize is that IT Operations may view the solution as an ESOP while Devs may view it as an Enterprise PaaS.  I think both of these are actually correct and will talk about the same thing, it is just how it is being viewed and by who, but it is still the same thing.

Hybrid Clouds will be exposed as another service capability:

Hybrid Clouds will be Public Cloud services that are exposed either directly or indirectly to the ESOP.  The ESOP will have the control, authentication, metering, and likely the QoS.  The EPaaS will have the allowed/exposed services and resources from the Public Cloud.  This will be at a different level than simply pushing and pulling VMs, Virtual Hardisks, or Creating VPNs.

I’m interested in people’s thoughts and comments:

Comment on this Post or Follow Me on Twitter – @mccrory

Current PaaS Patterns – Types of PaaS

23 Jan

There are many definititions of PaaS that I have run across, the most succinct of which is “A Service where Code is uploaded and executed”.  While succinct, this leaves a lot of “wiggle room” for what PaaS really is.  The secret is PaaS isn’t one thing, it is a broad array of things that can be used and mixed together.  What model ore TYPE of PaaS determines what capabilities and limitations the platform will have.

The Type 1 PaaS – Upload Your Environment

Type 1 PaaS Examples

This style of PaaS is an option from several different providers including Amazon EC2 and Microsoft Azure with the VM Role.  By imaging and then uploading an environment packaged as a VM, you are allowed to run legacy systems in Cloud environments

The Type 2 PaaS – Upload Your Compiled Application

Type 2 PaaS Examples

This PaaS is where an environment is already provided and you are uploading and executing an Application that was written/is supported by that PaaS environment. This could be a preconfigured Amazon EC2 VM, a RackSpace Cloud VM, Microsoft Azure Role, or any of the other dozens of Cloud providers.

The Type 3 PaaS – Upload Your Packaged Application

Type 3 PaaS Examples

PaaS here is presented as a container that is more restricted than a traditional environment and is more stringent on code.  This could be a Java WAR file for example that leverages a container such as Apache Tomcat, Amazon’s Elastic Beanstalk is a good example of this.  The solution could also just be a custom JVM such as the one that Google App Engine uses (where your App is a JAR).  Why is this different than a Type 2 PaaS?  It is a container in an environment, not just an OS environment like Linux or Windows.

The Type 4 PaaS – Upload Your Code

Type 4 PaaS Examples

This type of PaaS allows source code to be uploaded where the compilation happens in the PaaS itself.  By accepting the code as the uploaded payload a greater level of insight as to what the resource requirements are of the code can be gotten, which offers more versatility from the platform.  An example would be VMware’s Open PaaS (which is in Alpha currently).  Open PaaS accepts many different code types, looks at what the requirements are and adjusts the environment based on what the needs of the code are.  Other examples include Heroku and Engine Yard, both do Ruby on Rails. When the Ruby on Rails code is uploaded for example, then a MySQL server instance is created to support the application amongst other things that happen.  Nearly everything that is needed is allocated automatically on demand.

The Type 5 PaaS – Upload App/Platform Specific Code

Type 5 PaaS Example

PaaS here would only allow specific code which is designed to work as logic or an extension of the Platform is allowed.  While this is a highly restrictive form of PaaS, it can also be powerful and is a natural move for a Software as a Service provider looking to allow cutsomization.  Salesforce.com is a great example with their App Logic using Apex Code.  Apex Code allows a level of customization and extension to the Salesforce solution using their own blended Java/C# like syntax.

The future of PaaS is in leveraging many of these models to best meet design decisions and customer needs.  The biggest question will be what happens in the future when Enterprises want to adopt and adapt PaaS in their Data Centers.  While the economies of scale will always be with Public Cloud PaaS providers, there are benefits to having PaaS implementations inside the Enterprise.

In my next post I will talk about where PaaS could go.

Hyper9 is acquired by SolarWinds

19 Jan

The company I founded a few years ago has been acquired by SolarWinds Inc.  I’m pleased with the outcome and proud of all of those involved in the hard work it has taken to get here.

Details can be found here

CLASH – CLoud Admin SHell

11 Jan

It has been several weeks since I have posted to this blog.  I would blame this on the holidays, but that would be inaccurate as it has been something far more insidious!

What is CLASH?
CLASH is a universal shell.  What is a universal shell?  First, by universal I mean that it is intended to run on all major desktop operating system platforms including:
Windows XP, Windows Vista, Windows 7

Mac OSX Leopard, Mac OSX Snow Leopard
Ubuntu Linux, and most other flavors of Linux
——————————–
Now the shell portion is a bit different.  Since this is a CLoud Admin SHell, Cloud is an important part of idea.  In this initial prototype I went through many experiments in learning the nuances of JRuby <follow on post link here>, but have been able to get a reasonable working version of VIJava (the interface I’m using to get JRuby to work with VMware vCenter/vSphere).

Great, so what can I do with this prototype?

-You can try it out on any of the platforms listed above!
-If you are on a Windows System, you can either edit the clash.bat file and put in your server’s IP or name along with a username and password to connect
-If you are on Mac or Linux, you can simply type ./clash –Server 127.0.0.1 –Username administrator –Password password to connect 

-The following are the working commands:
> Get-VM SomeVMName
Above gets the VM object and prints out the Guest Operating System type

> $result
This command prints the name of the VM object
> $result $
This displays the methods available to the VM object
> $result $.get
This shows only the methods with “get” in them
> $result $.set
This shows only the methods with “set” in them
> $result $.find something
This shows only them methods that contain “something” in them
> $result method
This will execute the method against the object (i.e. $result getName will display the name property of the VM object from Get-VM)
> disconnect
This will cleanly disconnect from the vCenter / vSphere server
> Start-VM SomeVMName
This command is flakey at the moment, this will be fixed when the next prototype is released in a few weeks
> Stop-VM SomeVMName
This is in the same state as Start-VM
> Get-VM SomeVMName > $result getName
This allows a limited form of piping in clash by using the > as an operator (you must have whitespace on both sides of the > symbol.

Where is this headed?
After many experiments, it will be broken out into a flexible system that allows many different options and cool capabilities against not only vCenter and vSphere, but most Cloud platforms as well.  Currently planned platforms include:
-Amazon EC2 and S3
-Rackspace
-(Looking for the next provider for this list)

Other interfaces to the shell (for both input and output) will include a Web interface, I’m looking for thoughts on other types of interfaces desired.

How will this work?
Below is my latest planned diagram for how I hope/think things should work:

Where can I get the Prototype?
You can get the code from GitHub here
You can download the entire package here

Installation Directions (AGAIN, this is a PROTOTYPE, it does NOT follow best practices)
1.) Make sure that you have Java 1.5 or Above Installed
Download Java from Here

2.) Install JRuby 1.5.6
Download JRuby from Here
3.) Follow the JRuby Setup Instructions Here
4.) Download the CLASH prototype/alpha-1 from GitHub (See Above Links)
Unzip/Tar it to c:\clash or /clash directory in ROOT
5.) Start clash by going to c:\clash\bin\ or /clash/bin
On Windows edit clash.bat to contain the correct IP Address, Username, and Password
then run clash.bat
On Mac and Linux type ./clash –Server 127.0.0.1 –Username administrator –Password password
Make sure to select the IP or Name of a valid vCenter / vSphere Server
6.) Play with clash
A Request:
Please supply feedback to me through comments to this post or communicate directly with me through Twitter – my handle is @mccrory
I’m looking for ideas/things that you would like to see clash do, better commands, capabilities, features, etc.

Cloud Escape Velocity – Switching Cloud Providers

18 Dec

The term Escape Velocity is the speed needed to “break free” from a gravitational field without further propulsion according to Wikipedia.org.  Data Gravity as explained in THIS previous post is what attracts and builds more Data, Applications, and Services on Clouds.  Data Gravity also is what creates a high level of Escape Velocity to move to another Cloud.

Some background on why this post is timely:

A few days ago Amazon announced a new AWS service for importing VMware disk images (VMDKs) into EC2.  VMware already offered a method for converting EC2 instances through their Converter tool into Workstation VMs and with a 2nd pass conversion into ESX VMs.  While all of this sounds wonderful and it does have value, it brings to light an entirely different issue.  Only Stateful / Fully encapsulated applications can be moved around in this way.

Examples of sources of Cloud Gravity (App, Service, and Data Gravity Combined) on your specific Application.

If someone selects a Cloud provider and writes an application leveraging anything more than a handful of VMs, Data Gravity will make it virtually impossible to move to a new/different Cloud provider.  Don’t believe it?

See the Diagrams Below:

Here is a diagram of an app that has a Low Escape Velocity because of Lower Cloud Gravity:

Cloud Escape Velocity with Low Gravity

Below is a diagram of an app that has a High Escape Velocity because of High Cloud Gravity:

Cloud Escape Velocity with High Gravity

Some potential dependencies include:

Database with a specific API

Web Worker which serves as a web interface and uses internal Authentication (Your user logins are here!)

Application code that uses the Database and Web Workers specific APIs and/or depends on Low Latency and High Throughput access to them.

Here are a few additional things to think about:

– The longer (more time) an Application stays in a specific Cloud the more difficult it is to move.  Why?  Data Gravity increases due to more Mass (data being stored).  Imagine accumulating 100’s of GBs of Data, how easy will it be to shuffle/transfer that much data around?

– The more provider APIs and Services that you depend on the harder it is to move.  Why?  Because there are only two paths that can be taken in a move.  The first is to find another provider that has the exact same set of APIs and Services (this will limit your choices).  The second is to change or rewrite your application to take advantage of the new Cloud provider’s APIs and/or Services.

– Different providers have different charges for the consumption of the same resources.  Your current provider gives free usage of queues for applications. The provider you are looking to go to charges after the first X number of messages on the queue.  Now what do you do?  You will either pay more when you move, rewrite your application to fit the new provider’s model, or pick another provider that has free queue usage.

– Different QoS guarantees from Cloud provider to Cloud provider.  Some Cloud providers offer SLAs with reimbursements for outages, others only offer best effort.  Some providers offer tiered Services, others only offer a single tier.  What happens if you want to move and you can’t get the minimum level of QoS that you need?

This is NOT an attempt to dissuade anyone from using Public Clouds (they are incredibly valuable and powerful), but I would like more people to go in eyes wide open.

Microsoft Azure Cloud – Top 20 Lessons Learned about MSFT’s PaaS

13 Dec

Two weeks ago, Rob Hirschfeld (@Zehicle) and I (@McCrory) had the benefit of intensive Azure training at Microsoft HQ to support Dell’s Azure Stamp.

We’ve assembled a top 20 list of things to know about programming for Azure (and really any PaaS leaning cloud):

  1. If you want performance, optimize to reduce fees. Azure (and any cloud) is architected to penalize you if you use their resources poorly. The challenge is to fix this before your boss get the tab for your unenlightened design decisions.
  2. Coding .NET on Azure easy, architecting for Azure requires learning. Clouds put things in different places than you are used to and the rules are different. Expect a learning curve.
  3. Partitioning = parallelism. Learn to love partitions in all their forms, because your app will be throttled if you throw everything into a single partition! On the upside, each partition operates in parallel and even better, they usually don’t cost extra (SQL is the exception).
  4. Roles are flexible. You can run web servers (Apache, etc) on a worker and worker tasks on a web role. This is a good way to save some change since you pay per role instance. It’s counter to separation of concerns, but financially you should also combine workers into a single role where possible.
  5. Understand walking deployments. You can (and should) have simultaneous versions of the code operating against the same data so that you can roll upgrades (ala Timothy Fitz/Eric Ries) to reduce risk and without reducing performance. You should expect your data schema to simultaneously span mutiple code versions.
  6. Learn about Update Domains (UDs). Deployment domains allow rolling upgrades and changes to Applications and Services. They are part of how you partition your overall application. If you’re planning a VIP swap deployment, then you won’t care.
  7. Each role = ONE external IP. You can have many VMs backing each role and Azure will load balance between them so you can scale out each role. Think of each role as a clonable entity: there will be at least 1 and more can be added if you want to scale.
  8. Understand between VIP and DIP. VIPs stand for Virtual IPs and are external, public, and metered. DIPs are internal, private, and load balanced. Azure provides an API to discover your DIPs – do not assume you know them because they are DYNAMIC IPs. Azure won’t let you see other DIPs inside the system.
  9. Azure has rich diagnostics, but beware. Azure leverages the existing diagnostics built into their system, but has to get the data off box since instances are volitile. This means that problems can be hard to isolate while excessive logging can impact performance and generate fees. Microsoft lets you target individual systems for elevated levels. You can also Terminal Server to a VM for troubleshooting (with caution).
  10. The new Azure admin console rocks. Take your pick between Silverlight or MMC Snap-in.
  11. Everything goes into Azure Storage. Learn to love it. Queues -> storage. Tables -> storage. Blobs -> storage. Logging -> storage. Code Repo -> storage. vDisk -> storage. SQL -> SQL (they march to their own drummer).
  12. Queues are essential, but tricky. Learn the meaning of idempotent because using queues requires you to handle failures and timeouts. The scary part is that it will work nicely until you exceed some limits and then you’ll experience cascading failure. Whee! Oh yea, and queues require polling (which stinks as a notification model).
  13. SQL Azure is just mostly like MS SQL. Microsoft did a smart thing in keeping Cloud SQL so it was highly compatible with Local SQL. The biggest note is that limited in size of partition. If you embrace the size limits you will get better performance. So stop pushing BLOBs into databases and start sharding.
  14. Duplicating data in tables will improve performance. This has to do with how partitions and keys operate but is an interesting architecture for NoSQL – stage data for use. Don’t be afraid to stage the same data in multiple ways. It may be faster/cheaper to write data twice if it becomes easier to find when you search it 1000s of times.
  15. Table data can be “warmed up.” Storage has logic that makes frequently accessed items faster (sort of like a cache ;). If you can anticipate load spikes then you should warm the data just before the spike.
  16. Storage billing is both amount and transactions. You can get burned on a small, but busy set of data. Note: you will pay even if you 404 a request.
  17. Azure has a CDN. Leveraging Microsoft’s Content Delivery Network (CDN) will improve performance for your users with small, low latency, high request items. You need to change your URLs for those assets. Best practice is to use some versioning in the URI so that you can force changes. Remember, CDN is SLOWER for the first hit when the data is not in cache so avoid CDN for low volume assets!
  18. Provisioning time is not instant. Azure needs anywhere from 1-3 minutes to spin a new instance of a role. Build this lag into your architecture and dynamic scale plans. New databases and partitions are fast.
  19. The VM Role is maintained by YOU. Using the VM role is a handy shortcut, but has a long list of gotcha’s. Some of note: 1) the VM can be “reset” to the last VM image state that you uploaded, 2) you are responsble for VM OS upgrades and patches, 3) VMs must be clonable because they will operate in parallel.
  20. Azure supports more than .NET. You can setup anything in a worker (and now VM) role, but there are nuances to doing this effectively. You really need to understand how Azure works and had better be ready to crack open Visual Studio for some things even if you’re writing in Java.

We hope this list helps you navigate Azure deployments. No matter what cloud you use, understanding Azure’s architecture will help you write better cloud scale applications.

We’d love to hear your suggestions and recommendations!

Mirrored on both blogs: Dave McCrory’s Blog & Rob Hirschfeld’s Blog