Time To Move on from DevOps and Continuous Delivery, Says Google Advocate (zdnet.com)

A reader shares a report: Continuous improvement and continuous delivery (CI/CD) and DevOps may be on many peoples' minds these days, but there's nothing particularly new about the concept -- software shops should have put these concepts into action years ago. Instead, technology leaders should be now worrying about the futures of their businesses. That's the view of Kelsey Hightower, staff developer advocate at Google Cloud Platform, who says too many IT leaders are debating how to manage IT operations and workflows, when their businesses are being hit with unprecedented disruption. "CI/CD is a done deal -- like 10 years ago it was a done deal," he said in a recent podcast with CTO Advisor's Keith Townsend. "There is nothing to figure out in that domain. A lot of people talk about DevOps, and there may be some culture changes, in number of people who can do it or are allowed to do it. For me, that is the table stakes. CI/CD, DevOps; we have to say, listen, figure it out, or go work with another team outside this company to figure it out."

Comments

heads were removed from anuses

[Anonymous Coward]

So somewhere along the way people figured out again that quality of software is more important than the speed in which new features are pushed out the door.

I guess the cranio-rectal inversion over devops crap is finally coming to an end.

Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.

Re:heads were removed from anuses

[omnichad]

Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.

Nah - caching/boost server on premises. So you can have a thin cloud server to go with your thin clients.

Re:heads were removed from anuses

[Dayze!Confused]

Nope, turns out this person is arguing for software quality. They think CI/CD is settled in the sense that it isn't going away, stop trying to change it, move on to other things like the latest buzz words. I believe CI/CD is what has made software shit these days. Companies start by promising x number of features, and rush it out the door after x-y>0 features are partially done, then CI/CD with users as their beta testers. You no longer have a finished version and solid piece of software, and no way to stick with a particular version, which is especially true on the walled garden of iOS. Gone are the days of a solid product coming out that stands on its own for years without the need for anything but occasional security updates.

Re:heads were removed from anuses

[Anonymous Coward]

It was a thing, pre-internet.

Re:heads were removed from anuses

[Junta]

Of course the change now is that the standard was to have PTF type updates that would fix problems without changing functionality.

Now developers aren't forced to do that because they are too cool for that, and roll out fixes alongside functional changes that also aren't baked yet and bring new problems, so you don't get to stop and say "hey, you *almost* got it right here, I'll just take fixes from this version, thanks"

In this era of using software remotely, you can't even choose to ignore updates and stick with an abandoned version, it's just gone.

Of course there are enterprise vendors still doing this, but developers will bitch about being asked to support that 'ancient' platform that first released 3 years ago and screw it up by ignoring all the content and replacing with the random untested assortment of latest crap from gems/pypi/npm/whatever wtogether with a random build of the language runtime that partially screws up the system paths.

It's just not 'cool' to have maintenance branches, so.. here we are.

Re:heads were removed from anuses

[Junta]

CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks.

Also, while CI isn't in and of itself a bad thing, it does encourage a lot of organizations to skimp on vluable QA, made overconfident by misleading phrases like '100% test coverage' and deciding that means they automated the need for QA.

Also, by the same mistaken thought, they don't need maintenance branches anymore because the first release was necessarily bug free because those unit tests passed, so no need to think about whether a change makes sense to work into an older functional branch.

Re:heads were removed from anuses

[Junta]

Of course with CI, you can still have this phenomon. This is about midnset and developer strategy, You can still have developers sitting on their private branches and at the last minute end of conflicting with each other. Of course a sane process says they get to sit that week out, but in all likelihodd, one of those has some change that simply "can't wait" even a week, so the whole train gets held up despite the sane thing of punting that developer work for a week,,

Re:heads were removed from anuses

[0100010001010011]

Absolutely. But the "CI" part helps to automate it. Our builds are in the ~50 minute range. Individual developers build on their own machines. There's no 'safe' build machine. At least with a CI setup they get immediate "You broke it dumbass" feedback.

Re:heads were removed from anuses

[datavirtue]

Show me someone who has "100% test coverage" and I will walk over to the closet and let the unicorn out.

Re:heads were removed from anuses

[turbidostato]

"CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks."

That's because it's either "to production" or it is not CD at all.

Of course, "to production" may mean different things to different people. For a VAR/COTS mill it means, "that's what we are going to sell to our next customer", for an internal team, it will mean "deployed and tested to our production servers" but, still, "delivery" means "delivery"; if it's not delivered, then it can't be D, continuous or otherwise.

"Also, while CI isn't in and of itself a bad thing, it does encourage a lot of organizations to skimp on vluable QA"

Bad managers are always bad managers. Where in "continuous" is hidden the concept "let's take critical steps out of our flow"? Hint: nowhere.

For the ones in the know it has been always the same: let's think out a good process matching our goals, let's test it to be valid, let's take out people from the process where people adds no value, rinse and repeat. That's "continuous whatever". Now: start with a bad process and all that "continuous" can add is "fucking it faster" -which, provided you have good brains at the rudder, could be a good thing on itself except, of course, you have bad processes in place because you have bad brains at the rudder to start with.

And then, there is the "devops" thingie. Look at the "agile manifesto" and all the other "foundational" concepts on these fields. All of them go to the same thing: "let's understand this is still not a "proper" engineering -and maybe never will be, but more a craftmanship, so let's understand this is more about people and empowering people than it is about processes -just the opposite to taylorism". But then, this is not a "silver bullet", because there are no "silver bullets" and where the risk of taylorism is siloism and the unability of letting your most valuable craftsmen to provide you the most value (and, in the most extreme cases, letting your people dealing with procedures and paperwork so much as the output of real value being reduced to zero), the risk of "agilism" as empowering people, is empowering the wrong people -which given the lame state of current IT, both at the technical and managerial level will be "most of them" and it may be the case that, given Sturgeon's law, there's no way to avoid that at a scale.

"Also, by the same mistaken thought, they don't need maintenance branches anymore"

Again, it depends: a VAR/COTS requires maintenace branches, an internal product/service probably does not and a SaaS offer may or may not, depending on those pesky details.

Re:heads were removed from anuses

[Junta]

The curse of all of this is that good teams have always naturally done things that lead to good product, and then some folks comes along to try to 'distill' out the magic of those successes into useless aphorisms and make a consultancy industry out of it. Complicated by ditching the unprofitable pieces (for example the agile manifesto among other things stressed communication rather than processes and tools, but an Agile consultant will ditch that and focus on tools and processes because they can make money off of tools and processes are what sells to the management).

So 'continuous blah' and 'devops' and 'agile' are all afflicted by the curse of being the consultancy of the month and as such are applied to bad teams and leave bad tastes in the mouths of folks. Also, the business is held up by taking the no true scotsman both ways. A project that did the Agile or DevOps or CI/CD thing and failed, well they didn't do it right, so it wasn't "truly" whatever it was. By the same token, a project succeeds, it is deemed to have done it right, even as it makes no sense in the context of the purported philosophy..

Re:heads were removed from anuses

[Junta]

I guess I've been blessed in that I've never worked in a team that wasn't naturally continuously building and testing their changes. I couldn't imagine being more than a few minutes of being able to see the result of my work. So for me, CI comes into novel play only when merge requests happen that start exposing subtle conflicts between privately worked branches of work.

I suppose I could imagine someone spending a long time without even building and testing, but on the other hand I can't imagine that willingness translating to a good developer even if that particular bad habit is automated away.

The problem is that there is no 'Test' in DevOps

[Zubinix]

I've always felt that integrating and keeping up to date test automation processes as the greatest challange in the CI/CD space. As business cycles get shorter, creating and maintaining the required set of test automation processes that can give you confidence in the final production release can be an immense challange. This together with the increasing complexity of cloud based systems has made the testing challange a really hard nut to crack.

Re:The future is NoOps

[sexconker]

With Amazon Lambda and other microservices, you just need HR to hand out IAM accounts, and a company really doesn't need an IT staff whatsoever. Just some CI/CD mechanism to get pushes in production, and that is basically it.

Ops is dead. Who needs to rack and stack physical servers when the cloud takes care of that, and far cheaper. Who needs OS guys, app guys, net admins, and DBAs when serverless services replace all this?

Lets be real... the future is NoOps. Pay your Amazon bill, and they take care of your IT infrastructure.

The cloud is NOT cheaper. Amazon is expensive. And you never know how much you're going to pay.
Even hosting a simple static website is a nightmare. They have about different 40 products for simple domain name management alone.

Re:The future is NoOps

[sexconker]

Ha!

Here's the "simple calculator" that doesn't even cover all of the services:
http://calculator.s3.amazonaws...

Put it on S3? S3 is storage! You need it to be on EC2. Possibly behind Beanstalk. Oh, you want to actually make use of the fancy cloud features for internet-accessible shit? You'll need Route 53, too, and the Elastic Load Balancer.

https://aws.amazon.com/s3/pric...
https://aws.amazon.com/ec2/pri...
https://aws.amazon.com/route53...
https://aws.amazon.com/elastic...

Beanstalk is free, though!

Take a look at this fucking list. https://i.imgur.com/nBasljK.pn...

Re:The future is NoOps

[sexconker]

AWS doesn't pass on the economy of scale to you. They keep it, and then some, as profit. They're not a charity.

If you're a not a small shop, it makes sense to host yourself or colo. You can use any other datacenter for disaster recover / fallback.
It's cheaper and you have far more control.

AWS, Azure, etc. only make economic sense in a few niche cases. One of which is being a small, but not very small, operation who is willing to bleed money during a growth phase. Another is needing highly dynamic and geographically distributed operations NOW (not having the time to negotiate with partners).