51–60 of 152 posts
You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…
I swear, the HN front page algorithm is easily gamed, this gets a few points quickly and it rises straight to the front page. I don't know if HN is accounting for vote rings but some penalizing should be implemented.
AFAIK the content is curated. So content with a little ammount of upvotes can show up if some admin wants to.
Furthermore, there are protections against vote rings. If, for example, someone votes directly on the URL for a story, or if the referrer is often the same, those votes are discarded.
However, you're right that the algorithm has evolved over time. Visit https://news.ycombinator.com/classic to see the previous algorithm in action.
My approach is to design like microservices and develop like a monolith. Thinking about microservices will force you to define module, their boundary and interfaces. A monolith will simplify deployment, refactoring. Once your code matures, you'll know if any microservice has to be taken out and deployed seperately.
Earlier quoted context omitted.
In my experience scaling a monolith just costs more (i.e. hosting costs). Our product, when we started, was quite expensive to run at our high traffic times, but we were eventually able to cut our costs drastically by breaking certain pieces out into services.
Depends on the product, but for many startups those additional costs can be crippling. Also, I have found it much easier to onboard a new engineer, give them the requirements for a service and let them go at it. I've been using AWS Lambdas to great effect in this way.
Earlier quoted context omitted.
AFAIK the content is curated. So content with a little ammount of upvotes can show up if some admin wants to.
It's not curated. People used to be asked to repost their content if the admins thought it was interesting, but this no longer occurs. (This turned into a system that could automatically repost content considered interesting; I've stopped posting stories as often, so I'm not sure if it still happens.) Furthermore, there are protections against vote rings. If, for example, someone votes directly on the URL for a story…
I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase".
But it also have all the good parts of monolith: easy deployment and local setup, aggregation made easy, and ability to run integration tests.
For my rails projects, geminabox was of great use for me to achieve this, as it allowed me to host private gems. Lately, I've done a lot of golang, and was surprised to see how it's a natural pattern with go packages.
Only hurting part for ruby projects: keeping dependencies up to date in all those libs (since they all have their test suite, it means that I at least have to update them for test dependencies). To solve this, I've built some tooling that will update all my project automatically and create merge requests for them, running from a cron task.
Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…
Indeed. It's easier to change a monolithic stack while you're still discovering the actual architectural requirements of the particular problem you're solving. As you get a better understanding of how you need to handle things, where the performance bottlenecks are, etc., you can start breaking out pieces that would benefit from being isolated. It's extremely unlikely that in the short term (first year(s)) of the app…
Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…
My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Djan…
From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined. Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated. I would love to understand how this article believes that the modules in…
At work I built and maintain a large codebase that deploys to multiple servers to perform multiple tasks. We also license software. The answer to your question is simply libraries and build targets. My monolith is mostly shared code, with unique functionality at the fringes, but it all builds into a single deployable jar, minus the licensed libraries which are special cased. I'm a huge fan of SBT, despite its dwarf f…
OSGi[0][1]
I mention it mostly to assit those wanting to explore the concept of microservices itself, as opposed to assuming a network transport is always involved. Being JVM specific, "kicking the tires" on it naturally requires that environment. Perhaps, though, some of the writings discussing it would be of benefit to those using other tech stacks.
Of course, OSGi does not preclude distributed processing (and often is employed for such).
1 - http://www.theserverside.com/news/1363825/OSGi-for-Beginners