HNHacker News
TopNewBestAskShowJobs

sspies

47 karma · joined June 1, 2014

submissionscomments
sspies··on Design Pressure: The Invisible Hand That Shapes Your Code
Thank you for creating dataclasses!
sspies··on Nextpacket: Bare-Metal Routers for the Network Edge
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.
sspies··on Running Postgres in Kubernetes [pdf]
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
sspies··on How We Run BGP on Top of OpenFlow
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.
sspies··on TCP Over IP Anycast – Pipe Dream or Reality?
I can fully agree with your experience using DNS failover vs anycast failover. Made a video of how I implemented anycast https://www.youtube.com/watch?v=tsXpQHi7Udo
sspies··on TCP Over IP Anycast – Pipe Dream or Reality?
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 beta@datapath.io

Best, Sebastian

sspies··on Capsule Shield: A Docker Alternative for the JVM
I do not like fat jars. We use JVM + mvn + appassembler and pack the output into docker images. Not a big deal.
sspies··on Beej's Guide to Network Programming (2012)
+1 for Unix Network Programming. http://www.amazon.com/UNIX-Network-Programming-Richard-Steve...
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
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.
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
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.
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
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
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
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.
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
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
sspies··on Datapath.io: Provider-Independent Elastic IP Addresses
Nope
sspies··on Microsoft Azure Outage
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?
sspies··on YC W15 emails are out
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.
sspies··on If net neutrality falls, what happens next?
Could it be a business case to open up the routing system to users?
sspies··on Ask HN: Who is hiring? (June 2014)
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.