Thanks for the loving kindness. However clumsy was my attempt it stemmed from good will - I myself managed to cure myself out of extreme suffering (and near-death) by realizing, accepting and letting go of my anger.
1,561 karma · joined September 21, 2012
Anger always finds a target, and when you don't allow yourself to be angry at someone or something the target becomes yourself and (mostly mental) illness results.
Can't hear much (or any) aliasing in the tracks on the page. How does Zyn manage to avoid that?
> In computer science, a function or expression is said to have a side effect if it modifies some state outside its scope or has an observable interaction with its calling functions or the outside world besides returning a value. For example, a particular function might modify a global variable or static variable, modify one of its arguments, raise an exception, write data to a display or file, read data, or call other side-effecting functions.
Note "write data to a display or file". I think we agree that writing to a database falls under this definition, hence using terms like "side effecting" when talking about microservices is misleading.
If no one then what's the point of that service's existence?
That's plainly wrong. I get the gist of what you are saying and I more or less agree with it but you expressed it poorly.
Having API dependencies is not an issue. As long as the microservices don't touch each others data and only communicate with each other through their API boundaries microservices can and should build on top of each other.
In fact that's one of the core promises of the open source microservices architecture we are building (https://github.com/1backend/1backend).
I think your bad experiences are due to microservice apps which are unnecessarily fragmented into a lot of services. Sometimes, even when you respect service boundaries that can be a problem - when you have to release a bunch of services to ship a feature that's a sign that you have a distributed monolith on your hands.
I like to think of services, even my services, as third party ones I can't touch. When I view them this way the urge to tailor them to the current feature I'm hacking on lessens and I identify the correct microservice the given modification belongs to easier.
Usually what happens is that they try a complete rewrite which turns out to be rather expensive (especially in opportunity cost). They should ideally just move the pain points (ie. performance problems) to services and optimize that, but the enthusiasm towards the shiny new way of doing things that will fix their problems is so high that they opt for the riskier move of rewriting all the things.
That scenario is simply so dangerous and expensive that companies will be better off starting with a proper distributed framework - which doesn't really exists yet, but we are slowly getting there.
Anyway, this is just my 2c but I have seen this pattern of full blown rewrite at a lot of places.
I still feel like we are way ahead with the concepts in (shameless plug alert) https://github.com/1backend/1backend when it comes to the big picture of building microservices that actually build on each other, although it's statistically very likely this is just a personal opinion :)).
Anyway, I'm generally happy that this space is advancing, as someone who spent most of his recent career in this space I almost gave up hope: simply there was not even a common vocabulary to properly discuss ideas, everybody just wanted microservices because that was the next cool thing, and looked absolutely perplexed when explained the pitfalls.
GraphQL, this, and all the different kind of faas platforms popping up nowadays all help as a point of reference.
I truly think we are on the verge of radically changing how we build applications soon - I think these technologies can be viewed as a new breed of web frameworks, a breed which has the distributed principles in its core.
Perhaps those countries are not that poor anymore then?
The basic idea in terms of pricing was low cost and low maintenance for low traffic things: when someone is not running anything substantial even 10 quid a month feels like a waste.
And then when you start to have multiple side projects, you might need multiple servers (or set up more complex things like port forwarding based on domain etc)
So that's how it came about. But we are sure it's not sustainable entirely yet! We would just like to provide low cost and low hassle hosting. Let's see how it goes.
I guess we are trying to convey the idea that it's a complete product from user management to charging - you could install it for your company or launch a web hosting company with it.
Hats off to you. I remember when talking with Asim Aslam about him going and creating micro (https://github.com/micro), a microservices framework, I tried to advise him to go high level, as high level as possible and create a complete platform.
I used hook.io as the example of a project which is on the right path. He said the world is not ready for it. I said some day someone will make a tool like hook.io and promote it well and get incredibly popular.
Turns out we were both right. Seems like the world is ready for these kind of solutions now, and you were ahead of the curve with hook.io.
Good news is perhaps on your own machine it will run flawlessly :)))
And you are right, the ReadMe likely should say Angular 5 and not Angular 2.
One of the authors here! We hope you enjoy this much loved project we are building with our tiny team.
This is a love project of a team who failed at a startup. We decided to build something we love before getting back to our normal lives :)
I have worked in the faas/microservices space for years before but never wanted to build something like this (I thought it was too early to explain what we are doing).
Now with the advent of faas/serverless/lambda perhaps it's a bit easier.
Our focus is building something that enables service reusability and composability: no more writing the same login service multiple times.
We would also like to host other peoples low traffic services for free if we can (right now we can't because we are on a small server, fixing that).
Thanks
I have spent a good chunk of my life explaining companies why they don't need any special hand rolled platform - leaving hundreds of thousands of dollars on the table.
I guess parroting buzzwords is always more popular in this industry.
Most companies don't have specific needs. They think they do, but 90%+ of the companies out there are either building run of the mill CRUD apps or something barely more technically difficult.
If you have a monolith or two you can easily do one off tasks manually and forget about them forever, with microservices it's all about automation.
All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually.
Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice.
I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call.
Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
Although I am working on one platform like that right now (see https://github.com/1backend/1backend) the reason I started it was more the fact that I could not easily deploy a custom tiny service and call it easily.
We have solved both problem with 1Backend: launching a new service is as easy as creating a git repo on GitHub, and calling them is just like calling a library with the autogenerated clients.
That being said, until a project like 1Backend matures, anyone who starts their startup on a microservices architecture instead of a simple monolitic one is out of their skull.*
I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen.
Don't be that startup! We managed to screw it up with 100+ million dollars in funding, which was (is) extremely exceptional in Europe. Of course the tech was only part of the reason for failure, still: there are better way of spending money than chasing bugs across hundreds of services and building instrumentation.
*Edit: this sentence of mine was very unfortunately worded and said the exact opposite of what I meant. Hopefully the tons of upvotes I got was because that the upvoters correctly inferred from the context that I advice you to start with a monolith, and not with microservices. Thanks.
Have you ever heard yourself and your tech colleagues talk? :P
No execution limits, since you can deploy and fine tune it to your environment. Can be stateless or stateful depending on configuration.