Slashdot Mirror
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."
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.
I have yet to see to a CI/CD shop actually implement this in such a way that people can safely commit away.
I'm sure life is easier when you don't actually have customers that care about state or you just shit on your customers continuously. Google wins on both counts here!
I just started reading "Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript" by Harry J.W. Percival. Now CI/CD is obsolete.
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.
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.
I'll just leave this here : Human error caused Amazon Web Services outage, Apple iCloud service issues.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
No future in ops means nobody studies it. Who does Amazon hire in 30 years to keep it all going?
Unit and integration level tests are not enough by themselves as the gap between the systems these tests run on and the actually production system is too great, and with the complexity cloud deployments allow this gap is growing. Yes, you can run a set of smoke tests in production but that doesn't hide the fact that most of the testing is not performed in a realistic environment.
Someone has been reading too many issues of CIO magazine between rounds of golf!
Either that or this was a good troll. Either way... cloud is never cheaper for non trivial deployments and work loads. Period. If your cloud service is cheaper for real work then you're seriously incompetent and going out of business soon anyway.
Who is taking the 3am call when shit breaks? Your developers? They checked out at 3:45pm, went to the bar, did the deploy to production from there, got super drunk and passed out.
NoOps: more silly shit from people who never worked in the real world.
Too funny!
Even hosting a simple static website is a nightmare.
Put it on S3, you're done. Use whatever registrar you want. If you need help figuring out how to point your DNS to S3, then there are forums and stuff. Ask on Stackoverflow.
"First they came for the slanderers and i said nothing."
Now your customers say, 'where's your mobile app? I want to be able to have voice assistance to talk to your particular product.'
Is that really true? I thought apps were mostly a dead end now, and everyone is just writing for the web. Do people really want voice recognition in apps?
"First they came for the slanderers and i said nothing."
"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."
You sir, are a moron. This is the crap that PMO/MBA wannabe's push to C suits to get into Director/VP promotions and once it's done, they bolt. Anyone who says DevOps or Cloud as a term to solve a companies problems is going to blackhole the company. Unless you're a mobile app provider with 1-2 products, you don't do that. All Fortune 100 companies user Ops and even some Cloud and some DevOps, but in percentages where they work.
Next person that says web-scale......
How does one get online to the cloud without a network, I wonder?
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...
I wouldn't hire someone stupid enough to publicly say what you're saying here to work on my team. Good sense is important in any developer.
If you want to host a static website, all you need is S3. That is it. Don't forget to make your files public-readable. EC2 and load balancers are for dynamic content.
For the most part, you shouldn't be using the fancy cloud features. Keep it simple. The only way to have a reasonable system is to keep it utterly as simple as possible. Anything that ties you into Amazon proprietary products should be ignored, although Amazon will try to convince you to pay for them. Anything too fancy will come back and bite you.
"First they came for the slanderers and i said nothing."
. . . because, sooner or later, DevOps HAD to no longer be the New Hotness. . . Of course, the question is. . . what comes next ?
I think the complaint is developer written tests of their own code is frequently considered a replacement for an actual QA team, whether unit or integration test.
One of the *massive* gaps is if the developer is batshit crazy and designs horribly because they are not the target audience and do not understand the target audience, the tests are going to sail on through and be horrible because no 'mere mortal' could check that developers bizarre vision. Also a developer can be plain dumb and think the wrong thing and make tests that only will pass when a broken implementation is thrown at them.
The biggest problem is the buzz of CI/CD brands developers in general as infallible. CI at least is a good idea in and of itself to augment a process, but the collateral damage of how those words are interpreted by management is severe.
XML is like violence. If it doesn't solve the problem, use more.
While I agree with you that good test automation is challenging, I would say that it is no worse than on-premise product development. Effective testing requires engineering commitment to make test automation development co-equal with product development. It is an immense challenge. BUT, having worked CI/CD for both an on-premise product and a cloud-based (AWS) product, cloud seemed easier. If for no other reason than it is much easier to manage the equipment.
I think it's the efffects of the bubble. The late 90s did have whiffs of this too, though that bubble burst earlier in the cycle and communication wasn't as rapid as it is today, so it's a bit more severe. Developers in general had a wake up call after the bubble burst last time and things settled back down for a while there into more manageable offerings.
The real root cause is not the fads and rhetoric, those are a combination of band aids and denial about the reality that the market is flooded with students that became programmers because of big dollarsigns in their eyes and not so much passion for the industry, and companies have a very hard time recognizing the value of the more intrinsically dedicated and focus more on X developers should be able to do this, and if not there must be a magic process to fix that'
XML is like violence. If it doesn't solve the problem, use more.
The cloud is NOT cheaper. Amazon is expensive. And you never know how much you're going to pay.
When did Slashdot become full of people that talk in absolutes like this, and then get moderated insightful? It barely warrants a response, but I don't want to say that without any context.
Cloud is definitely not the answer for everyone, and AWS isn't always the right answer even when cloud is. It completely depends on your situation. Stop being so narrow minded and understand that your way isn't the right way for everyone in every situation.
As for the cost of AWS in particular, they absolutely nickel and dime. But, if you understand how it works, it's actually fairly predictable.
I can pay three to five salaries with the cost of Amazon. And even though you have Amazon, you still need those IT people to set it up and help people use it.
$200k/y for a service that cost $50k in hardware, $1k in power and 5% of a jr. FTE - reals savings.
Custom electronics and digital signage for your business: www.evcircuits.com
Mathematically it doesn't make sense how Amazon can be cheaper. So they host it instead of you. But now you have to pay Amazon and all their developers, middleman, taxes, and the same costs you paid when the servers were in your MDF.
The only logical reason why this is taking off is Wall Street is penny wise and dollar dumb and stupid as they only count revenue in quarters. So you have one fixed cost but no spikes which make the share price go up. Where if you hosted it you would see a dip in the quarterly shareprice as you would need to upgrade hardware/software.
So you end up paying more but evenly.
Unless you are traded on Wall Street or small and do not have an IT department yet it sounds like a bad bet. I see Amazon is becoming the next Microsoft with proprietary API's and frameworks which glue you in too which is another red flag. Unless the bet is the Amazon APIs are so amazing and good that they give you a solution you can't get with opensource?
http://saveie6.com/
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).
Not strictly true. If you have a globally applicable product that must nonetheless comply with local data residency and access rules then cloud services let you deploy globally without needing a complex fragmented physical estate.
For regions with sizeable footprints there will be an inflexion point at which self hosting makes commercial sense. Even there I'd constrain the solutions to the same deployments used in the cloud, for dev and ops simplicity.
"No future in ops means nobody studies it. Who does Amazon hire in 30 years to keep it all going?"
If they are clever (and corps don't tend to be too clever), they'll train their own people. If they don't, it'll end up more or less like Asimov's Empire nuclear facilities on the Foundation's saga: some magic tricks that nobody can repair much less enhance. But hey, it they manage to rise to monopoly position, it won't matter as nobody will have the knowledge to challenge their position, either.
AWS doesn't pass on the economy of scale to you. They keep it, and then some, as profit. They're not a charity.
I never claimed anything to the contrary, were you responding to someone else?
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.
You're making assumptions here, likely based on anecdotal evidence. I have plenty of my own, and I argue that infrastructure TCO (either cloud or on-prem) is far more complex than comparing an AWS bill to an amortized set of hardware and a monthly colo bill at Sungard.
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).
Again, assumptions. It's quite likely cloud never made sense in scenarios you've encountered, and that's fantastic for you. I currently run a large AWS footprint that would nobody from the on-prem world would call "small" if it was in their colo or datacenter, and it makes complete fiscal sense to do so. I've also run large on-prem environments...and having run both cloud and on-prem multiple times, I can guarantee you that the right answer is completely situational.
Hosting anything in AWS without integrating with and properly leveraging the ancillary services they offer makes little fiscal sense.
I remember when people talked how cheap it is.. we got 2 micro instances ( one did the work, another one was hot spare in case something happens to the first one ), and the bill at the end of the month was around $200 usd. This was sometime around 2010.
Look what you can get for that kind of money (granted, this was a bit more expensive back then, but amazon is still the same price): https://www.hetzner.com/dedica...
Now, it would've been cheaper, yes, if my boss fired me, his system admin, and managed all by himself. But he still needed me to make sense out of all of that, and setup everything we have / need running on these instances.
Amazon started this "oh we're cheaper if you do X, and Y" because it's their business and they wanted the money spent their way.