3 ms·
This is great. I hope something like this is built. Go needs it. However, not only did we need something like this 5 years ago, we needed it to be language/p
by bmurphy1976 12y ago
This is great. I hope something like this is built. Go needs it.
However, not only did we need something like this 5 years ago, we needed it to be language/platform agnostic then. We need it more so now. We won't be able to function without it 5 years from now.
The reality is Pandora's box has been opened there is no going back. We have software we need to run in production at scale that is written in a multitude of languages. We have our Python/Perl monitoring systems talking to our Java search APIs talking to our NodeJS frontend APIs talking to our legacy C#/Java/C++ applications over messaging systems written in Erlang/Ruby/Java/Go.
Every single one of these platforms need this functionality and everything needs to run in a cutthroat environment with fewer people, resources, and money to manage it.
We need performance, discoverability, security, scalability, deployability, testability, reliability and most importantly EASY. Not enterprisey over-engineered bullshit. I mean real easy to use plug and play, simple APIs, minimal JSON/YAML, small focused tools simple.
We need to do it in a way that is portable to every cloud provider so we can get the best bang for our buck and keep the cloud providers honest and avoid lock in.
We need to do it in a way that makes the "hardware" vanish. We don't want to manage hardware anymore. We want to deploy our software and we want to know it will work and we don't want to compromise functionality (ala Google App Engine or being forced into the "Tomcat 7" box).
I applaud this line of thinking, but I don't think it goes far enough. In 5 years time, I don't think we'll deploy servers anymore. We'll deploy services and those services will be in whatever language and those services will find each other and communicate with each other over the network and will be reliable, secure, and scalable.
Most importantly, it needs to be open. Truly open. We don't want to trade one master for another.
That's the software I would like to see. This could be a foundational component of something like this, but it's only the beginning.
I know about CoreOS/Docker/Mesos/Marathon, etc. Tools like those are an important piece of this puzzle, but not the only piece. They are a vast improvement over past initiatives (cough openstack cough), but they too are only a step in the right direction. We still have a lot of work to do to realize this vision of the future.
- sagichmal 12y agoI agree in the broad strokes. But the only way to this utopia is stepwise. I hope this Go kit is one of those steps.
- bmurphy1976 12y agoAgreed. My hope is that we don't stop at this, however, we continue to push forward. Too many times we build the beginning of something great but never see it through to the end.
- helloiamaperson 12y agoIt sounds like you want Cloud Foundry (or OpenShift, which I have no experience with). (http://www.cloudfoundry.org/about/index.html http://www.cloudfoundry.org/about/index.html)
- reality_czech 12y agoI am old enough that I used CORBA. That basically checked all your boxes... multi-language, platform agnostic, discoverable, standardized serialization formats, you name it. It was also an overly complex piece of shit. People learn nothing from the past.
- tekacs 12y agoI beg to disagree. I just gave a talk[1] about exactly how we[2] went back and took time to learn lessons from designs like CORBA (we're building another microservices framework). Not least I talk about how it's important to build something that modularises complexity and above all else, focuses first on being _usable by humans_ rather than on technical ascension. _Some_ of us _are_ listening. [1]: https://vimeo.com/118895501 https://vimeo.com/118895501 [2]: http://wym.io/ http://wym.io/