We can find in Dapr Quickstarts that with Dapr
you'll be enabling distributed tracing on an application without changing any application code or creating a dependency on any specific tracing system.
But the example presented uses code to call dapr api.
I tried to make some calls without calling the Dapr sidecar and they don't show up in the tracing.
Does this mean it only tracks calls made to/with the Dapr sidecar?
In that case, I'll need to change a lot of application code to add observability to an existing application that already uses direct calls, won't I?
You are correct Ocimar. Dapr can track only calls made to/from the sidecar. But you wouldn't use Dapr only for tracing purpose. Ideally you would use Dapr for some of the other features such as binding other external systems, service invocation, pub/sub, resiliency, etc. And you can do that, but not having any Dapr specific dependency within your application.
If you are using Dapr for these reasons, you can configure it and add tracing w/o changing your application. And the beautiful thing is that, tracing is not only for service-to-service invocation, but also bindings...
Related
I have a single screen desktop application developed in Java. It is a tool to convert files, given a file in .abc format, the tool converts it to .xyz format. Basically the tool works offline and acts as a translator to convert file from one form to another.
So now, to improve the infrastructure, there are discussions to move the tool to Kubernetes or to provide REST services for the file conversion. I completely have no idea about the containers nor the REST APIs as I am a front-end developer.
More about the tool, as I told earlier, the tool is a single page application, very light doing very minimal job, totally used by 200 users approximately. So, this being the shape and size of the application, which one would be the best approach to go with and why? Basically, I am looking for a short evaluation report of Kubernetes vs REST service and architecture recommendation with reasons.
Currently your application is a standalone application which is quite an old concept.
I can mention high-level changes needs to be done when your file conversion logic would be exposed over Rest Api in Kubernetes world.
you can go through one by one following mentioned areas to get a better understanding design-wise:
java code would be a backend code and its public methods that take inputs from UI actions will be exposed over rest API.
There are multiple rest API's (jersey, rest easy, etc or spring/spring-boot framework also provides rest API support) that you can go through any of them to get an understanding.
once your backend is exposed over the rest API then it needs to be containerized means your backend will be running under the container. Can go through docker documentation and can build one sample containerized app. There is huge material present in this area.
once your backend is containerized then it will be installed in a Kubernetes cluster
Kubernetes is basically a container orchestration tool and it's quite a wide thing. you can through its official documentation for basic understanding.
SPA will be running on a client machine like today also you are able to launch from your desktop but it will communicate with the Kubernetes cluster where your application is presently packaged in a container.
References:
docker :
https://docs.docker.com/
Kubernetes :
https://kubernetes.io/
I will be building an Android application (not a game) soon. I heard of containerized development and Docker/Kubernetes but I'm not well-versed in its functions and use cases.
Why should I build my Android application with Kubernetes?
Your question can be split up into two parts:
1. Why should I containerize my deployment?
I hope by "deployment", you are referring to the backend services that serve your Android application; not the application itself (not sure how one would do that...). Here is a good article.
Containerization is a powerful abstraction that can help you manage both your code and environment. Setting up a container with the correct dependencies, utilities etc., and securing them is a lot of work, as is the case with any server setup. However, once you have packaged everything into a container, you can deploy said container multiple times and build on-top of it. The value of the grunt work that you have done in the past is therefore carried forward in your future deployments; conversely, so are the bugs... Additionally, you can also leverage the Docker ecosystem and build on various community contributions greatly accelerating your workflows.
A possible unintended advantage is also protection against configuration drift. Whenever services fail or your application crashes, you can simply restart your container, and a fresh version of the service will be created again. However, to support these operations, you need to ensure that your containerized service behaves nicely across restarts and fails gracefully. There are many other caveats and advantages that are not listed here; you can find more discussion on Google.
2. Why should I use Kubernetes for my container orchestration?
If you have many containers (think in the order of 100s), then using a single-node solution like Docker/docker-compose to manage them becomes tedious.
If only there was a tool to manage across multiple nodes, implement service discovery between your nodes, have fault tolerance (ie. automatic restarts, backoff policies), do health-checking of your services, manage storage assets, and conveniently expose your containers to the public. That tool is Kubernetes.
Here is a more in-depth intro.
Hope this helps!
I want the ability for clients to create their own stateless services and be able to upload/publish it to join an existing cluster. Is this doable? I understand that I need to update the application manifests dynamically but not sure how or if this is possible programmatically without side effects of the service fabric runtime processes.
The workflow is to upload the code (zipped file maybe or whatever) via an API gateway.
The first thing to keep in mind is that you do not deploy individual services to a Service Fabric cluster. You deploy applications, which can contain one or more services.
So the key question to ask is whether you need the new code to be integrated with an existing application type or not. It sounds like what you're trying to do is just enable multiple clients to deploy independent applications on a shared Service Fabric cluster, in which case you would not be modifying existing application types, but deploying entirely new ones.
Thus, you would need your API gateway to dynamically generate application and service manifests, combine them with the client-provided code to create an application package, then copy, register, and create those applications in the cluster. As far as the Service Fabric runtime is concerned, this looks no different than if you had deployed an application type built and packaged in Visual Studio. Processes running existing applications are not impacted.
I see these both in Bluemix, but what is the difference between them?
Cloud Foundry and OpenWhisk are two Bluemix Compute models that a developer can used to power an application's workload.
I'll give a very high-level summary of both services and when I would use them...
Cloud Foundry
IBM Bluemix was originally based off Cloud Foundry's open technology. It is a cloud computing platform as a service that supports the full lifecycle, from initial development, through all testing stages, to deployment.
Cloud Foundry has a CLI program called cf which is the primary tool to interact with Bluemix (or Bluemix provides a web GUI for this).
Cloud Foundry introduces the concepts of Organizations that contain Spaces which you can think of as workspaces. Different spaces typically correspond to different lifecycle stages for an application.
Cloud Foundry introduces the concepts of Services and Applications. A Cloud Foundry service usually performs a particular function (like a database service), and an application usually has services and their keys bound to it.
OpenWhisk
OpenWhisk is a brand new IBM Cloud developed distributed event-driven compute model.
It has a distributed automatically scaling serverless architecture that executes application logic on events.
OpenWhisk also has a CLI program called wsk which can be used to run your code snippets, or actions, on OpenWhisk.
OpenWhisk introduces the concepts of Triggers, Actions, and Rules.
Triggers are a class of events emitted by event sources.
Actions encapsulate the actual code to be executed which support multiple language bindings including Node.js, Swift and arbitrary binary programs encapsulated in Docker Containers. Actions invoke any part of an open ecosystem including existing Bluemix services for analytics, data, cognitive, or any other 3rd party service.
Rules are an association between a trigger and an action.
Cloud Foundry vs. OpenWhisk
So the question remains: when should you use Cloud Foundry, or when should you use OpenWhisk?
In my limited experience using OpenWhisk, here are my thoughts. I like to think of OpenWhisk as an easily implementable automatically scaling architecture that application developers can use without needing much prior knowledge in backend development. I think of Cloud Foundry as a lower level in the software stack which might give you more customization, but will likely take more skill and knowledge for setting it up.
I would use Cloud Foundry if I...
Was a backend & application developer.
Had experience creating and connecting services together.
Needed functionality that just might not be possible using OpenWhisk.
I would use OpenWhisk if I...
Was an application developer.
Didn't want to worry about a server.
Didn't want to learn different programming languages, etc. to figure out how to set up my server.
Really wanted focus on developing my application and have the backend just work.
Hope that helped.
Edit:
Here's a cool image that I found that illustrates this:
CloudFoundry is a PaaS (Platform-as-a-service) platform, which means in a nutshell, that it hosts the platform for your application to run on. Examples of a platform include node.js or a JVM.
OpenWhisk is a serverless platform. The term FaaS (Function-as-a-service) seems to be emerging as well. You upload code, which is executed once an event happens. That event might be anything, ranging from a simple HTTP request to a change happening in your database.
The fundamental difference between the two is the mode of operation. PaaS means, you're still running a server-process. You'll have a long running process which listens to events and executes your logic, once an event happens. All the other time, the process is idle, still requiring CPU cycles and memory to actually listen for events.
In serverless, the platform takes the burden of "listening for events". Once an event happens, your code is instantiated and executed. That code is shutdown afterwards thus not requiring any resources anymore. That also explains why OpenWhisk actions have a time limitation of 5 minutes. It is not meant to have long running actions.
Disclaimer: Both platforms support a lot more than I described here, I tried to keep it down to the most substantial difference between the both.
I am new to Jboss, want to know if micro services architecture is a right choice on JBOSS. I cannot change the application server as it is decided by client architect and I have no choice.
Want to know whether we can develop micro services with underlying JBOSS application server.
I understand Spring boot comes with embedded tomcat container, which makes it flexible to stop and start, deploy individual service with no impact to other services.
However will that architecture works with JBoss too.
Please suggest.
Thanks,
I actually developed a feasibility study to investigate the solution you mentioned. My conclusion is that it is totally viable to use Micro Service principles in a JBoss Platform.
I used the combination of JBoss \ Spring Boot \ Netflix to create successful Micro Service stack, I personally do that to find a solution to the transaction problem (multiple micro services collaborating) and the fan out problem which caused because excessive Network communication and Serialization costs.
I also wrote a blog about the subject, you might find more details there if you like to, here is the link.
Micro Services – Fan Out, Transaction Problems and Solutions with Spring Boot/JBoss and Netflix Eureka
By the definition what micro services are, then conceptually yes. A micro service is a service that is an independent unit, it could deployed, updated, and undeployed independently without affecting any unrelated part of your application. So that would mean having multiple instances of JBoss for MS and your application calling them through some sort of gateway or any other mechanism depending on your use case. If you plan to deploy all your MS in the same JBoss instance then it defeats the very purpose of a MS. Given that, JBoss wouldn't be a right choice for MS deployment because it will only make your MS deployment infrastructure quite heavy.
Depending on what your client's requirements are, your could possibly keep your webapp in JBoss and deploy your MS containers separately.
It depends on what you want to get out of microservices.
Some of the developers at my organisation looked at Spring Boot but concluded that it's best off being run as a standalone container rather than in JBoss, otherwise you've effectively got two container frameworks competing (SB and JBoss) and a range of associated issues.
Deploying microservices in JBoss won't give you the same flexibility as a true container system like Docker. With Docker you create standalone packages for your microservices that contain all the code, system tools, runtime environment, etc. It can be as small or large as it needs to be. JBoss on the other hand is a large container running a single JVM designed to hold multiple applications. The level of isolation is not the same, and it's not efficient to have JBoss as a container for a single microservice so you have to appropriately size and then deploy to the instance to make use of the resources it has available.
If you're looking at microservices as a way to gain greater control over service lifecycle management (deployment, versioning, deprecating, etc.) as opposed to an automated, web-scale component deployment model a la Netflix or LinkedIn, you could do this adequately with JBoss.
I'm actually looking to do something along these lines here. It won't be true microservices but by packaging and deploying individual, properly versioned APIs rather than monolithic applications and following most of the other principles of microservice development (componentisation, business function focus, stateless etc.) we will be hopefully better able to manage and benefit from our APIs.
Our APIs will all be behind an API gateway and load balancer so we can choose how we distribute the microserves distributed across the JBoss instances and balance resource usage as required. Note that our organisation is relatively small and has relatively low and predictable traffic so this approach should work fine. Your needs however may be different.