This comment is over simplistic and reads like it was written by someone who doesn't know what they're talking about. All of these technologies have their place, but they should be adopted incrementally and where it makes sense. Posting a frenetic conversation benefits no one.
“It's The Future”
451–460 of 536 posts
Re: “It's The Future”
#452Earlier quoted context omitted.
Someone once suggested to me that 'big data' begins when it doesn't fit in RAM in a single rack any more.
That's soon going to be on the order of 100 terabytes, so there will be only a handful of companies doing big data ;-)
I'm only aware of servers up to 12TB. Care to elaborate?
Re: “It's The Future”
#453Earlier quoted context omitted.
cron jobs Once these are doing anything other than rotating log files, can the system really be considered monolithic ?
How do you define a monolith? Please establish that before we discuss further. :)
That's an incisive question. My impression, which may be mistaken, is that a cronjob would be used to move data (pages compiled from templates, chart images, etc.) into the PHP host on a "batch" basis. To me, that implied the existence of other systems that handle the data in their own way, but I guess in this thread the salient difference between micro and mono is that the former connects components via a web stack. Are there more agile interfaces available for cronjobs? If instead we're only considering transformations of data already resident on the host (as what, flat files?), I don't imagine that cronjobs are the best solution available.
Re: “It's The Future”
#454Earlier quoted context omitted.
> You should mention it costs $20 for information that can be found for free anywhere on the web. While other users answer the question, you simply refer to your piggy bank, shameless. Yep, it costs $20. Basically the cost of chinese food for 2, to ensure guaranteed victory in learning the essentials of AWS' platform while having a guided tour on how to deploy a fault tolerant web app with Amazon ECS from start to fi…
I love the comparison to chinese food for 2. As if everyone lives in the US with the same economic situation. Your posts are truly despicable.
I'm sorry you feel that way. Unfortunately time is something we all share, and it brings me a lot of joy to have students say that my courses have saved them a ton of time and helped them meet their goals.
I see that you recently left Amazon after making 200k/year there (a comment you made 5 days ago). I can see why you don't like people promoting Amazon products, I fully understand.
Re: “It's The Future”
#455Self admittedly, I am one of the P2P psychotic pundits. This is a good reminder that we need to tone our language down.
That said, if you can get your system to work with a single Heroku box, you really truly can simplify your life. That is what we're trying to do with http://gun.js.org/ , be able to start with a single machine and no configuration/setup/complexity. Then grow out.
We just had a discussion on the WebPlatform Podcast about all of this P2P stuff (https://www.youtube.com/watch?v=NYiArgkAklE) although, like I said, I probably got too jargony.
But props to circleci for calling out the elephant in the room. Great marketing actually.
Re: “It's The Future”
#456Earlier quoted context omitted.
Doesn't statically compiling programs solve the deployment issue better? I mean, as far as I can tell Docker only exists because it's impossible to link to glibc statically, so it's virtually impossible to make Linux binaries that are even vaguely portable. Except now Go and Rust make it very easy to compile static Linux binaries that don't depend on glibc, and even cross-compile them easily. Hell I think it's actual…
Have to admit, as a fellow Go dev, with single binary static compiles, I don't really GET why I need docker... all it seems to offer is an increased workload and complicated build proc
You don't really, but tools like kubernetes, which are really useful if you're deploying a number of heterogeneous apps, expect a container format as they aim at a market wider than just golang. The overhead of putting the service inside docker and following 12 factor is minimal and largely worth it, but if you're only running a single go binary, you could legitimatly go other ways.
Something like kubernetes also lets you abstract away the lock-in of your cloud infrastructure, so whilst it adds another layer and a bit of complexity, it again is arguably worth the effort if you're worried about needing to migrate away from your current target for some reason in the future.
As a framework it abstracts apps from infrastructure quite well. It's super easy for me to replace my log shipping container in kubernetes and have most things continue to work, as all the apps have a uniform interface.
Nobodies saying you can't build these things without kubernetes, but it definitely gives me more of the things than configuation managment systems currently do. Personally, I'd rather aim at the framework than handles more of what I need it to do.
Finally, bootstrapping a kubernetes cluster is actually quite trivial and you can get one off the shelf in GKE, so I'm not really sure why I'd personally want to go another route.
Re: “It's The Future”
#457Earlier quoted context omitted.
https://youtu.be/zut2NLMVL_k "All my work will be obsolete by 2005" -Steve Jobs If you aren't willing to accept that obselence is part of life, then you are either building something you aren't passionate about or confused about the cruelty of time.
As inspirational as Steve Jobs was, he wasn't correct about everything, nor was he a brilliant engineer.
Nor did anyone (in this thread) say he was.
The quote has bounded context. And in that context, seems generally valid and applicable.
Re: “It's The Future”
#458Earlier quoted context omitted.
Easier might not be the right word. 'tools that allow them to be lazier' might be more accurate. Gluing together pieces somebody else wrote and trying to get them all to work with as little effort as possible and are surprised when it doesn't work well. > devs spend too much time reinventing the wheel I'd argue the opposite. They spend too much time not reinventing the wheel. They strap factory made bicycle wheels on…
Or learn about better wheels designed by smart people back in the 60s and 70s, when no one had the capability to just keep sticking wheels onto cars to see what works - so they had to rely on thinking and solid engineering practices instead.
Precisely why I've started buying technical books from ages past. I'm working my way through Algorithms + Data Structures = Programs by Niklaus Wirth, Constructing user interfaces with statecharts by Ian Horrocks and Practical UML Statecharts in C/C++, Event-Driven Programming for Embedded Systems. The last one has been especially enlightening.
Do you have any suggestions for which 'better wheels' people should be looking at?
Re: “It's The Future”
#459Earlier quoted context omitted.
I guess Facebook, Twitter, and Google are doing things "flat out wrong", then. Yes, that's a weak argument (argument from authority) but it is true that monolithic repositories have major advantages even for organizations with multiple products. Common libraries and infrastructure are much easier to work with in monolithic repositories. My personal take on it, at this point, is that much of our knowledge of how to ma…
Those are huge organizations with commensurately large developer resources, and they simply work at a different scale than most people on HN. "It works for Google" is not an argument for anything. Monorepos come with their own challenges. For example, if any of your code is open source (which means it must be hosted separately, e.g. on Github), you have to sync the open-source version with your private monorepo versi…
It seems we agree, we are both claiming that "there is no one right way".
I love Git, and I used submodules for years in personal projects. It started with a few support libraries shared between projects, or common scripts for deployment, but it quickly ballooned into a mess. I'm in the process of moving related personal projects to a monolithic repository, and in the process I'm giving up the ability to tag versions of individual projects or provide simple GitHub links to share my code.
Based on these experiences, I honestly think that the only major problem with monolithic repositories is that the software isn't good at handling it, and this problem could be solved with better software. If the problem is solved at some point in the future, I don't think the answer will look much like any of the existing VCSs.
Based on experiences in industry, my observation is that the choice of monolithic repository versus separate repository is highly specific to the organization.
Re: “It's The Future”
#460"-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…
The problem with microservices is that your state is spread over multiple systems. You completely lose the concept of transactional integrity, so you will have to work around that from the start. The advantage though is that APIs (system boundaries) are usually better defined. Perhaps one should use the best of both worlds, and run microservices on a common database, and somehow allow to pass transactions between ser…
The problem with microservices is that your state is spread over multiple systems.
Then again, sometimes it's advantageous to identify parts of your system where aspects of state can be safely decoupled. And in which having them reside in disparate systems (and yes, sometimes be inconsistent or differently available) might actually be a better overall fit.
You completely lose the concept of transactional integrity, so you will have to work around that from the start.
Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way.
Depends, depends, depends.