I am trying to a good comparison between AppDynamics and Application Insights in regard to Azure App Service.
I tried to google around but couldn't find any good comparison, if someone can point me or summarize here.
Information I got from another website.
Application Insights (AI) is a very simplistic APM tool today. It does do transaction tracing, it has very limited code and runtime diagnostics, and it doesn’t go very deep into analyzing the browser performance. Application Insights is much more like Google Analytics than like a typical APM tool.
AI does not support mobile apps, AppDynamics does Android and iOS
AI only supports Java, .NET, and node.js while AppDynamics supports many
additional languages and technologies.
AI requires code changes to do additional metric capture from the
code. AppDynamics has do this on the fly without code change on most
languages.
AI doesn’t so transaction distributed tracing, it has a simple data
collection model similar to what New Relic does. This makes
troubleshooting much harder in complex apps. If your app is simple
it’s not required.
AI lacks transaction scoring and baselining, you must set manual
thresholds. AppDynamics does this for every metric and every business
transaction.
AI doesn’t monitor databases or data stores. AppDynamics does both.
AI is SaaS only, while AppDynamics can be deployed on premises or
SaaS.
Related
While googling for the confusion of mine, I didn't found the satisfactory resource.
so the question which I was searching for was, What is the difference between offline-first approached mobile apps and PWAs.
As to my level of understanding any mobile app lets say; a react-native app with redux in use or with SQLITE or with realm can be made as a offline-first approached app.
And with PWAs the service worker(of which i have less knowledge) makes all the offline user-interaction and at last when the net connectivity is confirmed the data is fetch or retrieved as required by PWAs.
Though I am not mentioning about other features PWAs can perform(again of which I have less knowledge). And even when the modern browser can only support for PWAs, why there is a hype of PWAs in todays trends?
Please guide me through with any mistake with my question. Any kind of information, knowledge or link to answer my query is much appreciated.
You can read the first of a series of articles about PWAs to get more details about PWAs features and their benefits.
The two concepts are not mutual exclusive. PWAs, thanks to the Service Worker and caching strategies, are able to implement/provide an offline first approach by caching target assets or data responses.
You can however provide an offline first approach also by using other technologies, without introducing a PWA.
The hype behind PWAs is due to the many extra functionalities we can add to a web app, making it behave and look like a native solution. Think just to the advantages of having your frontend team developing a web app that with very little efforts seems almost entirely a native app. And this without having to hire a dedicated native team (iOS/Android).
However PWAs are not the silver bullet for any scenario. They still have limitations that only native apps can provide (eg. SMS capabilities and accessing to the device contacts), even if there are different APIs that aim to solve these gaps, like Google Contact Picker API.
Most of the major apps till recent times was targeted towards countries having decent internet connections. With access to internet spiking in developing countries, most untapped market is coming to light. Though these parts have internet access now , the connectivity problems are plenty. So, to give the best experience for this new brand of customers, we need apps that can run offline
Offline First Approach :
This approach mostly caters to any device which can run offline until a reliable connection is interfaced. As developers , this would mean build the capabiltity to store information in the device through databases, caches or any other local storage approach.
And then when the user opens the app (desktop/mobile) , these run as normal as possible. Just give the user a heads-up that it is not in sync with the latest.
So, an offline first approach can be
Android native app with an offline capability
IOS App w/ offline features
Internet dependent Desktop app w/ offline support
WebApp w/ offline functionality : PWA is the latest
PWA (Progressive Web Apps) :
A PWA is a Web App which has the capability to run offline. With low cost devices (memory deficient, low processing power ) used by many of these users, it's imperative that people installing new native apps will reduce. Also, it's hard to convince people to download and install a new app.
That is where a Web app can be the game changer. A Progressive Web App which has native experience and offline capabilities could drive more users to try a new offering. Adding to that, without forcing a user to install one more app , a link can be easily marketed.
A Progressive Web App is a subset of the offline first approach. With browsers adding more capabilities to access native functions like Contacts as #Francesco pointed out , PWA might will be the first step towards modern app development to release any new feature.
I am exploring ways to improve some of our processes and applications using microsoft tools and more specifically the Custom Vision Cognitive Service. However, i am getting lost in the MS offerings and the Preview AI Builder service in PowerApps which seems to be offering the same capability.
The test that I am trying with both services i using Products pictures and utilize the services to provide me with the brand, sub-brand and some other specifications on the product. To start with, i have started with the browser version of the Custom Vision service (not the SDK) which, because it is a non-programmer interface, is really similar to the AI builder.
Has someone more inputs on the strategy behind the AI Builder in Powerapps and how it complements/replaces some of the capabilities of the MS cognitive services (and more specifically their browser/non-programmer versions)?
In a few words, tools in PowerApps (like in Microsoft Flow or even Logic Apps) are backed by other (more technical) services provided by Microsoft (or third party).
PowerApps and Flow are solutions designed to be used by non-developer people: understanding the technical behaviour / implementation is not needed.
Using AI Builder service in PowerApps vs Custom Vision: generally, there may be a delay between new technical features and the time they are provided in those tools for example. Some features are also never available in "business" versions.
I am evaluating wep api gateway for my new projects. I used azure api gateway in the past. Reading about nginx as it is new and adopted by many. Can someone help me point out with some facts, pros, cons? Bug matrix will be a best help for me
Azure API Management is a mature and widely-used product, with many customers being very respected enterprises. Take a look at some public case studies.
It offers a very wide range of features, which are typical of an API management platform, and it is still being very actively developed. However, one of its biggest strengths lies in integration with Microsoft Azure services and features - multiregional deployments, virtual networks, monitoring and alerting solutions, native support for Service Fabric, Azure Function Apps and Azure Logic Apps, Azure Active Directory and others.
If you are considering hosting your new projects with Microsoft Azure, Azure API Management is a no-brainier.
The product is also one of the main reasons why Gartner named Microsoft a leader in the enterprise integration space.
Disclaimer: Although all of the above is best to my knowledge, I am affiliated with Azure API Management.
Although I have just started looking into this myself, here's what I can already conclude.
Looking at www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/, Nginx requires a lot of manual configuration washed over many text files. That doesn't look flexible or effective, but I may have gotten a wrong impression.
Judging by how you're supposed to define your API keys using the map directive, Nginx API Gateway also looks like a new idea stretched on top of the existing product, while Azure API was designed for that exact purpose from the ground up.
Azure APIs, when published, come with auto-generated documentation and an interactive console that are in sync with all your updates.
With Azure API, you're putting all your eggs into one basket and completely depending on it's pricing and availability. At any moment Microsoft can increase their prices, or discontinue the product, and you cannot migrate elsewhere, at least not easily/quickly. At the same time, you can do your Nginx work once and run it on pretty much any server, starting with a low-end VPS or a Raspberry PI, if you'd like. It's pretty much yours.
I need to get hardware information from azure web roles / web worker to monitor it for critical conditionals like high memory/cpu usage.
I tried to use some addons which are provided in the azure gallery like the one from "logentries", but the gallery doesn't support my country yet...
Is there an other way to get the log information directly?
Last option would be Azure Diagnostics, but it stores everything in blob storages and I would have to pull everything out there on my own and send it to "manually" to logentries, geckoboard or whatever.
Three good options:
Windows Azure Diagnostics. Yes, it puts everything in table/blob storage which is painful, but there are tools such as Cerebrata's Azure Management Studio that can help gather and visualize the data.
Application Insights. This is still in preview, but it provides a very rich application monitoring and alerting platform.
The built in Azure monitoring. This is not quite as feature rich as Application Insights, but it is very easy to setup and use and includes monitoring and alerting.
I'm surprised that no one mentioned New Relic.
It has a comparable feature set to Application Insights but should be way more stable since it's not in preview like Insights. (although I am following the development of Insights closely, give it a while and it will be an awesome alternative)
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.