DevOps tooling : Proprietary or open source ?
20 views
Skip to first unread message
Naveen Joshi
Feb 16, 2015, 5:42:41 AM2/16/15
to london...@googlegroups.com
We are looking at transforming the IT delivery at organisation level DevOps way. On tooling part of this transformation we are still contemplating at building our own continous delivery pipeline using open source or going with IBM, Ca etc. to get this done. Your experience with any of these approaches will be very help full; both pros and cons.
Matt Saunders
Feb 17, 2015, 3:56:48 AM2/17/15
to london...@googlegroups.com
Hi Naveen,
Disclaimer: I'm an open-source advocate who works with a consultancy
(Contino) who sometimes partner with CA for DevOps projects.
I'd suggest that the choice of strategy is largely dictated by a
balance between the organisational structure you're working within,
and the extent of the organisation's desire to transform (see Conway's
law). If you have open-source advocates in the organisation then you
should by all means use them, and it's vital to give them the space to
experiment with the open-source tooling available. They will need
help at an organisational level though - since it can be a tough sell
in areas such as change-control and operational responsibility.
Vendor solutions will help you with the advocacy and high-level
buy-in, but they are of course financially motivated. Using a vendor
solution may lock you into their way of thinking and their software
stack. But some of them are starting to understand that just selling
some software and running away with the licence fees doesn't work any
more, and hence are looking to build a deeper relationship at an
organisational level, and this can be very useful to kick-start a real
transformation in a larger organisation. Whether you see this as a
good or a bad thing is debatable!
Hope this helps - I have discussions like this most days so happy to
talk further. ;-)
Matt.
--
Matt Saunders
07506 857125
http://www.yoyo.org/matts/contacts/
(Contino) who sometimes partner with CA for DevOps projects.
I'd suggest that the choice of strategy is largely dictated by a
balance between the organisational structure you're working within,
and the extent of the organisation's desire to transform (see Conway's
law). If you have open-source advocates in the organisation then you
should by all means use them, and it's vital to give them the space to
experiment with the open-source tooling available. They will need
help at an organisational level though - since it can be a tough sell
in areas such as change-control and operational responsibility.
Vendor solutions will help you with the advocacy and high-level
buy-in, but they are of course financially motivated. Using a vendor
solution may lock you into their way of thinking and their software
stack. But some of them are starting to understand that just selling
some software and running away with the licence fees doesn't work any
more, and hence are looking to build a deeper relationship at an
organisational level, and this can be very useful to kick-start a real
transformation in a larger organisation. Whether you see this as a
good or a bad thing is debatable!
Hope this helps - I have discussions like this most days so happy to
talk further. ;-)
Matt.
--
Matt Saunders
07506 857125
http://www.yoyo.org/matts/contacts/
Kief Morris
Feb 18, 2015, 2:55:03 AM2/18/15
to london...@googlegroups.com
Naveen,
It's important to choose tools that are flexible, customizable, and that you will be comfortable throwing away as you learn more about what suits your needs. At the start of a project to change the way you work, you need to choose tools in order to help you learn how to work.
Avoid choosing a tool that promises to meet every requirement and need, because a) you don't know exactly what your requirements and needs are, even though you have ideas, and b) no tool is going to meet every requirement and need.
I'm a big fan of infrastructure as code, so I want tools whose configuration is managed in files external to the tool (e.g. puppet manifests, chef cookbooks, etc.) so I can put them into version control, use them to trigger CI to test infrastructure changes, and promote them through environments. Tools which store configuration in an internal format don't work well with this model.
Beware of thinking that spending money on a vendor's tool will mean you won't have to do much work to get it configured and working as using open source tools. Inevitably, the tool doesn't do exactly what you need out of the box, but needs configuration, often from expensive consultants. This becomes another constraint to continuously learning and improving how you work, because it can be expensive to keep bringing consultants back, and not easy to find and/or build in-house expertise with a proprietary product.
Good luck,
Kief
On Mon, Feb 16, 2015 at 11:42 AM, Naveen Joshi <navj...@gmail.com> wrote:
We are looking at transforming the IT delivery at organisation level DevOps way. On tooling part of this transformation we are still contemplating at building our own continous delivery pipeline using open source or going with IBM, Ca etc. to get this done. Your experience with any of these approaches will be very help full; both pros and cons.
--
You received this message because you are subscribed to the Google Groups "London DevOps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to london-devop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
gareth rushgrove
Feb 18, 2015, 7:58:13 AM2/18/15
to london...@googlegroups.com
On 18 February 2015 at 07:55, Kief Morris <kiefm...@kief.com> wrote:
> Naveen,
>
> It's important to choose tools that are flexible, customizable, and that you
> will be comfortable throwing away as you learn more about what suits your
> needs. At the start of a project to change the way you work, you need to
> choose tools in order to help you learn how to work.
>
> Avoid choosing a tool that promises to meet every requirement and need,
> because a) you don't know exactly what your requirements and needs are, even
> though you have ideas, and b) no tool is going to meet every requirement and
> need.
>
> I'm a big fan of infrastructure as code, so I want tools whose configuration
> is managed in files external to the tool (e.g. puppet manifests, chef
> cookbooks, etc.) so I can put them into version control, use them to trigger
> CI to test infrastructure changes, and promote them through environments.
> Tools which store configuration in an internal format don't work well with
> this model.
>
Building on this, favour tools that provide APIs. As mentioned by Kief
> Naveen,
>
> It's important to choose tools that are flexible, customizable, and that you
> will be comfortable throwing away as you learn more about what suits your
> needs. At the start of a project to change the way you work, you need to
> choose tools in order to help you learn how to work.
>
> Avoid choosing a tool that promises to meet every requirement and need,
> because a) you don't know exactly what your requirements and needs are, even
> though you have ideas, and b) no tool is going to meet every requirement and
> need.
>
> I'm a big fan of infrastructure as code, so I want tools whose configuration
> is managed in files external to the tool (e.g. puppet manifests, chef
> cookbooks, etc.) so I can put them into version control, use them to trigger
> CI to test infrastructure changes, and promote them through environments.
> Tools which store configuration in an internal format don't work well with
> this model.
>
one tool won't solve all your problems so you'll see some integration
effort, however integrated a vendor tool set is. If that means working
with well defined and stable APIs that's relatively straightforward.
If that means screen scraping or hacking on a COM interface or reverse
engineering wire protocols (I've done all of those alas) it's time
consuming and fragile.
> Beware of thinking that spending money on a vendor's tool will mean you
> won't have to do much work to get it configured and working as using open
> source tools. Inevitably, the tool doesn't do exactly what you need out of
> the box, but needs configuration, often from expensive consultants.
important thing here is to look at market capacity. If a tool is
uncommon and the only option for consultancy is the vendor then prices
tend to be higher, if an ecosystem exists around a tool you can look
at the market for both independent consultants and companies that
offer support, training and consultancy. I think a lot of this depends
on your current suppliers and your organisations willingness to expand
that too.
> This becomes another constraint to continuously learning and improving how you
> work, because it can be expensive to keep bringing consultants back, and not
> easy to find and/or build in-house expertise with a proprietary product.
>
proprietary/open conundrum. The number of Mesos consultants is tiny,
the number of people with SAS or Websphere skills is huge. The
important part I think is whether a local market exists for the skills
you're looking for, whether good people want to learn those skills
(hands up who wants to learn more about Websphere?) and what training
options exist to help existing staff.
Their are a few more ramblings from me and previous colleagues on
https://www.gov.uk/service-manual/making-software/choosing-technology.html
from when I worked for the Government. I now work for a software
vendor so take the above with a pinch of salt.
Also, we should have more discussions on here :)
Gareth
> Good luck,
> Kief
>
>
>
>
> On Mon, Feb 16, 2015 at 11:42 AM, Naveen Joshi <navj...@gmail.com> wrote:
>>
>>
>> We are looking at transforming the IT delivery at organisation level
>> DevOps way. On tooling part of this transformation we are still
>> contemplating at building our own continous delivery pipeline using open
>> source or going with IBM, Ca etc. to get this done. Your experience with any
>> of these approaches will be very help full; both pros and cons.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "London DevOps" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to london-devop...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "London DevOps" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to london-devop...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Gareth Rushgrove
Web Geek
morethanseven.net
garethrushgrove.com
Reply all
Reply to author
Forward
0 new messages