March 28, 2017 at 9:13 pm
Comments posted to this topic are about the item Big Companies are Improving with DevOps
March 29, 2017 at 2:44 am
I think that there is HUGE misunderstanding regarding what DevOps is and how to implement it. For a start those who "get it" are probably already arguing with my using the term implement as how can you implement a culture?
Moving towards what some people call DevOps is DevOps.
Start small and change incrementally. The benefits will be small but stack up. Also people will see a return on their (often begrudging) investment quickly and therefore may be prepared to invest a little more.
Also, no it is not faster. This is a terrible misconception (sorry Steve but I believe that this is a myth that is being perpetuated here - managers see faster as developers can do twice as much and this is not what is happening as it is the automation of the manual release process that reduces overhead over time for testing and release, not necessarily for design and development). Some work isn't done faster at all. It is just delivered quicker as it is unhindered by other features and a time consuming release process. Faster? No. Earlier? Yes.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 29, 2017 at 2:45 am
'A small investment' - well, without any monetary benefit coming out of that 'let's try this' project, that's a no-go.
Furthermore, I don't like the way DevOps builds tiny pieces you need to deploy every other day (I *hate* the way my smartphone apps seem to need an update every other day!), and with different teams building different things, without properly managed supervision everyone starts to re-invent the wheel - multiple times.
I probably don't get it, maybe I'm too old school, but I still do not see how DevOps will work long term.
March 29, 2017 at 5:48 am
rharderwijk - Wednesday, March 29, 2017 2:45 AM'A small investment' - well, without any monetary benefit coming out of that 'let's try this' project, that's a no-go.Furthermore, I don't like the way DevOps builds tiny pieces you need to deploy every other day (I *hate* the way my smartphone apps seem to need an update every other day!), and with different teams building different things, without properly managed supervision everyone starts to re-invent the wheel - multiple times.
I probably don't get it, maybe I'm too old school, but I still do not see how DevOps will work long term.
I am not saying that there isn't a measurable ROI but I am saying that for individuals they will be more willing if they see their personal benefits after only a little bit of effort from themselves.
DevOps does not prescribe the frequency of releases at all. This is another misconception. It enables repeatable releases which can be used for frequent releases. Currently I am working in an environment with a DevOps culture that has quarterly releases. Admittedly we have more regular releases to testing teams but only four releases to production (at most) per year.
DevOps is as much about repeatability as anything else. The other two aspects I feel is shared responsibility and automation of repeatable tasks.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 29, 2017 at 6:15 am
rharderwijk - Wednesday, March 29, 2017 2:45 AM'A small investment' - well, without any monetary benefit coming out of that 'let's try this' project, that's a no-go.Furthermore, I don't like the way DevOps builds tiny pieces you need to deploy every other day (I *hate* the way my smartphone apps seem to need an update every other day!), and with different teams building different things, without properly managed supervision everyone starts to re-invent the wheel - multiple times.
I probably don't get it, maybe I'm too old school, but I still do not see how DevOps will work long term.
The SmartPhone updates really get up my nose as often they do not seem either thought through or thoroughly tested! The Phone app changed so that to answer a call you had to swipe the touch screen at 90 degrees to previously - why? - resulting in a few lost calls as I did not have my reading glasses on. Currently I have issues with both the Camera and TripAdvisor!
DevOps may be something for the future here but currently there are only two of us doing development and support with me doing all the SQL work and acting as DBA. NoSQL is also being fed into the equation despite me feeling it is not appropriate for us (I have 30 years SQL experience)!
March 29, 2017 at 7:50 am
mjh 45389 - Wednesday, March 29, 2017 6:15 AMrharderwijk - Wednesday, March 29, 2017 2:45 AM'A small investment' - well, without any monetary benefit coming out of that 'let's try this' project, that's a no-go.Furthermore, I don't like the way DevOps builds tiny pieces you need to deploy every other day (I *hate* the way my smartphone apps seem to need an update every other day!), and with different teams building different things, without properly managed supervision everyone starts to re-invent the wheel - multiple times.
I probably don't get it, maybe I'm too old school, but I still do not see how DevOps will work long term.
The SmartPhone updates really get up my nose as often they do not seem either thought through or thoroughly tested! The Phone app changed so that to answer a call you had to swipe the touch screen at 90 degrees to previously - why? - resulting in a few lost calls as I did not have my reading glasses on. Currently I have issues with both the Camera and TripAdvisor!
DevOps may be something for the future here but currently there are only two of us doing development and support with me doing all the SQL work and acting as DBA. NoSQL is also being fed into the equation despite me feeling it is not appropriate for us (I have 30 years SQL experience)!
I think smartphone updates are a bad example to use in this case, in total. The reason being, with the exception of the OS required apps, each individual app is created by a different company. So you have a situation where App A releases an update that has a bad interaction with App ZZZZZZZZZZZ, but you can't blame the problem on "the smartphone." You also can't expect the app developers to test every aspect of their app against every possible combination of installed app, so such situations *will* happen.
Now, from the POV of a single app, a DevOps culture can be (and likely in many cases is) a very big benefit. Regardless of how frequent they push updates, they've got an automated process in place so that when the tech security sites start screaming about "App A has *MASSIVE* security hole reports security researcher," they can get the fix for the hole out quickly with a reasonable assumption that it's not going to completely break the app.
Or it means an app developer can fill feature requests from end-users in a relatively shorter amount of time, or cope with changes to the OS (which they have no control or say in,) so that their interface remains consistent with the expected OS interface.
I even think where I work could benefit from moving to a more DevOps type culture, but considering how much effort it can take to get the most basic tools installed, it'll probably be well after I've left (and some new culture of development / deployment is on the rise) before it gains a foothold...
March 29, 2017 at 8:29 am
Your article is timely. Just this morning I received an email from our CIO discussing some possible, detrimental actions in the future for us. I can't share what at this time, just say that it would have consequences.
Anyway, my point is this, if DevOps really does save money, then that would be very good for us. Things I hear about quicker to market is all well and good, but in a way irrelevant to where I work. In order to help in our current situation we need to reduce cost. Does DevOps do that? Is there documented studies showing it does?
Kindest Regards, Rod Connect with me on LinkedIn.
March 29, 2017 at 9:31 am
NoSQL, DevOps, "The Cloud", "Internet of Things"...
With all the "hype", I'm sure there's tidbits of goodness in all of these things, but there's also issues to be considered. I know organizations with resources that can do "DevOps" very well, but some of us have neither the "Devs" or the "Ops"...
March 29, 2017 at 10:30 am
The separation between development and operations was unintended, no-one planned it and in retrospect it looks like being a bit IT mistake. It is obvious why it happened.
Specialisms grew and aggregated up into departments dedicated to their function.
For me DevOps is the collaboration throughout the process and the realisation that processes have huge scope for improvement. For this reason proceeding in small increments makes sense.
Collaboration implies that no-one gets a turd lobbed over their wall. The aim is to be transparent with risks and deal with those risks well ahead of time before they become issues.
March 30, 2017 at 6:07 am
chrisn-585491 - Wednesday, March 29, 2017 9:31 AMNoSQL, DevOps, "The Cloud", "Internet of Things"...With all the "hype", I'm sure there's tidbits of goodness in all of these things, but there's also issues to be considered. I know organizations with resources that can do "DevOps" very well, but some of us have neither the "Devs" or the "Ops"...
Being in a small company and working in both Dev & Ops I am practicing DevOps of a fashion. I am wary of continuous integration having worked somewhere where the Technical Lead decided it was the way to go and with no planning lead us into continuous frustration!
The other three buzz words really bug me these days!
March 30, 2017 at 7:08 am
Gary Varga - Wednesday, March 29, 2017 2:44 AMAlso, no it is not faster. This is a terrible misconception (sorry Steve but I believe that this is a myth that is being perpetuated here - managers see faster as developers can do twice as much and this is not what is happening as it is the automation of the manual release process that reduces overhead over time for testing and release, not necessarily for design and development). Some work isn't done faster at all. It is just delivered quicker as it is unhindered by other features and a time consuming release process. Faster? No. Earlier? Yes.
Yes and no. Faster because less time is wasted on tasks that can be removed or handled by a machine. Less rework time, which does equate to "done" being faster. Less time spent on tasks that customers might not use. Some still, but with faster feedback on portions of work, unnecessary features can be avoided.
Maybe earlier is a better term, but as you mention, it is dependent on what you do. This doesn't make developers come up with algorithms and code faster. It reduces waste and delays in release.
March 30, 2017 at 7:16 am
jasona.work - Wednesday, March 29, 2017 7:50 AMI think smartphone updates are a bad example to use in this case, in total. The reason being, with the exception of the OS required apps, each individual app is created by a different company. So you have a situation where App A releases an update that has a bad interaction with App ZZZZZZZZZZZ, but you can't blame the problem on "the smartphone." You also can't expect the app developers to test every aspect of their app against every possible combination of installed app, so such situations *will* happen.Now, from the POV of a single app, a DevOps culture can be (and likely in many cases is) a very big benefit. Regardless of how frequent they push updates, they've got an automated process in place so that when the tech security sites start screaming about "App A has *MASSIVE* security hole reports security researcher," they can get the fix for the hole out quickly with a reasonable assumption that it's not going to completely break the app.
Or it means an app developer can fill feature requests from end-users in a relatively shorter amount of time, or cope with changes to the OS (which they have no control or say in,) so that their interface remains consistent with the expected OS interface.I even think where I work could benefit from moving to a more DevOps type culture, but considering how much effort it can take to get the most basic tools installed, it'll probably be well after I've left (and some new culture of development / deployment is on the rise) before it gains a foothold...
This is the what I'd write. A smartphone, a Windows PC for a generic user, these are bad cases. The more stuff you install, the more likely you are to get an update. Not to mention for phones and PCs, there is such a variety of hardware and software settings, that it's no wonder that some of these apps struggle to work well. Even the core OS updates are sometimes problematic because of lack of specific manufacturer testing or carrier updates.
For your app, for your users, often you work in a much less complex domain, more tightly controlled conditions. Faster releases (not daily), but faster than you might otherwise do, with pieces of functionality, help to reduce the risk of your changes. Especially where you control the back end and possible part of the front (or middle) end. You can deploy changes, dark launch them, not send to all customers, and implement some testing. You can do A/B work. You can deploy risky changes separately from other changes. Perhaps more importantly, you can deploy fixes when you need to instead of waiting for some long release cycle.
March 30, 2017 at 7:20 am
Rod at work - Wednesday, March 29, 2017 8:29 AMYour article is timely. Just this morning I received an email from our CIO discussing some possible, detrimental actions in the future for us. I can't share what at this time, just say that it would have consequences.Anyway, my point is this, if DevOps really does save money, then that would be very good for us. Things I hear about quicker to market is all well and good, but in a way irrelevant to where I work. In order to help in our current situation we need to reduce cost. Does DevOps do that? Is there documented studies showing it does?
Depends on what costs you incur. Are you trying to get rid of technical staff? Certainly some of the aspects of implementing DevOps, such as automation (deploys, builds, tests) can possibly help. There is an offset with less knowledge and less people to work on software, not to mention the time to culturally alter development.
Releasing faster? Not really a lower cost item. Working on the value items that customers need and not wasting time on items that don't add value? not a direct cost reducer either.
March 30, 2017 at 8:29 am
I guess I just don't understand why people think you can "implement" DevOps. You can't implement a culture. You have to enable it and then let it happen.
I also don't understand why people think DevOps has anything to do with automating testing or deployment. If that can be done, that's great, but that's a method... not a culture and it's not DevOps.
DevOps is about intra and inter departmental communication and removing road blocks.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 30, 2017 at 10:51 am
Jeff Moden - Thursday, March 30, 2017 8:28 AMI guess I just don't understand why people think you can "implement" DevOps. You can't implement a culture. You have to enable it and then let it happen.I also don't understand why people think DevOps has anything to do with automating testing or deployment. If that can be done, that's great, but that's a method... not a culture and it's not DevOps.
DevOps is about intra and inter departmental communication and removing road blocks.
When I first started in IT in the early 1990's, we were the geeks in the corner who couldn't communicate with anyone, had really expensive toys, cost a lot of money, and were treated like a necessary evil.
We recognized that we needed to change the culture We needed to know more about operations than the operations department, more about marketing than the marketing department, and so forth.
We transformed the department into strategic partners to the rest of the business units. WHAT we developed was now on target, right the first time, and delivered measurable value to the entire organization.
This value did not apply to only to software development. Everything we put in place was designed to help everyone in the company perform their job functions better.
I guess that was DevOps without training, without a name, and without a lot of money spent.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply