19 ms·
“It's The Future”
- saynsedit 10y agoWow, what a strawman. Seems like someone was blowing off some steam.
- toolz 10y agoDepends on how you choose to read it. I love microservices and all the new tools we have to scale gracefully, but I read this as satire. It's more hyperbole on how some people always seem to be over-engineering and pretending that's the conservative way to write software without considering the time-sink required to be able to dynamically scale with all of those tools.
- saynsedit 10y agoCalling this satire insults the skill and wit of competent satirists the world over. It's not clever or funny. It's lazy. It's exaggerated to the point of questionable emotional stability on the part of the writer. Actually it is funny, but only in an ironic way. "-Well, Amazon has ECS, but you gotta write XML or some shit."
- forgottenacc56 10y agoI'm not sure I get the message.
- pawelkomarnicki 10y agoheroku is dead, docker is awesome, gluten free food does not have gluten ;-)
- forgottenacc56 10y agoI'm sure I don't get that message.
- Pyxl101 10y agoIt's all sarcastic. It's poking fun at how trendy advances might not necessarily be better than what existed before, as well as how much complexity is involved in them. It makes the most sense if you're already familiar with the concepts in the article (Docker, Heroku, CoreOS, etcd, and so on), and happenings in the technology industry related to them. As usual, if a joke needs to be explained (to a person) then it's not funny (to them). I found this amusing since it aligned with my experiences: > -Since no-one understands Paxos, this guy Diego… > Oh, you know him? > -No, he works at CoreOS. Anyway, Diego built Raft for his PhD thesis cause Paxos was too hard. Wicked smart dude. And then he wrote etcd as an implementation, and Aphyr said it wasn’t shit. > What’s Aphyr? > -Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy? > What? Did you say BDSM? There are several jokes here based on cultural references related to the aforementioned topics.
- reitanqild 10y agoI learned that <x> will laugh at a joke three times: * First when you tell it, * then when you explain it, * then finally when they get it. (x used to be English people when I was a kid.)
- DonHopkins 10y agoA gentle reminder that it's against the Hacker News guidelines to leave unclosed xml tags in your comments.
- rb12345 10y agoSurely that's BNF rather than XML?
- DonHopkins 10y agoAt least you level of certainty has increased.
- crdoconnor 10y agoI call the process it's satirizing 'fashion driven development'. It doesn't just happen in the devops world.
- LukeB_UK 10y agoPrevious discussion from 434 days ago: https://news.ycombinator.com/item?id=9688383 https://news.ycombinator.com/item?id=9688383
- audessuscest 10y agoIs it a blank page ? I don't see any text.
- dredmorbius 10y agoNo, it's not. Even renders on console browsers.
- forgottenacc56 10y agoDid you read this on an Xbox?
- akerro 10y agoYour browser is dead. Use servo instead. Works on servo.
- longsangstan 10y agoSeriously, the text colour is so light that it is very hard to read.
- dredmorbius 10y agoIn an earlier age, all we had to hate were frameworks. http://discuss.joelonsoftware.com/?joel.3.219431.12 http://discuss.joelonsoftware.com/?joel.3.219431.12 (Factory factory factory factory.)
- jondubois 10y agoThat's why we started https://baasil.io/ https://baasil.io/. The idea is you can deploy any app to any infrastructure of your choice (inside Docker containers). This means that you are not locked into Heroku and it gives you much more flexibility. It's basically a hosted Rancher http://rancher.com/ http://rancher.com/ service with a focus on a specific stack. I think in the future, there will be a lot of services like Baasil.io (specializing in various stacks/frameworks) and managed by various open source communities. Docker and Kubernetes WILL become more accessible to developers - I would bet my life on it. I'm currently building a CLI tool to allow deploying in a single command - So you can get the simplicity of Heroku while not losing any flexibility/control over your architecture.
- nbevans 10y agoBut all you've done is shift the problem to, er, you. If someone is uncomfortable taking out a dependency on say Azure or AWS - the two leading Docker hosting platforms, then they sure as hell aren't going to take out a dependency on "baasil.io" are they?
- jondubois 10y agoUm no, Rancher is open source can run and manage ANY infrastructure (including Amazon EC2) - You can run it on your own datacenter or even on your own local machine. Also Baasil.io is essentially just a control panel/dashboard (Rancher-as-a-service), you can quit Baasil.io at any time and switch to your own hosted Rancher instance and you don't have to change any of your application code or change infrastructure providers. The main benefit of Baasil.io is that it was built by an open source community using open source software and so we can offer the best possible support for apps built on top of our own open source stacks.
- nbevans 10y agoI took one look at "baasil.io" and saw the typical landing page with a "Plans" link at the top and questioned why anyone would want to take a dependency on this. If there is some OSS project behind the plan-based charade then that's fine. "Also Baasil.io is essentially just a control panel/dashboard (Rancher-as-a-service), you can quit Baasil.io at any time and switch to your own hosted Rancher instance and you don't have to change any of your application code or change infrastructure providers." But so you can with AWS and Azure - especially with their Docker offerings. So I'm not sure what problem baasil.io actually solves? If anything it just adds to the list of dependencies and points of failure.
- djhworld 10y agoOne thing that I liked about Heroku was the ease of deployment for Java applications (or any language for that matter as long as you had the right build pack) Since they upped the cost of their small tier, I moved to Digital Ocean and installed Dokku, which gives me that Heroku-like deployment experience so managing my (admittedly very small) website isn't that much of a hassle.
- axelfontaine 10y agoWe at Boxfuse (https://boxfuse.com https://boxfuse.com) provide the same ease of deployment for running Java apps (as well as Go and Node.js ones) on AWS. All you need to type is literally: boxfuse run myapp-1.0.jar -env=prod And you automatically get things like auto-scaling, database auto-provisioning. easy debugging and more. Disclaimer: I'm Boxfuse's founder and CEO
- atoko 10y agoHey, it looks like your "center-iframe" is pointing to an invalid link. It threw me off while I was looking around. Hope this helps
- TickleSteve 10y agoSometimes it seems the webdev world is unaware of the complexity its creating simply to execute instructions....
- MichaelBurge 10y agoI think every developer goes through that phase at some point.
- SolarNet 10y agoI think the problem is that it's an entire industry. And they don't even see to see the problem.
- kalleboo 10y agoWhat do you mean? I'm just running bytecode on a virtual machine ontop of a virtualized container on top of virtualized hardware on a CPU where the instruction set is virtualized in microcode...
- saynsedit 10y agoReasonable.
- mtrycz 10y agoIs there a computer-voice teddy-bear version of this? I find them much better than walls of text.
- sandGorgon 10y agoshow me an easy way to push a rails application to aws (with docker) that uses RDS ? is there ANY way i can spin up a server, add the ssh keys to some configuration file somewhere and just "docker-magic push" and have my rails application running ? or do "docker-magic bundle exec db:migrate" and have that command run on the server. Or push a Procfile with worker definitions and have the PAAS automatically pick it up, add it to supervisord/systemd and run it ?
- methyl 10y agohttps://github.com/dokku/dokku https://github.com/dokku/dokku
- imaffett 10y agoIve been looking for the same thing. Tried dokku and it was painfully slow. Tried rolling my own solution via git hooks but other devs had problems with execution. I would love to hear more about people running dokku on Digital Ocean (I was on a beefy azure server) In a very specific case, Heroku is the best solution for my problem. Sounds like it is for you too.
- sandGorgon 10y agoi would say for most use cases unless ROI becomes an issue. There is a point of time where it becomes cost effective to run your own S3.
- jeremyjh 10y agoDeis will do exactly that. http://deis.io/ http://deis.io/
- sandGorgon 10y agohey - not bad. The documentation looks very similar to heroku.. i cant find if they do stuff to handle workers in Procfiles (which need to be added to the job manager like supervisord/systemd). But interesting..
- 10y ago
- nathell 10y agoObligatory link to "The S stands for simple", a SOAP-bashing classic: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
- codeulike 10y agoEverything must be in XML. Except the SoapAction header. Which has no defined standard. Yeah I remember all that madness.
- jgalt212 10y agoremember? Thomson Reuters on demand APIs are still largely SOAP based.
- fs111 10y agonever touch a running system...
- jgalt212 10y agofair 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.
- creshal 10y agoIn 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.
- 10y ago
- hellofunk 10y agoI assume this entire article is one piece of sarcasm. Because after reading it, how could any sane person not prefer Heroku?
- paride5745 10y agoFrom your comment I see you didn't read the post. Read it, it's a lovely 5 minutes piece of writing.
- hellofunk 10y agoIt looks like I was not the only one to be confused: https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/
- paradite 10y agoYes. You are right. At least you understand the author's intention. I would be worried if some non-technical people took the title literally...
- pbiggar 10y agoPrepare to be worried: https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/
- hacksonx 10y agoRead it and passed it around to the guys at the office and I can tell you that it goes beyond the Heroku v Docker debate. For us, here at some kind of bank development shop it is about languages and frameworks. I would advice that you read the whole thing. Pretty funny I must add.
- raverbashing 10y agoAlso Hitler uses Docker: https://www.youtube.com/watch?v=PivpCKEiQOQ https://www.youtube.com/watch?v=PivpCKEiQOQ
- ex_amazon_sde 10y agoReally spot on - recommended! "You are a bunch of Node.js hipsters that just HAVE to install everything you read on Hacker News!" By the way, why all the downvotes to the parent?
- joeblau 10y agohttps://www.gitignore.io https://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).
- deleted 10y ago[deleted]
- Svenskunganka 10y agoThat'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 the thing.
- forgottenacc56 10y ago40k visitors per month isn't one per minute. It's anywhere from one per minute to 40k per second. Division of requests by time is the worst possible mistake in calculating load.
- buro9 10y agoPlus visitors != requests. I have 200k visitors per month generating 8m page views and about 50m hits on the servers (with CDNs taking another few hundred million hits). These all peak during the UK weekdays and wind down at nights and weekends. Divisions over time aren't going to work, but neither is translating visitors into requests, especially as it's only the page views that have a beyond trivial computation cost.
- joeblau 10y agoYeah, I just checked Cloudlfare and here are the requests Total Requests Last Month 622,482
- vpol 10y agoYet another comparison of hot and soft.
- vpol 10y agosounds like "POSTGRESQL IS DEAD, USE KUBERNETES INSTEAD"
- _pmf_ 10y agoDid you just tell me to go containerize myself?
- jfoutz 10y ago> So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others’ APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it? exactly. I mean look, if you have a lifestyle business that's only going to support 5-10 people, it's totally a waste of time. if you have some hope of scaling this is the way to go. I get it, just use Heroku. It's easy and convenient. If you're planning on a billion dollar exit, this way is way better. > I need to decide if i believe my own hype? yeah. sorry.
- mrhektor 10y ago"-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 into many different pieces. Also, the team spent too much time debating standards etc. I think micro-services can be valuable, but we definitely didn't do it right, and I think a lot of companies get it wrong. Any positive experiences with micro-services here?
- forgottenacc56 10y agoWhat was the benefit you envisioned?
- mrhektor 10y agoWe were looking to break up our monolithic rails app into micro-services so devs could iterate and develop faster. We also thought that the application as a whole would become more failure resistant. Unfortunately, inter-dependancies among the services themselves meant that the failure-resistance didn't pan out as we thought.
- nicolas_t 10y agoI 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 piece by piece. A small team starting a new project should not waste a single second considering microservices unless there's something that is so completely obviously decoupled in a way that not splitting it into a microservice will lead to extra work. It's also way easier to split into microservices after the fact than when you're developing a new app and you don't have a clue how it will look like or what the overall structure of the app will be in a year (most common case for startups).
- nicolas_t 10y agoOut of topic but, man, is coreos not ready for prime time. I've been using it following the stable channel and ended up having to turn off automated updates because it would break docker (docker would just hang with the last 4 updates)... Not a very convincing test of coreos :)
- xchaotic 10y agoI think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.
- tormeh 10y agoWhy not use Python instead? Shellscript is so... chaotic.
- chillydawg 10y agocos they run without needing python.
- DonHopkins 10y agoIt's much easier to not need shell scripts, than to not need Python scripts.
- DonHopkins 10y agoI pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Like the way the shell would fork off an "expr" sub-process to parse a mathematical expression to add two numbers, then write the result to a pipe via stdout, then terminate the process, clean up all its resources, and switch context back to the shell, which then read the serialized sum back in from the other end of the pipe, and went about its business, regardless of the fact that the CPU running the shell already had its own built-in "add" instruction in hardware.
- karma_vaccum123 10y ago> I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Unless you are over fifty years old, you never experienced this. Rob Pike said it best: "Those days are dead and gone and the eulogy was delivered by Perl." Perl being a thing in 1995...
- jondubois 10y agoKubernetes/Docker will become increasingly accessible to developers and it will loosen the reliance on lock-in PaaS like Heroku - This is the future; I'm betting everything on it. With tools like Rancher http://rancher.com http://rancher.com, you can already see things moving in that direction. Next step is rancher-as-a-service. When it comes to developers, I think open systems will always prevail in the end (it's just more flexible).
- vpol 10y agoI thought it's more important WHAT you run inside containers than containers itself. I got really upset about this rancher tool because it doesn't design my database schema. Shit, future was so close.
- jondubois 10y agoYou still have to write code, define your database schema and declare config files to specify how containers should be orchestrated but soon open source developers will start creating frameworks/boilerplates which capture some of these requirements and which can automatically run and scale on Kubernetes/Swarm/Mesos and this will greatly speed up application development and deployment. Right now, we think of frameworks as being components (part of) larger software systems - But in the future, frameworks will provide the foundations for entire software systems - They will be be responsible for declaring their own network topologies and resource requirements and they will be capable of scaling automatically to any number of machines. Developers will extend and customize the framework with their own logic but the framework itself will handle all the difficult stuff related to its own operations.
- vpol 10y ago[sarcasm]
- nogox 10y agoHow is rancher related?
- seanhandley 10y agoThis needs a "(2015)" adding to the title.
- CrLf 10y agoBecause 2015 was, like, 100 years ago...
- jsmith0295 10y agoWe should really have the year of the original post in the title already! It's the current year!
- awesomerobot 10y agoit was so last year
- deleted 10y ago[deleted]
- kbart 10y agoOn the timescale of the web technologies, that probably reads as "ancient".
- imtringued 10y agoContainers are obsolete. AWS Lamba is the new hot thing.
- allengeorge 10y agoI can always count on at least one comment per tech article with exactly this text. Having read the article back then (and reread it now) it seems like it's still relevant. Maybe we'll have to add the year qualifier after a while when AWS lambda becomes "the way".
- tjbiddle 10y agoAgreed, was reading through this and before I checked the date - all I could think was "I know I've read this before - did someone just republish this as their own?"
- jgalt212 10y agoQuestion: Is there an advantage to using docker when it takes 3 hours to rebuild our relatively small database?
- jwmoz 10y agoReminds me of https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- lambdacomplete 10y agoThere are 2 major issues with this: 1) Small teams (~1-5 people) trying to seem "big" by working at Google's scale. 2) Heroku's prices. We are currently (successfully so far) migrating a small Django project from bare Amazon EC2 instances to ECS with Docker. Even using 3 EC2 micro instances (1 vCPU, 1 GB RAM) for the Docker cluster we would spend ~8 USD/month/instance. With Heroku the minimum would be 25 USD/month/dyno. That's a 3x increase in expenses. It's very possible to take advantage of technologies like containers without getting too caught in the hype.
- StreamBright 10y agoIndeed, the goal is to solve your business problem with technology, not use Docker for everything that you can find in your infra. Many people are mixing up the two. Docker can be replaced with anything that is hyped at this level.
- lambdacomplete 10y agoExactly. Docker provides a set of features that are nice to standardized development environments and deployments across projects. Anything else that accomplishes that works as well.
- baq 10y agowait. 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.
- StreamBright 10y agoWhat a nice clickbait title. A is better than B, even though A is an apple while B is an orange, and we use them for entirely different purposes. Some functionality provided by Heroku can be replaced with Docker, and some missing features of Heroku are in the Docker infra, that can be added to Heroku using software (like service discovery: https://blog.heroku.com/managing_your_microservices_on_heroku_with_netflix_s_eureka https://blog.heroku.com/managing_your_microservices_on_herok...)
- BellsOnSunday 10y agoIt's a humorous lament on the fragmented state of devops, not to be taken too seriously.
- mrich 10y agoLovin' it!
- robteix 10y ago"Why don’t I just use Google’s thing? "-You think that’s going to be around in 6 months?" Isn't reputation a thing of beauty?
- reitoei 10y agoSeriously though, this is why I'm afraid to use something like Firebase now.
- deleted 10y ago[deleted]
- droidist2 10y agoSo true. Why people often use "it's backed by Google" as an argument in favor of anything is beyond me.
- driusan 10y ago"it's backed by Google" is the reason I avoided Go for years and is still the only reason I'm nervous using it.
- prodigal_erik 10y agoIf it's free software it won't just disappear. If it's proprietary and hosted by an org that isn't making real money from it, that's a different story....
- flukus 10y agoIs the development open though (serious question, I don't know how they do it with go)? Look at android, it's a closed project that the occasionally release some source code for. If google decided to drop android then it's a critical blow because there isn't much of a community around it.
- thearn4 10y agoThis is structured like one of those Xtranormal do-it-yourself cartoons from a few years back.
- nickjj 10y agoOr just put your app(s) into containers and run them through docker compose on a single VPS. That bypasses about 99% of the things listed in this article. You can still easily set things up so it's a git based deploy which is hands free after the initial push. Now you have a single $5-10/month server that runs your app's stack without a big fuss. Of course it's not "web scale" with massive resiliency but when you're just starting out, 1 server instance is totally fine and exactly what you want. I've ran many projects for years on 1 server that did "business mission critical" tasks like accepting payments, etc..
- golergka 10y agoLook, if you're a one man shop doing a small project — do LAMP. Do perl. Do cgi. Do whatever you're comfortable with; if you try to switch to the latest silver bullet tech, you'll just get disappointed. But if you're a CTO with a startup with 10+ server-side developers and plan to hire at least as much in near future, suddenly all these dockers and microservices actually make sense. So, unless you'll start conversations with _who_ you are and _what problem_ are you trying to solve, of course the other side will seem stupid.
- manarth 10y ago> if you're a CTO with a startup with 10+ server-side developers and plan to hire at least as much in near future, suddenly all these dockers and microservices actually make sense As a consultant, I often get asked those kinds of questions: "Should we use X?" Whether it's programming languages, databases, operating systems, whether it's Chef vs Puppet vs Ansible vs Docker vs Whatever, it's a question that comes up a lot. I generally answer it with "What are your team good at? What have they used, what do they know well?" There are always exceptions to the rule, but in general I encourage people to play to the strengths of their team, rather than recommending Technology X because it's shiny and bang on-trend.
- golergka 10y agoExactly my point. I used two broad categories just to paint the overall picture; the fact that they "make sense" doesn't mean that they're the silver bullet.
- nathan_f77 10y agoI've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes. Heroku is great, and free for small services. On the other hand, a highly-available kubernetes cluster is going to set you back at least $100 per month, which is just too much for small startups and side projects before they take off. I think I'm going to forget everything and head towards http://serverless.com/ http://serverless.com/. No Heroku, no Docker, no micro-services, no servers. Just everything running on AWS Lambda and DynamoDB. And everything static in S3 behind Cloudfront. Or maybe just Firebase. But I really am tired of managing servers.
- numbsafari 10y agoSo, why not ditch AWS and use GCP? Kubernetes cluster setup in one command, or use AppEngine. Maybe the problem is AWS.
- zeveb 10y ago> So, why not ditch AWS and use GCP? It's a Google product offering, which means it could be EOLed tomorrow. Or this afternoon. Or maybe it already has — better go check their blog.
- numbsafari 10y agoAmazon and Google have almost the exact same language in their ToS for deprecation policies. Also, k8s is open source, so you can at least go somewhere else if you really must. GCP isn't "Google Labs".
- deleted 10y ago[deleted]
- nzoschke 10y agoTake a look at Convox for setting up AWS then getting out of the way. It's open source and free aside from the base AWS costs. Disclaimer: I work at Convox.
- oelmekki 10y ago"Hi, my name is dokku, and I have no idea what you're talking about" :) This rant sounds just like any rant from old dev mocking a new tech. "This is less efficient, this is too complicated, this can't be taken seriously, this won't last". Creating a character obsessed with "this is dead" hardly dissimulate the obsession with "this won't work". Do whatever you please, we don't care. But don't mock others about what they please. Passing through that, let's address the critics. Microservices and docker are not necessarily tied. I write only monolithic apps, and use them with docker through dokku. Etcd is a microservice problem, not a docker one. You don't need coreos or kubernetes to use docker in production. You need them if you want massively scaled applications, just like you would have many servers running the same app with replication without docker. Most of us don't need that (and those who need it probably won't find it more complicated than what is needed to do that without docker). If you don't want to manage servers, well, don't manage them. That's what cloud services are made for. But please tolerate some people love devops and not spending much direct money into infrastructure.
- 2100821021 10y agoYou mean B.S. written to impress investors and dominate a market segment for 2 or 3 years until the "founders" have a good exit.
- icebraining 10y agoParody is just a light-hearted way of criticizing. You shouldn't take it personally (unless specifically targeted). In any case, the author of the post actually agrees with you: https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/
- oelmekki 10y agoYeah, I tend more and more to be annoyed by some devs negativity every time someone is trying something new. I may take that personally, yes, not about docker and microservices, but because I'm always told to stop creating and use what already exists each time I'm trying to develop a new concept on sideprojects. I have to let that go, I guess. Thanks for the article, a lot of interesting things in it. It's funny how it's focused on the scaling problem. It may depend on which circles we're in, but it seems to me that what people were most interesting about in heroku was more the ease of deployment than the scalability. It probably depends on the size of your usual projects. Yet, what is interesting in docker is not just scalability. I find it way easier to code system dependencies with docker than with chef, that's already a big win. Also, I've stayed out of heroku for my own projects, mainly because of the cost. Docker, with dokku, allows me to have the same comfort one have on heroku, but with a 80€/mo server (handling about 15 small apps, and still having one third of memory available). And having several applications using several versions of ruby or postgres on the same server is not a problem anymore. In that regard, docker is not only interesting for people who have massive infrastructure to manage, but also to people who are used to self hosting and want an easier way to deliver.
- hoechst 10y agoPlease also read the followup (https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/). I read both articles a year ago and it really helped me grasp the whole container movement.
- QuantumRoar 10y agoI'm not a web developer but I sometimes put some programs on the web for me and my friends. I use FreeBSD Jails for that. Can someone explain to me the advantages of Docker compared to Jails?
- chillydawg 10y agoIn your use case: pretty much no advantages. Stick with jails and be happy.
- rendambathu 10y agothis old gem is back trending now!
- cdnsteve 10y agoDuplicate story: https://news.ycombinator.com/item?id=9688383 https://news.ycombinator.com/item?id=9688383
- DonHopkins 10y agoWhere do Beowulf Clusters fit into all of this?
- radarsat1 10y agoI'm actually looking into using Docker as an easier way to deploy my software to a Beowulf cluster..
- rajeshp1986 10y agoThe 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, space exploration and what not) or I feel they are somewhat trying to hide their insecurities. Anyway long story short, most of these people do not really understand why they need all this rocket science to manage < 500 internal users. One of the new buzzwords I am hearing these days is mostly related to bigdata and machine learning. One of my managers came to me and asked me why dont we integrate our product with hadoop it will solve the performance problems as it can handle lot of data. I am frustrated by the industry as a whole. I feel industry is simply following marketing trends. Imagine the no. of man-hours are put into investigating technologies and projects dropped mid-way realizing the technology stack is still immature or not suitable for at all.
- johnward 10y agoI too consult for an enterprise product and hear the same things. People don't know what the buzzwords mean but they know they must have it. That and then the assumption that ML based products are all just magic and require no effort. "You mean it doesn't just figure that out for me". Thanks marketing department.
- chucknelson 10y ago> ...the assumption that ML based products are all just magic and require no effort. Yep, same experience here with both "Big Data" and the ML space. The decision makers need to see the sheer amount of Java, Scala and/or Python code you need to actually implement to do anything useful. Nope...not magic.
- karrotwaltz 10y agoMy 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"
- chukye 10y agoMan, I dont think this is the future at all. OK, Docker is good and has its propose, and is very good on what its do: "Run only one process in one brand new kernel", but beyond than that, its just a daemon that uses and abuses of linux containers, you can easily scale, but is a pain in the ass to upgrade apps, also you need to run only one process on that. Does not looks like the future for me to have 30 different linux containers running just only one process in each of them, dude, you have a kernel in your hand, why the hell you will run only one process on it? (what the heck, you can protect yourself and scale without be the bitch of a daemon, you just need to know your best friend kernel), you dont need to make micro services for everything, its good ok, but its not the solution for everything like the people are saying... I really dont have any idea why the people are are so excited about "docker" all the things.
- piva00 10y agoIt's all about simplifying deployment. That's it, that's what's so good about using containers. I don't know if you understand what Docker really is when you say something like this: "Run only one process in one brand new kernel", the kernel is shared between containers, that's the whole idea, you package the things your application need and be done with it. The current problem with containerization is that there are no really good or understood best practices, people are still experimenting and that's why it's a big moving target and, consequently, a pain in the ass if you need to support a more enterprise-y environment. You will need to be able to change and re-architecture things if the state-of-the-art changes tomorrow. I agree with your sentiment about going overboard on "docker all the things", that's dumb and some people do it more because of the hype than by understanding their needs and using a good solution for it but I think you are criticising something you don't really grasp, these two statements: > "Run only one process in one brand new kernel" > you have a kernel in your hand, why the hell you will run only one process on it? I'm not trying to be snarky, I really recommend you doing a bit more of research on Docker to understand how it works. Also, Docker doesn't make it a pain in the ass to upgrade apps, quite the contrary if you do it in some proper ways.
- IshKebab 10y agoDoesn'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 actually not even that hard to do with C/C++: https://www.musl-libc.org/how.html https://www.musl-libc.org/how.html If I have a binary built by Go, what problems does Docker solve that just copying that binary to a normal machine doesn't?
- jakozaur 10y agoThumb rule: Divide number of backend engineers by 5 you get optimal number of micro-services.
- degenerate 10y agoI got 0.2 Should I round up or down?
- krallja 10y agoCongratulations! It's serverless!
- deleted 10y ago[deleted]
- gchokov 10y ago*_+
- imtringued 10y agoSince we are seeing so many "ads" here in this discussion. Does the average HN reader prefer this type of advertising to regular adsense ads? There is no violation of privacy, no autoplaying video, they are actually relevant to the discussion and it's obvious that they are trying to sell you something. Oh and probably the most important thing si you can downvote them.
- LukeB_UK 10y agoI dislike it because they just seem to have read the title and not the actual post.
- lopatin 10y agoI got a genuine laugh out of this quote "Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM.".
- eddd 10y agoMaking sort of funny articles about Docker doesn't change the fact that circleci's support for docker is horrible. I don't use it on prod (and I probably won't) but since circleci forces me to use ubuntu 12.04 which is not something I use on prod I want a docker container which looks like my production host. Having said that - circle really tries to support docker, but It doesn't. I have to use ECS for caching (I am not happy about it) Builds might fail due to the custom docker version/compilation You can mock docker, but people are using it in one way or another and you should support it properly.
- rjcrystal 10y agodoesn't anyone think about performance anymore? I mean just add more vms or increase their config, no one talks about efficient resource utilization asfaik. And there might be times where you containerizing everything is an over overkill.
- pbiggar 10y agoFunnily enough, people do. In fact, containerization came from Google caring a lot about performance! A good intro to how containers help, and to the probable future of computation: http://m.youtube.com/watch?v=7MwxA4Fj2l4 http://m.youtube.com/watch?v=7MwxA4Fj2l4
- wjd2030 10y agoI love everything about this.
- EGreg 10y agoYou know what's better than microservices? Nodes. Nodes running open source software that can power a distributed network. Microservices often hit the same database. You want to be able to split up the database. Not just into shards, but into distributed nodes. And by doing this, you split up the whole stack.
- bbcbasic 10y agoSolution: .NET
- spriggan3 10y agoClickbait titles like that don't make me want to do business with circleci , it feels like a business full of immature kids yelling at each others. Not even going to click on the link.
- daveheq 10y agoCheck back next year for Docker is dead article.
- wyldfire 10y agoI must've missed a tech cycle (or two) - I had heard of Heroku but didn't know what it did. I've used lxc and Docker and read bits about CoreOS/rkt/appc/kubernetes/etcd. I know it's tongue-in-cheek but few if any of these new fangled things are critically dependent on one another.
- jpalomaki 10y agoWhen it comes to micro services and containers, we are are missing fairly detailed descriptions of real world architectures from successful projects. And actually that applies to many other technologies as well. When it comes to micro service, it would be interesting to know simple things like what kind of services were created, how large are, how communiction is handled, how large team(s) behind the service etc. For some companies these are of course trade secrets, but sometimes opening things up might be good marketing. An example is Backblaze with their very detailed descriptions of their storage pods.
- mooreds 10y agoWould you find this presentation useful? https://www.infoq.com/presentations/microservices-comparison-evolution https://www.infoq.com/presentations/microservices-comparison...
- nickbauman 10y agoWhat containers do for you is two and only two coarse-grained things. 1. Make you more productive rolling out validated infra 2. Better utilize your hardware. Both of these things imply that you were using VM/AMIs before and you were hand-crafting your entire stack using things like Chef and Ansible. If you weren't doing that before (like, if you were using Google App Engine or Elastic Beanstalk or Lambda), Docker will make you less productive than you are today.
- laithshadeed 10y agoI believe microservice is the wrong term used to describe SOA. The word 'micro' make it looks simple & applicable for tiny apps 10-50K SLOC. I believe you should start chopping off your monolithic app only when it reach > 100K SLOC. Still you can split it up by well defined modules with clear interface, without necessarily using SOA if it is running on same box. Having monolithic app does not make it bad. What makes it bad is not having proper modules with proper interfaces. SOA comes handy when you want to distribute your workload, so now we have proper modules but those modules needs more computing power, so split them up into boxes and pay the pain for managing that, because you have no option.
- tedmiston 10y agoI guess this is meant to be hyperbolic but honestly it's true. > So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others’ APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it? > -Yes! Isn’t it glorious? > I’m going back to Heroku.
- cerebellum42 10y agoThis definitely reflects some of my experiences when trying out Docker and some of the other stuff associated with it. Serious question though: I would absolutely love to have an introduction on how to use Docker to deploy one or two web applications that use a typical amount of backend services, say some sort of database and a redis server. All of this would probably run on a single VM (whether Amazon, DigitalOcean, Linode, ...) and you mainly use Docker to isolate the applications from each other in terms of the environment/dependencies that they need. How do I do this with Docker in a way that gets me an easy deploy process? (Or maybe the question is actually, should I even do this with Docker?)
- pbecotte 10y agoMy personal blog is basically an example of deploying a simple app using docker. HTTPS://GitHub.com/pbecotte/devblog ... The makefile wraps up the actual commands.
- josh_carterPDX 10y agoIt's amazing that an article from a year ago can still create a buzz on HN like this. Goes to show there are still a lot of people talking about this.
- brightball 10y agoAs the author of that "Docker is the Heroku Killer" post that was popular a couple of years ago I have to say that I agree with this. When I wrote that article it was largely focused on the potential for Docker to create a bunch of Heroku competitors as well as a simplified development experience across multiple languages. The businesses aren't there yet although a ton are trying. The local dev experience has not materialized yet either outside of native Linux due to performance issues with volumes that only a 3rd party rsync plugin have come close to fixing. I still use and advocate for Heroku pretty heavily for just about any non-enterprise environment.
- BenfromOz 10y agoI'm working on one of those Docker powered Heroku "competitors". This post and your post both rung true for me. It's a constant balancing act. Too flexible, it becomes overwhelming. Too constrained and you sacrifice a bunch of the perks of using Docker. The conclusion I've come to is the only way to do it is to be unashamedly opinionated about keeping things simple for the average user. Otherwise you end up having that exact conversation
- brightball 10y agoYea. The most realistic way to get things working IMO is Dockerfiles with 80% use case defaults for parts of the stack. From there if people want/need to dive in and tweak them they'd have the ability to do so but ideally the average user doesn't need to know they are touching Docker much beyond knowing that it's there if they need it.
- jacques_chester 10y ago> The local dev experience has not materialized yet either Have a look at PCFDev. Disclosure: I sit next to the PCFDev team and use it in my dayjob.
- oneplane 10y agoThis pretty much sums it up. New stuff, stacked on existing stuff, with the theory that older stuff was hard, and new stuff is better, but you still needs the old stuff, so you basically end up doing exactly what you did, but now with more stuff in between, adding cost, complexity and additional failure modes while solving nothing. Any of the proposed problems that containerization was supposed to fix are already fixed by using proper configuration management. In almost all cases so far, people yammering on about docker and containers (and CoreOS), it ended up being their idea of configuration management, because they didn't have any in the first place. Say you want to fix your 'problems' with setting up servers, how about doing it the right way. You will need deployment services, regardless of containers, VMs or bare metal. You will also need configuration management services, and monitoring. Containers and special distributions solve none of it, knowledge to run systems is still required and not actually fixing your problems and layering stuff on top of it doesn't actually help. Get something like SaltStack or Chef, and configure the out of everything. It doesn't care what you're running on, and actually solves the problems that need fixing.
- trevyn 10y ago(2015)
- room271 10y agoMost commenters don't seem to realise that this is satirical, and that the author actually thinks Docker is 'the future': https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/ But there is, as the author notes, truth in the satire.
- deleted 10y ago[deleted]
- cocktailpeanuts 10y agoGlad to know there's the same kind of hipsterism going on in the backend world as much as in the frontend world. You could basically substitute all these backend buzzwords with "Webpack", "Grunt", "Gulp", "Requirejs", "React", "Angular", "Ember", "Backbone", etc. and it would have same effect on the readers--they think you're an annoying hipster.
- clifanatic 10y agoI'm sure I could go back 5 years and see an almost identical complaint about Heroku.
- joryhatton 10y ago> 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. reader implements and gets massive bill for personal blog hosting "Am I doing this right?"
- farorm 10y agoWell I think that people and developers in particular needs to start realising that companies like docker has gotten really good at marketing them selfs towards them. Most of the stuff you hear about a technology is just marketing stuff that makes you sound smart when telling your peer about a new technology.
- rjvir 10y agoThere was a time when Heroku seemed just as foreign to me as Docker does in this article. - So shared webhosting is dead, apparently Heroku is the future? - Why Ruby, why not just PHP? - Wait, what's Rails? Is that different from Ruby? - What's MVC, why do I need that for my simple website? - Ok, so I need to install RubyGems? What's a Gemfile.lock? None of these commands work on Windows. - I don't like this new text editor. Why can't I just use Dreamweaver? - You keep talking about Git. Do I need that even if I'm working alone? - I have to use command line to update my site? Why can't I just use FTP? - So Github is separate from Git? And my code is stored on Github, not Heroku? - Wait, I need to install both PGSql and SQLite? Why is this better than MySQL? - Migrations? Huh?
- dmix 10y agoWhen you heard about Rails it sounds like it was mature enough for you to start using it. Because it was a serious improvement over PHP, as I took a similar route. Docker/virtualization is still early and people are figuring out how the pieces fit together, and what the best pieces are. So it's best to wait until then (IMO).
- bertiewhykovich 10y agoTo be fair, a lot of these questions are valid. You arguably /don't/ need MVC for yours simple website, if Dreamweaver floats your boat you might as well use it, it's unclear why a small website needs an elaborate deployment infrastructure, using a VCS for personal code can be overkill, PGSql and SQLite aren't better than MySQL for every use case -- and so on. Frameworks, orchestrations, even just new technologies -- these are great if they actually make your job easier or if they make your product better. Unfortunately, they often do exactly the opposite.
- softawre 10y agoAgree until > using a VCS for personal code can be overkill I've been burned before, have you? If you're using something like Google Drive, you should use DropBox instead, since it seems less likely to lose your work.
- pbiggar 10y agoAuthor here. To answer some questions: yes this is obviously poking fun at Docker, but I also do really believe in Docker. See the follow-up for more on that: https://circleci.com/blog/it-really-is-the-future/ https://circleci.com/blog/it-really-is-the-future/ In a self-indulgent moment I made a "making of" podcast about this blog post, which is kinda interesting (more about business than tech): http://www.heavybit.com/library/podcasts/to-be-continuous/ep-16-its-the-future/ http://www.heavybit.com/library/podcasts/to-be-continuous/ep... And if you like this post you'll probably like the rest of the podcast: http://www.heavybit.com/library/podcasts/to-be-continuous/ http://www.heavybit.com/library/podcasts/to-be-continuous/
- deathanatos 10y agoIt's a good post. It capture both the innate complexity of the problems some of us are working on, and the incredible WTF moments involved. Both sides of your theoretical conversation have their own pitfalls. Everyone in the comments here seems stuck on the "I don't really need microservices train", (and there is such a thing as overdoing it … but I've never seen it) but I can't help but think that Italics nailed it here: > -It means they’re shit. Like Mongo. > I thought Mongo was web scale? > -No one else did. It's so incredibly true, and I laugh (and cry, b/c we use Mongo) at this section each time I read it. Also, this gets me every time: > And he wrote that Katy Perry song?
- Semiapies 10y agoI have to admit, I was startled to get to the "we sell these services" blurb at the end, because that was such a well-done unsell.
- davesque 10y agoI like the humility on display here. And I'm not trolling or being sarcastic.
- qwertyuiop924 10y agoDon't listen to hype. Look at the problems you need to solve. If you need a big, complex, distributed system, than maybe microservices are a good idea. If you're building a simple webapp... not so much. Things that work in the large don't necessarily work in the small. I write stuff in Scheme. I'm a hobbyist, there's no reason for me not to, and I love the language. The apps I write are sometimes single-threaded (or coroutine-based) monoliths. But I only have one machine available for me, and the things I'm writing are fairly simple. It's good ENOUGH. And Worse really is Better[1]. 1:and I truly mean that in the Gabriel sense. As in the New Jersey model. Not any other way.
- geggam 10y agoSee .... microservices are where you take a process using IPC and force it to go over a network and use TCP ...then you pretend it will run better and scale more but avoid the whole 10x infrastructure growth and the fact the devops team has tripled in size to manage the frankenstein ... dont forget to add in the whole SDN layer the network guys absolutely love
- discordianfish 10y agoHype is as bad as seeing a promising technology just as hype without trying understand the problems it might solve. This is quite frustrating for both people who are aware of those issues and trying to fix them as well as the people missing out on the real advantages of such technologies. This reminds me of similar sentiment around virtualization and cloud computing later in my peer group: Some sold VMs as security feature and people focused their criticism on that, without understanding other advantages like quick/self-service provisioning of systems. Later one, cloud computing was trivialized as "it now just somebody elses computer" which completely ignored advantages like no ramp up costs and the ability to problematically manage your systems life cycle. PS: Considering every new thing a fad probably also makes you consider 'hadoop' the latest shit in big data processing and assume today's tech companies hipster are fighting over wordpress plugins. (Like, really?)
- a-priori 10y agoThere's a theory in economics about the optimal size of a firm. How big should a company be? The optimal size could be infinite, where all of society acts as one firm. Think Communist-style command economy. Or it could be one, where everyone acts as networks of individual contractors or single-owner businesses. Think anarcho-capitalism. But in reality it's neither extreme and falls somewhere in the middle; why? It turns out that the optimal size depends on the balance between the overhead costs associated with allocating resources within one firm and the transaction costs associated with two firms doing business with each other. The overhead costs are higher with large firms because there's more internal resources, including people, to allocate. On the other hand, transaction costs are higher with small firms because each firm does less themselves so they need to transact more with others to accomplish their goals. As the relative costs vary over time, the optimal size varies too, and firms in an industry will grow and shrink. If it increases, then you'll see mergers and acquisitions produce larger firms. If it decreases then you'll see firms start splitting or small startups disrupting their lumbering competition. I suspect a similar thing happens in software, where there's an optimal service size. It could be infinite, where it makes sense to build large monoliths to reduce the cost of two systems communicating. Or it could be one, where it's optimal to break the system at as fine a granularity as possible (function level?). The optimal size depends on the balance of costs. All else being equal, by drawing a service boundary between two bits of functionality you shrink the services on either side but you increase the number of services and add communication costs for them to exchange data and commands. How these costs balance out depends on the technology, and there are competing forces at work. As languages, libraries and frameworks improve, we can manage larger systems at lower costs. That tends to increase the optimal service size. As platforms, protocols and infrastructure tools improve, the costs to run large numbers of services decreases. That tends to decrease the optimal service size. The microservices movement, and to an extent the serverless movement, assume that in the medium- and long-term the technological improvements are going to tip the scales sharply in favour of small services. I agree that's likely the case. But we're not there yet, except in some specialized cases such as large distributed organizations (Conway's law). But it's going to be at least a few years before it's worthwhile to build most software systems in a microservice architecture.
- mangeletti 10y agoI wonder if the original HN "Heroku is Dead..." title will cost Heroku money / market share in indirect ways. When I see titles like that (despite the fact that it was intended as sarcasm), I think to myself, e.g., "I bet at least hundreds of people who scrolled past it thought it was sincere, and now they will have this subconscious 'Heroku is Dead... Docker...' thought at times when deploying projects. Maybe they'll even check out Docker. Maybe these hundreds of people will represent a tipping point of sorts for Heroku->Docker migrations, because one of them will write a really great blog post about it, and it will receive thousands of views..." (alternate endings of the same thought continue to be brute-forced for a few moments). Along the same vein of thinking, back in 2008 I had this "realization" that Google could control the world by simply showing results based on headline titles (e.g., a search for "Obama" during the election could have resulted in articles / results whose titles have words/phrases whose presences are positively correlated to lower or higher stress levels, assumptions, other emotions, etc., resulting in a net positive or negative sentiment, respectively, about the subject of the search query, all while simply scanning the results to determine which one to click).
- Fiahil 10y ago> I wonder if the original HN "Heroku is Dead..." title will cost Heroku money / market share in indirect ways. This would be true for an average BuzzFeed-consuming-crowd, which -to my knowledge- isn't the case here.
- deleted 10y ago[deleted]
- krisgenre 10y agoIs there really something called "Ew" ? Its hard to Google something thats just two chars.
- deleted 10y ago[deleted]
- pbiggar 10y agoThe search term is "Jimmy Fallon ew".
- h8x0rd 10y agoHe slowly caressed his docker image while tenderly inserting it in the continuous delivery pipeline. The slow throbbing of the Jenkins service increased in intensity as the automated tests started firing off in a crescendo of etcd writes leaving a quivering micro-service that lay panting in its pod. That was a memorable deployment. The first of many that night...
- epalmer 10y agoI am going to ramble. Just move on if you don't care to hear the ramblings of a 62 year old development manager. I'm pretty docker ignorant. I think I get it in concept. I manage >150 web sites (~15,000 pages total) that are php based with eXist-db and oracle (overkill but forced to use it) for database backends. My team develops on mac os x and pushes code to RHEL. We have never had a compatability problem between os x and RHEL except for some mgmt scripts in bash that were easily coded around. Big data to me is a 400 MB apache log file. I go home grateful I don't have to be in the buzz word mix. I do read a lot about technology and over time that informs some changes like using apache camel for middleware, splunk for log file analysis yada dada... I have had bosses that brought me buzz word solutions that don't ever match the problems we have. I hate that but right now I am not in that position. My boss leaves technology decisions to us. Least you think we are not modern at all we do use a CDN, git and more. Some days I get anxiety from reading HN, feeling stupid. Some days I get a lift from HN from reading articles like this one and the comments. I am so glad I'm not in the business of chasing technology.
- SurrealSoul 10y ago"I thought Mongo was web scale?" This joke will never get old to me
- linkregister 10y agoI actually learned a couple of things from this article even though it's satire. I struggled through the de-monolithing of an application into microservices and then into Docker containers. Do people actually do this without having pressing issues that haven't lead them to this path? Is there any reason to spread into microservices unless the monolith is not keeping up with requests? I would have never considered Docker containers unless artifact preservation/isolation and deployment issues hadn't forced me to look toward a solution.
- reledi 10y agoThe post got one critical detail wrong. The microservices won't have their own API. APIs are dead. They'll use Kafka for messaging. That's the future.
- partycoder 10y agoWell, repeating buzzwords and pushing for early technology adoption for the sake of early technology adoption seems to be dumb, as the article implies. But new technology is necessary and early adopters are necessary. Iteration is necessary. Don't punish it.
- samhunta 10y agoThis reminds me of React state. Sagas, selectors, constants, components, containers, routes, reducers, actions, connectors, shoot me.
- colemannerd 10y agoThis 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.
- deleted 10y ago[deleted]
- Florin_Andrei 10y agohttps://en.wiktionary.org/wiki/joke https://en.wiktionary.org/wiki/joke
- marknadal 10y agoSelf 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/ 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 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.
- snambi 10y agoReally Hilarious and Reality. Lot of noise about docker, kubernates, microservices etc.
- Almaviva 10y agoI think words are very powerful, in particular "microservices" vs "monolith". By accepting those words, we imply the conclusion: microservices sound sexy and lean and elegant - who can argue with separation of concerns? And a monolith is a big unchangeable rock. I think we need a better word for apps that are single tight self-contained systems than "monolith". You can design elegant interfaces, and avoid creating a sloppy mess, with function calls or objects too.
- atulatul 10y agoNot exact but somewhat similar feelings expressed here: Let Me Just Code: http://www.drdobbs.com/tools/just-let-me-code/240168735 http://www.drdobbs.com/tools/just-let-me-code/240168735 Getting Back To Coding http://www.drdobbs.com/architecture-and-design/getting-back-to-coding/240168771 http://www.drdobbs.com/architecture-and-design/getting-back-...
- beweinreich 10y agoAs someone who recently drove down the path of learning all the new "hotness" in the DevOps world, I can safely say I came out of it with two learnings: 1. I have a much better understanding of what's happening behind-the-scenes 2. For most small startups, you should seriously consider the time (and therefore, cost) of investing in your own infrastructure. For point #1, I think understanding your options and how they benefit your company is essential for you transition from a small -> medium -> large size company. The paradigms you learn by virtue of researching the new technologies might end up being applicable in other parts of your development process. On point #2, I partially regret not deploying to Heroku, seeing where our system became stressed, and optimizing. Attempting to scale for things you don't know about yet is tough, and can lead you down a path of wasted time and money.