Given that Kubernetes doesn’t offer full visibility into how services interact with each other I want to derive and map services automatically. For eg as shown in the below diagram, how can we derive that the payment service interacts with the cart service and cart service interacts with catalogue and redis.
So far what I had tried is,
kubectl get services command - This command only gives the list of services but does not hint on any communication happening between the services.
Tried Kubeview -> This plots only the deployment architecture and gives a graphical representation but mapping between various services is not derived.
So what is the easiest way to derive information about services interacting with each other and what could be the data source for this information in Kubernetes?
We faced this as well when we were building Otterize -- we needed something to map "who is talking to who" in order to bootstrap our solution, but every tool seemed to be ill suited for the task of simply creating a "network map" without all sorts of stuff we didn't want. We ended up rolling our own, and open sourced it: https://github.com/otterize/network-mapper .
It's based on combining information from DNS queries (actually just query responses) as well as detecting open connections, which gives you an IP-level network map, and then adding a simple resolution heuristic to derive a logical name-level map. You can read more details in this blog post, by one of the guys who built the tool: https://otterize.com/blog/kubernetes-traffic-discovery .
Hope this helps!
You can consider linkerd or other similar tools which offer service Observability
A service mesh like Linkerd is a tool for adding observability, security, and reliability features to “cloud native” applications by transparently inserting this functionality at the platform layer rather than the application layer.
service-mesh
For example, in below screenshot you can see how gate-way service interact with another service
It will also show how the request is going, amount of request with inbound and outbound
So in your case,if payment app is part of mesh you will able to see the inbound and outbound for the service along with requests info.
linkerd-install-helm
Service meshes have three main goals around interservice communication:
Connectivity
Security
Observability
Related
I got a question regarding namespaces and seeking your expertise to clear out my doubts.
What I understood about namespaces is that they are there to introduce logical boundaries among teams and projects.
Of course, I read somewhere namespaces can be used to introduce/define different environments within the same cluster.
E.g Test, UAT and PRODUCTION.
However, if an organization is developing a solution and that solution consists of X number of microservices and have dedicated teams to look after those services,
should we still need to use namespaces to separate them or are they gonna deploy in one single namespace reflecting the solution?
E.g if we are developing an e-commerce application:
Inventory, ShoppingCart, Payment, Orders etc. would be the microservices that I can think of. Should we deploy them under the namespace of sky-commerce for an instance? or should they need dedicated namespaces.?
My other question is. if we deploy services in different namespaces, is it possible for us to access them through APIGateway/ Ingress controller?
For an instance, I have the front-end SPA application and it has its BFF (Backend For Frontend). can the BFF access the other services through the APIGateway/Ingress controller?
Please help me to clear these doubts.
Thanks in advance for your prompt reply in this regard.
RSF
Namespaces are cheap, use lots of them. Only ever put two things in the same namespace if they are 100% a single unit (two daemons that are always updated at the same time and are functionally a single deployment) or if you must because a related object is used (such as a Service being in the same ns as Pods it references).
When creating a new Kubernetes namespace, a request is sent using the namespace API using the defined syscalls, and since Kubernetes has admin privileges, a new namespace will be created. The new namespace will contain specifications for the capabilities of a new process assigned under its domain.
In regards to your question above, yes you can keep services in different namespaces as long as they are able to talk together and render the services to the outside world as one piece.
Since all organizations are different, it is up to you to figure out how best to implement and manage Kubernetes Namespaces. In general, aim to:
Create an effective Kubernetes Namespace structure
Keep namespaces simple and application-specific
Label everything
Use cluster separation when necessary
We have a MicroService based Architecture where each service has a REST End point. These services talk to each other via REST.
However I noticed that a lot of developers have directly started calling these Services in the Javascript code of our Web Application. I want to know if it is recommended to access these MicroServices over the Internet OR they should be hidden behind a Facade layer. Of course all the end points are authenticated but all Web application users can find these end points once they do a F12.
thanks,
Abhi
I would not do that for the following reasons
Security. You are exposing your endpoint as is and it allow other people to know quite a lot about your endpoints then what you rather want them to know. Authentication is ok, but are still open for DDOS for your individual services, out of turn calls, unexpected load etc.
Service Discovery. By allowing access to the endpoints directly you are basically forcing dev to bind themselves with a given URL. This may work but since it is restricting you to make changes in future to your URL etc its better not to do it. By having a layer in between you will be required to change one url if ever required
Code Duplication There are quite a few cross cutting concerns when it comes to URL handling like request logging, https stripping, authentication, prevention of DDOS, request limiting etc. By having one common layer before your services you can manage all these at that one place rather than doing each of them for each services
If you think any of these are or could be major concerns that you should add an additional layer in between and route your internet facing api via that.
I use OmniFocus a ton and I'd really like to be able to connect my data there to other things (Zapier, IFFFT, Beeminder, etc). There's a lot of support for putting data into OmniFocus through these services, but I can't find any support for getting data out of OmniFocus.
In thinking about this, I realized my question isn't really about OmniFocus but rather about building a connector to a service that I don't own. So this is my scenario:
I have data on some publicly accessible web service (in the case of OF, it's Dropbox)
I want to build and host some sort of application that accesses that data and parses it and then provides a REST API that other servers can then query.
Ideally I'd like to make this service available to others - this seems tricky because they have to somehow enable my application to read their data.
I'm a fairly experienced software dev but I have zero experience with web applications or cloud applications. I'm not looking for a super in-depth answer here, but more of a general sketch of how this would work (or a confirmation that this really isn't feasible).
What is the difference between an SOA service and other kinds of services like an application or domain service ?
Have a look here. http://www.bennadel.com/blog/2385-application-services-vs-infrastructure-services-vs-domain-services.htm
Short answer
DDD Domain Services operate on Domain Entities. Usually where the work that needs to be done spans multiple Aggregate roots.
DDD Application Services drives workflow. For example if you want to do some work on a domain entity, the Application Service would be responsible to fetch the entity from the data store, call the domain service to do the work, do some work via an integration service if needed, and then lastly persist the change.
This is an interesting question since SOA is such as broad and overloaded term.
If we take SOA to mean any implementation that results in a mechanism to reach 'services' then even application and domain services will form part of SOA services. Application and domain services will even fall within the realm of micro-services although application services are usually surfaced through some integration mechanism.
I like to think of these things in terms of 'reachability'. WikiPedia:
In graph theory, reachability refers to the ability to get from one vertex to another within a graph
So, it depends on how reachable your code is. A bunch of domain services could, theoretically, form a service-oriented architecture.
The only differences is in how you surface your services.
I just successfully implemented a WF4 "versioning" system using WCF's Routing Service. I had a version1 workflow service to which I added a new Decision activity and saved it as a version2 service. So now I have 2 endpoints (with identical service contracts, i.e. all Receive activities are the same for both service) and a router that checks the content of a message (a "versionId" string on the object that all of my Receive's accept as an argument) to decide which endpoint to hit.
My question is, while this works fine when no changes are made to the service contract, how to I handle the need to add or remove methods from my service contract and create a version3 service? My original thought was, when I add the service reference to my client, I use the latest workflow service's endpoint to get the latest service contract. Then, in the config file, I change the endpoint I connect to to the router's endpoint. But this won't work if v1 and v2 have a different contract than v3. My proxy will have v3's methods and forget all about v1 and v2.
Any ideas of how to handle this? Should I create an actual service contract interface in my workflow solution (instead of just supplying a ServiceContractName in my Receive activities)?
If the WCF contract changes your client will need to be aware of the additional operations and when to call them. I have used the active bookmarks, it contains the WCF operation, from the persistence store in some applications to have the client app adapt to the workflow dynamically by checking the enabled bookmarks and enabling/disabling UI controls based on that. The client will still have to be updated when new operations are added to a new version of the workflow.
While WCF was young I heard a few voices arguing that endpoint versioning (for web services that is) should be accomplished by using a folder structure. I never got to the point of trying it out myself, but just analyzing the consequences of such a strategy seems to me as a splendid solution. I have no production experience of WCF, but am about to launch a rather comprehensive solution using version 4.0 of .NET (ASP.NET, WCF, WF...) and at this stage I would argue that using a folder structure to separate versions of endpoints would be a good solution.
The essence of such a strategy would be to never change or remove the contract of an endpoint (a specific version) until you are 100% sure that it is not used any more. While your services evolves you would just add new contracts and endpoints. This could lead to code duplication if one is not such a structured developer as one should be. But by introducing a service facade the duplication would be insignificant
I have been through the same situation. You can maintain the version by the help of custom implementation. save the Workflow Service URL in Database. And invoke them as per desire.
You can get the information about calling the WF Service with the URL by the client.
http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html
Hope this helps