I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.
Why not use Python instead? Shellscript is so... chaotic.
Python + Fabric is a lovely devops/sysadmin toolbox.
“It's The Future”
151–160 of 536 posts
Re: “It's The Future”
#152"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
> Any positive experiences with micro-services here? Yep. We already had a feature flag system, a minimal monitoring system, and a robust alerting system in place. Microservices make our deployments much more granular. No longer do we have to roll back perfectly good changes because of bugs in unrelated parts of the codebase. Before, we had to have involved conversations about deployments, and there were many things…
That sounds more like your team doesn't know how to use git beyond nothing more than an SVN replacement.
Re: “It's The Future”
#153https://www.gitignore.io runs on Heroku and it gets 40k+ visitors a month on a free Dyno. I use Heroku because I don't want an IAAS solution, I want a PAAS solution. If I wasn't using Heroku, I would probably find another PAAS, before switching to Docker (even though I do love Docker).
Thanks for providing that - I just notices that your shell instructions don't include completion. I use the following in zsh: https://gist.github.com/lorenzhs/ad6c009f5748d333b73376e07ae... With that, I can do "gi " to get a list of all possibilities.
I'm literally in the process of switching to zshell over the next few weeks. Since it's more than a 1-liner, could I just add that to the Advanced CLI instructions[1] section and credit you?
[1] - https://github.com/joeblau/gitignore.io/wiki/Advanced-Comman...
Re: “It's The Future”
#154"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…
In practice micro services mean that you turn a function or method call into a network request. This doesn't really limit communication bottlenecks. It is often more difficult to argee on a network interface than on a simple function or object interface. It's also more difficult to change. You introduce a whole new set of failure modes due to going over the network. Debugging is more difficult since you now can no longer step through your program in a debugger but rather have an opaque network request that you can't step into. You can no longer use editor/IDE features like go to definition. It becomes harder to do integration tests. Version control becomes harder if the different services are in different repositories. A network request is much slower than a function call. You no longer have the advantage of a garbage collector for logical values that now cross network boundaries, and rather need to manually free them. Deployment is more difficult. The list is much longer than this, but I'd be interested in the counter-list: what are the advantages of micro-services?
Re: “It's The Future”
#155Earlier quoted context omitted.
wait. you're comparing $25 with $75. it is 3x but it's still accounting noise by any standard imaginable unless you're running a charity server for an open source project.
What about the standard of "I'm young and this is a side project I'm doing in a couple of hours at the weekends"? Of course once you have a real company with more than two customers $75 is nothing. But version 0.1 is often a tool that's only useful to you.
Young people doing side projects on the cheap... are they Heroku's bread and butter?
Re: “It's The Future”
#156Earlier quoted context omitted.
never touch a running system...
fair enough, but I posit X users started consuming this API when SOAP was prevalent and Y users started when ReST was prevalent and Y >> X. Furthermore, SOAP is hard to maintain these days because it's so ancient. i.e. the libraries are not new and/or actively maintained. As such, I maintain SOAP should be gone for the good of the running system.
In Python you simply don't have good SOAP libraries. They were all started at the tail end of its popularity and then all died quiet deaths when attention shifted to ReST before they were actually production ready, and if you now want to talk to a SOAP service… well, better don't do it in Python. 2, that is. Forget about 3.
Re: “It's The Future”
#157Earlier quoted context omitted.
I think it's more to do with a need rather than going straight just because you have enough people on a team. For instance, if you find that some of your processing/specific request handling can outperform better by using a different framework, programming language than the ones it's currently developed on, then you should definitely consider a microservice approach by decoupling that specific service/functionality f…
>decoupling that specific service/functionality from your current stack. I do wish people would stop conflating "running in a different service" and "loose coupling". They are completely orthogonal. I've worked on some horrendously tightly coupled microservices.
OSGi makes it easy to end up with a cornucopia of tightly coupled nanoservices all running in the same JVM.
Unless you can coax dOSGi into working (which is tons of fun), then you can have services tightly coupled to other services running on entirely different machines causing frequent (and hilarious) cascades of bundle failures whenever the network hiccups.
OSGi is a trigger word for me now. I've worked on two large OSGi projects (previous job and current job) and it's always the same. Sh*t is always broken (and my lead still insists that OSGi is the one true way to modular bliss). And the OSGi fanboys always say "Your team is using it wrong!" Which very well might be true, but I no longer care. Apparently it's just too damn hard to get a team of code monkeys to respect service boundaries when OSGi makes it so damn easy to ignore them.
If I'm ever in a position of getting to design a new software architecture (hasn't happened in 10 years, but hey I can dream), I'll punch anyone who suggests "OSGi" to me right in the face.
Re: “It's The Future”
#158https://www.gitignore.io runs on Heroku and it gets 40k+ visitors a month on a free Dyno. I use Heroku because I don't want an IAAS solution, I want a PAAS solution. If I wasn't using Heroku, I would probably find another PAAS, before switching to Docker (even though I do love Docker).
That's 1 request per minute, you could slap that into a raspberry pi on a 3G connection, and do the same for your next 400 apps that has 1 request per minute. People seem to underestimate just how powerful modern machines really are. And I don't get why people seem to think it's hard to deploy simple web applications. Just write a 4-line shell script that rsync's, runs whatever DB migrations you may have and restarts…
Well technically it's:
622482 / 43800
= 14.2119178082 requests per minute
I definitely understand that modern machines are powerful, but I used to STIG RHEL 4 and RHEL 5 boxes for 4 years as my primary day job. I've done everything from create creating kickstart files to manually locking down a whole Linux instances to creating RPM files. At this point in my career I just don't care about the extra cycles I get by using .
If my product needed the extra performance, trust me I would switch.
Re: “It's The Future”
#159The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…
My manager and CEO are going wild with "blockchains", and how we should use it for everything.
"We could store gigabytes of data on the clients without having to pay for servers"
Re: “It's The Future”
#160The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…
"I am frustrated by the industry as a whole"
Unfortunately I have to agree as a developer. My job is to make a fast, reliable, stable product but at the same time I'm questioned the tools I use by people who don't have any knowledge but heard the latest trend.
But sometimes it's also very easy to please people. Big data: just insert 10M records in a database and suddenly everyone is happy because they now have big data :|