I mean, I don't think that's a good argument - it costs you cents per user. Either way, I think you should charge however much value users can take from the product, completely unrelated to the cost.
At the moment though, being notified whenever my github repo is trending is a nice to have that gives me nearly 0 value as there's no actions I can take from that (other than share with my team :)). So I would try to find some other way to monetize it or to bring value to the users. Sorry for the harsh feedback.
Not at all harsh! Very valuable. Tbh it was really about just trying it out for now, its very arbitrary! :-) Do you have any suggestions on what exactly you'd like to do after you find out its Trending?
I don't believe the goal of Serverless Framework is necessarily to tackle vendor lock in, it's more about simplifying and somehow unifying the deployment process. Similarly to Terraform, it ends up being cloud specific in a lot of the details.
I agree that managed services provided by the cloud providers allow you to save money and make life easier. Our main goal is to enable people to use those that are common across clouds without locking themselves in. Of course some features are only available in some clouds, and you'll still have to deal with data fees if you want to move, but having your configuration cloud agnostic saves you a lot of time if you either want to move or want to go multi-cloud.
The cloud environment right now offer so many things that you'd be wasting your time recreating everything in plain linux instances.
At the end of the day using cloud native managed resources offer real advantages from time to market to pricing that we believe people should leverage as much as they can. Unfortunately it's also how you end up being locked in, so we are trying to tackle that.
Terraform is quite generic in its nature. At the end of the day it's just a state management tool. We decided to start there as it's the de facto IaC tool, but we are planning on launching a web portal soon and offer other ways to interact with Multy in the future such as an SDK and a CLI tool.
My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes.
Of course this was long ago before it was a final 1.0 version so I'm supposed to give some flex there, but it put me off badly enough that I'd never consider TF a SMT.
At the end of the day, as long as your tool is on top of TF, it will always be a function of the developer to understand all of the idiosyncrasies of not only the different cloud layers, but also the underlying tool. I think you're trying to solve a great problem, but basing it on TF doesn't help.
It is me, or is it weird that this has a hard constructor dependency on Constructs[1], which is pretty much undocumented?
At least in golang, this brings in some other dependencies and golang init() reflect code [2], which then depends on interacting with javascript!? [3]... something smells odd here.
It is a fundamental issue with TF. It wasn't designed to support that. It isn't generic, it is very specific with the providers. Bolting a generic provider running on top of that isn't going to solve the underlying problems with TF/HCL.
You even admit you haven't used TF in a long time, and when you did use TF it hadn't been 1.0 yet, which means you should fully expect breaking changes to take place.
In no way is your complaint valid for a technology that hadn't even been released yet, and you should know that.
And a "luddite" is just "a person opposed to new technology or ways of working." How many servers you do or don't manage is totally irrelevant to that. Terraform is new, you dislike it because it's new (my guess), therefore you are a luddite.
Did you think I was claiming you belonged to the group of 19th century English mill workers who destroyed factory machinery to protest those machines taking your job?
I really like the way GoLang handles concurrency. Sometimes it might be a bit verbose to create wait groups and whatnot but I think it makes it pretty readable.
Is there any reason people prefer the async/await primitives?
Async/Await makes your asynchronous code runs like synchronous code, synchronous code is more readable than asynchronous code. Your dont have to worry about goroutines execution order, communication, exceptions(leak, panic, deadlock). Besides, Async/Await can help your write less code.
That makes a lot of sense when you have real team (and most importantly) process boundaries. Isolate the code and deployment aligned with your team and process boundaries.
But if you're a company of 10-20 people all pretty much working on the same code? Microservices just adds complexity and overhead. Deployment, telemetry, documentation, version synchronization, tracing -- everything becomes more complex when you start creating boundaries between sub parts of your system.
For me, microservices are about boundaries. The question is what benefit that boundary provides for the team. For large companies where there are many discrete teams following different processes and release cadences, microservices might be worth the overhead. For small companies, it is wasted effort.
Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.
I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app.
One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices.
Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...
You have an app and just 3 microservices web + recommendation engine + payment gatway
This means that the team that handles recommendation engine can deploy as fast as they want while the payment gateway (which is brittle and mission critical) stays put.
If you have just a monolith then everytime the recommendation engine is tuned, the payment gateway code is also redeployed with possible downtime (contrived example but just to give you the idea)
> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.
Strong agree. The need to transition to microservices will sneak up on an organization -- and that's okay. It's surprising how much life you can squeeze out of a monolith.
For the bulk of the smaller companies the monolith is an excellent choice. For a smaller number of them decomposition of that monolith into a few (< 10 and usually < 5) services makes good sense. Typically the kind of project you are working on will suggest nice 'cut here' lines and if it does not then you're going to have to be a bit more creative. You could try going by entities or by processes or by large chunks of the project accessed by different people.
And then there are projects that grow way beyond the point where even that will keep them manageable, in which case microservices may well make sense. But the number of companies faced with challenges at that level is quite small relative to the total and the chances that you find yourself in one of those if you don't have a few hundred co-workers as developer is very small.
Oh! That's a good idea. I didn't think about that.
I think at some point I'll have a free plan for everyone (with limited features). I just need to finish implementing all the profile components and then enable only some of them for the free plan.
I struggle to see a notification being worth paying 5.99/month though