FreeHugs · HackerTrans

For the load balancer solution, a lot more is needed then to just rent a load balancer.

Example: What do you expect to happen when the server with your DB goes down? Just send the next UPDATE/INSERT/DELETE to DBserver2? Which is replicated from the DBserver1? When DBserver1 comes back, how does it know that it now is outdated and has to sync from DBserver2? How does the load balancer know if DBserver1 is synced again and ready to take requests?

Even if you set up all moving parts of your system in a way that handles random machine outtages: Now the load balancer is your single point of failure. What do you do if it goes down?

FreeHugs

6 lat temudiscuss

    What happens when the IP address changes?

Changes how? It's not as if the IP of a server magically changes out of the blue.

    Why re-invent DNS?

There is no reason to re-invent DNS. Each docker container will have to have the info where the other containers are. So you could write that into /etc/hosts of the containers for example.

    Also, how do you protect these services
    from unauthorized access?

You need to do this no matter if you use Kubernetes or your own config scripts.

FreeHugs

6 lat temudiscuss

    If you have microservices then you need
    a way for services to discover each other

Why not run them in docker containers with fixed IPs?

FreeHugs

6 lat temudiscuss

If your physical hyp dies, how do you redirect your traffic to a different one?

FreeHugs

6 lat temudiscuss

A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second on a single $20/month VM. And in my experience from the last years, VMs have uptime >99.99% these days.

What made you settle on a multi-machine setup instead? Was it to reach higher uptime or were you processing very heavy computations per request?

comments