Earlier quoted context omitted.
It'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…
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…
“It's The Future”
241–250 of 536 posts
Re: “It's The Future”
#242Wow, what a strawman. Seems like someone was blowing off some steam.
Depends 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.
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."
Re: “It's The Future”
#243"-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…
Ah yes, the 'let's have decentralised microservices with centralised standards!' anti-pattern. It results in lots of full-fledged, heavyweight, slow-to-update services, which also have all the problems of a distributed system. It's the worst of both worlds.
Re: “It's The Future”
#244The 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 da…
Since when is 10M records is considered big data?
My goto gauge for big data is that it can't fit in memory on a single machine. And since that means multiple TB[1] these days, most people don't really have big data.
[1]: *Heck you can even rent ~2TB for $14/hour! https://aws.amazon.com/ec2/instance-types/x1/
Re: “It's The Future”
#245"-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…
Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind. The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be la…
Unsure if sarcastic.
Re: “It's The Future”
#246When 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.
Re: “It's The Future”
#247The 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 da…
Re: “It's The Future”
#248Earlier quoted context omitted.
Cloud Foundry is probably what you want. To the point that the Ruby buildpack code is a soft fork of Heroku's (source: I work on the Cloud Foundry buildpacks team). It'll run on AWS, vSphere, OpenStack, Azure, GCP is coming and others to follow. There is, however, still a hump to get over in installation -- you need to learn what BOSH is, install BOSH, then install Cloud Foundry with BOSH. In the long run, for a prod…
thanks for this ! how do you look at deis.io vs Cloud Foundry. Do you see yourself subscribing to one of the popular camps out there... or will you stick to Cloud Foundry in the long term ?
CF is already a relatively successful business with hundreds of million dollars in annual revenues across a pile of companies. Kubernetes and Docker are small in comparison as "businesses" but of course the momentum there is surging in terms of both pure open source adoption and contribution. It's likely going to be a big market with a lot of choice like Deis, or plain k8s, or RedHat OpenShift, or IBM bluemix, Pivotal , Docker Datacenter, or Mesos/Marathon, etc. It's a bit of a market war brewing and that competition will make for better solutions.
What is great about open source vs. past tech "gold rushes" is that these experiments and feedback loops exist across communities that are otherwise competing and overlapping. Mesos adopted the Docker image format independently of the Docker runtime ; Kubernetes introduced pods independently but also reused parts of Docker. Docker container networking and volumes are being used compatibly in the latest incubated CF releases. RedHat submitted a way to get CF style buildpacks working on K8S. Someone found a way to make CF run on Mesos; I could see a similar attempt on Kubernetes some day. It's a confusing and busy time but also an explosion of activity. And even if there is competition for dollars in the end among all these players that will lead to tension , the work is out in the open mainly.
Re: “It's The Future”
#249Earlier quoted context omitted.
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 lo…
A thousand times yes. Distributed systems are hard.
> 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.
Yes. Folks underestimate how difficult this can be.
In theory it should be possible to have tooling to fix this, but I've not seen it in practice.
> You can no longer use editor/IDE features like go to definition.
Not a problem with a good editor.
> Version control becomes harder if the different services are in different repositories.
No organisation should have more than one regular-use repo (special-use repos, of course, are special). Multiple repos are a smell.
Re: “It's The Future”
#250Earlier quoted context omitted.
"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 da…
> 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 :| Since when is 10M records is considered big data? My goto gauge for big data is that it can't fit in memory on a single machine. And since that means multiple TB[1] these days, most people don't really have big data. [1]: *Heck you can even rent ~2TB fo…