eicnix

The employee or contractor has the "Urheberrecht"(german law that states the rights of a content creator) for any code he wrote during his work. Additionally the employer automatically gains the "Nutzungsrecht" (rights to use, distribute and duplicate the work).

While the employee still has the creator rights he cannot exercise them since the content contains trade secrets.

In the EU you would need the explicit permission of the user to share their data with the new parent company.

Which isn't a huge issue since most users will accept any data privacy declaration.

Somebody wrote a blog article about this: https://thehftguy.com/2017/09/26/hitting-hacker-news-front-p...

The best solution for this would be to enable similar data protection laws like the ones that will become active in 2018 in the EU.

A breach of this law would cost a company 2-4% of their revenue as a fine. Seeing how these big companies operate there would be a lot of breaches.

You might want to look for sites / agencies hiring especially for contractors that travel to the client onsite.

At those positions you are able to charge much more than the basic bid for project website. Plus you don't have too deal with the masses of offshore devs that underbid you. The downside is that you need to travel to your client which means sleeping in a hotel 3-4 nights a week

Nowaday you would often run containers with a container network(flannel, calico, etc.) that assigns an unique IP per container thus avoids conflicting port mappings regardless how many containers with the same port run on a single host.

Do you have the name or a link to one of these studies?

My main reason to run basically everything in Kubernetes is abstraction between resources and applications and standardization of deployments.

While you can achieve the same with various other ways like good configuration management and virtual machines I have found that the overall cost of creating/running and monitoring deployments on Kubernetes is smaller than on a traditional VM based solutions.

Why shouldn't you run databases on it? Ive been running larger databases(10tb+) on it for some time.

If your database can deal with failure of single node and uses network storage it's totally doable to run databases on Kubernetes.

Take a look at Patroni on how to run Postgres on IaaS or Kubernetes.

Sure: https://www.amazon.com/Practical-Guide-Commands-Editors-Prog...

There is also a 3rd Edition which was released in 2012.

https://www.amazon.com/Practical-Guide-Commands-Editors-Prog...

You could pay for Google apps for work and don't have your data indexed. So it's really more a question how much money / work to switch to another provider is your data worth to you?

I believe its more like "write once, run everywhere except for mac". Microsoft is working on running linux containers natively on Windows.

Thats probably true but you could enforce it at a corporate level with a whitelist of apps that should have access to certain permissions.

@Proxy I am not sure what the issue is that you are facing. kubectl proxy should create a tcp-proxy from your loopback device to the pod. So there should be no http_proxy involved. If you think a kubernetes component does not respect the no_proxy setting you should create an issue.

@storage If you want to move your disks with your containers you need an additional storage system(SAN, cloud provider or distributed storage in kubernetes). Then you create persistence volumes in kubernetes that references a disk from the storage provider. This allows you to assign this disk to a pod with a persistence volume claim. The disk that is linked to the container through persistent volume and persistent volume claim will be moved on the same node the container is scheduled. If you want to run stateful workloads on kubernetes I would advice you to use a storage system. You can use local disks but you loose some of the flexibility that you gain from kubernetes by tying your containers to certain nodes with the data. There is also work being done on improving the handling of local storage to treat it more like a resource and introduce separation by using local volume per kubernetes local disk volumes.

It seems you have not discovered the wide possibilities of kubernetes yet :)

How are you setting up your cluster?

A) Kubernetes abstracts the networks solution so people can choose between multiple implementations. Some people already use openstack and want to use their openvswitch network for their containers others want to use a pure container network like flannel. Kubernetes distributions usually come with a integrated network solution.

B) You can still retrieve the logs from a container is CrashLoopBackOffState. You can even retrieve the logs from the previously failed container by using the `kubectl logs <container> --previous`. Applications can write information about their failure to /dev/termination-log which can be used to debug the failure.

C) You can define the port yourself otherwise kubernetes defaults to a random port to avoid port conflicts. The recommended way to expose HTTP services would be by using ingress.

D) You can run an instance on every node by using a daemonset.

E) Are you talking about outbound traffic from your containers to an external system? You would need to configure this in the container engine and the container itself. I had little problem doing this in an enterprise environment that required an http proxy for all external communication.

F) You can attach you existing SAN solution over iSCSI, fibre channel or even NFS. Another solution would be to run a distribution storage like ceph or glusterfs in kubernetes for kubernetes. You then provision persistent volumes that are attached to the node your pod is running on. If your pod is rescheduled the volume will be moved too.

G) If you have resource requests/limits set kubernetes will not schedule your pods if you have no resources available.

You can run distributed stateful workloads on kubernetes with local storage and disable rescheduling when the node goes down. This means that you need to manually migrate/restart workloads if a node goes down. There is work being done on improving handling local node storage https://github.com/kubernetes/community/pull/306 but it doesn't scale as well as network storage.

If you have an existing SAN solution you can connect to it via fiber channel over iSCSI.

When you are running on your own hardware you usually have multiple options for storage:

- Use the local node storage although this is very simple but can get complicated on more complex installations

- Connect to your existing storage solution using ISCSI or NFS

- Running your own distributed storage solution on top of Kubernetes for Kubernetes. e.g. https://github.com/rook/rook

There is currently some work being done for improving local storage usage in k8s. https://github.com/kubernetes/community/pull/306

Additionally k8s can be configured to restart pods on the same node so you can use the local node storage for persistence and rely on your DB for replication.

How does this compare to other HA postgres products like stolon or Postgres-XL?

There is the Onyx Book Max which is a 13.3" grayscale Android tablet with an e-ink display. Which is kinda "cheap" with around $750 compared to other large e-ink devices.

I use it to read PDFs and take notes with a stylus pen.

https://www.amazon.com/Onyx-Max-13-3-Flexible-Handwriting/dp...

I agree that the communication you described isn't completely REST style but rather "just" using HTTP as an application protocol. There is no real downside in doing so but it shouldn't be called REST.

REST based on the Richardson maturity model[1] involves:

Level 0: Using HTTP as the transport protocol: e.g. SOAP

Level 1: Identifiable objects: e.g. /object/object_id

Level 2: Using HTTP as the application protocol: e.g. Using POST to create new objects and DELETE to remove them

Level 3: HATEOAS

[1] https://martinfowler.com/articles/richardsonMaturityModel.ht...

The GCP services are usually within their SLA target so I don't see the problem with the incidents. So you know what you buy and can take actions if you need a higher SLA for your application.

https://status.cloud.google.com/summary tells a different story or do you have other information?

I have used GCP for some time without being affected from any incident.

Which is coincidently down.

GCP also provides globally distributed load balancers which reduces the overhead to deploy is multiple regions.

Can you talk about the additional latency between your front-page and backend by running in different cloud environments?

How do you deal with a availability zone failure of a cloud provider?

Single droplets are a single point of failure and have a limited availability. You can take actions to mitigate this SPOF like running multiple droplets and distributing requests by adding all of these droplets to your DNS configuration also known as DNS round robin.

Another solution is too pay Digital Ocean to provide network endpoints that are more available and allow you to provide a higher availability for your application. Because DO works on different level of abstraction they have more possibilities to provide this availability.

I have some question about your loadbalancer and your plans about kube on DO:

- Does your loadbalancer support HTTP/2 yet?

- Can you share your scripts for setting up a HA kube cluster on DO?

- Do you plan to provide a kubernetes cloud provider for DO?

Having a DO cloud provider and standard scripts would probably help the adoption of kube on DO. Without a cloud provider I can't many benefits compared to traditional bare metal providers which are still cheaper.

How does Caddy compare to nginx performance wise? I have a similar setup like you running on nginx.

For loadbalancers I mainly care about performance and not usability of the configuration language.