Building Data Science Team

 From the book: http://www.datascienceassn.org/sites/default/files/Building Data Science Teams.pdf

A data-driven organization acquires, processes, and leverages data in a timely fashion to create efficiencies, iterate on and develop new products, and navigate the competitive landscape.

Author wrote also:

There are many ways to assess whether an organization is data driven. Some like to talk about how much data they generate. Others like to talk about the sophistication of data they use, or the process of internalizing data. I prefer to start by highlighting organizations that use data effectively.

See also: altexsoft.com blog post on datascience: how-to-structure-data-science-team-key-models-and-roles

What was my Wifi password?

If you have a Wifi connection on your Laptop and you need to know the password for it follow the next steps in a DOS command line:

netsh wlan show profile

This will show the known profiles. Copy the name of any profile you need to know its password.
Then call the next command to see the password in clear text:

netsh wlan show profile <name> key=clear

What is my IP-number in Azure

When you send a request to somewhere that uses your ip-number to whitelist, your ip number becomes important to know.
It is pretty simple when you do this on your laptop where you can open up a browser and find your outbound ip-number in Google. When you run your request within an Azure Web App which is running on an ASP, you might want to open up a console in Azure Portal and use the following PowerShell command:

(Get-AzWebApp -ResourceGroup <group_name> -name <app_name>).OutboundIpAddresses 

See also: find-outbound-ips

How to Ping in Azure Console

Source: https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet 

Tools

The tools ping, nslookup, and tracert won't work through the console because of security constraints. To fill the void, two separate tools are added. To test DNS functionality, we added a tool named nameresolver.exe. The syntax is:

ameresolver.exe hostname [optional: DNS Server]

You can use nameresolver to check the hostnames that your app depends on. This way you can test if you have anything misconfigured with your DNS or perhaps don't have access to your DNS server. You can see the DNS server that your app uses in the console by looking at the environmental variables WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER.

You can use the next tool to test for TCP connectivity to a host and port combination. This tool is called tcpping and the syntax is:

tcpping.exe hostname [optional: port]

The tcpping utility tells you if you can reach a specific host and port. It can show success only if there's an application listening at the host and port combination, and there's network access from your app to the specified host and port.

Additional debug steps include:

• Connect to a VM in your virtual network and attempt to reach your resource host:port from there. To test for TCP access, use the PowerShell command test-netconnection. The syntax is:

  1 test-netconnection hostname [optional: -Port]

• Bring up an application on a VM and test access to that host and port from the console from your app by using tcpping.

Think before going Microservices

The goal of microservices is to sufficiently decompose the application in order to facilitate agile application development and deployment.

The following is based on the book Microservices from Design to Deployment from NGINX. My goal is to know the difficaulties that this inevitable is bringing with in order to be prepared for.

The Drawbacks of Microservices

1. One drawback is the name itself. The term microservice places excessive emphasis on service size. While small services are preferable, it’s important to remember that small services are a means to an end, and not the primary goal.
   
   

2. Another major drawback of microservices is the complexity that arises from the fact that a microservices application is a distributed system. Developers need to choose and implement an inter-process communication mechanism based on either messaging or RPC. Moreover, they must also write code to handle partial failure, since the destination of a request might be slow or unavailable.
   
   

3. Another challenge with microservices is the partitioned database architecture. Using distributed transactions is usually not an option, and not only because of the CAP theorem. They simply are not supported by many of today’s highly scalable NoSQL databases and messaging brokers. You end up having to use an eventual consistency-based approach, which is more challenging for developers.
   
   

4. Testing a microservices application is also much more complex. A simple test class for a service
   would need to launch that service and any services that it depends upon, or at least configure stubs for those services.
   
   

5. Another major challenge with the Microservices Architecture pattern is implementing
   changes that span multiple services. Fortunately, most changes typically impact only
   one service; multi-service changes that require coordination are relatively rare.
   
   

6. Deploying a microservices-based application is also much more complex.
   
   

7. Each service will have multiple runtime instances. That’s many more moving parts that
   need to be configured, deployed, scaled, and monitored. In addition, you will also need to
   implement a service discovery mechanism that enables a service to discover the locations
   (hosts and ports) of any other services it needs to communicate with.