Which would you choose? Or should you be choosing at all?
Introduction
These days, you can’t go to a Microsoft conference where the question of “What is the difference between Microsoft Flow and Azure Logic Apps?” isn’t asked. For many people, they think the answer is binary; you need to use one or the other. While people have preferences, and perhaps even biases, it is important not to rule the other technology out, as you are likely missing out on opportunities for your organization.
When Microsoft has answered the Azure Logic Apps vs. Microsoft Flow question in the past, personas generally played a role in deriving an answer. When it comes to “Power users” or even “Citizen Developers,” Microsoft Flow is generally identified as the tool of choice, in part due to it being the targeted audience for why the tool was created.
For one of our clients who is a very big player in medical device development, we had to develop a solution which will be easily deployable in the cloud or on-premise infrastructure. So, as you might suspect, we knew that we will work with containers.
There was no discussion of containerization technology, so Docker first and Docker Compose second.
Hello developers and software designers. I'm writing this article to open a discussion about the idea of developing a skeleton for Xamarin applications with pluggable components and services. I've finished writing a technical document after we — as a team — finished delivering a line-of-business mobile application to oen of our clients. We planned from the beginning to shape a skeleton inside this project that can help us later with the next projects. Let's share it with you.
This is a technical article that demonstrates the architecture and designs used to implement the desired features. I tried to illustrate each piece of code, designs, thoughts, and decisions visually with diagrams.
In this article, we are going to see how to restart the Azure web app using Azure Logic App. I am assuming that you know about Azure Logic Apps. If you want to read more about Azure Logic Apps, check out this article.
Looking to build a next-generation smart application?
Well, if that’s the case, then IoT can help you achieve that. IoT applicationscan make the lives of organizations and enterprises easier in various ways, including increased protection of data and improved, secure ways of informing users about accidents, theft, or breaches.
The Azure team at Microsoft (myself included) has been strengthening its commitment and outreach to the Java EE community and customers. A few months ago, I ran a study with the community and customers to understand how Java EE developers move to the cloud. One of the interesting findings of the study is that Java EE developers like to see migration guides that speak to their use case from cloud providers like Microsoft. Following up on these findings, the team is now developing just such guidance that hopefully speaks to you, starting with Linux virtual machines and Kubernetes.
The idea is to target Azure migration of major Java EE application server workloads (such as WebSphere ND, WebSphere Liberty, WebLogic, JBoss EAP, and WildFly). The guidance will likely include online documentation, ARM templates, Azure Marketplace solutions, Docker images, Helm charts, samples, workshops, talks, and so on. All the materials will be developed completely in open source so customers and the community can contribute at any point.
Azure Functions V2 supports ASP.NET Core functions like dependency injection. It is especially good if we write wrapper functions for shared libraries and components we are also using in web and other applications of our solution. This blog post shows how to use dependency injection in Azure Functions.
"Intelligence is the ability to adapt to change." These are words from the great Stephan Hawkins and can justly encapsulate the core meaning of the Agile concept which has revolutionized the way we conceptualize and produce software. The tech industry has gone through sweeping changes that have resulted in expeditious software production. Gone are the days where software teams would spend months and even years to deliver on new features to improve the experience of their customers. Now, changes can be implemented in a matter of weeks, if not days. A major push towards the change has been due to the maturing of cloud services and CI/CD practices.
Serverless is the latest trend in cloud computing, a technological concept that, if understood and implemented properly, is one that can further our movement towards true Agile development. Therefore, the aim of this piece is to revisit the core concept of Agile, go through the developments in the tech industry and highlight the future of Agile with serverless as a practical base.
As we demonstrated in Part 1 of the series, running on the cloud is not only for cool new applications following twelve-factor principles and coded to be cloud-native. In the first article, we demonstrated how to migrate a legacy Java Spring application to run on Azure App Service and how to address handling JNDI, credentials, and externalizing the configuration. In this article, we will show to enable logging, and monitoring to use Azure native capabilities. The full application example is available on Github.
Application Insights
Application Insights is an extensible Application Performance Management (APM) service helping to monitor web applications. It will automatically detect dependencies such as HTPP or JDBC calls and includes powerful analytics tools to help you diagnose performance issues. For more details, refer to Microsoft's Getting Started Guide.
Enterprises across all industries, sizes and geographies have been tapping into the power of the cloud. Gaining widespread use over the last few years, cloud computing has made it easier for businesses to get an edge in the digital age. Gartner survey predicts cloud computing as a $300 billion business by 2021. More and more companies are recognizing the business advantages of cloud computing and leveraging it to run their organizations efficiently, better serve their customers and increase profit margins.
Cloud computing boosts cost efficiency, promotes collaboration, aids disaster recovery, increases mobility and provides flexibility for businesses. If you are planning to migrate your virtualized workload to the cloud, then it is crucial to choose a Cloud Service Provider (CSP) that can best match your business, operational, security and compliance needs.
Are you looking to get started with the world’s most popular open-source database and wondering how you should set up your MySQL hosting? So many default to Amazon RDS when MySQL performs exceptionally well on Azure Cloud. While Microsoft Azure does offer a managed solution, Azure Database, the solution has some major limitations you should know about before migrating your MySQL deployments. In this post, we outline the best way to host MySQL on Azure, including managed solutions, instance types, high availability replication, backup, and disk types to use to optimize your cloud database performance.
The first thing to consider when weighing between self-management and a MySQL Database-as-a-Service (DBaaS) solution is what internal resources you have available. If you’re reading this, you likely already know the magnitude of operational tasks associated with maintaining a production deployment, but for a quick recap, there’s provisioning, de-provisioning, master-slave configurations, backups, scaling, upgrades, log rotations, OS patching, and monitoring to name a few.
It is not unknown to SQL users that some of the SQL Server versions have become outdated. This is the main reason why most of the SQL Server users are migrating to Azure. Along with this, many are also moving to Azure due to its unique features. If you are switching platforms, you may also need to import the local SQL Server database to Azure. In this post, we will discuss two different approaches for the migration from on-premises SQL Server to Azure SQL database.
"Hello, all. I am writing here as I am in need to know the method to import data from SQL server to Azure. I have tried moving the database using the manual method, but that was unsuccessful as various issues came up. Please suggest me some effective method to perform this database migration smoothly and successfully."
Ready to transition from a commercial database to open source, and want to know which databases are most popular in 2019? Wondering whether an on-premise vs. public cloud vs. hybrid cloud infrastructure is best for your database strategy? Or, considering adding a new database to your application and want to see which combinations are most popular? We found all the answers you need at the Percona Live event last month, and broke down the insights into the following free trends reports:
Every container you run in Kubernetes is going to be generating log data. No one has time to go through and regularly check individual container logs for issues, and so in production environments, it is often required to export these logs to an aggregator for automated analysis.
If you're using Azure, then Log Analytics may be your log aggregator of choice, and so you need a way to export your container logs into Log Analytics. If you are using AKS, you can deploy the Azure Monitor solution which does this for you, however, if you are running your own cluster, or even using another cloud provider and still want to use Log Analytics, then that it's not quite so simple. This is where Fluent Bit can help.
Deploying a React app to Microsoft Azure is simple. Except that... it isn’t. The devil is in the details. If you're looking to deploy a create-react-app — or a similar style front-end JavaScript framework that requires pushState-based routing — to Microsoft Azure, I believe this article will serve you well. We’re going to try to avoid the headaches of client and server side routing reconciliation.
First, a quick story.
Back in 2016, when Donovan Brown, a Senior DevOps Program Manager at Microsoft, had given a "but it works on my machine speech" at Microsoft Connect that year, I was still in my preliminary stages as a web developer. His talk was about micro-services and containers.
[...] Gone are the days when your manager comes running into your office and she is frantic and she has found a bug. And no matter how hard I try, I can't reproduce it and it works perfectly on my machine. She says: fine Donovan, then we are going to ship your machine because that is the only place where it works. But I like my machine, so I'm not going to let her ship it...
I had a similar sort of challenge, but it had to do with routing. I was working on a website with a React front end and ASP.NET Core back end, hosted as two separate projects that were deployed to Microsoft Azure. This meant we could deploy both apps separately and enjoy the benefits that comes with separation of concern. We also know who to git blame if and when something goes wrong. But it had downsides as well, as front-end vs. back-end routing reconciliation was one of those downsides.
One day I pushed some new code to our staging servers. I received a message shortly after telling me the website was failing on page refresh. It was throwing a 404 error. At first, I didn’t think it was my responsibility to fix the error. It had to be some server configuration issue. Turns out I was both right and wrong.
When building a React app for production (assuming we’re are using create-react-app), it’s worth noting the folders that get generated. Running npm run build will generate a build folder where an optimized static version of the application lives. To get the application on a live server, all we need do is feed the server the content of the build folder. If we were working on localhost, there is no live server involved, so it is not always equivalent to having the application on a live server.
Generally, the build folder will have this structure:
→ build
→ static
→ css
→ css files
→ js
→ js files
→ media
→ media files
→ index.html
→ other files...
Client-side routing with React Router
React Router uses the HTML5 pushState history API internally. What pushState does is quite interesting. For example, navigating (or using Link in react router) from the page https://css-tricks.com to the page https://css-tricks.com/archives/ will cause the URL bar to display https://css-tricks.com/archives/ but won't cause the browser to load the page /archives or even check that it exists. Couple this with the component-based model of React, it becomes a thing to change routes while displaying different pages based on those routes — without the all-seeing eye of the server trying to serve a page in its own directory. What happens, then, when we introduce servers by pushing the code to a live server? The docs tell it better:
If you use routers that use the HTML5 pushState history API under the hood (for example, React Router with browserHistory), many static file servers will fail. For example, if you used React Router with a route for /todos/42, the development server will respond to localhost:3000/todos/42 properly, but an Express serving a production build as above will not. This is because when there is a fresh page load for a /todos/42, the server looks for the file build/todos/42 and does not find it. The server needs to be configured to respond to a request to /todos/42 by serving index.html.
Different servers require different configuration. Express, for example, requires this:
...as documented in the create-react-app docs. Keep in mind though, this assumes that we’re hosting create-react-app at the server root, which is making use of a wildcard route (*) that catches all route and respond to all route request by serving the index.html file in the build folder which sits at the root of the server application. Also, this is tightly coupled with the back-end. If that’s the case, we would most likely have this kind of folder structure (assuming the back-end is in NodeJS):
→ Server
→ Client (this is where your react code goes)
→ build (this is the build folder, after you npm run build)
→ src
→ node_modules
→ package.json
→ other front-end files and folders
→ Other back-end files and folders
Since my front-end (create-react-app) and back-end (ASP.NET) were two different projects, serving static files by navigating the directory was sort of an impossibility.
In fact, since we are deploying a static app, we do not need the back-end. As Burke Holland put it: "Static" means that we aren’t deploying any server code; just the front-end files.
I keep mentioning ASP.NET here because during the course of my research, I figured configuring Azure required a configuration file in a wwwroot folder and ASP.NET's folder structure typically has a wwwroot folder. Remember the application’s back-end was in ASP.NET? But that’s just about it. The wwwroot folder seemed to be hidden somewhere on Azure. And I can’t show you without deploying a create-react-app. So let’s go do that.
Getting started with App Services on Microsoft Azure
Navigate to All services → Web → App Services
Navigating on the Azure portal from All services, to Web, to App services
We want to add a new app, give it a name, subscription (should be free if you’re on a free trial, or if you already have one), resource group (create one or use existing), then click on the Create button down at the bottom of the panel.
We should get a notification that the resource has been created. But it won’t immediately show up, so hit "Refresh" — I have other resources, but the AzureReactDemo2 is what I’m using here. You’ll click on the name of your newly created app, which is AzureReactDemo2 in my case.
The blade shows you information about your app, the navigation to the left has everything you need to manage your application (overview, activity log, deployment center...).
For example, the DeploymentCenter is where the app deployment is managed, Slots is where things like staging, production, test are managed. Configuration is where things like environmental variables, node versions and — an important one — Kudu are managed.
The overview screen shows a general view of the application Status, URL... Click on the URL to see the live site.
The app is up and running!
What we’ve done is create a new App Service, but we have none of our code on Azure yet. As said earlier, all we need to do is to feed Azure the content of the build folder generated by building React for production, but we don’t have one yet. So let’s go local and get some React app.
npx create-react-app azure-react-demo
cd azure-react-demo
We also want to install react-router (react-router-dom, actually)
npm i react-router-dom
All things being equal, starting the app with npm start, we should get the default page.
Because this will be about testing routes, I needed to make some pages. I’ve modified my local version and uploaded it to GitHub. I’m banking on the fact that you can find your way around react and react-router. Download a demo.
My folder looks like this:
The changed files have the following code:
// App.js
import React, { Component } from "react";
import "./App.css";
import Home from "./pages/Home";
import Page1 from "./pages/Page1";
import Page2 from "./pages/Page2";
import { BrowserRouter as Router, Switch, Route } from "react-router-dom";
class App extends Component {
render() {
return (
<Router>
<Switch>
<Route exact path="/" component={Home} />
<Route path="/page1" component={Page1} />
<Route path="/page2" component={Page2} />
</Switch>
</Router>
);
}
}
export default App;
Running the app works locally, so the routes deliver when links are clicked and even when the page is refreshed.
Deploy the app to Azure
Now, let’s get it up on Azure! There are a few steps to make this happen.
Step 1: Head to the Deployment Center
On Azure, we need to go to the Deployment Center. There are quite a few options each with its pros and cons. We’ll be using Local Git (which means your local git app straight directly to Azure) for source control, Kudu for Build Provider.
Remember to click continue or finish when you select an option, or else, the portal will just keep staring at you.
After the third step, Azure generates a local git repo for you. And it gives you a remote link to point your react app to.
One thing to note at this point. When you push, Azure will ask for your GitHub credentials. It is under the deployment tab. There are two: App and User. App credential will be specific to an app. User will be general to all the apps you as a user has Read/Write access to. You can do without User Credentials and use App credentials, but I find that after a while, Azure stops asking for credentials and just tells me authentication failed automatically. I set a custom User Credentials. Either way, you should get past that.
In the React app, after modification, we need to build for production. This is important because what we want to upload is the content of the build folder.
We need to tell Kudu what node engine we’ll be using, or else, the build will most likely fail,
due to the reported fact that react-scripts requires a node version higher than the default set on Azure. There are other ways to do that, but the simplest is to add a nodes engine in package.json. I’m using version 10.0 here. Unfortunately, we can’t just add what we like, since Azure has Node versions it supports and the rest are unsupported. Check that with the CLI with the command: az webapp list-runtimes
Add the preferred node version to the package.json file, as in:
"engines": {
"node": "10.0"
}
Step 2: Build the App
To build the React app, let’s run npm build in the Terminal.
Step 3: Initialize the Git repo
Navigate into the build folder and initialize a Git repo in there. The URL to clone the repo is in the overview page. Depending on what credentials you’re using (App or User), it will be slightly different.
Now, visit the live app by using the URL on the overview page. As you can see, the app fails on /page2 refresh. Looking at the network tab, a 404 is thrown because the page tried to be fetched from the server — with client-side routing, as we have already set up, the page shouldn’t even be server fetched at all.
Configuring Azure to reconcile client and server side routing
In the public folder, let’s add a web.config XML file with the following content:
I’ve intentionally decided to not format the code snippet because XML is strict about that. If you miss the formatting, the file has no effect. You can download an XML formatter for your text editor. For VSCode, that would be the XML Tools plugin.
The app can be built again at this point, although we’ll lose the Git info in the build folder since the new build overrides the old build. That means it would have to be added again, then pushed.
Now the app works as shown below! Whew.
We don’t want to have to npm run build every time — that’s where continuous deployment comes in. Check out the link below for appropriate references.
Conclusion
There is a lot to Azure, as it can do a lot for you. That’s nice because there are times when you need it to do something that seems super specific — as we’ve seen here with client and server side routing reconciliation — and it already has your back.
That said, I’ll leave you with a couple of related resources you can turn to as you look to deploying a React app to Azure.
If you are deploying SQL Server in Azure or any Cloud platform for that matter, instead of just provisioning storage like you did for your on-premises deployments for many years, you may consider that storage in Azure isn't exactly like the storage you may have had access to on-premises. Some traditional "best practices" may wind up costing you additional money and give you less than optimal performance, all while not providing you any of the intended benefits. Much of what I am about to discuss is also described in Performance Guidelines for Azure in SQL Server Virtual Machines.
I'm not here to tell you that you must use UltraSSD, Premium Storage, or any other disk type. You just need to be aware that you have options and know what each disk type brings to the table. Of course, like anything else in the cloud, the more money you spend, the more power, speed, throughput, etc. you will achieve. The trick is finding the optimal configuration so that you spend just enough to achieve the desired results.
Building upon my earlier post, today, I wanted to share with you updated graphics and links for the analytic and big data services offered by Microsoft Azure and Amazon Web Services.
It is my hope that this post will be a starting guide for you when you need to research these analytics and big data services. I have included relevant links for each service, along with some commentary, in the text of this post below. I’ve done my best to align the services, but there is some overlap between offerings.