I don't know if I would call it that but I have a few:
1. I live 20mi from my office, I prefer to use my bike (bicycle) over any other means of transportation. I hate riding Lyft/Uber, driving is insanely stressful at times. I like the time on the bike and it adds a ton of value in my life in general. It is quirky because I never really take the 20mi route and often prefer the longer routes.
2. I wake up at the same time every single day. 4:45 am. Wether it's the weekend, weekday, doesn't matter, I wake up and I just get up of bed.
Again, I don't know if I would call these quirky but those are the ones I can think of.
My goal was to create a toolchain that is battle-tested production-ready and pluggable to help companies deliver code faster and worry less about operations.
I started it in my spare time and worked on it for about 3-4 months.
I still believe there is a HUGE need for this and that many companies are solving the same problem over and over again. It's super expensive to build.
The challenge is catching companies at the right time. It needs to be as easy to start as it is with Heroku and a Rails application BUT you should be able to grow and scale up with batteries includes (unlike AWS).
Another challenge is the fragmentation of development tools/frameworks/configurations and cycles.
We hired multiple bootcampers. I can definitely say the experience this time was good and the employees are successful.
It does take time and patience (and a path), it includes quite a bit of mentoring and guidance.
It's also about expectations. You can't expect them to be "in the know" of everything and it requires more management resources in the beginning. If the company is committed to it and not doing it as a means to save money, it can most definitely work.
I spent a good chunk of the last 10 years in a travel startup that targeted consumers.
I am unsure of the business model here but I can only imagine it's a pay-per-click from the big OTAs, mainly for hotels.
The main problem with consumer travel is the fierce competition you are facing, Google is absolutely annihilating the search results in their favor, disgustingly so in the US and even worse in US on mobile.
This leaves a startup like this in a tough spot, how do you acquire users?
If you think about paying for them, you are in for a world of hurt, you can spend 1.8$ to get .8$ back for a hotel booking and it's absolutely an uphill battle to scale that up.
I searched the name on Google and I saw the HN page, you two seem to have built a travel business before, you likely know a lot of the difficulties, but in my experience, trip planning scaling is a lot harder than what it seems, especially if you want to monetize it.
If you don't mind sharing, what is the revenue model for TravelChime?
We plan on making money via affiliate links to start with! It's a model we're familiar with in our past projects.
Having worked in travel for a while now, we realize that paid marketing is incredibly competitive. Based on that understanding, we've actually never spent a single cent for paid marketing on our previous projects.
For growth: We want to just provide a really good central tool for people to plan their trips, and an easy way for those people to share plans with their friends. We think travel is inherently social, and that's something we want to do well (while respecting privacy).
Companies use this jargon of `breakthrough in the space`, it has been nonsense since Apple introduced FaceTime as a breakthrough in the space even though you had video chat for ages before that.
> “But you cross an ethical line when you copy an idea without any meaningful differentiation and attempt to call it your own, let alone attribute the source of your inspiration.
This, to me, is complete BS. I mean, yes, it would be nice if PMs would actually attribute it and then in companies press release it would mention that but that's just a very naive expectation.
Yes, it is naive to expect businesses not to tell lies and to refrain from representing other people's ideas as their own. But it is also naive to expect people not to complain about it.
It's basically a non-standard use of IPv6, which is to ideally issue a /64 to each end point. Personally I don't mind, but some people think they need 18,446,744,073,709,551,616 addresses per host.
The idea being with all those addresses you can create subrouters to manage your network topology. Unless you're doing some weird tunnelling setup through your VPS, I can't see why you'd need or want such a huge block.
People complain about only getting a /64 on their home routers.
Blocking certain outbound traffic is another matter: that really stinks.
Who do you use instead? I'm really disappointed by their IPv6 support and undocumented egress firewall rules, but found other providers to have their own set of problems. Would love suggestions.
You are being downvoted but I think it's a pretty legitimate question and the answer to it is: Yes.
If you want to have a united interface to multiple services behind the scenes and incorporate ACL or any kind of top-level resource management, GraphQL is a great way to go about doing that.
> If you want to have a united interface to multiple services behind the scenes and incorporate ACL or any kind of top-level resource management, GraphQL is a great way to go about doing that.
I like GraphQL outside of these points as well because it's more opinionated than REST. It means you can get on with things instead of having long disagreements about what is and isn't RESTful.
What is the reasons for a backend service to delegate it’s authentication/authorisation to the graphql in front of it. Making the graphql server a super user for the service
Sounds wrong to me
They advocate one graph, because it's too hard to merge graphs in parent-child (many-to-one, many-to-many) relationships (recursively) in a flexible way.
This is purely because of technical limitation of GraphQL IMO.
E.g. each frontend team/application owns its own schema owned by these teams. They can compose the backend services however they wish—and whatever is the most natural representation for their domain.
Yup, we see this pattern a lot. You get the benefits of fewer bytes on the wire, typed APIs, elimination of data fetching code, etc.
But it leaves a lot on the table. The bigger wins come when new features can draw from all your data (in unanticipated combinations) without new API or services development, when you can make new data available for every team's use just by plugging it into the central graph, and when you have a birds-eye view of exactly how all your data is being used so you know where to make further investments.
Don't know if this is related, but after initially being excited to hear about GraphQL, I was very disappointed to find that it doesn't seem to offer any way to (in effect) express joins.
Am I missing something here? Has this been addressed?
I would concur. The BFF pattern works really well with GraphQL.
I think 'One Graph' makes sense if that's how you model your data under the covers (e.g. Facebook's graph store)—but if you're in a service-laden world, it makes far less sense.
Likewise. Sometimes it doesn't make sense to stitch graphs together. We have a gateway that proxies different services and exposes their graphs individually.
Access could be limited by authorization. Role in JWT for instance.
You can't control malicious clients so I don't think the access part holds much water.
I think they are advocating a monolith deployment to maintain contracts across ownership and client expectations as a best practice vs the version management of multiple graphs requiring different cross sections of data for each client. It helps keep it consistent.
One graph does not mean that the different parts have to know about each other. The different parts can be merged together without them knowing and form a single endpoint that the user can query without knowing where that data is coming from.
I agree, if your data spans multiple logical core domains you could potentially have one entry per core domain, auxiliary data that spans domains can be supplied by each core domains issuer in a manner that is logical for that domain.
Just out of curiosity, do you have multiple independent teams working on your app? Do you use a monorepo, and if so, do you feel like it makes refactoring and bug fixes more difficult?
Your last sentence is something I have been thinking about for a very long time.
I have been in Devops since it before it had a name and I see many companies solving the same problems.
Like ths auto-scaling post. That's not the first company to deal with it (nor the last). Providing a set of tools can be very beneficial but so hard to dial down.
I have a very big itch around solving this problem.
There are many limitations that you need to "read between the lines" with AWS auto scaling.
For example, we have daemons reading messages from SQS, if you try to use auto scaling based on SQS metrics, you come to realize pretty quickly that CloudWatch is updated every 5 minutes. For most messages, this is simply too late.
In a lot of cases, you are better off with updating CloudWatch yourself with your own interval using lambda functions (for example) and let the rest follow the path of AWS managed auto scaling.
There is also a cascading auto scale that you need to follow. If we take ECS for example, you need to have auto scaling for the containers running (Tasks) AND after that you also need auto scaling for the EC2 resources. Both of these have different scaling speeds. Containers scale instantly while instances scale much slower. Even if you pack your own image, there is still a significant delay.
The effectiveness of dynamic scaling significantly depends on what metrics you use to scale. My recommendation for that sort of system is to auto-scaled based on the percent of capacity in use.
For example, imagine that each machine has 20 available threads for processing messages received from SQS. Then I'd track a metric which is the percent of threads that are in use. If I'm trying to meet a message processing SLA, then my goal is to begin auto-scaling before that in-use percentage reaches 100%, e.g., we might scale up when the average thread utilization breaches 80%. (Or if you process messages with unlimited concurrent threads, then you could use CPU utilization instead.)
The benefit of this approach is that you can begin auto-scaling your system before it saturates and messages start to be delayed. Messages will only be delayed once the in-use percent reaches 100% -- as long as there are threads available (i.e., in-use < 100%), messages will be processed immediately.
If you were to auto-scale on SQS metrics like queue length, then the length will stay approximately zero until the system starts falling behind, and then it's too late. If you scale on queue size then you can't preemptively scale when load is increasing. By monitoring and scaling on thread capacity, you can track your effective utilization as it climbs from 50% to 80% to 100%; and you can begin scaling before it reaches 100%, before messages start to back up.
The other benefit of this approach is that it works equally well at many different scales; a threshold like 80% thread utilization works just as well with a single host, as with a fleet of 100 hosts. By comparison, thresholds on metrics like queue length need to be adjusted as the scale and throughput of the system changes.
From a bird's eye view, you also need to figure out what costs you more.
For example (and I know nothing about the use-case of OP, can only estimate), you might be able to buffer requests into a queue and have it scale up slower.
You might have auto scaling that needs to be close to real time and auto scaling that can happen on a span of minutes.
Every auto scaling needs to also keep in mind the storage scaling, often you are limited by the DB write capacity or others.
AWS employee here. If you are able to achieve consistent greater than 50% utilization of your EC2 instances or have a high percentage of spot or reserved instances then ECS on EC2 is still cheaper than Fargate. If your workload is very large, requiring many instances this may make the economics of ECS on EC2 more attractive than using Fargate. (Almost never the case for small workloads though).
Additionally, a major use case for ECS is machine learning workloads powered by GPU's and Fargate does not yet have this support. With ECS you can run p2 or p3 instances and orchestrate machine learning containers across them with even GPU reservation and GPU pinning.
I'm not totally up to speed on ECS vs EKS economics but it seems like EKS with p2/p3 would be a sweet solution for this. Even better if you have a mixed workload and you want to easily target GPU-enabled instances by adding a taint to the podspec.
ECS GPU scheduling is production ready, and streamlined quite a bit on the initial getting started workflow due to the fact that we provide a maintained GPU optimized AMI for ECS that already has your NVIDIA kernel drivers and Docker GPU runtime. ECS supports GPU pinning for maximum performance, as well as mixed CPU and GPU workloads in the same cluster: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
Apart from pricing and the potential to overcommit resources on EC2-ECS, there are a couple of other differences.
One is your options for doing forensics on Fargate. AWS manage the underlying host so you give up the option of Doing host level investigations. It’s not necessarily worse as you can fill this gap in other ways.
Logging is currently only via CloudWatch logs so if you want to get logs into something like Splunk you’ll have to run something that can pick up these logs. You’ll have that issue to solve if you want logs from some other AWS services like Lambda to go to the same place. The bigger issue for us is that you can’t add additional metadata to log events without building that into your application or getting tricky with log group names. On EC2 we’ve been using fluentd to add additional context to each log event like the instance it came from, the AZ, etc. Support for additional log drivers on Fargate is on the public roadmap[1][2] so there will hopefully be some more options soon.
At least one is, that you get to use the leftover CPU and memory for your other containers when you use an EC2 instance. With some workloads this lets you to overcommit those resources if you know all your containers won't max out simultaneously.
Edit: another one is that you can run ECS on spot fleet and save some money.
Fargate is orthogonal to ECS and can be used together. The difference is that instead spinning VMs as hosts and configuring them for ECS and worrying about spinning just right amount of them, you select fargate, which does all of that behind the scenes (kind of like lambda), but the VM instances provided by fargate are a bit more expensive.
1. I live 20mi from my office, I prefer to use my bike (bicycle) over any other means of transportation. I hate riding Lyft/Uber, driving is insanely stressful at times. I like the time on the bike and it adds a ton of value in my life in general. It is quirky because I never really take the 20mi route and often prefer the longer routes.
2. I wake up at the same time every single day. 4:45 am. Wether it's the weekend, weekday, doesn't matter, I wake up and I just get up of bed.
Again, I don't know if I would call these quirky but those are the ones I can think of.