Ops should be limited to maintaining infrastructure services like VMs and creating tools to allows devs to deploy to prod on their own in a controlled way.
That's a valid approach for sure. What I've found in that case, however, is that taking Ops out of the loop and relying completely on developers for operational response to an incident in production yields poor results. Put simply, it's not their core competency, and most don't take to it well (although some do!). It's a very different type of pressure to which they're unaccustomed.
In my experience, a hybrid approach is best, where Ops personnel quarterback a production incident (or Support, assuming it's a mature org), and escalate as needed to development.
You sound like you're referring to corporate IT throughout your comment, or at least that's my impression. DevOps concepts don't really apply there...or at best it's a square peg in a round hole situation.
Building custom software, and more specifically SaaS, truly do have a lot to gain by adopting DevOps, especially when combined with Agile development.
Interesting. To be fair, I only ever had their internet service after cutting the cord years ago, and handled my own wifi. The price was around 50/mo for years, and they periodically doubled my speed for free.
I had Grande service for years, and they were by far the best internet provider I've ever had. Low and consistent price, and rarely any connectivity or speed issues.
I recently moved to an area they don't service and am stuck with Spectrum...which has been a horrible experience all around. This article makes me miss them even more.
The point is not having secure passwords, the point is having different passwords for your services.
Agreed.
Your password security is only as secure as where you are using them.
I disagree. If I use Keepass and store my DB locally, then I'd argue that's more secure than anything stored in the cloud. At the very least, it's up to me to ensure it's secure, rather than hoping someone else is doing so for me.
With cloud stored passwords, you can have auto generated arbitrary passwords, each different for each service so in case of a leak, your other services aren't compromised.
This doesn't require cloud storage of passwords.
Just make sure the password vault is encrypted client side and it should be reasonable secure for "random online stuff".
Or, store it COMPLETELY client side...and encrypt it.
For banking or high secure requirements, then no. Something involving keys would probably be better.
So you propose using a cloud storage service for passwords, unless you're banking?
I mean seriously it's a sad reflection on society when 100 millions of people just give everything to an unaccountable company and then cry about it later.
Many of those "crying about it" never signed up for Facebook in the first place...yet Facebook keeps data on them anyway.
What other practices have you seen used a lot, practical processes which really provide clear value?
Measure key metrics like cycle time, quality (bugs), code coverage, test stability, and escapes. Review weekly as a team, however small that may be. You generally don't optimize or improve what isn't measured and regularly reviewed. Release small changes often rather than big changes less frequently, and automate as much of the release process as possible.
I have hope that better and better tools and processes will be developed, and I'd like to help develop them. So far I've started by applying practices such as code review in organizations that didn't previously do it. We've found that code review / peer review reduces bugs enough to make it worthwhile.
This stands out in this day and age. I'm glad you've successfully introduced peer review, but I haven't heard of a shop in the last decade that doesn't implement peer review. Sounds like a change at the top is needed if you're at a shop that far behind.
I was going to mod you up, but that last link is useless in the context of this conversation. My home town of 10k people in the middle of the midwest is on it..
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.
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.
Maybe people will start realizing that the Cloud is just "someone elses servers" and you have no idea how they manage them or back them up.
Hosting was around long before cloud, and for some reason never garnered the amount of haters that cloud currently endures. VPS is hosting, not cloud...please direct your hate appropriately.
I'd argue it's not about SaaS being "about lock in" or not. It's more about implementation time and/or upfront investment for whatever you purchase.
If a SaaS service requires no upfront investment of hardware and takes little time/effort to implement, then lock in is a silly thing for which to strive via licensing and will push potential customers to the competition. On the other hand, if either are true, lock in occurs by default to some extent...with or without licensing.
Slashdot Mirror
Ops should be limited to maintaining infrastructure services like VMs and creating tools to allows devs to deploy to prod on their own in a controlled way.
That's a valid approach for sure. What I've found in that case, however, is that taking Ops out of the loop and relying completely on developers for operational response to an incident in production yields poor results. Put simply, it's not their core competency, and most don't take to it well (although some do!). It's a very different type of pressure to which they're unaccustomed.
In my experience, a hybrid approach is best, where Ops personnel quarterback a production incident (or Support, assuming it's a mature org), and escalate as needed to development.
YMMV
You sound like you're referring to corporate IT throughout your comment, or at least that's my impression. DevOps concepts don't really apply there...or at best it's a square peg in a round hole situation.
Building custom software, and more specifically SaaS, truly do have a lot to gain by adopting DevOps, especially when combined with Agile development.
From the article:
Bulc said EU member states would have until April 2019 to decide whether they would permanently remain on summer or winter time.
Wow. I get ditching DST, but make a call one way or the other across the board. This will get messy..
Interesting. To be fair, I only ever had their internet service after cutting the cord years ago, and handled my own wifi. The price was around 50/mo for years, and they periodically doubled my speed for free.
I had Grande service for years, and they were by far the best internet provider I've ever had. Low and consistent price, and rarely any connectivity or speed issues.
I recently moved to an area they don't service and am stuck with Spectrum...which has been a horrible experience all around. This article makes me miss them even more.
The point is not having secure passwords, the point is having different passwords for your services.
Agreed.
Your password security is only as secure as where you are using them.
I disagree. If I use Keepass and store my DB locally, then I'd argue that's more secure than anything stored in the cloud. At the very least, it's up to me to ensure it's secure, rather than hoping someone else is doing so for me.
With cloud stored passwords, you can have auto generated arbitrary passwords, each different for each service so in case of a leak, your other services aren't compromised.
This doesn't require cloud storage of passwords.
Just make sure the password vault is encrypted client side and it should be reasonable secure for "random online stuff".
Or, store it COMPLETELY client side...and encrypt it.
For banking or high secure requirements, then no. Something involving keys would probably be better.
So you propose using a cloud storage service for passwords, unless you're banking?
I mean seriously it's a sad reflection on society when 100 millions of people just give everything to an unaccountable company and then cry about it later.
Many of those "crying about it" never signed up for Facebook in the first place...yet Facebook keeps data on them anyway.
What other practices have you seen used a lot, practical processes which really provide clear value?
Measure key metrics like cycle time, quality (bugs), code coverage, test stability, and escapes. Review weekly as a team, however small that may be. You generally don't optimize or improve what isn't measured and regularly reviewed. Release small changes often rather than big changes less frequently, and automate as much of the release process as possible.
I have hope that better and better tools and processes will be developed, and I'd like to help develop them. So far I've started by applying practices such as code review in organizations that didn't previously do it. We've found that code review / peer review reduces bugs enough to make it worthwhile.
This stands out in this day and age. I'm glad you've successfully introduced peer review, but I haven't heard of a shop in the last decade that doesn't implement peer review. Sounds like a change at the top is needed if you're at a shop that far behind.
The one written in Perl.
Hang on a second, what did Perl do to deserve getting pulled into this? Everything else was spot on, but that's taking it too far!!
And even this GitHub project.
I was going to mod you up, but that last link is useless in the context of this conversation. My home town of 10k people in the middle of the midwest is on it..
You come off as pretty dumb defending this..
Then say neither agree/disagree, and simply express your opinion. The double negative in question is never appropriate (imo).
I don't disagree
In that case, just say "I agree, but"
I noticed that as well. It appears one is real, anyway:
https://slashdot.org/~Puls4r
https://slashdot.org/~BeauHD+(...
Hosting anything in AWS without integrating with and properly leveraging the ancillary services they offer makes little fiscal sense.
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.
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.
does this magical antenna thing work on your phone or tablet?
I don't necessarily agree with everything else the gp said, but with Tablo you can watch antenna TV on your mobile device:
https://www.tablotv.com/blog/a...
Yes, obviously. And I've been saying it for years.
Golly, kindly provide details on how we can all subscribe to your newsletter!
+1 to that. clearly the gp has never used both..
Wow, so you're pretty much a dick, huh..
Maybe people will start realizing that the Cloud is just "someone elses servers" and you have no idea how they manage them or back them up.
Hosting was around long before cloud, and for some reason never garnered the amount of haters that cloud currently endures. VPS is hosting, not cloud...please direct your hate appropriately.
Since when is SaaS not all about lock in?
I'd argue it's not about SaaS being "about lock in" or not. It's more about implementation time and/or upfront investment for whatever you purchase.
If a SaaS service requires no upfront investment of hardware and takes little time/effort to implement, then lock in is a silly thing for which to strive via licensing and will push potential customers to the competition. On the other hand, if either are true, lock in occurs by default to some extent...with or without licensing.
So someone went to the effort of editing this post to add gnome to the headline despite its having nothing to do with the article.
Haha, that reminds me of this line from Total Recall:
Someone..? We're talking about the fucking agency!
https://gointothestory.blcklst...