Re: Myopic View of DevOps Misses the Mark

28 views
Skip to first unread message

Jon Wood

unread,
Jun 26, 2011, 5:27:44 AM6/26/11
to dev...@googlegroups.com, agile-system-...@googlegroups.com

On Sunday, 26 June 2011 at 10:21, Guillaume FORTAINE wrote:

Hello,

I would greatly appreciate to have the point of view of the DevOps
community about these various questions, if
possible, please :
The answer to all those questions is the same - your sysadmin team. "Devops" is almost by definition not a team in itself, but greater collaboration between teams. Just because your developers and sysadmins have decided to work closer together doesn't mean that everyone stops specialising, and the ops team suddenly doesn't have any time to maintain your infrastructure because they're too busy building autocompletion into your software.

These considerations don't stop being made, but with teams that are working closely they can be made with a better insight into everybody's requirements, rather then the ops team passing down decrees from on high.

Jon
http://pleasediscuss.com/andimann/20100326/myopic-devops-misses-the-mark/

a) Who handles ongoing support, especially software update for the
unrestrained sprawl of non-standard systems and components.

b) Who ensures each new application doesn’t interfere with existing
and especially legacy systems (and networks, storage, etc.)?

c) Who handles integration with common production systems that cannot
be encapsulated in a VM, like storage arrays (NAS, SAN), networking
fabrics, facilities, etc.

d) Who handles impact analysis, change control and rollback planning
to ensure deployment risk is understood and mitigated?

e) Who is responsible for cost containment and asset rationalization,
when devops keeps rolling out new systems and applications?

f) Who ensures reporting, compliance, data updates, log maintenance,
Db administration, etc. are built into the applications, and
integrated with standard management tools?

g) Who will assure functional isolation, role-based access controls,
change auditing, event management, and configuration control to secure
applications, data, and compliance?

I look forward to your answer,

Best Regards,

Guillaume FORTAINE
gfor...@gfortaine.biz
+33(0)631.092.519

Matthew Macdonald-Wallace

unread,
Jun 27, 2011, 2:16:01 AM6/27/11
to agile-system-...@googlegroups.com
Hi,

I agree that the vast majority of data that I can find out there on
DevOps/CI/CD is developer orientated, however one of the reasons I
started my blog (shameless plug I know, but hey! :P ) was to try and
even that balance out a bit.

We've "stolen" a lot of ways of doing things from our developers where
I work meaning we now use Jenkins to automatically provision virtual
machines and deploy our puppet manifests to them so we can automate
the testing.

The final goal is to reach a point where if all the tests pass in
Jenkins, the puppet manifests are deployed to "live" without human
intervention and actioned with an MCollective-powered Puppet run,
although we're still probably about 3 months away from that.

What we've already found (and we've only been using this properly for
about two months) is that by automating the testing of the puppet
manifests and system builds we are freeing up our time to apply system
updates and look at ways to improve the various platforms - "DevOps"
***saves you time*** in our experience.

I've popped a few replies to some of the original questions in line
below, hope that's of some help.

Matt.

On 26 June 2011 10:27, Jon Wood <j...@blankpad.net> wrote:
> On Sunday, 26 June 2011 at 10:21, Guillaume FORTAINE wrote:
> a) Who handles ongoing support, especially software update for the
> unrestrained sprawl of non-standard systems and components.

You should be working towards "back-porting" these systems into
puppet. If you don't have a clue what's out there on your network,
run some form of auditing tool and get a good idea, then write the
puppet manifests to bring these systems into a standardised pattern.

> b) Who ensures each new application doesn’t interfere with existing
> and especially legacy systems (and networks, storage, etc.)?

This is the job of developers in my view, however as a SysAdmin, you
need to work very, very closely with them to ensure that they make
educated decisions about how to deploy and interact with older
systems.

> d) Who handles impact analysis, change control and rollback planning
> to ensure deployment risk is understood and mitigated?
>
> e) Who is responsible for cost containment and asset rationalization,
> when devops keeps rolling out new systems and applications?
>
> f) Who ensures reporting, compliance, data updates, log maintenance,
> Db administration, etc. are built into the applications, and
> integrated with standard management tools?
>
> g) Who will assure functional isolation, role-based access controls,
> change auditing, event management, and configuration control to secure
> applications, data, and compliance?


The answer to all of the above is "Who does this role currently in my
organisation?".

As Jon said, moving to DevOps doesn't mean that sysads stop being
sysads and become developers, it means that we can all share the tools
that we use to improve systems delivery.

M.

Reply all
Reply to author
Forward
0 new messages