I was just watching a discussion on DevOps, Automation and Continuous integration and heard the following,
"Chef is a tool for doing infrastructure automation - config management, application deployment - all of that stuff" (Adam Jacob - CPO, Opscode)
Two things that I would like discuss regarding that quote.
What is Infrastructure?
In my current role at Cisco - we have been discussing to great length platform - and what that platform actually is.
Have a look at the following diagram.
Where does the platform fit? What would you call the infrastructure? What is platform?
If you are a typical virtualization guy you most probably would focus on the bottom part of the diagram. You would say that is the basis of any infrastructure - without the compute, storage, network and perhaps some of other parts (hypervisor or OS could actually float up or down between the two halves) - but without those things - you cannot build anything on top.
If you were to ask a typical developer - then they would say it is all in the top half - because without having the java framework, the application foundations - then the end product (what you are selling to the customer) would not work, you cannot develop applications unless you have the infrastructure underneath.
It all depends on your perspective.
At the moment - the top half of the diagram - developers are making great use of abstraction of the underlying layer. They go to AWS, Openstack, VMware and access an API.
Developers do not care about the underlying layer - they will place an call to an API to provision a VM - the whole underlying framework is abstracted.
That is why there is such massive use of Cloud for this kind of work. For a developer - just give them a VM and plop it down somewhere - what they really need is an IP and network connectivity to do their work.
But for the IT guys they are very worried about providing everything and piecing it al together to bring up that API and expose to the end user. That is not so simple. Automating the deployment of any of the squares above is not a simple task.
SDDC and SDN are great buzzwords that are trying to define those things today.
Which brings me to the second topic.
Is DevOps the answer to everything?
Again - this will depend on your perspective.
From a developer's eyes - hell yes! I can deploy a full product as code - multiple times a day, it is reproducible, repeatable and just exactly right up my street. I can make an operational change - role it out to hundreds of instances, and if I really find that I messed things up - then role back that change with a small change of the code.
In principle I agree, except for one thing. Tools like Puppet or Chef can do this with what I would define as new generation technologies, NoSQL databases, lightweight web applications, messaging frameworks. This is not valid for the legacy - deeply-embedded enterprise applications, take MSSQL and Oracle for example.
I do not know of a easy to implement solution that will perform a database schema change and easily roll that back with a quick change of a line of code, it is much more complicated than that. I do not say it is not possible - it is - it just takes a lot more planning and thinking. But then again - how many of you are actually using Oracle or MSSQL in the cloud? Not many I think.
Over to the IT guy…
Is DevOps the holy grail? Not by a long shot. Today there is very limited options available to deploy the bottom half of the stack. There are some modules today that can build out an Openstack deployment. Razor provides some of the functionality to deploy a vSphere infrastructure - but again it is not a polished solution and still has a lot of place for improvement.
Do you know of a puppet module that will deploy a UCS/HP chassis? Is there a Chef recipe that can provision a NetApp/EMC storage array? No there is not - at least not today.
So if you were to ask me - DevOps is definitely not the answer to everything - at least not until it can handle the whole stack from top to to bottom
As Robbie Minshall said on the same discussion (39:00),
"What we are trying to do is tie the phases together… You cannot have DevOps in one space and then have it hit an organizational barrier in another - where they do it completely differently or not all"
For me today this is not a theological problem. It is a technological one. There are very few (if any) tools today that can properly automate a full stack that span both halves of the diagram above.
The vendors are moving into that direction - but are not quite there - yet.
(The original discussion is embedded below)Does DevOps deliver the ultimate converged infrastructure? Discuss.
— Ed Grigson (@egrigson) July 8, 2013
Please feel free to add your thoughts or comments below.