thorgaardian

19 ms·

1.
by thorgaardian 3y ago
A lot of people will argue that state helps protect against drift, but the real reason I find that you have to have state is to store values that won't be returned a second time and still construct and connect the graph of resources in
2.
by thorgaardian 4y ago
Looks awesome! I hadn't had the chance to dive into eBPF yet, but I had hoped someone would be able to use it in a clever way like this! I was digging through the docs and it looks like you have custom language detection. Did you consi
3.
Why distributed apps need dependency management(architect.io)
5 points by thorgaardian 6y ago|0 comments
4.
Creating your first microservice: NestJS(architect.io)
5 points by thorgaardian 6y ago|0 comments
5.
Credential cycling without cycling containers(architect.io)
4 points by thorgaardian 6y ago|0 comments
6.
How dynamic credentialing makes apps portable(architect.io)
3 points by thorgaardian 6y ago|0 comments
7.
Using Hashicorp Vault to enable credential cycling(architect.io)
5 points by thorgaardian 6y ago|0 comments
8.
The Feature Docker Forgot(architect.io)
6 points by thorgaardian 6y ago|0 comments
9.
The Importance of Portability(architect.io)
5 points by thorgaardian 6y ago|0 comments
10.
by thorgaardian 7y ago
Interesting use-case for it. Without prior knowledge of a solution like this I would have suggested you send the webhooks to a queue backed notification system (e.g. SNS backed by SQS) and subscribe to the event topic, but sounds must easie
11.
by thorgaardian 7y ago
That last paragraph is an interesting addition I handn’t considered actually, so great answer! While I’d be hesitant to use a 3rd party, hosted solution for this use case, I can also see how that affords you the ability to optimize fullfilm
12.
by thorgaardian 7y ago
What you described in the first sentence is commonly referred to as an API gateway - protecting ingress traffic into a publicly accessible service/app (e.g. Kong, AWS API gateway, Ambassador, etc). Lately there's been a lot more g
13.
by thorgaardian 7y ago
I’d speculate this is likely a result of one or both of the following: 1. A de-risking strategy. Investing early effectively discounts a future acquisition, but doesn’t go so far as to bet the farm on the businesses success. They would also
14.
by thorgaardian 8y ago
This is a problem I've seen at every company I've ever worked at. Everyone starts off thinking they'll have independence, but it's only natural to build on what already exists and thus you end up with complex dependency
15.
by thorgaardian 10y ago
Confirm.io | Backend Engineer | Boston, MA (ONSITE) | Full-time Confirm.io is an 18 month old, Series B funded SaaS startup providing APIs and SDKs to authenticate state and federally issued identity documents. Our team specializes in machi
16.
by thorgaardian 10y ago
Thanks for the suggestion! We're actually using a lot of k8s inspired processes to power the tool, and may end up building on top of k8s as we learn more about how other developers use snappi. Definitely a lot of synergies, and I'
17.
by thorgaardian 10y ago
I have and personally I'm quite fond of it, but it doesn't quite go far enough imo. Linkerd is very lean and requires virtually zero knowledge of how the underlying service it manages works, but the knowledge of interface contract
18.
by thorgaardian 10y ago
Looks just like that. As dstaten said, "just Promise.all but for microservices". I've been contributing to an open-source project called snappi.io - a microservice blueprint that includes very comparable dynamic RPC functiona
19.
Automating deployment in a microservice architecture(blog.snappi.io)
6 points by thorgaardian 10y ago|0 comments
20.
Single and separated – the way responsibilities should be(medium.com)
7 points by thorgaardian 10y ago|0 comments
21.
Service location and dependency injection in a microservice architecture(blog.snappi.io)
6 points by thorgaardian 10y ago|0 comments
22.
Microservices interfaces – Normalizing communication between services(blog.snappi.io)
6 points by thorgaardian 10y ago|0 comments
23.
by thorgaardian 10y ago
> I think that standardisation should happen at the level of the stack/component (not at the application level). Most application developers don't know enough about specific components like app servers, databases, message queue
24.
Microservices are a smart way for apps to scale, but aren’t quite smart enough(blog.snappi.io)
3 points by thorgaardian 10y ago|0 comments