6

Such question could be an indication of a poor architectural slicing into microservices. From What are Microservices?: These services are built around business capabilities and independently deployable by fully automated deployment machinery. The key point missed in such case would be their independently deployable aspect. The point could also be ...


6

Linux, without docker In Linux, you can create arbitrarily many IP address for each interface. A comment in https://serverfault.com/questions/328146/max-number-virtual-ip-addresses-per-nic reports success with 2000, and hearsay of 5000 successful IPs. So. Pick any Linux box on your intranet, which could of course be a VM, and create as many IPs on its ...


6

The concept of service discovery works like this: When a server, such as a database, starts up, it contacts a central registry and says Hi, I am a database, and these are my connection details. Then when a client starts up, it contacts the registry and says Hi, I need a database and the registry replies Here are the connection details and the client ...


5

I'll add an answer of what my solution is so far, but I'm still really interested in hearing how other organisations are solving this problem and the best practices they have. To resolve the issue of not having a consistent base to create projects for, my idea is to create a repository (repositories?) of boilerplates/templates and use cookiecutter as a tool ...


5

You should have 3 names when you're willing to do a blue/green deployment. Two set of names, one for blue, one for green, which will works as is, and a production entrypoint which will point to either the blue name or green name. The point of a blue/green deployment is to be able to test the full deploy before switching the clients entry point, so your ...


4

This is an area where Kubernetes has the correct model, there should be a load balancer between all systems which should have functional health checks. Once you start to add Nagios, Zabbix or other types of monitoring to the system you start to build a large state machine. This will break the loose coupling model and introduce inter-dependencies that ...


4

One commonly used solution(not container-specific) is to build a health check API within your service which tests all the functionality you want monitored (say availability of DBs and other dependencies) and the app itself, and returns some expected output (say < service >: < status >). You can then trigger alerts from a monitoring service like Nagios ...


4

Use a configuration management/automated deployment system. This is what these were designed for. Things like Kubernetes, Puppet, Chef, Ansible and Salt Stack are designed for just this purpose and can be utilized with Golden Master templates, kickstart scripts, Amazon AMIs or just a Docker container. This allows you to use default base templates and then ...


4

In your approach I see a few scalability problems - I'm judging from a Google App Engine (GAE) context, where scalability is achieved via breakdown of the work in small tasks/work items and strict limitation of the response time for a task execution: you're duplicating some piece of functionality: both scripts need to parse the same page, leading to your ...


4

Monorepos are nice because it eliminates the technical constraints between multiple projects. This does however open the door to other complications within your repository (naming conventions, cross-team dependencies, merge conflict increases, etc.). I do not have any experience with CircleCI, but I will provide some input based on other CI tools I have used....


4

We faced exactly the same choices for our live service that deploys a laravel API and multiple react apps. There is no generic correct answer to a question "what tool/provider is better?" as it depends on your circumstances. Cost is a particularly tricky question. Are we just talking about the cost of getting something live, or the cost of running an ...


4

I'm not altogether sure if there actually is a problem you're trying to solve, or whether you are looking for confirmation that you are on the right track. Some thoughts: Internally openshift should be able to allocate dedicated pods Sure. Add a post-build step in your CI pipeline which does the following: Fashion a .yaml or .json description of that ...


3

I recommend that you take a look at the NetworkX library for Python. With a script you could query Consul and build a graph of linked nodes which could be rendered to an image file and served with a web server. A Flask microservice for this would be fairly simple to set up and provide a very useful visualization of your microservices spiderweb.


3

Short answer Ideally, you should store secrets as environment variables, and retrieve them from a secrets management system like Hashicorp's Vault or AWS Parameter store. Long answer I saw your questions out of turn, and kinda touched on this in your other question: Again, there are many perfectly valid options for handling secrets: Chef vault, ...


3

This question is broad so if my answer is a little off-base feel free to add context and specific examples so that I have a better understanding. Using a machine image such as AWS' AMI would allow you to create a base or golden image, which you could then maintain and distribute or implement in your continuous delivery. Using this architecture you are ...


3

So both have their place. On one hand, putting service definitions in the package helps to keep the number of "moving pieces" to a minimum. On the other, it also requires a more complex package build process to at least some degree (like you would have to build your own packages for things instead of using distro packages). If you have the capability to do ...


3

Keep the DB containers separate. The concept of microservices and containers is to allow each part to be independently updated without introducing changes and outages to the rest of the application stack. Containers should also be running a single app per container to allow error detection and log gathering from that application. Each container is simply an ...


3

The metaphor of "mesh" is "many interconnected things". We might describe TCP/IP as a "mesh technology" as it is the technology that connects many things and performs useful services like resending lost packets and adapting to changes in available bandwidth. Modern "service mesh" technologies let you write basic code then wrap it in something readymade ...


3

I'll ignore your usage of the word "VM" here, since you have "Docker" in the title and "container" in the tags. One would indeed not deploy each microservice in their own VM, which would be an incredible waste of resources. But Docker is different. It is no VM. There is no virtualization. There is no extra layer between the processes running inside the ...


2

If nothing exists to easily mock Consul, have you considered spinning up a Consul service along with your other microservices? Consul can run in Docker, so this should be fairly straightforward if you use docker-compose and your apps can be configured to point to a different Consul endpoint. Once your docker-compose is configured to spin up all the ...


2

What you have installed, the ingress controller, is only one part of the story. The other part is an ingress: in an ingress you define what pods/services should receive traffic of what domain and request path. The ingress controller picks this information up, and dynamically reconfigures the underlying proxy, in your case nginx. You can find examples of ...


2

Ingress controllers allow you to not manually wire stuff up, that's the whole point. If you'd rather do it manually You could have an nginx array (either inside Kubernetes our outside of it) and just point to the ip/port of the services that expose your microservices. If you use an nginx array external to Kubernetes you'd have to use the externalIP service ...


2

Putting it behind a DNS name with a load balancer across multiple SDS servers is a good setup for reasonable availability. If SDS is down, Envoy will simple not get updated, so it's generally not the most critical failure -- new hosts and services simply won't get added to the cluster/endpoint model in Envoy. If you want higher availability, you set up ...


2

I have done this in the past using https://github.com/hashicorp/consul-template. What consul-template does it generate a configuration file (for nginx) based on a certain template you provide. And the values that it fills into this template are coming from the configuration stored in consul. Each time your micro-services register themselves in consul and ...


2

A good source for statistics could be stackshare.io. In general, polyglot services i.e. teams delivering different stacks could create silos, and additional overhead for diverse toolchains; nevertheless I consider that larger organizations have the polyglot situation organically because this type of thing is not always an issue of top-management. ...


2

I would suggest to only run stateless apps in k8s. One should run statefull apps like databases in dedicated database solutions like AWS RDS.


2

This question ties in heavily with your other question with where the secrets are set and where they retrieved from. I assume your question is asking about 'canary deployments' where you change the config for only a small portion of your apps, to test things out before deploying everywhere. If you follow the best practice of using the 12 Factor app's ...


2

Prometheus is a popular tool for monitoring microservices deployed to the cloud in combination with Grafana. For a better understanding of your inter-service issues, a distributed tracing tool is needed as well.


2

The 200 limit can be raised, however this is a grinding process that can take months. You work through customer support to get "elevated" as a client to more AWS privileges. Resources: - Worked under a company that specifically ran into this problem, took 8 months before that limit was lifted.


1

We had a similar situation wherein one of our applications had to be built, deployed and be up & running before the second one was. This was because application A has some functionality that should be executed prior to it being referenced via application B. The way we accomplished this was by building it into a single delivery pipeline. That way, all the ...


Only top voted, non community-wiki answers of a minimum length are eligible