March 24, 2014
It seems like Google lets out something out of the bag once in a while.. take Google Omega..
and their recent announcement about their use of linux containers –
To me, this sounds like a developer / app deployer being able to specify the characteristics of the workload when they deploy it (represented by SLAs – priority, latency expectation etc..) and the management platform using metadata about resource pools, their available capacities to fulfill the SLAs , then choosing the right pools and then deploying them there..
So, in effect, it’s not just their workload scheduler, they require the right metadata to be populated along with their workloads..
It just so happens that the unit of deployment they may be using is containers using cgroups and kernel namespaces, and they add additional metadata to the definition of the containers that users can manipulate
one can start doing this with docker today, with custom metadata.. the harder part is the scheduler, which would have to be something custom (maybe piggy backing on openstack work around nova scheduler, neutron etc .. or an existing PaaS ecosystem like openshift)
This is probably a truer version of workload management moving towards the idea of autonomic computing, than just moving VMs around.. Granted you could do the same with VMs, add metadata, but you’d also have to deal with resource management at two levels – at the hypervisor and at the vm level — which is usually not a good idea.
May 20, 2013
If you have been following the cloud trend, with virtualization, programmable stacks, sdn, message based orchestration etc.., this bit of news http://www.lightreading.com/software-defined-networking/rumor-google-to-add-sdn-smarts-to-android/240155256 may not seem like anything new, just another trend.
However, if you dig deeper into this, you’ll notice that the result of adding networking / sdn smarts to android actually has much deeper connotations. This first paves the way for running android in the datacenter servers. With SDN and orchestrated spin-up, spin-down of android vms in the datacenter, you could run in split seconds or minutes thousands of these in the datacenters. And if you’re an android phone/tablet user, you will know that this operating system is quite capable of running any kind of application.
One minute detail that may be easily overlooked is the fact that the entire android operating system comprises of most of the code run in the Dalvik virtual machine, with few bits and pieces running on a custom linux kernel.Now, if most of the SDN pieces being talked about in the article is actually added to the VM portion of android, then what you end up with is a fully programmable container for code and data. That container could be serialized and shipped via network to any platform that can run the dalvik vm and run again…
This brings up a whole new connotation to the “cloud” paradigm. It’s a cloud that’s going to be raining runnable bits of code and data everywhere. The possibilities, if this is where it’s heading, is actually endless..
Comments welcome as always.
There’s a lot of buzz lately in the industry around cloud stacks and how to build and manage them. Openstack, cloudstack, tosca, EC2, google compute, openshift, cloudfoundry, heroku, cloudbees etc..
Notice I clubbed IaaS and PaaS stacks together.
To me, what stands out from the rest is openstack.
Openstack is now proving to be a workable and replicable solution for standing up a managed IaaS cloud stack in real world situations. You could argue that cloudstack is the same way and amazon, GC have already proven it.
The reason openstack stands out is because it reminds me of the linux phenomenon 20+ years ago. The community believes in it. And the community is willing to put forth blood and toil to expand the reach of openstack.
As a result, openstack today, is not just an IaaS management framework anymore. It’s an ecosystem of “service” enablers all tied by a thread of common interest – commoditizing information systems – via common apis, common component architecture model, opensource roots, modularity etc.
What comes out of that is an ecosystem of pluggable components bound by interfaces and a scaleable architectural principle for the components.
That’s a breeding ground for explosive growth and exponential uptake of any technology.
And just because it’s opensource does not mean there’s no money to be made. Examples abound. VCs salivate!
It’s the ecosystem that openstack enables. You can’t say that for cloudstack, or google compute. You could argue about EC2.. but that’s just because they were first on the ground and cheap (not sure for how long)
And the ecosystem will start to go up the stack, you’re already seeing ties to cloudfoundry and openshift. Heroku probably has to watch out.
It’s easy to counter a company or a group of people. It is very hard to counter a movement .. and that’s what openstack is turning out to be.
I know this is a loaded post, and mostly opinions.. I’ll take the flak and take comments.
November 13, 2012
It seems there is a lot of confusion and debate around DevOps and XaaS, specifically the PaaS portion of XaaS.
The below is an attempt to shed light on some of the definitions and thinking around that.
XaaS (DC as a service, Infrastructure as a Service, Platform as a Service and Software as a Service) is all about delivering services to consumers (subscribers of a service). There are notions of expectations from a subscriber (requirements) and notions of guarantees that a service provider can provide, which are bound together by a contract between the subscriber and the provider using Service Level Agreements.
It helps to think of XaaS as layers that build upon an underlying layer and providing capabilities. As such, IaaS builds upon capabilities provided by DCaaS services and provides it’s capabilities that are services that can be bound in SLAs. Similarly PaaS builds upon those IaaS services and provides platform capabilities as services that themselves can be wrapped in SLAs. SaaS then builds upon PaaS services and provides applications and other higher-level capabilities as services. This layering provides a facility to bound the capabilities into like umbrellas that can be delivered/changed independently of each other. It’s sort of like the OSI model in a certain sense.
All this, keeping in mind that SaaS capabilities do not always have to deal with the PaaS layer, they can directly consume services from the IaaS layer. If there are more cases of this happening then it may help to think of it as a case of the PaaS layer not being able to fulfill all of the SaaS requirements. The PaaS layer may need to accommodate those requirements in future versions of it’s services.
DevOps is an evolving model that attempts to ease some of the hardships around delivering and managing these services. It comes from the disciplines of development (as in software development) and operations (infrastructure and platform operations). As such, the goal of DevOps is to minimize the hurdles that a developer (builder of application services) faces while still maintaining typical operational goals like uptime, availability, resiliency, change tracking etc.
DevOps stresses things like provisioning automation, build automation, test automation, repeatability, scriptability, version tracking, near-instantaneous instantiation etc to enable the development folks to work closely with the operations teams. In fact, the idea is to meld the development aspects and the operations aspects into one continuous and cohesive set of processes and teams.
As such, besides the processes and actions that are recommended by DevOps, there are foundational components that are also recommended by DevOps, such as host configuration management systems, centralized version control systems, distributed version control systems, continuous build systems, debugging hooks, image build systems etc. In fact I would go so far as to say that DevOps takes the typical components in an application Lifecycle Managment (ALM) set of systems and merges Operations principles with it.
All of these components can also be one of the XaaS offerings themselves with their own guarantees and SLA bindings.
One could go so far as to say that DevOps principles and services could be used to itself build not just SaaS services (applications), but also PaaS services and even IaaS services. On the flip side, one could say that the XaaS service offering themselves can and should provide hooks and apis that enable integration with other services to holistically provide the developer and operator conveniences and control that DevOps advocates.
As one can see, DevOps and XaaS do not conflict with each other. In fact I would argue that they are complementary viewpoints to the same set of issues. The key to seeing the synergy between them is to see offerings of capabilities from a Service management point of view, even DevOps oriented offerings.
This will be crucial to enterprises trying to tackle PaaS/SaaS/Cloud technologies and DevOps paradigms together.
As always thoughts and comments are welcome.