3,433 karma · joined September 27, 2010
Uber is still at risk to lose their current monopolistic world market share, everybody knows it (Travis too), and they need to work and fight hard 24/7 to retain it. IPO is a distraction.
Ponzi schemes are only bad if you are in the last batch of investors. The first ones do get a nice return (otherwise the scheme itself would not last long).
A smart investor could decide to put some money in a Ponzi scheme, as long as he knows what's his number in line, deciding to gradually disinvest some % as times goes on in order to collect the enormous gains.
Without an abstraction layer and proper planning, different teams will start building microservices with lots of common functionality like security, authentication, logging, transformations that over time will increase the complexity and the fragmentation of the entire system. Ideally you would want services to simply receive a network request, serve a response, and delegate all the complimentary middleware execution somewhere else, like an API gateway.
Traditionally API gateways in a pre-container world were centralized in front of an API, but modern API gateways can also run in a decentralized way alongside your server process, to reduce latency.
Then once you have everything in place, you end up with a bunch of microservices that your developers (maybe belonging to different departments) will have to use. You will need to fix discoverability, documentation and on-boarding. Some of these services may be also opened up to partners, so there's that too. Traditionally developer portals were only being used for external developers, but they are becoming a requirement for internal teams as well.
Finally, you need to carefully monitor and scale your services. Without a proper analytics and monitoring solution in place it will be impossible to detect anomalies, scale horizontally each service independently, and having an idea of the state of your infrastructure.
Generally speaking running microservices can be split in two parts:
1. Building the actual microservice.
2. Centralizing common functionality, documentation/on-boarding and analytics/monitoring.
Most of the developers or project managers I regularly speak to tend to forget the second part.
Disclaimer: I am a core committer at Kong[1]
He is a nice guy, he helps people, and he has strong passion in hating the failure. Is Uber too aggressive? Maybe yes - but you need to be aggressive to fight regulations, governments, taxi cartels and the like all over the world.
Turns out eventual consistency doesn't work well with chat apps.
Any pre series-C company, which is still adjusting the product/market fit and fighting for survival will not be able to afford the lack of creativity that a core local engineering team provides, and the higher communication costs associated to working remotely (especially in different time-zones).
It maybe can work for non-core engineers, or for remote core-engineers that have given up to their chances to build up a career and level up, since those spots will be taken by folks who work locally next to the leadership team.
Most likely if a remote engineer turns out to be spectacular, he will receive an offer to move locally under the same roof in order to unlock his career.
They have tried once, and it's called AWS Elastic Beanstalk.
Anyways it would only mitigate the risk without fixing the root problem.
Kong[2] uses it extensively, by leveraging the underlying OpenResty[3] framework.
[1] http://luajit.org/ext_ffi.html
Taxies are a regulated monopoly, definitely not a healthy market. Hordes of consumers moved to a better alternative like Uber at the first chance they had.
> Uber is just a criminal organization acting solely out of greed.
Uber, whether you like it or not, has revolutionized personal transportation for better. Consumers are using Uber because Uber is a better product. That's a fact.
So the client will keep working even if a few months from now you want to change the link to something else. A simple example: if retrieving articles can be done by requesting this link "/articles", I can potentially change it in the future to "/v2/articles" and the client would still work.
$ time
real 0m0.002s user 0m0.000s sys 0m0.000s
When the Review approval is missing or required, please make it clear in the "Pull Requests" list-view by updating the color of the little dot and it's popup description.
Right now the colored dot and its description are only including "Checks" but not "Reviews". It would be nice to have a clear indicator of which Pull Requests are missing a review just by looking at the list.
In my experience meetings and management time grow proportionally, since meetings are a good way to talk with the team, set expectations and review the results. Or, in other words, some meetings == management.