sspies
sspies on Hacker News
Thank you for creating dataclasses!
Location: Frankfurt, Germany / Languages: German (native), English (C2)
Remote: Only
Willing to relocate: no
Technologies: C, Kotlin, Rust, Python, eBPF/XDP, Rails, Typescript, VueJS, Kubernetes, Postgres, AWS
Résumé/CV: https://data.sloc.de/s/BJfHigA9B4RxcmD/download/CV.pdf
Email: [email protected]
Posted by
sspies on Tuesday October 29, 2024 @05:51PM
from the launch5k.com dept.
Hey there. Please go ahead creating an account using the form just below the hero. You should be able to provision a router right away.
Posted by
sspies on Wednesday January 25, 2023 @06:41AM
from the nextpacket.net dept.
I have been running my own postgres helm chart with read replication and pgpool2 for three years and never had major trouble. If you're interested check out
https://github.com/sspies8684/helm-repo
Actually, each tenant has just a view of the full table. There is no need to save the same routes for each customer over and over again. Furthermore, there is aggregation done before a route is installed on the switch.
We are working on this as well at
http://datapath.io. You can use multiple iaas providers using global elastic IP addresses that you can announce from multiple locations at the same time. If you want to participate in our beta please write to
[email protected]Best,
Sebastian
Posted by
sspies on Thursday November 19, 2015 @11:22AM
from the self-post dept.
The idea of datapath.io is to close a gap in today's computing environments: You can rent CPU, disk and memory in many flavors and use SDN to configure local network connections between your instances. What you cannot do is to configure your WAN connection: You are stuck with the IP transit offer of your provider. The mission of datapath.io is to enable businesses to configure their WAN...
I do not like fat jars. We use JVM + mvn + appassembler and pack the output into docker images. Not a big deal.
Transit providers sell access to the whole internet to us. We are in negotitations with them, but we will be more specific, once we have the commitments. Technically, we choose at least three different providers, so our appliance has a good basis of decision-making.
For the connection between your VPC and our appliance, we use the regular AWS DC API.
Traffic passes the appliance at the edge of the hosting provider. It takes congestion at all links and the appliance itself into account and re-routes accordingly.
Depending on the characteristics of the location, at least three very unsimilar transit connections are used.
We have seen providers set the TTL value to 300 seconds no matter what. Chrome has been caching names forever while running...just two examples
You cannot do graceful failovers with Route 53. This is, because DNS is a system of many dependend caching layers and the TTL value is not realiable.
Id adds one hop (our appliance) to the path. It tries to increase performance of your path by taking non-standard BGP metrics into account: congestion and latency
Posted by
sspies on Wednesday January 28, 2015 @03:08PM
from the datapath.io dept.
Do you run multi-region or maybe multi-provider setups? How do you migrate your instances from failed regions to healthy ones? How do you route users to the healthy regions? DNS? Do you think anycast could be an alternative?
Working on
http://datapath.io, which is an SDN solution for WANs. We open the internet routing system to DevOps and provide anycast routing to cloud users and remote transit provider bypass.
Could it be a business case to open up the routing system to users?
Posted by
sspies on Thursday July 03, 2014 @06:10PM
from the github.com dept.
Mainz, Germany - vastly.de
Currently, SDN use cases only affect the networks within datacenters or campuses. With vast.ly, we address the WAN, one of the last IT areas that exists out of reach for most developers. We think that developers deserve control about which network routes, ISPs and countries their content passes to reach users! It's time for the democratization of the internet backbone.
We are looking for talented software and network engineers. If you are interested to develop distributed software and already had a hand on OpenFlow, BGP or OSPF mail me sspies [AT] sloc.de
We offer a competitive salary and the possibility to work from remote.